Home

Автор: Ирина Соколова, Senior QA Engineer, qualsolife.ru
Оригинальная публикация

Некоторое время назад я написала статью о своем опыте организации работы QA Инженера на проекте. Сейчас хочу продолжить эту тему, но уже в более узком ее направлении — автоматизации тестирования. Речь пойдет о том же самом проекте, он небольшой, но развивающийся под запросы постоянных клиентов. Быть может мой подход не очень подойдет командам, где работают много десятков сотрудников и каждый отвечает за свою часть (по-моему, в таких проектах работа каждого должна быть строго регламентирована, иначе такой махиной управлять просто невозможно, хотя и они найдут здравое зерно), но он точно будет интересен тем, кто, как и я, однажды пришел на новую работу, и встал на перепутье как самому организовывать свое место под новым солнцем.

Готовимся учиться

Итак, как же можно организовать автоматизацию тестирования на проекте? Если ваш ответ — взять замечательный Selenium и какой-нибудь фреймворк к нему и вперед, то с высоты 13-летнего опыта работы в тестировании я бы не стала так делать точно. Придется осваивать новые горизонты.

Чем же чреват подход «зациклиться на selenium»? А тем, что вы уже и сами не раз читали и слышали. Тем что, эти тесты UI-ные, они дорогие и долгие как в написании и прогоне, так и в поддержании работоспособности. Это знает каждый, но со всей болью этой истины сталкиваются лишь тогда, когда ее игнорируют. UI end-to-end автотесты должны быть обязательно, никто кроме них, не даст вам уверенности в том, что то, что увидит клиент после очередного деплоя не станет для него разочарованием. Но они не должны стать центром автоматизации вашего тестирования.

Возьмите за центр контроля за качеством вашего продукта Test Pyramid Principles. Те самые, о которых уже тоже много где сказано, но на практике не каждый QA понимает, как эту пирамиду сделать прикладной.

Ее рисуют вот так:

И вот так:

Каждый найдет вариант для своей архитектуры.

Внедряем Testing Pyramid Principles в работу QA

Во-первых, как бы лениво и непривычно это ни было, освойте белоящечное тестирование и станьте «частично девелопером».

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

Во-вторых, разберитесь с автотестами, которые пишут сами разработчики.

Найдите их место в структуре проекта, какие виды тестирования и инструменты используются, как запускаются. Оцените покрытие проекта автотестами, научитесь ориентироваться в них. Есть множество инструментов для автоматической оценки покрытия, можете пользоваться, но я сейчас говорю не об этом. Я больше о развитии вашего чутья: берете кусок функционала и смотрите, как он покрыт автотестами: хорошо или плохо. Если хорошо, повод быть вам за эту часть спокойным, если плохо — вы нашли себе фронт работы на те дни, когда на повестке нет срочных задач. А пока при каждом прогоне регрешна имейте в виду, что это место в коде уязвимо.

В-третьих, наберитесь смелости, ревьюйте пулл реквесты разработчиков.

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

В-четвертых, наберитесь еще большей смелости, и пишите автотесты прямо в коде продукта.

Да, также как это делают разработчики. Наравне с ними. Каждый раз когда вы сталкиваетесь с тест кейсом, который нужно автоматизировать, не бросайтесь сразу воплощать его обособленными инструментами, используемыми лишь внутри команды QA. А первым делом задайте себе вопрос, можно ли его автоматизировать посредством юнит/интеграционных автотестов в коде продукта? Если да, сделайте именно так. Если страшно, то это страшно только в первый раз, зато какой level-up ваших скиллов, ведь ваши пулл реквесты будут ревьюить опытные программисты. Да, сначала разнесут в пух и прах то, что вы сделали, но развитие всегда предполагает боль :) Зато в итоге вы получите прекрасные дивиденды:

• такие тесты будут поддерживаться всей командой разработчиков
• они будут работать постоянно, непрерывно и быстро
• они будут интегрированы в CircleCi и запускаться при каждом деплое автоматически (если это реализовано на проекте)
• залатаются дыры в тестировании (вы напишите то, что не было написано до вас)
• вы сможете помочь разработчикам в написании тестов, если они не успевают

В-пятых, создайте ограниченный маленький набор UI end-to-end автотестов, которые имитируют действия конечного пользователя в браузере.

Это будут тесты, которые будут поддерживаться лишь командой QA. В них можно воплотить

• самые ходовые, критически важные сценарии клиентов
• то, что в интеграционных тестах в основном коде не удается полноценно воплотить, например, работу со сторонними сервисами

И да, вы теперь имеете доступ к проекту, и вам ничего не стоит обновлять front-end проекта так, чтобы обладать удобными и надежными локаторами для Selenium. Не надо никого ждать и просить — открывайте пулл реквесты в основной код продукта.

Что из этого получается

Сейчас я работаю именно по такому сценарию. В итоге на верхушке моей пирамиды тестирования всего 9 штук end-to-end тестов. И их поддержка — моя ответственность. А все остальные десятки и сотни тестов живут вместе с основным кодом продукта, начинают свою работу еще на локальном компе разработчика и поддерживаются всей командой инженеров.

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

Когда все тестовые проверки в коде продукта пройдены, мы деплоим тестируемый бранч на тестовое окружение и прогоняем на нем end-to-end тесты посредством Jenkins. Еще несколько ручных функциональных тестов для пущей верности от QA и все, можно бранч мержить в мастер. Сегодня Jenkins джобы для автотестов на тестовом окружении гоняю не только я, разработчики постоянно запускают их, когда им нужно генерировать свежие тестовые данные и имитировать активности пользователей. Их немного, поэтому они стабильны и всегда работают. Удобно всем.

Отмечу еще одно приятное преимущество для QA Инженера в такой вот реализации пирамиды тестирования. Получается,, вы по полной программе становитесь частью команды инженеров. Вы, действительно, делаете неотъемлемую часть единой работы — пишете код вместе со всеми, просматриваете код разработчиков, общаетесь с ними, и они делают то же самое по отношению к вам. Вы видите работу друг друга, лучше collaboration, сильнее team building. Вы будете разбираетесь в проекте не только снаружи, но и изнутри, достойно уважения, не правда ли?

Заключительное напутствие

Моя статья не претендует на универсальную пилюлю, которую можно использовать всегда и везде. Все проекты очень разные, все команды очень разные — каждая должна строить свой самый лучший путь сама, часто это квинтэссенция разных подходов и инструментов. Даже знаменитый Скрам, сколько проектов я видела, каждый исповедует по-своему :) Я вообще не верю в строгие инструкции, верю, что они нужны как ориентиры, а действовать нужно по ситуации.

Однако мир IT развивается, и в него приходят все новые и новые люди, поэтому уверена, что среди читающих этот материал обязательно найдется тот, кому мои маленькие инструкции помогут выбрать верный путь. Улыбнитесь мне в комментариях, если было полезно :), мне будет приятна обратная связь!

Обсудить в форуме