Вы просили - выкладываю. Очень многие читатели моего канала спрашивают об обязанностях тестировщика (оговорюсь сразу, тестировщик != (не равно) QA-специалист, но так мне проще вести повествование).
А также многих читателей интересует, как выстроить процесс тестирования на проекте с нуля. Итак, я решила косвенно перепрелести эти две в тоже время разные, но в целом тесно соприкасающиеся тематики.
Итак, начнем по порядку и с примером сразу.
Допустим: Вы более-менее опытный тестировщик, Вас подключают на проект. Что делать дальше?
Первое: найти себе человека, у которого можно выцыганить всю информацию о проекте.
Вы должны знать ВСЕ:
1. Когда проводятся митинги (встречи-созвоны) с командой, в какое время. Если митингов нет - назначаем их ежедневно, организуем общий чат дейли в мессенджере и просим всех готовится к каждому митингу, ответив заранее для себя на вопросы:
Что ты делал вчера?
Что будешь делать сегодня
Какие у тебя есть проблемы?
Что это даст - вы будете в курсе всего, сможете контролировать процесс разработки и текущую стадию продукта. При наличии каких-то проблем - сразу к непосредственному руководству. Какая может быть проблема: например, вы замечаете, что разработчик уже три дня подряд говорит, что фиксит один баг и будет продалжать фиксить его дальше. Наводит на мысли - может у него проблемы? Может нужно подключить тим-лида-разработчика и помочь ему?
2. В каком состоянии находится проект? Какой сейчас этап разработки (смотрим жизненный цикл процесса разработки ПО).
Если Вы в самом начале - на этапе сбора требований и первого MVP, то Вам повезло, Вы у самого истока - продолжайте фиксировать документацию, договоренности и описывать приложение.
Если уже есть функционал за плечами, то сначала нужно разобраться в том, что уже есть и зафиксировать тест-кейсы/чек-листы в формате исседовательского тестирования. Тут же можно откопать много багов (идем искать документацию п.3 ИЛИ при её отсутствии хранителя знаний по проекту).
3. Где ведется документация? Где оформляются задачи разработчиков, аналитиков, тестировщиков, дев-опсов и т.д. Где оформляются требования? И кто ответственный за обновление документации. Если ответственных нет, документации нет - берем это на себя, заводим новый документ в общем доступе для команды, фиксируем туда всю необходимую информацию, вплоть до того, что устанавливать и как. Делаем один раз - дальше передаем новичкам (новым сотрудникам на проекте и просим искать ошибки + оставлять комменты сразу, проверяем ошибки - обновляем документацию).
Что это даст? Вы сразу фиксируете все свои знания в одном месте - забыли - посмотрели или отдали ссылочку нуждающемуся. Экономит кучу времени и сил.
4. Отвечаем на три главных вопроса:
Что тестировать?
Где тестировать?
Как тестировать?
и четвёртый вопрос про сроки - Когда тестировать?
Ответ на вопрос "что тестировать" может быть разный: веб-приложение, мобилку, десктоп и т.п. Но плясать от него будем по-своему, выбирая правильные виды и типы тестирования.
Ответ на вопрос "где тестировать" должен быть из разряда: вот тестовый стенд (если его нет, то просим у разработчиков сделать ИЛИ краткую инструкцию КАК сделать).
Ответ на вопрос "как тестировать" должен примерно появиться на этапе исследовательского тестирования. Если совсем кратко, то изучаем, что такое функциональное/нефункциональное тестирование, превращается в пользователя нашей системы (будь то 13-летний подросток тик-тока, или 50-летняя тетушка из налоговой инспекции) и фигачим тесты.
Итак, первый этап более-менее прошли, двигаемся дальше в следующей статье.
Если Вам интересен такой формат статей, напишите в комментариях, продолжение скоро будет.