Будучи совсем малышариком (стажёром/джуном) я попал в относительно небольшую компанию, которая занималась автоматизацией налоговых и бухгалтерских процессов для среднего и малого бизнеса. Это был классный и разносторонний опыт тестирования: микросервисная архитектура, сложная бизнес логика приложений, задачи на тестирование фронта и бэка, автоматизация и много других активностей, которые вели к бурному росту. Расстраивал только один факт - тестовая документация в google таблицах... В MS Teams была wiki страничка, где по годам были распределены ссылки на тест-кейсы разных команд, условно:
2021 год:
- Тест-кейсы команды 1 - ссылка
- Тест-кейсы команды 2 - ссылка
...
- Тест-кейсы команды 10 - ссылка
2022 год:
- Тест-кейсы команды 1 - ссылка
- Тест-кейсы команды 2 - ссылка
...
- Тест-кейсы команды 10 - ссылка
и тд.
Внутри каждой такой таблицы были листы, которые делились по фичам. Думаю всем понятно, на сколько было неудобно этим пользоваться? Никакого вменяемого поиска тест-кейсов, полное отсутствие возможности составления прозрачного тестрана, чего уж тут говорить про удобность поддержки этих тест-кейсов. Вспоминаю всё это как страшный сон, бррр.
Потом я попал на проект с удобной TMS, и жизнь заиграла совершенно другими красками. Все тест-кейсы в одном месте, удобный поиск, простой интерфейс для написания сценариев проверок, интеграция с автотестами - ну просто сказка. В таком радостном состоянии я пребывал ровно до того момента, пока мне в работу не упала задача на рефакторинг огромного количества legacy тест-кейсов! Продукт очень бурно развивался, регулярно пилились новые фичи, проводились какие-то эксперименты, менялся вектор компании. В какой-то момент это естественно привело к деградации тестовой документации. Я пришёл на проект как раз в тот момент, когда лиды тестирования дружно сказали:
Хватит это терпеть!
Были запущены все необходимые процессы для устранения беспорядка, но делалось это впопыхах с вечно пропадающими дедлайнами и суетой. Болезненные воспоминания об этом периоде побудили меня написать эту статью, которая напомнит тебе, что актуализация тестовой документации - это важно, и если ты будешь откладывать этот процесс в долгий ящик, то никто тебе спасибо не скажет потом.
Привет, читатель Хабра, на связи Колдомасов Артем, бери калькулятор и давай считать вместе.
Я знаю очень мало людей, которые прям кайфуют от процесса написания тестовой документации. На такую нелюбовь могут повлиять: простая лень ("Я вам че, джун чтоль, тест-кейсы писать?"), отсутствие внятной продуктовой документации, постоянно меняющиеся требования и дизайн, неудачно выбранная TMS система (или ее полное отсутствие), нехватка времени или принципиальное непонимание зачем это делать. Точно такую же нелюбовь можно встретить и к систематическому рефакторингу тест-кейсов (особенно чужих).
Разбираться, что с этим глобально делать я не буду, да и сам я ленив в этом деле, но давай посчитаем, сколько примерно времени может стоить затянувшийся рефакторинг кейсов, а в конце статьи дам парочку советов всем нам на будущее.
Давай представим, что у нас есть 100 тест-кейсов, которые никто основательно не актуализировал уже больше года, и теперь с них надо сдуть цифровую пыль и привести в актуальное состояние. Ниже буду расписывать примерные процессы, которые нам для этого потребуются, они не обязательно должны идти последовательно и могут выполняться асинхронно.
Первым делом нужно ознакомиться с самими кейсами, внимательно прочитать их, понять из каких атрибутов они вообще состоят. Предположим, что это 3 минуты на кейс - 300 минут.
Пока не прогонишь тест-кейс, сходу не поймёшь, есть ли в нём какие-то неточности или ошибки, поэтому следующим этапом у нас будет воспроизведение каждого тест-кейса. Давай заложим на это по 5 минут на кейс - 500 минут.
Теперь, давай представим, что во время воспроизведения, не получилось прогнать 10 кейсов, которые ну очень сильно протухли. Тебе скорее всего придётся сравнить поведение на нескольких окружениях (чтобы убедиться, что это не проблема конкретного тестового стенда), скорее всего ты пойдёшь за уточнениями к автору кейса (если он ещё работает в компании), надо будет списаться с аналитиком, с разработчиком, с другими QA. Если повезёт, то ты потратишь примерно 60 минут рабочего времени на кейс (и не только своего) - 600 минут.
Допустим, ещё 10 тест-кейсов были тоже протухшие, но не так безнадёжно. Где-то удалось найти ответ в продуктовой документации, какие-то моменты пофиксились простым здравым смыслом, а где-то была простая невнимательность автора проверки. Иными словами удалось всё разузнать самостоятельно, без дополнительных уточнений у кого-либо, заложим на такой кейс по 20 минут - 200 минут.
Осталось 80 тест-кейсов, из них 40 актуальные (их больше не трогаем), а остальные 40 нужно немного подправить(проставить нужные компоненты и тэги, исправить опечатки, обновить аттачи), закладываем на кейс по 5 минут - 200 минут.
Итого, на 100 кейсов у тебя может уйти примерно 1800 минут или же 30 часов.
500 тест-кейсов - 150 часов!
1000 тест-кейсов - 300 часов!!
И это всё по минимуму, на некоторых проектах есть более строгие правила к оформлению тест-кейсов, где нужно в одном кейсе указать сразу все ссылки на документацию, инструкции по генерации тестовых данных и так далее, здесь тоже каждый этап может навалить не одну сотню минут. А если представить, что всем этим занимается новичок? Тут сразу прилипают дополнительные коэффициенты, ведь новобранцу в разы сложнее разобраться со всем этим. Вместо решения настоящих бизнес задач, он будет тратить сотни часов на то, чтобы разобрать твои долги (если он вообще останется это делать и не свалит с испытательного срока).
Давай ещё накинем на вентилятор, представь, что вашей компании предстоит переезд из одной TMS в другую. Да, большинство информации переедет автоматом при импорте, но что-то может затеряться или пойти не по плану. Это ещё добавляет какое-то количество драгоценных часов, потраченные на поиски недостающей информации.
Или же представь, что компания решилась запустить автоматизацию тестирования. К вам приходит бравый сеньор автоматизатор, или даже парочку, и вы им с трепетом вручаете косарь неактуализированных тест-кейсов. Лица автоматизаторов представили?
Тут можно много накидывать подобных ситуаций, одна краше другой, и если конвертировать это всё в рубли, то мы получим кругленькую сумму, которой бизнес не очень обрадуется. Да и вообще, мне кажется на работе есть более увлекательные занятия, поэтому старайся не оказываться заложником обстоятельств, когда тебе или команде надо потратить сразу 100+ часов на актуализацию тестовой документации.
Береги тест-кейсы смолоду!
Будет круто, если ты будешь стараться:
Не затягивать с написанием тест-кейсов. Да - у нас мало времени и много других задач, да - писать кейсы неинтересно. Но помни, что каждый не написанный или плохой тест-кейс - это дополнительный сантиметр ямы, которую ты усердно роешь самому себе.
Внедрить практику ревью тест-кейсов. Даже самое поверхностное десяти минутное ревью от коллеги QA поможет защититься от большого количества неточностей.
Выделять фиксированное количество времени в спринте на деятельность, связанную с тестовой документацией. Это может быть написание новых кейсов, редактирование старых, ревью. Что угодно, лишь бы было направлено на тест-кейсы. Стабильность и дисциплина.
Запускать всеобщий рефакторинг тест-кейсов хотя бы раз в полгода. Возьми, например, все кейсы старше двух лет, разбей их по таскам и распредели между коллегами. Проверенным кейсам, можешь ставить метку свежести, с датой проверки.
Не забывать, что тест-кейсы нужны не только тебе. Даже если ты единственный QA на всю компанию, рано или поздно вместо тебя (или к тебе) придёт другой тестировщик, и он уже зависит от тебя и от твоего отношения к тестовой документации.
Буду рад в комментариях почитать твои истории про рефакторинг тест-кейсов на твоих проектах. Какое рекордное количество протухших кейсов встречал за раз? Были ли какие-то нестандартные ситуации, при попытке актуализиовать древний кейс? Или может у тебя идеальный проект, на котором получается без проблем поддерживать все тест-кейсы?