Автотестер А1

Попытка 3 или Успешная попытка Научить тестировщиков писать автотесты

Тогда пришла в голову гипотеза, что если мы обучим тестировщиков самостоятельно разрабатывать автотесты — то пофиксим все наши боли. Итак, с чем мы начали?

  1. Для начала мы выстроили правильную пирамиду тестирования. Согласно ей, наша тестовая стратегия заключалась в том, чтобы тесты были на разных слоях приложения. И между каждыми слоями должны быть интеграционные тесты. И руками тестироваться должны только приемочные тесты. При этом сразу после приемки — они автоматизируются. То есть в следующую итерацию тестировщик снова тестирует ТОЛЬКО изменение.
  2. “Размазали” процесс автоматизации тестирования по команде. Так как тесты были разные, то и разрабатывали их разные члены команды. Тесты на api разрабатывались разработчиком api. Фронт-разработчик покрывал свои UI-компоненты тестами. Тестировщик должен быть запроектировать тестовую модель и реализовать интеграционные тесты, которые исполнялись со стороны браузера (selenium тесты).
  3. Использовали простые инструменты для автоматизации тестирования. Мы решили не усложнять себе жизнь и выбрали наиболее простую обертку над selenium-ом. На текущий момент — это selenide, если ваши автотесты пишутся на java.
  4. Создали инструмент для написания автотестов непрограммистами. Об этом бибиотеке (Akita BDD) уже была написана статья в нашем блоге https://habrahabr.ru/company/alfa/blog/350238/. И благодаря тому, что мы используем BDD, смогли вовлечь аналитиков в написание автотестов. Кстати, библиотека в open source: https://github.com/alfa-laboratory/akita и https://github.com/alfa-laboratory/akita-testing-template
  5. Научили тестировщиков чуть-чуть программировать. Среднее время обучения занимало от 2 недель до 2 месяцев.

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

Когда команда сама участвует в разработке автотестов — они сами отвечают за тестовое покрытие и понимают, какое количество тестов уже написано, и какое необходимо еще дописать, чтоб уменьшить время на ручную регрессию. Не происходит дублирования автоматизации одних и тех же сценариев. Так как разработчики о них в курсе, и при написании своих e2e-тестов и юнит-тестов смогут предупредить тестировщика, об отсутствии необходимости автоматизировать определенные сценарии.

Быстро решается проблема устаревших автотестов. Когда продукт быстро развивается, наличие доп. человека отвечающего за автоматизацию генерит для него много бессмысленной работы. Потому что пока он сегодня автоматизирует по прототипам какой-то новый набор тест-кейсов, дизайнер с PO могут принимать решение о том, что логика полностью будет другая. И получается, что на следующий день ему снова надо переделывать свои тесты. Только находясь всегда внутри команды, можно “держать руку на пульсе” и понимать, какие тесты имеет смысл автоматизировать уже сейчас, а с какими имеет смысл повременить.

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

А не пострадает ли качество тестов

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

Я расскажу вам историю, которая приключилась со мной. Когда я только пришла в Альфа-Банк, там уже был свой фреймворк для автоматизации тестирования. Он разрабатывался выделенной командой разработчиков автотестов, про которую я уже говорила. Разрабатывался на протяжении 2-3 лет. Это был монструозный франкенштейн, научиться пользоваться которым даже бывалому разработчику было сложно. Соответственно, любые попытки научить тестировщика автоматизировать тесты с его помощью заканчивались провалом. А также попытки затащить этот инструмент в команды.

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

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

Сейчас эта библиотека используется более чем в 20-ти командах. И она сама развивается — тестировщики из команд постоянно контрибьютят и дополняют при необходимости новыми шагами.

Возможно, вы спросите, а причем тут отказ от разработчиков автотестов, когда ты нам рассказывала сейчас про командную работу над автотестами. Дело в том, что ситуация с наличием разработчика автотестов и разработчиками внутри команды напоминают ситуацию, когда слишком много «поваров на кухне». То есть приводит к тому, что члены команды наступают друг на друга (или на код друг друга). И в итоге мы получаем картинку, когда разработчики приложения перестают писать код автотестов, а значит, перестают знать контекст проблемы написания автотестов и то, как они могли бы их решить или не допустить при написании своей части кода.

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

Рассмотрим на конкретном примере: когда наш фронт-разработчик начал пробовать писать автотесты, и познал боль написания xpath-запросов до различных ui-компонент на странице — то предложил в момент верстки страницы создавать уникальные css class name для удобного поиска элемента на странице. Таким образом мы смогли стабилизировать тесты и ускорить их написание за счет упрощения поиска этих элементов. А у фронт-разработчика просто появилось новое правило в работе — которое не осложняло его рабочий процесс ни на йоту

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

Выводы

  • Наличие выделенной команды автотестеров — это не agile.
  • Наличие выделенных разработчиков автотестов — это дорого для продукта/команды
  • Поиск/хантинг таких людей дорог и долог. И это тормозит развитие продукта
  • Разработка автотестов значительно отстает от разработки продукта. В итоге мы получаем не максимальное велью от автоматизации тестирования.

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

Ну и, наконец, команда сама должна захотеть писать автотесты и сама решить, кто что будет делать. Без принуждения «сверху».

p.s. Если вам интересен мой опыт, то приглашаю в свой блог (http://travieso.me). Там опубликованы все мои выступления, статьи, лекции и заметки.

Вы можете помочь и перевести немного средств на развитие сайта

Диагностические приборы серии Автотестер.

Приборы серии «Автотестер» предназначены для диагностики систем управления двигателями с впрыском бензина с различными типами контроллеров (блоков управления).

Название прибораПоддерживаемые типы контроллеровФото прибораКраткое описание
Автотестер BMWMotronic: М1.1, М1.2, М1.3, М1.7, М1.7.2, М1.7.3, М3.1, М3.3, М3.3.1, М3.3.2, ME5.2, MS40, MS41, BMS43, BMS46Автотестер позволяет:
Сканировать блоки управления Motronic: М1.1, М1.2, М1.3, М1.7, М1.7.2, М1.7.3, М3.1, М3.3, М3.3.1, М3.3.2, ME5.2, MS40, MS41, BMS43, BMS46, сканировать блоки управления наиболее распространенных систем AIRBAG и ABS/ASC и:

  • отображать на ЖКИ тип сканируемого блока управления (БУ) и идентификационные номера БУ;
  • считывать накопленные ошибки и выводить на ЖКИ краткое их описание;
  • стирать ошибки запомненные в БУ;
  • запоминать номера считанных ошибок в тестере;
  • осуществлять быстрый вход в просмотр запомненных тестером ошибок;
  • сбрасывать сигнализацию сервисных интервалов;
  • управлять исполнительными механизмами двигателя для визуального контроля их работоспособности.

Инструкция по эксплуатации в формате MS Word

Автотестер Святогор-RenaultFENIX-5Прибор позволяет просматривать параметры работы двигателя, управлять исполнительными механизмами, просматривать ошибки, а также сбрасывать их.
Инструкция по эксплуатации в формате MS Word
Автотестер М1.5.4Bosch M1.5.4Bosch M1.5.4.NЯнварь-5Прибор позволяет просматривать идентификационные данные, комплектацию автомобиля, состояние каналов АЦП контроллера, более 20 параметров работы двигателя, включая температуру, угол опережения зажигания, расход топлива и многие другие, управлять исполнительными механизмами (форсунки, модуль зажигания, вентилятор системы охлаждения и др.), регулировать обороты холостого хода и содержание СО в отработанных газах (только для автомобилей без датчика кислорода), просматривать текущие и сохраненные ошибки, а также сбрасывать их.Инструкция по эксплуатации в формате MS Word
Автотестер M7.9.7Bosch M7.9.7Прибор позволяет просматривать идентификационные данные, состояние каналов АЦП контроллера, более 60 параметров работы двигателя, включая температуру, угол опережения зажигания, переменную нагрузки и многие другие, тестировать исполнительные механизмы (форсунки, модуль зажигания, вентилятор системы охлаждения и др.), регулировать обороты холостого хода, просматривать ошибки, а также сбрасывать их.Инструкция по эксплуатации в формате MS Word
Автотестер MP7.0 Euro-2 и Euro-3Bosch MP7.0Прибор позволяет просматривать идентификационные данные, состояние каналов АЦП контроллера, более 70 параметров работы двигателя, включая температуру, угол опережения зажигания, переменную нагрузки и многие другие, тестировать исполнительные механизмы (форсунки, модуль зажигания, вентилятор системы охлаждения и др.), регулировать обороты холостого хода, просматривать ошибки, а также сбрасывать их.Инструкция по эксплуатации в формате MS Word
Автотестер MP7.0 Euro-2Bosch MP7.0Прибор позволяет просматривать идентификационные данные, состояние каналов АЦП контроллера, более 20 параметров работы двигателя, включая температуру, угол опережения зажигания, переменную нагрузки и многие другие, тестировать исполнительные механизмы (форсунки, модуль зажигания, вентилятор системы охлаждения и др.), регулировать обороты холостого хода, просматривать ошибки, а также сбрасывать их. Инструкция по эксплуатации в формате MS Word
Автотестер МИКАС 5.4МИКАС 5.4Прибор позволяет просматривать идентификационные данные, комплектацию автомобиля, состояние каналов АЦП контроллера, более 80 параметров работы двигателя, включая температуру, угол опережения зажигания, расход топлива и многие другие, управлять исполнительными механизмами, просматривать ошибки, а также сбрасывать их.
Инструкция по эксплуатации в формате MS Word
Автотестер МИКАС 7.1МИКАС 7.1Прибор позволяет просматривать идентификационные данные, комплектацию автомобиля, состояние каналов АЦП контроллера, 116 параметров работы двигателя, включая температуру, угол опережения зажигания, расход топлива и многие другие, управлять исполнительными механизмами, просматривать ошибки, а также сбрасывать их.
Инструкция по эксплуатации в формате MS Word

По вопросам приобретения «Автотестера» обращайтесь по адресу [email protected]

27.04.2004

Попытка 2 Разработчик автотестов является частью 2-3 команд

Тогда я подумала, что если автотестер занят примерно на 50 %, то, может, попытаться «шарить» его на 2 команды? И вот что у нас получилось:

Выходит, что у разработчика остается около 20 часов на кодинг в недельном спринте. И тут проблема оказалось простой: ему просто стало не хватать времени. Переключение контекста между продукта привело к тому, что теперь он не мог быстро включаться в процесс автоматизации. И у нас снова проблема с тем, что разработка автотестов отстает от развития продукта. К тому же командам оказалось весьма сложно синхронизироваться, чтоб их встречи не пересекались и чтоб разработчик успевал на все встречи у команд.

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

Попытка 1 На команду выделен 1 тестировщик и 1 автотестер

Первое, что пришло мне в голову — это попытаться обеспечить каждую команды разработчиком автотестов. Ключевое слово — попытаться. За целый год я прособеседовала более 200 кандидатов, и только трое из них оказались в нашей команде. И тем не менее, мы все равно решили попытаться и по крайней мере пропилотировать процесс, когда разработчик автотестов внутри команды. Наш процесс тестирования снова претерпел изменения:

  1. Теперь, когда артефакт приходил на тестирование, тестировщик делал приемку.
  2. Затем тесты на этот артефакт сразу же автоматизируются.
  3. Таким образом вся наша регрессия — автоматизирована.
  4. И артефакт деплоится на прод с уже реализованными автотестами.

Казалось бы, все идеально. Но спустя пару спринтов обнаружилось следующее:

  • Продукт/проект не генерировал соответствующую нагрузку на автотестера. Это несмотря на большое количество встреч, которые присутствовали у команды. И на которые в среднем в недельном спринте тратилось около 10 часов.
  • При этом автотестер отказывается заниматься функциональным тестированием, если попытаться оставить его одного в команде.
  • Но и тестировщик не настолько компетентен, чтобы писать автотесты самостоятельно.
  • Когда же предложили писать сервисы для приложения разработчику автотестов — он отказался, так как его навыков не хватало. И как ни странно, не все автотестеры заинтересованы в развитии себя как разработчика.

Добавить комментарий

Похожие записи