Представим, вы пришли в проект и оказались первым и единственным тестировщиком. Ваша главная задача — провести тестирование. И тут важно перебороть желание сразу делать автотесты и красивые отчеты. Тут нужно остановиться и подумать над несколькими вопросами.
Наш ментор и Software developer in test Данил Бирюков-Романов поделился, с чего начать тестирование с нуля, почему стоит забыть про автотестирование и как правильно ставить цели.
Вопрос первый: А команда-то что хочет?
Сразу же стоит уточнить, что ожидает команда или тимлид от тестирования в целом и от вас, как от специалиста. Они хотят красивые автотесты? Они хотят меньше багов в проде?
Чаще всего, к сожалению, команда не знает, чего она хочет. Это нормально, вы тут как раз и нужны за тем, чтобы дать команде понять, что можно получить с помощью вашей работы.
Вопрос второй: А какие цели у тестирования в этом проекте?
Обычно цель отличается от желаний. Команда может хотеть «иметь меньше боли», но надо оформить это в понятную цель. Но и цели должны быть приближены к реальности. Например, задача «0 багов в проде» нереальна, так что давайте рассмотрим примеры хорошо поставленных целей:
- сделать релизы быстрее
- меньше багов в продакшене
- делать рефакторинг быстрее и проще
И важно помнить, что цель — это не KPI и не показатель работы. Это измерительный прибор показывающий, а туда ли мы идем?
Итак, мы определились куда бежать и что команде хочется. Теперь надо оценить, что мы имеем.
Вопрос третий: А что с пайплайном?
Он вообще есть? Или программисты правят код прямо на продакшене, потом забывают влить это в git и всё идет по кругу заново?
Пайплайн в вакууме имеет следующий вид:
- Программист пишет изменения в ветке;
- Отправляет MR в основную ветку;
- Код проходит юниттесты, спелчекеры, линтеры, проверки безопасности и так далее;
- Код проходит ручное ревью;
- Мерж в основную ветку;
- Собираем билд;
- Билд уходит на тестирование;
- Билд уходит на stage/prod.
Переход на следующий шаг возможен только при успешном завершении предыдущего. А то будет неприятно узнать, что код не запускается в stage, потому что забыли добавить импорт какой-то библиотеки или закралась простая опечатка. Также стоит обратить внимание на то, чтобы у каждого билда был уникальный номер: числовой или хеш. Чтобы точно знать какую версию вы тестируете, какая версия сейчас в stage, какая в prod.
Вопрос четвертый: А что с тестированием?
И вот только сейчас стоит посмотреть пайплайн:
- есть ли тестирование вообще?
- как сохранены тест кейсы?
- сохранены ли вообще?
- как пишутся отчёты о прошедших тестах?
- пишутся ли вообще?
- есть ли автотесты?
- на них вообще смотрят?
- а они стабильные?
Тест-кейсы могут быть простым чек-листом в гугл-доках, потому что даже простой чек-лист позволит не пропустить глупые ошибки.
Отчёт не обязательно должен быть большим описанием того, как проходил тест. На первых этапах будет достаточно зафиксировать: «Билд Х, тесты прошли, ссылка на прогон». Ну или список багов в багтрекере.
И забудьте про автотесты. Пока не будет работающего тестирования, автотесты просто будут автоматизировать бардак, а не тестирование. Только когда тестирование будет поставлено именно как процесс, вы будете понимать, какие части проекта наиболее критичны/часто меняются/проблемные, можно начинать автоматизацию тестирования. Там тоже хватает своих подводных камней, но о них в другой раз.
Автор статьи: Данил Бирюков-Романов
Software developer in test — Cindicator и ментор Solvery