В этом посте хочется поделиться 20-летним личным опытом в тестировании и приходу к частичному отказу от тестовой модели с использованием тестовых кейсов. Переход был плавным. Не планировала загружать статью сложными метриками и цифрами, но хотела показать постепенную эволюцию сквозь призму личного опыта в стиле некоторого ревью. Для многих мой опыт наверняка окажется созвучным с их личной практикой, но также допускаю, что есть ситуации, компании или продукты, где стоит использовать классические подходы. Так или иначе, кто-то подкрепит свои догадки и сложившиеся подходы, а кому-то будет интересно почитать, как оно все происходит у других, и почему они выбрали именно такой подход.

Представлюсь: меня зовут Березко Настя, я — тимлид команды тестирования K2 Облака. В тестировании работаю с 2007 года, про тестовую модель могу рассказать много всего и очень долго считала ее основой тестирования. Да и вообще, имея в арсенале тестовую модель, могла спокойно ложиться ночью спать, не думая, что где-то там что-то проскочило без моего ведома и желания. 

Начав работать в команде по разработке облака, я оказалась в условиях без технической документации и какой-либо существующей тестовой модели или минимального тест-плана для каждой части нашей системы. Команду возглавляли и продолжают возглавлять разработчики, выполняя роль аналитиков и подчас тестировщиков. До конца 2024 года тестированием занималась команда инженеров, причем бОльшая часть из них занималась DevOps задачами, то есть не специализированные QA инженеры. Очень много свободы от бюрократии в тестировании, мало времени, наличие тыла в виде автоматизированной регрессии бэкенда и главное - команда мечты, где много экспертизы, проблемы решаются оперативно «здесь и сейчас» и нет никаких межличностных или регламентных преград на пути решения, все это давало нам возможность выпускать релизы, максимально оптимизируя затраты на тестирование. Тестовая модель в нашей экосистеме не прижилась, и сейчас подробнее расскажу, почему так случилось и как мы выживаем без бюрократии и строгих отчетов для руководства.

Какие бывают команды тестирования и как в них происходит взаимодействие

За 18 лет работы в тестировании я побывала в разных командах и узнала, как можно сохранять равновесие между «мы сейчас тут все до основания протестируем и вытрясем душу из разработчиков» и «ща гляну быстренько и в прод».

Для себя разделяю три варианта взаимодействия команды с тестами и покажу примеры из своей практики:

1. Тестовая модель, крутая TMS, тестировщики на все руки

Мой первый опыт в тестировании состоялся в телекоме. Я проверяла систему платежей. Пришла уже на существующую TMS HP Quality Center (см рис 1) и готовую тестовую модель. В 2007 году автоматизированное тестирование только зарождалось и повсеместно не использовалось, я была «ручником» и моя работа выглядела так: получаю список требований для нового релиза, вношу каждое требование в QC*, создаю и актуализирую тест-кейсы в разделе TestPlan, вношу в QC и линкую с требованиями. Далее самое интересное - в разделе TestLab формирую набор для релиза из текст-кейсов новых требований и регресса, который был затронут, и которому требуется проверка. В разделе TestLab происходили запуски тестов, с внесением результатов, если кейс был неуспешен, то регистрировался баг и линковался к тест-кейсу в TestLab. 

По завершении тестирования релиза имеем новые тест-кейсы, которые будут уже в следующем цикле тестирования использованы в качестве регрессионных. Такая история хороша, но актуализация тестов и проход по тестовой модели, для выявления необходимых регрессионных тестов (а чаще всего просто тестировали всё) занимало время, которое больше хотелось потратить на задачи. При этом на составление тест-плана как части тестовой модели уходило тоже приличное количество времени, ну и общий отчет (шаблонный документ, где чаще всего менялся только номер релиза и дата) по релизу, который никто никогда не читал, но прикладывать его к заявке на внедрение требовалось обязательно, так как по правилам выпускать релиз без этого документа запрещено. 

Про команду: было три тестировщика, у каждого своя зона ответственности и свой кусок функциональности, взаимозаменяемость очень посредственная - у каждого сотрудника свой фронт работ в регрессе каждый релиз, да и кейсы были без подробностей, написаны для «будущего себя на регрессе».

2. Тестовая модель на 20 томов собрания сочинений тест-дизайнеров в количестве 10 человек, переход с QC на MS TMS, тестировщики «по бумажке».

Новый вид отношений с тестовой моделью я повстречала также в телекоме, но уже другом, куда пришла сразу менеджером по тестированию, и там меня ждала совершенно другая команда:

• Более дюжины очень погруженных в функциональность системы тест-дизайнеров, прокаченные гигабайтами ТЗ и написавшие тома тест-кейсов в копилку тестовой-модели. Ребята, укоренившиеся на своем месте.

• Тестировщики 15-20 человек: стажеры, младшие специалисты, чаще всего студенты, приходящие-уходящие. Их задача - получить свой набор тестов с очень подробным описанием действий, с указанием входных данных, с указанием результата, в общем всеми возможными атрибутами тест-кейса, провести сверку по этим кейсам и в случае обнаружения расхождения завести ошибку. То есть без воображения, без “отсебятины”, без использования опыта - просто тестирование по бумажке. Причем за тестировщиком (который, к слову, завтра мог больше на работе не появиться, потому что у него изменились планы на жизнь) не было закреплено никакой функциональности. Просто получал свой тест-набор, компьютер с доступом к тестовой среде (деперсонализированные данные) и проводил тестирование по заранее составленному дизайнером плану.

В этой схеме мы получали своеобразную замену автотестам с постоянной актуализацией кейсов, и практически вся ответственность за качество ложилась на плечи тест-дизайнеров. На регресс уходило громадное количество трудозатрат, и человеческий фактор в такой схеме мог тоже сыграть плохую роль.

3. Тестовая модель представлена только для части системы, нет тест-дизайна, нет TMS, тест-план составляется по ходу тестирования

Сейчас я работаю в команде разработки облачной платформы. Наша команда - это разработчики, DevOps-инженеры, тестировщики и технические писатели. Несколько инженеров совмещают работу - DevOps и тестирование, это в 90% работа с бэкендом и тестирование с очень высокой погруженностью в техническую часть системы. Тестировщики - фуллстек-тестирование, но с уклоном в бизнес-логику. По большей части каждый тестировщик взаимозаменяем и обладает большой экспертизой в системе. Я как тимлид могу всегда с легкостью перераспределять задачи между коллегами в случае возникновения форс-мажоров. Что же с тестовой моделью? В данный момент идет постепенная разработка автотестов фронт-части, параллельно с этим наполняется тестовая модель нашей web-консоли. Для нашего обширного регресса бэкенда есть автотесты, которые пишут и актуализируют разработчики (повелось с тех времен, когда тестирования не было вообще). Полный набор автотестов мы прогоняем каждый релиз (спринт ~ 2 недели) на препрод стенде (регрессия занимает около 25 часов). Часть тестов, чаще всего одну/две сьюты, запускаем при тестировании задачи и при внесении изменений в автотесты на собственном dev-стенде. Каждая задача, которую мы тестируем не имеет плана до начала работ и по итогу план никто не требует, но отчет должен быть и к его наполнению есть определенные требования, но пишем его в свободной форме в задаче в Jira, либо приложив файл.

Таким образом, имея на руках автотесты регресса мы получили свободу от необходимости актуализации и составления тестовой модели. Мы не тратим много времени на ручной регресс и посвящаем больше времени на погружение в задачу.

Почему мы выбрали путь без модели?

Ответ на этот вопрос до смешного прост - изначально так сложились обстоятельства: бизнес активно рос и разработка не могла позволить себе бюрократию и тестовые модели. Как видно из предыдущего раздела статьи в команде отсутствуют аналитики, а все это приводит к тому, что нет и документации. Да, мы имеем пользовательскую документацию и все понимаем, какая разница между ней и ТЗ. 

Как же мы в принципе тестируем без документации? Получая задачу на тестирование, мы имеем только описание и решение в тикете Jira, иногда разработчики указывают, на что обратить внимание и что точно протестировать. Далее начинается скрупулезная работа: открыть pull request и посмотреть код, оценить затронутые изменениями части системы, оценить изменения для пользователя, если такие имеются, понять текущие сценарии и какой ручной регресс нужно проверить «глазами». Подготовка к задаче — это всегда взаимодействие с разработчиком, обсудить задачу, порефлексировать над “Можно ли было сделать иначе и оптимален ли этот путь?”, в таком подходе меньше формальностей, но больше выгоды, превосходство над автоматизацией и командная работа. Мы, скорее, не кошка с собакой, а сотрудники и партнеры, помогающие друг другу, на благо общего любимого облака.

Тестировщик, начиная проверку задачи не обязательно в своем арсенале уже имеет составленный тест-план, могут быть просто наброски, чек-листы, что-то краткое, на что можно опереться при проверке задачи, т.к. тестировщик не имеет четких написанных (тем более кем-то) тестов. Приходится много исследовать и погружаться в соседние от изменений области системы, повышается уровень знаний и экспертиза, даже по архитектуре и по используемым технологиям, имея полный доступ к логам и коду тестирование превращается в исследование и по ходу работы насыщается даже не тест-план, а уже сразу отчет. В большинстве кейсов тестировщик сам понимает, какой должен быть результат его действий, и как система поведет себя в конкретном кейсе. И не факт, что об этом будет написано в задаче. 

Обрастая сценариями по ходу работы над задачей, тестирование помогает выявить определенные поведения и в частных случаях ошибки, которые было бы трудно найти по плану, написанному до основной фазы тестирования, только на базе описания функциональности. 

Как говорится «Лучше один раз увидеть, чем семь раз услышать», в данном случае видим мы во время тестирования, а слышим только при прочтении тз/описания требования.

Но что же нам мешало сгружать все составленные тесты по каждой функциональности в тестовую модель и работать с ними в TMS? 

Мы пробовали TMS. И передумали

Изначально работа в Облаке велась по своим правилам: мы очень вдумчиво кодим и сами же это проверяем — согласитесь, такая схема далека от канонов ISTQB. Мой руководитель молодой и уже крутой тестировщик тут же предложил писать тест-кейсы и собирать их в бесплатный для него (у него хорошие связи) TestRail. Но готовность взаимодействовать с этой TMS была только у моего начальника (на тот момент тестировщик) и одного инженера, хотя код создавался и тестировался многими. Функциональность развивалась очень стремительно, с ней же автотесты, время на тестирование и ведение плюс актуализация тестовой модели вскоре начали сравниваться, а вопросы, зачем это все делалось, прибавлялись. Никто не проводил ручное тестирование во время подготовки релиза по составленным тест-кейсам, эту работу выполняла регрессия. Росло непонимание - зачем нам этот процесс, если он не приносит плодов в виде обнаружения серьезных/критичных ошибок. Постепенно задачи обходились только вдумчивой разработкой и проверкой, по итогу которой составлялся отчет о тестировании с перечнем проведенных проверок и артефактов. То есть даже бесплатная TMS не соблазнила нас на трату времени, сил и наших возможностей, которые можно было вложить в вещи намного полезнее, чем тест-дизайн. Выводы все равно были сделаны и в качестве одной из опорных точек был разработан документ - свод правил и подсказок для тестировщиков — QA-hints. Это не бюрократическая история, это помощь и поддержка, которая не загоняет в рамки, а говорит, куда идти и как идти, если опыт еще не позволяет взяться за задачу своими силами.

Прошло время, бренд «К2Тех» стал заметными на рынке, и к нам стали регулярно «стучаться» компании с различными предложениями. Лично я получала предложения о триальном долгом периоде использования наших российских TMS (очень похожих на HPQC ?), заходили и со стороны разработки к нашим экспертам и буквально уговаривали купить свалку для тест-кейсов. Посмотрели стоимость в год на количество наших тестировщиков, и сумма совершенно нас обескуражила. Мы и за бесплатно не стали пользоваться, а тут выложи полтора миллиона. У нас уже есть Git-платформа, за которую мы платим, и в котором храним наши регрессионные автотесты, вплетая их в наш CI.

Приоткрою небольшую завесу о том, как дела обстоят на западе: США, Европа. В компаниях, где работают мои друзья и бывшие коллеги либо нет вообще тестировщиков и все абсолютно на автотестах (в том числе и новая функциональность) и без сборника сочинений тест-кейсов, конечно же, либо похожий на нас процесс — автотесты, новая функциональность проверяется и исследуется руками, а модель — это и есть набор регрессионных автотестов, просто все это написано не словами, а кодом. А знаете почему? Потому что важнее всего - время и деньги. «Это бизнес, детка», — говорю я себе, когда вспоминаю, как долго не хотела принимать пользу и неизбежность автотестирования.

Но как же качество?

Когда мы говорим о тестировании, то никогда нельзя забывать о том, что мы ограничены во времени. Да, можно на 100% проверить всю систему, но время, затраченное на такие капризы стремится к бесконечности, мы - не кони и мы не в вакууме, поэтому мы идем по наиболее оптимальному пути. 

Тестирование новой функциональности (могут быть отклонения в зависимости от специфики задачи):

Тестирование нового релиза, составленного из проверенных за последний спринт задач:

Это очевидная золотая середина, где мы можем гарантировать отсутствие критичных проблем у пользователей, с оптимальным временем отгрузки изменений, которые им необходимы, да и нам тоже, что таить. Если есть возможность махом провести весь регресс, пока релиз-менеджеры и тестировщики отдыхают на выходных, то почему бы его не сделать, и не нужно набирать тест-кейсы для проверки, оценивать их важность, актуализировать, в большом составе сидеть денно и нощно руками тестировать, не зная сна и покоя. Актуальное состояние авторегрессии у нас поддерживается не только разработчиками, но и тестировщиками, так как failed-тест не всегда говорит об ошибке в коде, а о том, что тест потерял актуальность и его нужно привести в соответствие с действительностью, для этого заводим баг.

Что получает команда? Профит для всех сторон

Определились с обеспечением качества, но еще есть команда, и здесь мы тоже должны уважать каждого в ней, понимать потребности. Очень мало найдется людей, которым будет интересна монотонная однообразная работа - из релиза в релиз. Сизифов труд без конца и края можно вытерпеть, если это сезонная работа или просто подработка во время учебы. В этом мало ответственности и мало желания развиваться, это постоянная текучка кадров, ближе к аутсорсингу, там нет понятия «команда», нет вовлеченности, которая позволяет улучшать себя и продукт. У нас всё иначе — каждый понимает, что приносит пользу, потому что не читает по бумажке, как и что протестировать, а сам выбирает для себя модель исследования по задаче. Есть код, описание проблемы/задачи — это наша документация, это исходник нашего тест-плана, оттуда мы черпаем сценарии проверок новой функциональности, а знания в конкретной области и анализ изменений позволяет определиться с ручным регрессом. 

Как я выше намекнула: тестировщики при работе над задачей смотрят изменения в коде, это постоянно повышает их уровень знаний в системе, позволяет оценить изменения, узнать про тех из них, о которых могли ненароком умолчать в решении, подготовить инструкцию по обновлению стенда для данной задачи и провести тестирование инсталляции. Все это про рост компетенций и про погружение в задачу и нашу систему. Когда в процессе работы ты постоянно совершенствуешься и узнаешь что-то новое, это дает определенную мотивацию, это же и помогает отращивать экспертизу и не застаиваться на одном месте. Появляется гибкость в решении задач, мы смотрим на все изнутри, не ограничиваясь тестовой моделью, которая кем-то ранее написана; мы выходим за рамки и каждый сам определяет набор проверок. Для новых сотрудников, которые еще только знакомятся с системой и её «внутрянкой» набор проверок контролируется наставником. 

Вообще у нас очень комфортная система внедрения новых сотрудников в рабочий процесс. Помимо наставника и некоторого списка лабораторных задач, которые нужно решить, чтобы обеспечить себе условия для тестирования, мы предоставляем все же тестовую модель нашей Web UI консоли. Прохождение этих тестов позволяет познакомиться с системой, предметной областью, но, конечно, это далеко от тестирования, которое ждет после прохождения испытательного срока. Кстати, эта тестовая модель написана на основе автотестов для Web UI. 

Мы стремимся автоматизировать всю регрессионную рутину и в процессе подготовки релиза тестировать на предрелизном стенде вручную только то, что было изменено и самую критичную функциональность. 

Важное замечание: у нас нет центров компетенции в лице одного человека - мы стараемся не зацикливать одну область/направление функциональности на одном тестировщике, чтобы обеспечивать high availability тестирование для наших сервисов. Всегда есть тот, кто подхватит задачу при появлении форс-мажоров.   

Модель – это не бронежилет (Формальность ≠ качество)

Мы отказываемся от формальностей в процесс функционального тестирования. Что в данном случае понимать под формальностью: во-первых: считать, что имея тестовую модель по всем функциональностям в системе, мы покрываем тестами 100%, но это всегда является утопией, так как всевозможных кейсов, в том числе со специфичными прод-данными может быть великое количество у системы, которая ведет свою непрерывную жизнедеятельность; во-вторых: проводить каждый релиз регрессионное тестирование по одним и тем же тест-кейсам - пусть на это тратиться много ресурсов, пусть они поддерживаются, но чаще всего такие процедуры не приведут к поимке проблем, тк баг закрадывается туда, где ранее внесли изменения или рядом, для таких случаев вручную тестируется новая функциональности и проводится анализ изменений. 

Если считать, что проведенное ручное тестирование при поддержке огромного количества тестов спасет от внезапных ночных звонков с работы, то это создает ложное чувство контроля и уверенности, но признаем честно, человеческий фактор в таком случае тоже играет свою роль. Когда у вас больше 1, 2, 4 тысяч тест-кейсов в модели и все их нужно пройти, причем бывает в императивной форме вам ставят план passed-кейсов на день, весь процесс регрессионного тестирования превращается в карго-культ, вы уже не стремитесь к качеству, вы выполняете план и с ужасом думаете, что кто-то где-то может найти проблему, которая не позволит написать «бумажку» разрешающую выход на прод.

Заключение

Хочу еще раз подчеркнуть, о чем писала ранее: мы не ленимся, мы стараемся оптимизировать затраты, не раздувать их лишними действиями, а пользоваться благами прогресса, не истязать себя однообразной повторяющейся работой, смотреть вперед и оглядываться на прошлое только ради его совершенствования и переноса в будущее. Тестирование эволюционирует, а нам нравится снижать затраты на рутину и занимать себя чем-то новым, требующим нашего бОльшего внимания.

Хочу сразу успокоить тех, у кого «по-другому», кто лелеет свою тестовую модель и бережно ее содержит, кто проводит ручной регресс каждый релиз и пишет многостраничные отчеты для юридического обоснования возможности выхода на прод - на это есть определенные причины, скорее всего строгий договор с заказчиком, чаще всего это заказчики из госсектора. Да, наш образ жизни вам не подойдёт. Я писала эту статью для тех, кто готов и имеет свободу отказаться от ручной регрессии, вкладываться не в рукописные тест-кейсы, которым всегда нужен человек с глазами, а в автоматизацию, взращивание тестировщиков с экспертизой в системе готовых исследовать систему здесь и сейчас, без использования некогда кем-то написанных сценариев.

Статья помогла мне сменить оптику на время и посмотреть с другой стороны на наши процессы, взяли в работу автоматизацию тестирования еще одного блока системы и будем «усиливать» существующие автотесты основной части нашей системы - добавим им прозрачности путем описания происходящего в кейсе и оценим покрытие в сьютах и на основе этой оценки будем принимать решение о дополнениях в проверках. А также после готовящейся модернизации веб-интерфейса займемся разработкой критичных e2e-автотестов.

Понимаю, что повезло попасть на проект с готовыми автотестами бэкенда и их поддержкой со стороны разработки, но объективно ничего не мешает взять автоматизатора и приступить к нужной работе, которая пусть не в ближайшей перспективе, но даст свои очень нужные для вашего рабочего проекта профиты. Моя статья про то, что при наличии автоматизации тестирования и процесса ее поддержки, тащить в багаже громоздкую тестовую модель становится дорогим и бессмысленным трудом.