Интересный кейс, job scheduler так настроены? Или реально 20 минут процессинга? Видимо у меня просто личный опыт наложился, где я видел сценарии которые 20-25 минут кликают по экрану. Там были крайне сложные сценарии, где настраивались визарды, дублировались сложные логики, чтобы сделать тест атомарным, было очень большое количество проверяемых действий. Я даже не подумал, что у вас сценарий просто 20 минут ждет...
Организовать 2к+ тестов в одном неймспейсе чисто семантически не очень правильно.
Почему в один, вам главное значение order одинаковое проставить, количество namespace может быть разным.
Думаю, вам не нужно объяснять, что если cpu и диск под 100%, то о стабильности автотестов можно не мечтать.
Приложение, БД и тесты деплояться на один хост для запуска тестов? Просто есть подозрение, что cpu 100% при запуске в 30 потоков вам обеспечили тесты. На вряд ли приложение захлебнеться от 30 одновременно работающих пользователей. А вот если у вас синхронные тесты, то неосвобождение потока:
пока вы ждете элемент на странице(см. await Task.Delay(...));
пока вы ждете ответ от http сервера, сериализуете его;
пока исполняется скрипт в БД.
Будет приводить к тому, что cpu будет захлебываться при 30+ потоках. Ваши тесты в 99% случаях просто ждут и при этом не освобождают ресурсы.
Тестам, которые длятся более 25 минут, мы присваиваем букву А вначале. Тестам от 20 до 25 минут — букву B, от 17 до 20 — букву С, от 14 до 17 — D и от 10 до 14 — букву E.
Вам не кажется, что наличие автотеста, который проходит более 25 минут является маркером плохого тест-дизайна. Вроде всегда тесты можно разбить на части, тем более вы написали:
В наших тестах есть все виды взаимодействия: api, ui, запросы к базе через драйверы и т.д.
Соответственно привести систему к любому состоянию - дело десятка секунд.
"тестирование патча в среднем на 8 часов". Я правильно понимаю, что придумали довольно хитрую систему с A, B ..., чтобы сэкономить максимум 25 минут из 8 часов? Но ведь для этого достаточно им приоритет поднять и все, плюс минус 15 минут относительно 8 часов, уже допустимая погрешность.
В нашей команде автоматизации сформировалась высокая культура программирования. Мы не используем thread.sleep в коде, только явные ожидания
Тут вы особо не выиграли. За wait-ерами все-равно спрятаны Thread.Sleep(к примеру https://github.com/SeleniumHQ/selenium/blob/trunk/dotnet/src/webdriver/Support/DefaultWait%7BT%7D.cs) А так у вас была возможность использовать await Task.Delay и освободить поток для других тестов, но тут придется очень сильно переделывать тесты. Если у вас тесты и тестируемый объект находятся на одной физической машине, возможно удастся еще чуть-чуть увеличить количество выполняемых тестов в единицу времени.
Но чем ниже был уровень параллелизации, тем меньше было ложных падений.
Я же правильно понимаю, что в системе с тестами только api и ui шаги. Если это так и с увеличением уровня параллелизации увеличивалось количество падений, то у вас проблема с атомарностью кейсов. Обычно в этом случае мы в командах начинали с выпиливания всех статических методов(за исключением чистых функций), после этого смотрели на бизнес сценарии и, либо выделяли соответствующие категории сценариев, либо делали тест атомарным. Скорее всего вам не надо было уменьшать количество потоков, а необходимо было править тесты.
Мы пошли дальше и сделали сортировку по строкам — названиям тестов. Тестам, которые длятся более 25 минут, мы присваиваем букву А вначале. Тестам от 20 до 25 минут — букву B, от 17 до 20 — букву С, от 14 до 17 — D и от 10 до 14 — букву E.
Не очень понял, чего вы хотели добиться? Есть тесты, которые:
могут исполняться параллельно;
должны запускаться последовательно относительно друг друга и могут запускаться параллельно относительно других тестов;
не могут исполняться одновременно с другими.
Зачем вводить категории по продолжительности? По бизнес value - логично, по продолжительности не очень вижу логику. Они же все равно все должны пройти.
Можно сделать автотесты частью процесса разработки, пока автотесты не сделаны — фича не закончена и не может идти в релиз. Проблема, когда надо писать автотест быстро и «вчера», показывает неоптимальность процесса и это значит не то, что не надо писать автотест, а то, что надо оптимизировать процесс. Очень часто автоматизаторов берут именно в быстроразвивающиеся продукты с частыми релизами, поскольку нет возможности тратить время на длинные регрессы.
Тестирование Usability не относится к автоматизированному тестированию, но данная часть может быть выполнена ui/ux designer, в этом случае привлекать тестировщиков для этого становится необязательно.
Вполне традиционные, но как мне кажется такое решение опять же временное, как показывает опыт(прошло два года после https://habr.com/ru/post/492054/), разработчики не очень хотят развивать инструменты для автотестирования, но это вполне возможно из-за их топорности(инструментов), неразвитости подходов и простой логики. Несколько SDET должно быть в компании, они бы мониторили развитие инструментов, осуществляли обновление, писали моки для внешних систем, осуществляли поддержку infrastructure as code для тестовых стендов, осуществляли code review и пр. Сейчас разработчики и так должны мониторить очень большой спектр инструментов, у многих есть pet проекты для обкатки новых технологий, добавлять ещё десяток инструментов для "e2e" уже лишнее, инструменты слишком разные.
Я бы составил слегка другой прогноз и выделил другие причины. Выделение компетенций автоматизатора тестирования произошло из-за увеличения требований к скорости обновления ПО. Т.е. был QA часть обязанностей перешло QAA, после появилось требование не просто к быстрой верификации, но еще и качественной(проблемы flaky тестов) появляются SDET. Это текущая отправная точка, лишь у небольшого количества компаний сформировано понимание, какие компетенции необходимы SDET, какие обязанности он должен выполнять, из-за этого растет спрос на «универсалов» и «T-shaped». Но растет он в краткосрочной перспективе, пока не поймут их зону ответственности. «универсалов» и «T-shaped»:
1. трудно найти;
2. трудно подготовить;
3. Готовят их со спецификой продукта, т.е. при переходе специалиста его снова приходится доучивать.
Исходя из этого спрос на них, как я считаю, будет расти не долго. Потом будет расти спрос на SDET и на QA. Спрос на QA вернется, потому что у QA огромная зона ответственности. от нее будут понемногу «откусывать» и выделять новые должности, спрос на QA будет похож на синусоиду. Спрос на SDET уже сложно спрогнозировать, все таки, как мне кажется, отправная точка — QA.
Границы между QAA(SDET, возможно будут еще переименования) и QA не будут стираться, наоборот произойдет четкое разделение зон ответственности. Именно разделение зон ответственности позволяет компаниям уменьшить кадровые риски. Причин по которым в долгосрочной перспективе произошел откат к «универсалам» я не вижу.
Спасибо за статью и за ссылки, часть объявленных принципов в свое время пришлось подтверждать примерами, что бы начать перестраивать процесс, но теперь я могу это делать более аргументированно.
Шина довольно проблемное место, т.к. является асинхронщиной по-умолчанию.
Интересное замечание. Вы же понимаете, что шина сейчас основной метод коммуникации внутри систем, которые должны быть доступны 24/7. Она априори не может являться проблемным местом. В одном из проектов компании все "Contract Test" реализованы через шину событий. В этом проекте планируется автоматическая доставка релизов, соответственно нестабильных тестов там быть не может.
UI тест который зависит от асинхронного бэк компонента может со временем вылиться в дикую головную боль.
Если на проекте актуальный frontend framework и команда разработки имеет опыт работы с ним и умеет правильно управлять state-ом приложения - головной боли не будет.
SQL запросы напрямую в базу - к сожалению, утопия. Каждый раз как бэковый компонент накатывает миграцию, где есть non-null поля, ваши тесты будут краснеть. К тому же поддерживать такие plain-text запросы довольно сложно, когда их количество вырастает в разы.
Да, Plain SQL запросов в коде автотестов должно быть минимум. Вся логика уезжает в stored procedures и накатывается миграциями. Мы в проектах стараемся объединять миграции интеграционных тестов и e2e в отдельный контекст, они всегда в актуальном состоянии, иначе интеграционные тесты не проходят, это блокирует исполнение e2e. Если нет желания бороться с stored procedures, можно попробовать code-first подход по взаимодействию с БД.
Эмулятор - вот тут поясните, что вы имеете ввиду, т.к. не очень понятно.
Автотесты переезжают в репозиторий тестируемого проекта. В "Эмулятор" выносится логика контроллеров. Соответственно через "Эмулятор" напрямую взаимодействуете с кодом. Самый стабильный вариант из всех, если логики в контролерах нет.
Вообще, самый надёжный способ все же использовать API.
У меня есть задача, чтобы можно было параллельно исполнять тесты, мне надо клонировать сущности, при формировании которых участвует 30+ таблиц, с небольшими изменениями(имя заменить плюс еще пару параметров). Данные шаги вызываются в 3000 сценариях. Через UI их выполнять примерно 4.5 минуты. Через существующие методы API ~3 минуты. Через Stored Procedure 15 секунд. Когда стоит задача быстрой верификации качества, нужны шаги по взаимодействию с базой.
P.S. я не выделяю ни один из подходов. когда я последний раз писал систему для e2e тестов, были реализованы все подходы, кроме шины событий. Это был монолит, а для него данный подход неактуален.
Конечно, нужно сразу оговориться, что для достижения такого процесса, QA-инженеру нужно проделать огромную работу — выбрать удобные для разработчика тест фрэймворки (и дописать/интегрировать их), настройка CI, написание документации, примеров, проведение сессий обучения тест дизайну, воркшопы по автоматизации.
Не все из этого процесса придется делать QA. В быстрой и качественной проверке заинтересованы не только QA, но и Dev Team Lead, Solution Architect, Project Owner, CTO, в некоторых командах заинтересованы DEV, поэтому все, что может быть делегировано, должно быть делегировано компетентных лицам. Из личного опыта «выбрать удобные для разработчика тест фрэймворки (и дописать/интегрировать их)», «проведение сессий обучения тест дизайну» и «воркшопы по автоматизации» делать не пришлось. Архитектуру приложения для E2E сделать похожей на архитектуру основного приложения — желательно -это добавит еще плюс в мешок, сможете новеньких людей в проект вводить через расширение проекта с e2e. Это еще и решает проблему с кадрами, автоматизаторов найти крайне затруднительно, да и в этом процессе они становятся не нужными.
Именно поэтому API и SQL не взаимозаменяемые, если есть логика приложения при формировании сущности — API, если ее нет, нужна операция клонирования с изменением нескольких полей, к примеру — SQL процедура.
В большинстве случаев, если делают документированный API выпускают клиентов под разные языки. Таким образом необходим шаг, который проверял, что версия используемого клиента соответствует версии тестируемого объекта, если шага такого нет — красный регресс, который узнаешь по факту.
Для разработки модуля, реализующего SQL шаги, можно применить Database-first подход. Таким образом будет отдельный шаг, который будет синкать entity, дальше можно заиспользовать верификацию контрактов(я делал через верификацию маперов в AutoMapper), и в случае, если верификация не пройдена, блокируется начало выполнения тестов.
А какая разница? Изменение структруы БД ведет за собой обновление контрактов API, если не автогенерируемый клиент, необходимо будет точно так же отслеживать изменения контрактов. А вообще в автотестах нужно и использование эмулятора(API) и SQL запросы -они не взаимозаменяемые, у каждого из них своя зона ответственности.
Утверждение «Архитектура портов и адаптеров направлена на то, чтобы убедиться, что вы используете принцип единой ответственности» крайне ошибочно:
1. Адаптер — пример простейшего шаблона проектирования. Не имеет за собой архитектуру;
2. Адаптер позволяет круг превратить в квадрат. Что тут может позволить убедиться «что вы используете принцип единой ответственности». В кривых руках круг превращается в колесо с полным нарушением SRP и адаптер позволяет это сделать.
В статье смешали понятия паттернов и реализации паттернов. Сами по себе паттерны на нарушают принципов(ни SOLID, ни DRY, ни каких бы там ни было). Они лишь содержат рекомендации и могут иметь разные реализации. Поэтому утверждать, что PageObject не соответствует SOLID, а Screenplay соответствует, я считаю некорректно. Все реализации PageObject, которые я видел(кроме собственной :)), нарушают SRP и DIP. В самом первом примере нарушены практически все принципы SOLID. Я думаю, если статью прочитает человек с большим опытом разработки, чем у меня, найдет нарушения и во втором.
Presenter First – это модификация model-view-controller (MVC) для организации кода и разработки с целью создания полностью протестированного программного обеспечения с использованием test-driven подхода к разработке (TDD):
1. MVC — не совсем паттерн, это способ организации кода(мое личное мнение, понимаю, что многие не согласятся);
2. это модификация «способа организации кода» для организации кода и разработки с целью создания полностью протестированного программного обеспечения с использованием test-driven подхода к разработке (TDD). Я честно несколько раз перечитал, но так и не понял, что Вы хотели сказать. Как может паттерн иметь цель «создание полностью протестированного программного обеспечения»? Паттерн решает проблему. Проблему «создания полностью протестированного программного обеспечения» решает разработчик, ни один паттерн ее не решит.
Уже упомянутый BddFy не имеет Gherkin syntax(псеводоязыка) при этом реализует BDD подход. Gherkin syntax определяет правила описания сценариев, которые совпадают с правилами написания тест кейсов, что позволяет определить однозначное соотвествие между автотестами и набором регрессионных тестов ручных тестировщиков, поэтому его использование это вполне логичный шаг, а не просто модно. BDD подход разделяет сценарии и реализации шагов, что позволяет без дублирования кода из шагов формировать сценарии, что так же является логичным шагом.
Если сомнение именно в псевдоязыке, то есть другие BDD Framework, реализующие правила Gherkin syntax, при этом без псеводоязыка. SpecFlow(cucumber) будет выигрывать за счет возможностей. По крайней мере в мире .Net это так, аналогов SpecFlow по возможностям нет. Для меня killer feature-ами в SpecFlow являются:
1. Встроенный DI контейнер;
2. Встроенная система расширения поведений за счет хуков. Она неявная — это минус, но то, что у меня чистые сценарии, без различных инфраструктурных настроек — это очень удобно;
3. Встроенная система плагинов;
4. У меня с самого начала понятные формулировки степов, поэтому после того, как произошел мапинг результатов во внешнюю систему, я без труда понимаю, что происходило в этом сценарии;
сделать для них API удобный
Это дорого. SpecFlow(cucmber) — определенный стандарт, а это значит, что есть множество third-party libraries, что инструмент активно развивается.
Вначале в команды автоматизации перестали искать новых кандидатов. Со временем люди либо перешли в разработку, либо ушли из компании. Никого не разгоняли.
… автотесты разработчики пишут? А тест кейсы для конкретной фичи кто формирует?
В компании каждая команда разработки состоит из 4 DEV и 2 QA. Тест кейсы формитуют QA, так же они формируют сценарий в SpecFlow. Если не хватает реализаций в автотестах внутри команды решают кому это будет сделать проще, чаще всего это DEV.
зачем вам Specflow?
SpecFlow из коробки предоставляет огромное количество фич, реализация их для framework задача очень трудозатратная. Мы в одном из проектов брали BddFy и доводили его до нужного состояния, на проработку основного функционала потребовалось 2 месяца dev (верхнеуровневая архитектура + DI + converter-ы + читабельный report), а это все еще и поддерживать надо самим.
Почему считается идеальной ситуация, ручные тестировщики пишут тест-кейсы, а автоматизаторы пишут по ним автотесты? По-моему, это плохой паттерн :)
Паттерны решают проблему. Есть ситуации, в которых данный паттерн не применим — небольшие проекты в разработке, которых принимает участие не больше 3 команд(10 DEV, 6 QA). Если проект крупный с четким разделением зон ответственности(DEV, DevOps, ItOps, BA, QA,...), то выделение команды QAA логичный шаг.
Дизайн ручных тест-кейсов и тест-кейсов для автоматизации различается. Сценарии для автотестов нужно нарезать иначе.
В идеальной ситуации не различаются. Думаю уже есть команды, которые смогли реализовать Cucumber(любой BDD с Gherkin синтаксисом) first подход и наслаждаются жизнью.
Ужасно долгий воркфлоу «тестировщик написал тест-кейс — создал задачу автоматизатору — автоматизатор написал тесты». Если в рабочих процессах можно обойтись без лишних рабочих центров и передачи задач между ними — нужно обходиться.
Современный тенденции говорят об обратном. Из последнего разделение Dev на backend, frontend, database, devops. Разделение позволяет писать более качественный код.
Путь развития автоматизатора мне кажется сомнительным. Ты все еще не настоящий разработчик, но и с ручными тестировщиками тебе не по пути. В итоге, ты остаешься один или с несколькими такими же, как ты. Тебе не у кого учиться и вместо best practices написания кода ты учишься странному.
Все зависит от руководителя и от личностных качеств работника, но во большинстве случаев, как бы это грустно не звучало, все именно так. Исходя из личного опыта, можно подойти к DevTeam Lead любой команды и попросить, чтобы он проводил code review и составил план обучения. Чтобы быть отличным автоматизатором, ты должен быть хорошим разработчиком.
Почему не стремиться к тому, чтобы тестировщики делали всё: писали сценарии и писали автотесты? Это даже не утопия, я видел такие команды.
QAA должен обладать определенными знаниями, которыми QA не обладает:
Знание принципов написание поддерживаемого кода (SOLID, DRY, KISS, ...) — иначе через два года можете прийти к выводу, что проще переписать с 0, чем это поддерживать
Знание языка, на котором пишет, компилятора/ интерпретатора/ runtime среды ...
Знание инструментов автоматизации.
Без этих навыков невозможно написать стабильную, масштабируемую систему исполнения тестов.
Спасибо за статью, но все таки хотелось бы уточнить пару моментов.
В идеальном мире эти навыки соответствуют задаче: функциональные тестировщики прорабатывают тест-кейсы и фактически формулируют задачи на автотесты. Автоматизатору остается описать то, что он видит. Но на реальных проектах автоматизатору приходится немного глубже погружаться в суть вопроса.
Проблема неидеальности Вашего реального проекта решается выделением одного QA команде QAA. Таким образом сразу решаются еще и следующие проблемы, если при автоматизации применяется BDD:
ревью сценариев;
соответствие сценриев автоматизации и test suite «ручных» тестировщиков;
Скажу честно, первым делом, когда прихожу в команду автоматизации, договариваемся, что если кейс непонятен, скидываем, либо выделенному QA, либо автору. Это минимизирует время потраченное на автоматизацию, так же помогает решить проблему с подбором пересонала, с которой Вы столкнулись:
В последнее время ко мне на собеседования приходит много автоматизаторов, не имеющих базы в тестировании. У них есть опыт автоматизации как таковой. Но в своей работе они всегда полагаются на чужой тест-дизайн (выполненный “ручниками”).
…
Автоматизатор, который миновал стадию ручного тестирования, зачастую умеет просто писать код. Но этого мало. И в двух словах всю недостающую базу не объяснишь. Чтобы ее получить, нужно обратиться в сторону функционального тестирования, как бы странно это ни звучало. Мы же в первую очередь тестировщики, а уже потом автоматизаторы.
Это несправедливо по отношению к разработчикам и DevOps. У меня был опыт, когда Solution Architector захотел поробовать «новенькое» и выстроил архитектуру приложения для e2e тестов и это был однозначно очень ценный опыт. Наличие людей с оптытом в DevOps и/или разработки очень положительно сказывается на системе для автоматизированного тестирования, особенно, если система большая (>5000 сценариев), а запускаться тесты должны часто. Нужны ли в команду автоматизации люди с опытом «ручного» тестирования — нужны, но как мне кажется их количество может составлять (25-30% от команды). Задачи в командах автоматизации очень разные:
1. донастройка тестовых environment(octopus, puppet);
2. подготовка образов(docker);
3. CI;
4. Оптимизация времени прогонов;
5. Уменьшение времени, затрачиваемого на поддержку системы;
6. Тестовая инраструктура далека от идеала, для всего нужны плагины, форки;
7. Ведение документации в wiki;
8. Нагрузочное тестирование;
9. Интеграция со сторонними системами (Allure, Kibana, Jira, ...);
Был опыт, когда один человек писал формулировки сценариев, другой писал реализации, сделало ли это второго плохим автоматизатором? Я считаю нет, он делал все, что я перечислил выше и при этом писал очень качественный код. Я бы все таки предложил разделять зоны ответственности. Regression test suite — лицо «ручных» тестировщиков, все должно быть в идеальном состоянии, чтобы это мог воспроизвести человек без опыта, если это не так, тест кейс должен быть переписан. В этом случае автоматизатору становится необязательно иметь опыт в «ручном» тестировании, а можно сконцентрироваться на своей зоне ответственности. И это не должно быть утопией, как преподнесено в статье(по крайней мере мне так показалось), это должно быть правилом.
Что касается ответа на вопрос статьи
Доводилось ли вам переходить между ИТ-направлениями? Как вы выбирали свой путь?
:
Я начинал на позиции jun BA, после закрытия проекта предложили заняться тест дизайном, так я попал в QA отдел, параллельно взял удаленный проект в веб-разработке. Потом перешел в автоматизацию. Там решил развиваться не в менеджерскую позицию, а в техническую, в итоге осуществлял экспетризу в нескольких командах и за полтора года автоматизировал всего 6 кейсов(базовый набор тестов в новой системе). Недавно понял, что настал тот момент, когда накладно мониторить изменения в автоматизации и разработке и перешел в разработчики. Начинал свой путь в BA, поскольку было пересечение проектной специфики и бакалаврской работы.
Понял, спасибо за разъяснения! Классная статья!
Интересный кейс, job scheduler так настроены? Или реально 20 минут процессинга? Видимо у меня просто личный опыт наложился, где я видел сценарии которые 20-25 минут кликают по экрану. Там были крайне сложные сценарии, где настраивались визарды, дублировались сложные логики, чтобы сделать тест атомарным, было очень большое количество проверяемых действий. Я даже не подумал, что у вас сценарий просто 20 минут ждет...
Почему в один, вам главное значение order одинаковое проставить, количество namespace может быть разным.
Приложение, БД и тесты деплояться на один хост для запуска тестов? Просто есть подозрение, что cpu 100% при запуске в 30 потоков вам обеспечили тесты. На вряд ли приложение захлебнеться от 30 одновременно работающих пользователей. А вот если у вас синхронные тесты, то неосвобождение потока:
пока вы ждете элемент на странице(см. await Task.Delay(...));
пока вы ждете ответ от http сервера, сериализуете его;
пока исполняется скрипт в БД.
Будет приводить к тому, что cpu будет захлебываться при 30+ потоках. Ваши тесты в 99% случаях просто ждут и при этом не освобождают ресурсы.
Вам не кажется, что наличие автотеста, который проходит более 25 минут является маркером плохого тест-дизайна. Вроде всегда тесты можно разбить на части, тем более вы написали:
Соответственно привести систему к любому состоянию - дело десятка секунд.
"тестирование патча в среднем на 8 часов". Я правильно понимаю, что придумали довольно хитрую систему с A, B ..., чтобы сэкономить максимум 25 минут из 8 часов? Но ведь для этого достаточно им приоритет поднять и все, плюс минус 15 минут относительно 8 часов, уже допустимая погрешность.
Тут вы особо не выиграли. За wait-ерами все-равно спрятаны Thread.Sleep(к примеру https://github.com/SeleniumHQ/selenium/blob/trunk/dotnet/src/webdriver/Support/DefaultWait%7BT%7D.cs) А так у вас была возможность использовать await Task.Delay и освободить поток для других тестов, но тут придется очень сильно переделывать тесты. Если у вас тесты и тестируемый объект находятся на одной физической машине, возможно удастся еще чуть-чуть увеличить количество выполняемых тестов в единицу времени.
Я же правильно понимаю, что в системе с тестами только api и ui шаги. Если это так и с увеличением уровня параллелизации увеличивалось количество падений, то у вас проблема с атомарностью кейсов. Обычно в этом случае мы в командах начинали с выпиливания всех статических методов(за исключением чистых функций), после этого смотрели на бизнес сценарии и, либо выделяли соответствующие категории сценариев, либо делали тест атомарным. Скорее всего вам не надо было уменьшать количество потоков, а необходимо было править тесты.
Не очень понял, чего вы хотели добиться? Есть тесты, которые:
могут исполняться параллельно;
должны запускаться последовательно относительно друг друга и могут запускаться параллельно относительно других тестов;
не могут исполняться одновременно с другими.
Зачем вводить категории по продолжительности? По бизнес value - логично, по продолжительности не очень вижу логику. Они же все равно все должны пройти.
Тестирование Usability не относится к автоматизированному тестированию, но данная часть может быть выполнена ui/ux designer, в этом случае привлекать тестировщиков для этого становится необязательно.
Вполне традиционные, но как мне кажется такое решение опять же временное, как показывает опыт(прошло два года после https://habr.com/ru/post/492054/), разработчики не очень хотят развивать инструменты для автотестирования, но это вполне возможно из-за их топорности(инструментов), неразвитости подходов и простой логики. Несколько SDET должно быть в компании, они бы мониторили развитие инструментов, осуществляли обновление, писали моки для внешних систем, осуществляли поддержку infrastructure as code для тестовых стендов, осуществляли code review и пр. Сейчас разработчики и так должны мониторить очень большой спектр инструментов, у многих есть pet проекты для обкатки новых технологий, добавлять ещё десяток инструментов для "e2e" уже лишнее, инструменты слишком разные.
1. трудно найти;
2. трудно подготовить;
3. Готовят их со спецификой продукта, т.е. при переходе специалиста его снова приходится доучивать.
Исходя из этого спрос на них, как я считаю, будет расти не долго. Потом будет расти спрос на SDET и на QA. Спрос на QA вернется, потому что у QA огромная зона ответственности. от нее будут понемногу «откусывать» и выделять новые должности, спрос на QA будет похож на синусоиду. Спрос на SDET уже сложно спрогнозировать, все таки, как мне кажется, отправная точка — QA.
Границы между QAA(SDET, возможно будут еще переименования) и QA не будут стираться, наоборот произойдет четкое разделение зон ответственности. Именно разделение зон ответственности позволяет компаниям уменьшить кадровые риски. Причин по которым в долгосрочной перспективе произошел откат к «универсалам» я не вижу.
Спасибо за статью и за ссылки, часть объявленных принципов в свое время пришлось подтверждать примерами, что бы начать перестраивать процесс, но теперь я могу это делать более аргументированно.
Интересное замечание. Вы же понимаете, что шина сейчас основной метод коммуникации внутри систем, которые должны быть доступны 24/7. Она априори не может являться проблемным местом. В одном из проектов компании все "Contract Test" реализованы через шину событий. В этом проекте планируется автоматическая доставка релизов, соответственно нестабильных тестов там быть не может.
Если на проекте актуальный frontend framework и команда разработки имеет опыт работы с ним и умеет правильно управлять state-ом приложения - головной боли не будет.
Да, Plain SQL запросов в коде автотестов должно быть минимум. Вся логика уезжает в stored procedures и накатывается миграциями. Мы в проектах стараемся объединять миграции интеграционных тестов и e2e в отдельный контекст, они всегда в актуальном состоянии, иначе интеграционные тесты не проходят, это блокирует исполнение e2e. Если нет желания бороться с stored procedures, можно попробовать code-first подход по взаимодействию с БД.
Автотесты переезжают в репозиторий тестируемого проекта. В "Эмулятор" выносится логика контроллеров. Соответственно через "Эмулятор" напрямую взаимодействуете с кодом. Самый стабильный вариант из всех, если логики в контролерах нет.
У меня есть задача, чтобы можно было параллельно исполнять тесты, мне надо клонировать сущности, при формировании которых участвует 30+ таблиц, с небольшими изменениями(имя заменить плюс еще пару параметров). Данные шаги вызываются в 3000 сценариях. Через UI их выполнять примерно 4.5 минуты. Через существующие методы API ~3 минуты. Через Stored Procedure 15 секунд. Когда стоит задача быстрой верификации качества, нужны шаги по взаимодействию с базой.
P.S. я не выделяю ни один из подходов. когда я последний раз писал систему для e2e тестов, были реализованы все подходы, кроме шины событий. Это был монолит, а для него данный подход неактуален.
К ответу выше, я бы еще добавил:
Не все из этого процесса придется делать QA. В быстрой и качественной проверке заинтересованы не только QA, но и Dev Team Lead, Solution Architect, Project Owner, CTO, в некоторых командах заинтересованы DEV, поэтому все, что может быть делегировано, должно быть делегировано компетентных лицам. Из личного опыта «выбрать удобные для разработчика тест фрэймворки (и дописать/интегрировать их)», «проведение сессий обучения тест дизайну» и «воркшопы по автоматизации» делать не пришлось. Архитектуру приложения для E2E сделать похожей на архитектуру основного приложения — желательно -это добавит еще плюс в мешок, сможете новеньких людей в проект вводить через расширение проекта с e2e. Это еще и решает проблему с кадрами, автоматизаторов найти крайне затруднительно, да и в этом процессе они становятся не нужными.
В большинстве случаев, если делают документированный API выпускают клиентов под разные языки. Таким образом необходим шаг, который проверял, что версия используемого клиента соответствует версии тестируемого объекта, если шага такого нет — красный регресс, который узнаешь по факту.
Для разработки модуля, реализующего SQL шаги, можно применить Database-first подход. Таким образом будет отдельный шаг, который будет синкать entity, дальше можно заиспользовать верификацию контрактов(я делал через верификацию маперов в AutoMapper), и в случае, если верификация не пройдена, блокируется начало выполнения тестов.
1. Адаптер — пример простейшего шаблона проектирования. Не имеет за собой архитектуру;
2. Адаптер позволяет круг превратить в квадрат. Что тут может позволить убедиться «что вы используете принцип единой ответственности». В кривых руках круг превращается в колесо с полным нарушением SRP и адаптер позволяет это сделать.
В статье смешали понятия паттернов и реализации паттернов. Сами по себе паттерны на нарушают принципов(ни SOLID, ни DRY, ни каких бы там ни было). Они лишь содержат рекомендации и могут иметь разные реализации. Поэтому утверждать, что PageObject не соответствует SOLID, а Screenplay соответствует, я считаю некорректно. Все реализации PageObject, которые я видел(кроме собственной :)), нарушают SRP и DIP. В самом первом примере нарушены практически все принципы SOLID. Я думаю, если статью прочитает человек с большим опытом разработки, чем у меня, найдет нарушения и во втором.
Presenter First – это модификация model-view-controller (MVC) для организации кода и разработки с целью создания полностью протестированного программного обеспечения с использованием test-driven подхода к разработке (TDD):
1. MVC — не совсем паттерн, это способ организации кода(мое личное мнение, понимаю, что многие не согласятся);
2. это модификация «способа организации кода» для организации кода и разработки с целью создания полностью протестированного программного обеспечения с использованием test-driven подхода к разработке (TDD). Я честно несколько раз перечитал, но так и не понял, что Вы хотели сказать. Как может паттерн иметь цель «создание полностью протестированного программного обеспечения»? Паттерн решает проблему. Проблему «создания полностью протестированного программного обеспечения» решает разработчик, ни один паттерн ее не решит.
Если сомнение именно в псевдоязыке, то есть другие BDD Framework, реализующие правила Gherkin syntax, при этом без псеводоязыка. SpecFlow(cucumber) будет выигрывать за счет возможностей. По крайней мере в мире .Net это так, аналогов SpecFlow по возможностям нет. Для меня killer feature-ами в SpecFlow являются:
1. Встроенный DI контейнер;
2. Встроенная система расширения поведений за счет хуков. Она неявная — это минус, но то, что у меня чистые сценарии, без различных инфраструктурных настроек — это очень удобно;
3. Встроенная система плагинов;
4. У меня с самого начала понятные формулировки степов, поэтому после того, как произошел мапинг результатов во внешнюю систему, я без труда понимаю, что происходило в этом сценарии;
Это дорого. SpecFlow(cucmber) — определенный стандарт, а это значит, что есть множество third-party libraries, что инструмент активно развивается.
Вначале в команды автоматизации перестали искать новых кандидатов. Со временем люди либо перешли в разработку, либо ушли из компании. Никого не разгоняли.
В компании каждая команда разработки состоит из 4 DEV и 2 QA. Тест кейсы формитуют QA, так же они формируют сценарий в SpecFlow. Если не хватает реализаций в автотестах внутри команды решают кому это будет сделать проще, чаще всего это DEV.
SpecFlow из коробки предоставляет огромное количество фич, реализация их для framework задача очень трудозатратная. Мы в одном из проектов брали BddFy и доводили его до нужного состояния, на проработку основного функционала потребовалось 2 месяца dev (верхнеуровневая архитектура + DI + converter-ы + читабельный report), а это все еще и поддерживать надо самим.
Или вопрос про BDD подход?
Паттерны решают проблему. Есть ситуации, в которых данный паттерн не применим — небольшие проекты в разработке, которых принимает участие не больше 3 команд(10 DEV, 6 QA). Если проект крупный с четким разделением зон ответственности(DEV, DevOps, ItOps, BA, QA,...), то выделение команды QAA логичный шаг.
В идеальной ситуации не различаются. Думаю уже есть команды, которые смогли реализовать Cucumber(любой BDD с Gherkin синтаксисом) first подход и наслаждаются жизнью.
Современный тенденции говорят об обратном. Из последнего разделение Dev на backend, frontend, database, devops. Разделение позволяет писать более качественный код.
Все зависит от руководителя и от личностных качеств работника, но во большинстве случаев, как бы это грустно не звучало, все именно так. Исходя из личного опыта, можно подойти к DevTeam Lead любой команды и попросить, чтобы он проводил code review и составил план обучения. Чтобы быть отличным автоматизатором, ты должен быть хорошим разработчиком.
QAA должен обладать определенными знаниями, которыми QA не обладает:
Без этих навыков невозможно написать стабильную, масштабируемую систему исполнения тестов.
Проблема неидеальности Вашего реального проекта решается выделением одного QA команде QAA. Таким образом сразу решаются еще и следующие проблемы, если при автоматизации применяется BDD:
Скажу честно, первым делом, когда прихожу в команду автоматизации, договариваемся, что если кейс непонятен, скидываем, либо выделенному QA, либо автору. Это минимизирует время потраченное на автоматизацию, так же помогает решить проблему с подбором пересонала, с которой Вы столкнулись:
Это несправедливо по отношению к разработчикам и DevOps. У меня был опыт, когда Solution Architector захотел поробовать «новенькое» и выстроил архитектуру приложения для e2e тестов и это был однозначно очень ценный опыт. Наличие людей с оптытом в DevOps и/или разработки очень положительно сказывается на системе для автоматизированного тестирования, особенно, если система большая (>5000 сценариев), а запускаться тесты должны часто. Нужны ли в команду автоматизации люди с опытом «ручного» тестирования — нужны, но как мне кажется их количество может составлять (25-30% от команды). Задачи в командах автоматизации очень разные:
1. донастройка тестовых environment(octopus, puppet);
2. подготовка образов(docker);
3. CI;
4. Оптимизация времени прогонов;
5. Уменьшение времени, затрачиваемого на поддержку системы;
6. Тестовая инраструктура далека от идеала, для всего нужны плагины, форки;
7. Ведение документации в wiki;
8. Нагрузочное тестирование;
9. Интеграция со сторонними системами (Allure, Kibana, Jira, ...);
Был опыт, когда один человек писал формулировки сценариев, другой писал реализации, сделало ли это второго плохим автоматизатором? Я считаю нет, он делал все, что я перечислил выше и при этом писал очень качественный код. Я бы все таки предложил разделять зоны ответственности. Regression test suite — лицо «ручных» тестировщиков, все должно быть в идеальном состоянии, чтобы это мог воспроизвести человек без опыта, если это не так, тест кейс должен быть переписан. В этом случае автоматизатору становится необязательно иметь опыт в «ручном» тестировании, а можно сконцентрироваться на своей зоне ответственности. И это не должно быть утопией, как преподнесено в статье(по крайней мере мне так показалось), это должно быть правилом.
Что касается ответа на вопрос статьи :
Я начинал на позиции jun BA, после закрытия проекта предложили заняться тест дизайном, так я попал в QA отдел, параллельно взял удаленный проект в веб-разработке. Потом перешел в автоматизацию. Там решил развиваться не в менеджерскую позицию, а в техническую, в итоге осуществлял экспетризу в нескольких командах и за полтора года автоматизировал всего 6 кейсов(базовый набор тестов в новой системе). Недавно понял, что настал тот момент, когда накладно мониторить изменения в автоматизации и разработке и перешел в разработчики. Начинал свой путь в BA, поскольку было пересечение проектной специфики и бакалаврской работы.