Suggestion: Чего не хватает в принципах тестирования
Привет! Меня зовут Андрей Небольсин, я Cтарший Тестировщик на проекте Сбер МегаМаркет. Мой опыт в QA-сфере относительно небольшой, тем не менее я думаю, что у меня есть, чем поделиться)
Начнем с начал…
Давайте представим какого-то человечка, допустим его зовут Саша. Наш Саша недавно только закончил школу, не захотел поступать никуда в ВУЗ, т.к. не видел смысла в «корочке». На первое время Сашенька пошел работать официантом в какой-то ресторан, чтобы были какие-то деньги на жизнь. Проходит немного времени и он понимает, что денег на жизнь не хватает…
Тут Саша находит сокровище — курс «Тестировщик с нуля». Он понимает, что порог вхождения в профессию низкий и он может стать IT-шником. Это же престижно, да и мечтал он как-то этаким каким-то программистом быть. А самое главное, он не будет ходить каждый день на СКУЧНУЮ работу!
Перехожу к сути: Он начинает учить курс и одно из первых с чем Саша встречается — это «Цели тестирования». Тут то я и хочу остановится подробнее.
Цели тестирования ПО (Как их знают все)
На любом курсе говорят об основных 3-х целях тестирования. Везде разные формулировки, но все они говорят об одном и том же. Вот одна из формулировок*:
Выявление дефектов до того, как их обнаружат пользователи.
Предоставление актуальной информации о состоянии продукта на данный момент.
Проверка на соответствие ПО всем заявленным требования.
Эти цели можно сократить до двух понятий: Верификация и Валидация.
И вот наш Саша познакомился с этими понятиями и пошел в бой.
Первый этап: Верификация
Прошло немного времени. Наш персонаж уже пару месяцев на должности Junior QA в быстрорастущем старт-апе. Он очень прилежно трудится, но чем же он занимается все свое рабочее время?
Пока что Саша умеет только верифицировать продукт… То есть он может сравнить ожидаемый и фактический результаты и сказать, что работает не так, а что так. Он находит огромное количество тривиальных и минорных багов, связанные с тем, что что-то работает не так, как это прописано в требованиях. Кнопку «Cancel» покрасили в зеленый? Саша уже об этом знает! Он уже завел баг-репорт и тегнул разраба. Саша молодец.
Но наш тестировщик еще не знает, что кроме сравнения сайта с требованиями, ему еще нужно понимать, что продукт выполняет свою цель.
Второй этап: Валидация
Прошло уже 2 года с тех пор, как Александр начал свой путь в IT. Он уже занимает уверенную должность Middle QA. Алекс научился анализировать требования; уже понимает немного процессы и бизнес, в котором он работает. Себя Саша предпочитает везде называть Quality Control Engineer, т.к. уже лучше разбирается в терминах.
Теперь на проекте выполняются все цели тестирования, так как Саша теперь понимает, что и требования нуждаются в тестировании. Он является большим энтузиастом по нахождению несостыковок в работе аналитиков.
Качество сайта действительно улучшилось. Пользователи реже начали замечать баги, заказчики знают, в каком состоянии продукт перед релизом каждого спринта.
Что дальше? Все цели выполнены!
А дальше…
А дальше, наш QC перерастает в QA. Он погружается в пучину тестирования и налаживания процессов. От релиза к релизу, от спринта к спринту он борется за качество продукта. Но он перестал чувствовать, что работа ему интересна. Чувство, что он делает «что-то важное» испарилось. Да, он продолжает развивать свои технические навыки и затачивать их все лучше и лучше…, но что по поводу целей? Неужели со временем, человек, который знает все тонкости продукта продолжает заниматься все той же Валидацией и Верификацией.
К сожалению, на практике так и есть… Я общаюсь достаточно не с узким кругом таких Сашь. Я вижу как у Сеньеров год за годом происходит выгорание и «замыливание» глаз.
Вижу ли я выход с этого? Да, вижу! Я видел Инженеров по тестированию и сам таким являюсь, которые нашли новую цель для себя. И эта цель не дает выгорать.
Suggestion: Постоянно улучшай!
Я считаю, что тестировщик — это действительно человек, который лучше всех разбирается в своем продукте! Он знает техническую часть продукта, так как постоянно тестирует функциональность, но при этом хорошо знаком с бизнесовой стороной. И такой человек как никто другой должен знать, что можно улучшить в самом продукте!
Когда QA думает не только о том, что продукт работает, как нужно. А еще он думает и о том, как можно сделать лучше — то его глаза загораются огнем! Постоянно есть чувство, что ты делаешь что-то очень важное. А когда твои улучшения реализуются, то ты хочешь вкладываться в продукт еще и еще!
Как это выглядит на практике? После твоего e2e-тестирования в списке из 10 багов, должны быть еще 3 тикета с пометкой [Suggestion].
Вывод: Я считаю, что в цели тестирования нужно добавить еще один пункт — «Работать над улучшением продукта».
Это хорошая вакцина от выгорания специалистов и отличный двигатель прогресса продукта. Понимание об «улучшении» должно быть прописано на подкорке QA-ного мозга — тогда ты становишься не просто хорошим инженером в тестировании, а лучшим!
*Формулировка взята из «Шпаргалка начинающего тестировщика» — Наталия Матвеева
