Некоторое время назад я написала статью о своем опыте организации работы QA Инженера на проекте. Сейчас хочу продолжить эту тему, но уже в более узком ее направлении — автоматизации тестирования. Речь пойдет о том же самом проекте, он небольшой, но развивающийся под запросы постоянных клиентов. Быть может мой подход не очень подойдет командам, где работают много десятков сотрудников и каждый отвечает за свою часть (по-моему, в таких проектах работа каждого должна быть строго регламентирована, иначе такой махиной управлять просто невозможно, хотя и они найдут здравое зерно), но он точно будет интересен тем, кто, как и я, однажды пришел на новую работу, и встал на перепутье как самому организовывать свое место под новым солнцем.
Итак, как же можно организовать автоматизацию тестирования на проекте? Если ваш ответ — взять замечательный Selenium и какой-нибудь фреймворк к нему и вперед, то с высоты 13-летнего опыта работы в тестировании я бы не стала так делать точно. Придется осваивать новые горизонты.
Чем же чреват подход «зациклиться на selenium»? А тем, что вы уже и сами не раз читали и слышали. Тем что, эти тесты UI-ные, они дорогие и долгие как в написании и прогоне, так и в поддержании работоспособности. Это знает каждый, но со всей болью этой истины сталкиваются лишь тогда, когда ее игнорируют. UI end-to-end автотесты должны быть обязательно, никто кроме них, не даст вам уверенности в том, что то, что увидит клиент после очередного деплоя не станет для него разочарованием. Но они не должны стать центром автоматизации вашего тестирования.
Возьмите за центр контроля за качеством вашего продукта Test Pyramid Principles. Те самые, о которых уже тоже много где сказано, но на практике не каждый QA понимает, как эту пирамиду сделать прикладной.
Ее рисуют вот так:
И вот так:
Каждый найдет вариант для своей архитектуры.
Во-первых, как бы лениво и непривычно это ни было, освойте белоящечное тестирование и станьте «частично девелопером».
Поднимите проект локально, так же как это делает каждый разработчик (наверняка, на проекте есть документация как это сделать, найдите). Вероятно, вы стопятьцот раз проклянете это дело, делая это в первый раз, у вас будет миллион вопросов и проблем, но когда вы это сделаете вы уже многое будете знать: каковы архитектурные идеи, какая база данных, что откуда куда пересылается, где нужные конфиги, а главное, где хранятся автотесты и как их запускать.
Во-вторых, разберитесь с автотестами, которые пишут сами разработчики.
Найдите их место в структуре проекта, какие виды тестирования и инструменты используются, как запускаются. Оцените покрытие проекта автотестами, научитесь ориентироваться в них. Есть множество инструментов для автоматической оценки покрытия, можете пользоваться, но я сейчас говорю не об этом. Я больше о развитии вашего чутья: берете кусок функционала и смотрите, как он покрыт автотестами: хорошо или плохо. Если хорошо, повод быть вам за эту часть спокойным, если плохо — вы нашли себе фронт работы на те дни, когда на повестке нет срочных задач. А пока при каждом прогоне регрешна имейте в виду, что это место в коде уязвимо.
В-третьих, наберитесь смелости, ревьюйте пулл реквесты разработчиков.
Каждый раз когда вы приступаете к разработке нового функционала, запишите себе все тест кейсы для него. Отметьте те из них, которые нужно обязательно автоматизировать, чтобы больше не возвращаться к ручному тестированию этого функционала. Ревьюйте пулл реквесты разработчиков и обоснованно требуйте реализацию тех автотестов, которые они пропустили. Мне много раз попадались очень крутые разработчики, которые писали классные тесты, но даже они уступали хорошему QA в понимании того, как точно, скорее всего, будет пользоваться продуктом конечный клиент. Поэтому даже для матерых спецов находится, что порекомендовать в написании автотестов.
В-четвертых, наберитесь еще большей смелости, и пишите автотесты прямо в коде продукта.
Да, также как это делают разработчики. Наравне с ними. Каждый раз когда вы сталкиваетесь с тест кейсом, который нужно автоматизировать, не бросайтесь сразу воплощать его обособленными инструментами, используемыми лишь внутри команды QA. А первым делом задайте себе вопрос, можно ли его автоматизировать посредством юнит/интеграционных автотестов в коде продукта? Если да, сделайте именно так. Если страшно, то это страшно только в первый раз, зато какой level-up ваших скиллов, ведь ваши пулл реквесты будут ревьюить опытные программисты. Да, сначала разнесут в пух и прах то, что вы сделали, но развитие всегда предполагает боль :) Зато в итоге вы получите прекрасные дивиденды:
В-пятых, создайте ограниченный маленький набор 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 развивается, и в него приходят все новые и новые люди, поэтому уверена, что среди читающих этот материал обязательно найдется тот, кому мои маленькие инструкции помогут выбрать верный путь. Улыбнитесь мне в комментариях, если было полезно :), мне будет приятна обратная связь!
Готовимся учиться
Итак, как же можно организовать автоматизацию тестирования на проекте? Если ваш ответ — взять замечательный 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 развивается, и в него приходят все новые и новые люди, поэтому уверена, что среди читающих этот материал обязательно найдется тот, кому мои маленькие инструкции помогут выбрать верный путь. Улыбнитесь мне в комментариях, если было полезно :), мне будет приятна обратная связь!
Комментарии (10)
4kist
13.09.2019 13:09+1Более плотная интеграция с разработкой это добро, общение идёт на одном языке. Но про ограниченность набора е2е UI тестов надо в школе рассказывать, это боль, особенно когда система сложная, с большим количеством интеграций и когда менеджмент не переубедить, что это путь ад поддержки тестов
Qualsolife Автор
13.09.2019 13:10Да, общение с менеджментом пора выделять в «отдельный вид искусства» :)
Спасибо!
raptors
16.09.2019 06:46+1Улыбка вам от меня в комментарии :)
Отличный план. Он не изобилует техническими деталями (это очень зависит от специфики проекта), и полезен тем QA, которые порой даже сами не совсем понимают свою роль. А некоторые не хотят развиваться в техническую сторону, утешая себя тем, что свою работу «мануальщика» они выполняют. Для них это возможность прочитать прописные истины и переосмыслить свою роль на проекте.
mrmoby
16.09.2019 06:47+1Черт возьми, замечательная статья! Мне сейчас предстоит работа по построению QA процессов на проекте, не терпится применить ваши рекомендации :)
Большая к вам просьба — публикуйте свои статьи чаще, чем раз в полгода :)
Katty23Cat
16.09.2019 14:50+1Как единственный тестер, так еще и мануальщик — прочитала статью с огромным интересом. И ваши комментарии тоже добавили поводов для мотивации, это супер круто, и радостно, что где-то есть такие компетентные специалисты.
Qualsolife Автор
16.09.2019 14:51А для меня «супер круто» получать такие вот отклики :) Спасибо! И удачи вам, я тоже когда-то начинала обычным мануальщиком.
qwez
Неплохо написано, но это, как бы, прописные истины :)
Да, этому мало кто следует, лишний раз можно перечитать, но хотелось бы реальных кейсов посмотреть. Что вы конкретно сделали, как это восприняла остальная команда, какие были сложности и противостояния?
У меня тоже был опыт построения более тесных взаимоотношений с разработчиками. И их лид не очень желал идти на встречу. Много усилий было приложено, чтобы коммиты моих ребят начали попадать в мастер.
Qualsolife Автор
Большое спасибо за обратную связь :)
Очень здорово, что вы сейчас на том уровне, когда для вас это стало прописной истиной. Еще года три-четыре назад, я не знала, что вот так можно работать. (И думаю, среди читающих тоже найдутся юные коллеги, кто еще не верит в силу этих истин). В тех моих старых проектах, команды QA и команды разработчиков будто существовали параллельно, каждая сама по себе. Пока я не попала в анлийский проект, где девушка QA (англичанка с ямайскими корнями) была настолько ЛИДОМ, что все разработчики в сложных ситуациях спрашивали у нее «что мы будем делать дальше?». Тогда я и поняла насколько, это здорово, когда QA имеют голос, и заразилась от нее уверенностью, что наша роль в команде — действительно, важная и крутая! Поэтому мне сложно согласиться с утверждением, что этому мало кто следует. Мои два последних проекта только так и работают :). Так работал тот проект с той девушкой QA. И так работает мой текущий проект, где я сама QA Lead. Здесь тоже костяк девелоперов — англичане. ( Быть может лояльность и типичная вежливость англичан и служит мне хорошую службу...)
О том, что я конкретно сделала, чтобы закрепить свои позиции в команде, в которой вообще не понимали зачем нужны QA, я писала в статье, ссылка на которую дана в первых строках. Если коротко, когда я пришла на проект, я устроила meeting, на который созвала всех от CEO до рядовых девелоперов, где первый пункт обсуждения был " Какие ожидания у вас от меня?", а последним пунктом я рассказала «Что я буду делать, и как я представляю свою работу». И я во всеуслышание заручилась стопроцентной поддержкой и «благославением» всего руководства )))
После этого никто ни разу не пожелал «не идти мне навстречу» (русскоязычные разработчики здесь тоже имеются). Позже у нас появилась вторая QA, и девелоперы очень тщательно просматривали наши коммиты и давали подробные инструкции «как надо и как не надо делать». Моя история такова, мне жаль, что вам так не повезло с тем тим лидом...))