Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Как объяснить разработчику, кто такой тестировщик
28.08.2017 00:00

Оригинал статьи: http://katrinatester.blogspot.ru/2017/04/introducing-testers-to-developers.html

Автор: Катрина Клоки (Katrina Clokie)

Перевод: Ольга Алифанова

Когда я заканчивала учебу на программиста, я создавала ПО без помощи тестировщиков. Под конец обучения я начала искать позицию разработчика, плохо разбираясь, с какими еще профессионалами мне придется сотрудничать в IT. Я не знала, кто такие тестировщики, чем они занимаются, и чем именно могут мне помочь. Думаю, я не одинока: в том же положении оказываются многие начинающие разработчики.

На моей первой работе тестировщиков не было. Проведи я там больше времени – и я умудрилась бы стать опытным разработчиком, не имеющим ни малейшего понятия о профессии тестировщика. Компаний, создающих ПО без участия специально обученных тестировщиков, довольно много – то есть в моем положении оказываются и многие опытные разработчики.

Разработчики, которые никогда не работали с тестировщиками, скорее всего, понимают, что такое тестирование – но понимают его как вид деятельности, а не как роль в команде. Тестирование – часть их работы, а не задача специальных людей. Зачем отдавать тестирование в чужие руки, если разработчик и сам прекрасно справится с созданием и выпуском качественного ПО?

Если вы разработчик и думаете примерно так, встреча с тестировщиком может вызвать у вас затруднения. Попробую представить его вам через аналогию.

Тестировщиков нет

Шеф-повар ресторана создает еду, которая поставляется клиенту. Качество определяется навыками шеф-повара, качеством ингредиентов и практиками, которым шеф следует.

Во многих ресторанах еда готовится, поставляется к столу и затем съедается. Самая ранняя обратная связь поступает шеф-повару от клиента. В случаях, когда клиент недоволен, решить вопрос, как правило, довольно сложно – ущерб уже нанесен.

Тут можно провести параллель с разработкой ПО без тестировщиков. Качество определяется навыками разработки, качеством платформы, и принятыми практиками. Обратная связь поступает от пользователя, который может и не простить ошибки.

Рестораны могут вполне преуспевать, работая по этой модели – как и компании, занимающиеся разработкой ПО.

Тестировщик в водопадной модели

В студенчестве я работала официанткой на полставки. В одном из ресторанов, где я работала, менеджер пользовался небольшой рабочей станцией, расположенной прямо перед двойными дверьми на кухню.

Шеф-повар этого ресторана отличался лихим темпераментом и оборонял свою территорию как лев, поэтому менеджер редко забегал на кухню. Однако во время подачи еды она часто останавливала официантов, несущих блюда из кухни за столики.

Если блюда для столика доводились до готовности в разное время, она придерживала официантов, пока все заказанные блюда не были готовы. Если блюдо плохо выглядело на тарелке, она исправляла эту оплошность. В тех редких случаях, когда ей не нравился размер порции или качество еды, она возвращала тарелку на кухню.

Шеф-повар бесился, когда ему возвращали еду, и часто перетруждался, исправляя ошибку. Что, порция свинины в кисло-сладком соусе была маловата? Ах так, ну теперь целый час все будут получать порции в двойном объеме! Однако постепенно он успокаивался и возвращался к более приемлемым размерам порций.

Если подумать, менеджер ресторана был первым моим столкновением с тестировщиком как отдельной ролью. После окончания разработки она исследовала финальный продукт. Смотря на него свежим глазом, она подмечала проблемы, упущенные кухней.

Менеджер ресторана вкладывалась в качество продукта – что-то подправляла сама, а о чем-то сообщала шеф-повару, чтобы ошибку исправил он. Он не всегда доброжелательно на это реагировал, но проблемы исправлял, и это улучшало жизнь нашим клиентам.

Тестировщики ПО действуют точно так же – они смотрят на программу незамыленным взглядом, дают быструю обратную связь человека с ориентацией на клиента, и могут самостоятельно поправить какие-то мелочи, чтобы улучшить пользовательский опыт работы с ПО.

Тестировщик в Agile

Менеджер ресторана улучшала качество готового блюда. Но что, если существует способ улучшить еду в то время, пока она еще готовится? В этом случае шеф-повар может сориентироваться во время работы над блюдом, а не исправлять готовый продукт.

Иногда несколько элементов блюда готовятся одновременно. Шефу тяжело уследить за всем подряд, и что-нибудь да пригорит. Что, если кто-то другой установит таймер, заметит, если время приготовления нарушается, и вмешается в процесс?

Иногда ингредиенты блюда похожи друг на друга, и их легко спутать. На этой неделе я готовила еду, используя две специи – смесь специй с тажином и с кускусом. Что было бы, если бы кто-нибудь заметил, что я открыла не тот пакет специй, и сообщил мне об этом?

Иногда от блюд требуется постоянство качества. Как шефу убедиться, что крем-брюле, приготовленное сегодня, идентично приготовленному вчера? Что, если кто-нибудь еще смог бы проверить рецепт, размер порции и презентацию блюда на тарелке и убедиться, что все они соответствуют некоему минимальному стандарту?

Гипотетически, это разумные меры. В реальности шеф-повар, предпочитающий готовить в одиночку, воспримет это как ночной кошмар. Он скорее согласится выбросить пригоревшую или странную на вкус еду, чем пустить посторонних в свое царство.

Тут можно провести параллель с тестировщиком, работающим по Agile-методологии. Успех в ней зависит от сотрудничества, которого трудно добиться. Разработчиков бесит обратная связь от тестировщиков, особенно тогда, когда они к ней не привыкли. Тестировщику придется объяснять и демонстрировать, как именно они вкладываются в улучшение финального продукта.

Разработчику зачастую трудно адаптировать свой подход под Agile и адекватно воспринимать обратную связь. Если информация, полученная от тестировщика, нерелевантна, поступает поздно, или неконструктивно изложена, они должны сообщить об этом. Налаживание взаимовыгодных партнерских отношений требует времени и сил от обеих сторон.

Любой тестировщик

Неважно, по какой методологии работает тестировщик – все они хотят помочь создать наилучший продукт для пользователей. Если вы встретили тестировщика впервые, отнеситесь к нему доброжелательно.

Тестировщики смотрят на проблемы свежим взглядом, дают быструю обратную связь, и вносят свой вклад в общее качество продукта. Позвольте им это. Они помогут вам добиться лучших результатов, чем если бы вы работали в одиночестве.

Обсудить в форуме