Если так сложилось, что вы трудитесь в компании по созданию программного обеспечения для пользователей, значит вы хоть раз, но слышали о пользовательских персонах.
Что такое персона? Персона — это, своего рода, репрезентация определенного сегмента конечных пользователей создаваемого ПО.
Например, если компания Х делает сайт по продаже частных домов, то одной из привлеченных тест-персон должен быть собственник или жилец дома, который недавно приобрел жилье и может предоставить полезную информацию касательно процесса выбора и подбора жилья для продажи.
Известный QA-инженер Кристин Джеквони предлагает для ознакомления ТОП-4 тестовых персон, с которыми никогда не стоит взаимодействовать. Итак, разберем эти вымышленные персоны.
Плохие примеры тест-персон
Тест-персона №1 (Тэд)
Тед очень сильно любит прогонять ручные тесты и удалять их, когда они завершаются.
Он постоянно чувствует максимальную удовлетворенность, когда наблюдает процесс прохождения тестов.
Ему не очень важно понимать, как именно функционирует ПО, он просто любит делать только то, что ему говорит руководство.
Но из-за того, что он не сильно разбирается в работе программного обеспечения, порой, он пропускает очень критические дефекты.
Если он замечает что-то неладное в работе ПО, он, банально, не вносит такую информацию в тест-план, а просто перестает обращать на это внимание.
Он уверен исключительно в том, что его базовая задача — тестировать ПО, а не вникать в особенности его работы. И это очень большой минус для всей команды по тестированию ПО.
Тест-персона №2 (Анна)
Анна уверенна в том, что она первоклассный инженер-автоматизатор. Она всецело уверенна в том, что ручное тестирование — бессмысленная трата времени.
Ей по душе заниматься чем-то очень сложным, например, создавать и поддерживать работоспособность автоматизированных тестов.
Когда выполняется создание новой фичи, она не забивает голову исследовательским тестированием, она попросту начинает создавать программный код, так как уверена, что автоматизация помогает находить даже самые незаметные баги!
Что объединяет Теда и Анну?
Они каждый день совершают одну и ту же ошибку: никто из них никогда не захочет тратить рабочее время на то, чтобы понять, как именно должно функционировать ПО.
Они всегда пропускают дефекты из-за недостачи такого понимания: Тед не разбирается в коде, который «заставляет» фичу работать, а Анна не понимает особенности сценария применения ПО.
Тест-персона №3 (Патти)
Патти всегда стоит на страже качества ПО. Ей нравится, когда все работает правильно, но еще больше ей по душе процесс и стандарты тестирования.
Она всегда ожидает, что остальная проектная команда будет следовать ее тест-планам и методикам.
Она приверженец мнения, что все регрессионное тестирование должно закончиться к тому времени, когда стартует исследовательское, но в регрессе много тестов, и возникает большая заминка.
Проблема в том, что при условии выпуска ПО каждый месяц, у проектной команды вообще нет времени на исследовательские проверки.
Тест-персона №4 (Рэй)
Рэй тоже считает себя максимально ответственным за качество ПО — ни один дефект не должен остаться незамеченным.
Когда Рэй открывает сайт в IE11 и видит сломанную верстку, он будет во что бы то ни стало стараться выяснить причину бага.
Он может потратить недели на исследование проблемы, и ему все равно, что тем же IE11 пользуются не более 10% от всех востребованных веб-браузеров. Он должен раскрыть все тайны!
Чтоб общему между Патти и Рэем?
Оба банально тратят рабочее время впустую. Они концентрируются на чем угодно, но только не на первичных задачах: созданию качественного ПО вовремя с минимальным числом багов.
Патти так зациклена на процессе тестирования, что не замечает важности и надобности в проведении исследовательского тестирования, которое помогает найти новые дефекты.
А Рэй так сильно поглощен изучением каждого бага, что попросту игнорирует важные процессы тестирования, которые могут положительно повлиять на куда большее количество будущих (потенциальных) пользователей.
Вместо завершения
Иногда, каждый из нас, тестировщиков, может «впадать» в состояние той или иной тест-персоны. Но если мы детально знаем о каждой из них, мы можем вовремя остановиться, чтобы не быть Патти или Анной.
Хорошие QA-инженеры прекрасно знают свое ПО, могут принимать исключительно взвешенные решения, что и при каких условиях нужно тестировать, и постоянно держат навыки в тонусе, пытаясь улучшить свою методику проверки программного обеспечения.
Оставить комментарий