Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Ошибочное восприятие ошибочных восприятий?

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

Вот о каких "ошибочных восприятиях" идет речь:

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

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

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

Выход за рамки багов

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

Итак, поехали.

Используйте PQIP (или что-то подобное)

PQIP расшифровывается как "проблемы, вопросы, идеи, похвала". Я уже неоднократно рассказывала об этом методе – например, во второй части этого цикла статей.

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

Выявляйте риски

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

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

Участвуйте во всех этапах жизненного цикла продукта

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

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

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

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

Общайтесь

Я часто пишу про коммуникацию, потому что она крайне важна. Хорошая коммуникация – фундамент успешной команды, и она выручит вас в трудную минуту.

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

Учите

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

Людям трудно увидеть прямую ценность того, что вы делаете, если они не понимают, что это вообще такое – так расскажите же им об этом! Это подразумевает также распространение полезных ссылок, парную работу и наставничество.

Тестируйте (и меняйте) способы работы

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

В ходе тестирования приложения, на котором основан этот мини-цикл статей, я много занималась чем-то подобным, когда только присоединилась в команде, и продолжала над этим работать по ходу дела. Я начала с модели, которая, как все модели, была ложной – чтобы хоть с чего-то начать. Затем эта модель пересматривалась и улучшалась, и мы увидели, как хорошо она работает. Вы тоже это можете!

Делайте то, что имеет смысл

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

Думайте сами

Это важнее всего – думайте сами! Не надо тупо следовать сценариям, процедурам и инструкциям…или советам людей вроде меня! Думайте критически: задавайте вопросы, экспериментируйте, анализируйте, делайте открытия. Делайте то, что не умеют машины – думайте по-настоящему.

И всегда будьте любопытны.

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