Комментарии 12
Большое спасибо за статью. Подскажите, пожалуйста, сколько времени прошло от первой попытки до текущего результата? Прошу прощения, если упустил это в статье.
Часто сталкиваюсь с ситуацией, когда компания страдает от недостатка автоматизации и нанимает сеньора/лида/команду со словами "мы хотим, чтобы вы сделали, как надо". Однако потом оказывается что-то в духе "у нас уже есть 5 E2E ручных тестов, которые мы гоняем раз в месяц, но хотим ежедневно. Осталось только заскриптовать." Или, что ещё хуже: "наши эксперты-программисты уже написали фреймворк для вас, но у них нет времени поддерживать, пока этим занимаются ручные тестировщики, но они тоже начали жаловаться на недостаток времени". И в том, и в другом случае команда автоматизации тратит больше времени не на то, чтобы "сделать, как надо", а на то, чтобы объяснить, что текущие практики не соответствуют (физически не могут, к сожалению) ожидаемым результатам, и показать (читай "продать") те baby steps, которые приведут к качественным изменениям. При этом менеджеры искренне удивляются, почему нанятые специалисты до сих пор не могут сделать автоматизацию стабильной. Достаточно типичным является диалог, когда автоматизатор предупреждает, что данная попытка приведёт к ситуации
"стабильности запусков не было и понимания, как это сопровождать — тоже"
на что менеджеры говорят что-то в духе "откуда ты знаешь — ты же не пробовал в нашей компании? Не сравнивай нас с другими — мы другая компания". Фактически, автоматизаторов просят пройти весь путь от первого подхода и первой попытки заново.
Данная статья хорошо показывает реальный опыт прохождения этого пути. Я искренне надеюсь, что она поможет компаниям осознать, сколько времени и ресурсов уходит на "попробовать" и прийти к тому, с чего они могли бы сразу начать.
Казалось бы, можно заложиться на эту тенденцию к динамике изначально, при выборе архитектуры автоматизации. Но на практике никогда не дают времени хоть сколько нибудь достаточно всмотреться в перспективу и продумать более менее безболезненный путь. Тебя всегда гонят вперед.
Автоматизация для менеджеров состоит только из преимуществ и единственный ее «недостаток» это ее стоимость. Поэтому они считают всякие ROI. У меня от этого слова глаз дергаться начинает, простите.
Я обычно так обьясняю: задача тестирования предоставлять критическую информацию о состоянии продукта. Автоматизация этого процесса, дает соответственно повторяемость, разгрузку человеческого ресурса, бескомпромиссную точность (которая часто для начинающих оборачивается сюрпризом в виде нестабильных тестов). В результате у нас появляется поток информации, который нужно обработать. Разбирать, является ли остановка ошибкой в системе автоматизации или в продукте. Соответственно, роли немного меняются. Теперь тестировщик занимается анализом того, что выдала автоматизация, и уже по результатам анализа заводит репорты.
У нас например в день вываливается столько результатов тестов, по всем билдам, что просмотреть их все физически невозможно. И тут это промах менеджмента заказчика, что им важно количество автотестов. А то, что генерируемую этими тестами информацию невозможно обработать никакими силами, уже никого не волнует. И получается такая ситуация как «горшочек, не вари». И это я молчу про то, сколько бывает тестов, которые пишут лишь бы цифры сходились. Поставь неправильную цель и загубишь все. А происходит все оттого, что заказик сам знает как правильно, и никого ни о чем не спрашивает.
А вот теперь самое интересное, касательно эффективности.
Я считаю есть единственная метрика эффективности автоматизации. Если с ней плотность выявления проблем в продукте увеличилась. — она эффективна, если нет, то она в данном случае неэффективна. Вообще плотность выявления проблем в продукте, единственная метрика для какого бы-то ни было тестирования. Все остальное не имеет прямого отношения к цели тестирования.
Вы скажете что-то в духе: «Но как же, количество багов в продукте к релизу будет меньше!».
Не согласен. Затраты на выявление следующей ошибки будут расти, да. А количество багов нам не известно никогда.
Вспомним известную цитату Э. Дийкстры: «Тестирование может лишь показать наличие ошибок, но не их отстутствие». Не надо питать иллюзий, любая сколь-нибудь сложная программа — черный ящик.
Так вот, автоматизация тестирования в частности может вполне быть неэффективна на продукте который часто претерпевает изменения, или находится на этапе формирования.
На помощь приходит здравый смысл. Если у вас ручное тестирование находится в хаотичном состоянии, например в основном это исследовательское тестирование, к которому часто прибегают на сырых проектах, который еще не оброс документацией и пр., то автоматизировать наверное рано, получится автоматизированых хаос.
А регрессию, т.е. то, что давно и всегда должно работать автоматизировать вполне нужно.
Исходя из этой задачи вы выбираете, что нужно автоматизировать. Логично начать с тех тестов которые, наиболее легки в реализации.
Бонусом ко всему вышесказанному добавлю, что автоматизатор должен разбираться в архитектуре приложения. Это обязательно, чтобы правильно писать тесты, и чтобы писать правильные тесты. Например, при использовании «серых» методов управления программой, это позволит понять, какие слои приложения будет охватывать сценарий. Если я дёрну какую-то внутреннюю функцию в приложении для чего-то там, эквивалентно ли это тому, что будет происходить при использовании вживую. Очень важно четко понимать где твой автотест заходит за черту своей целесообразности.
Я например пишу е2е тесты под эмулятор приложения. И иногда, несмотря на шестилетний опыт, обжигаюсь на том что забываю, что реальный, назовем его — «бекэнд», будет вести себя не так как моки. Т.е. я проверяю работу приложения с моками «бекэнда». Часто моки ведут себя идеальнее «бекэнда». Тут на помощь приходят разработчики и говорят, что тестировать эту функцию на моках нет смысла. Поэтому нужно разбираться в архитектуре и слоях приложения, чтобы не тратить силы на то, на что тратить силы не нужно, а тратить их на то, что действительно полезно.
P.S. У нас сейчас идет пятая инкарнация автотестирования за восемь лет, самая живучая и перспективная пока, но не без проблем конечно. Правда, проект серийный, поэтому заказчик может себе позволить сеять, сжигать и сеять заново.
Даже сложно что-то добавить, но я попробую)
1) автоматизаторов нужно плотнее интегрировать в остальную команду и это не только тестировщики но и разработка. Многие проблемы решаются в разы быстрее, если налажено такое взаимодействие.
2) Позволю себе не согласиться с единственной метрикой автоматизации. Да, она повысит плотность, но не сама по себе, а высвобождая ресурсы ручных тестировщиков. Поэтому метрик наверное будет как минимум на 1 больше — высвобождаемое время ручных тестировщиков. Полезных метрик конечно)
2) Я имею ввиду это конечная метрика в которую вливается все. Плотность обнаружения ошибок повышается, конечно, в большой степени при помощи людей, которые теперь получат больше времени на нужные, но сложные для автоматизации сценарии для проверки руками. И, при хорошо настроеной автоматизации заведение репортов на тривиальные ошибки должно сократиться. А само по себе высвобожденное время никакая не метрика эффективности автоматизации тестирования. Ведь у нас нет цели освободить людей от работы. А скорее, с помощью компьютерных технологий увеличить эффективность человека, по большому счету.
Спасибо за проявленный интерес.
Все описанное в статье заняло около 3х лет. ± 2 месяца.
Мы тоже искренне надеемся, что наш опыт кому-то поможет.
Странная автоматизация, когда время на прохождение автотеста, больше времени ручного тестирования=)
В большинстве случаев время прохождения автотеста меньше времени ручного тестирования. Но это не значит, что если это не так, то это что-то странное. Потому что не совсем корректно сравнивать машиночасы с человекочасами.
У меня было несколько примеров на практике: тестирование совместимости и compliance testing (прошу прощения, не знаю, как это нормально переводится на русский). Представьте, что у вас есть приложение, которое теоретически может конфликтовать с антивирусами (драйвера, системные перехваты и т.п.). Скорее всего вам придётся регулярно проводить тестирование на машинах с разными антивирусами. Ручные тестировщики делают это так: держим машины с установленными антивирусами, а сам процесс тестирования выглядит следущим образом:
- обновляем версию антивируса, устанавливаем последние модули проверки;
- делаем новый снепшот машины для следующего прогона;
- устанавливаем наш продукт;
- тестируем;
- откатываем на снепшот;
- удаляем самый старый снепшот для экономии ресурсов.
В данном случае тестирование очень небольшое, потому что нам достаточно буквально несколько (максимум пару десятков) тест-кейсов, чтобы убедиться, что не возникают deadlock'и или прочие конфликты с антивирусом. В итоге оказывается, что большую часть времени тестировщики тратят на пункты 1, 2 и 5, 6, т.е. те, которые с нашим продуктом вообще не связаны.
К сожалению, в то время, когда я этим занимался, руками обновлять или конфигурировать антивирусы было в 100 раз проще, чем надёжно автоматизировать (попробуйте надёжно кликнуть кнопку "Обновить" в кастомных GUI под Windows).
В итоге, в данном случае пожертвовать временем ради освобождения ручных тестировщиков будет вполне себе разумной идеей. Автотесты автономно гоняются раз в неделю, пусть это даже будут 2 машинодня по выходным и 2 человекачаса в понедельник на разбор результатов. И это будет примерно в 4 раза лучше чем 1 человекодень каждую неделю.
Аналогичная история с compliance'ом: если вам раз в месяц нужно проверить совместимость с обновлениями Windows, освобождение ручных тестировщиков от этой задачи будет ценнее сэкономленных машиночасов. Да и если посмотреть, то подобных задач не так уж и мало. Другой вопрос, что в большинстве своём они связаны с нефункциональными требованиями, куда автоматизация не всегда успевает (или физически может) добраться, кроме, может быть, требований производительности и надёжности под нагрузкой.
Можно немного пояснений? Не могу уловить, почему автотесты у вас работают дольше, чем ручной тестировщик при выполнении всех пунктов 1-2-3-4-5-6 последовательно? То что вы их запускаете в нерабочее время понятно. Это разумно. Но почему дольше?)
Или вы имели ввиду, что время одинаковое, просто вы экономите рабочее время?
Тогда тут нужно считать затраты на разработку и сопровождение этого теста.
Разница во времени появлялась из-за того, что пункт 1 (обновление антивируса) был очень тяжёл для автоматизации. Вот несколько проблем, которые легко решаются вручную, но сложны в автоматизации:
- Какие-то антивирусы не предоставляли возможность конфигуации/обновления на клиенте — это означает, что надо каким-то образом тригернуть обновление с серверной компоненты.
- Антивирусы не склонны, по понятным причинам, предоставлять возможность конфигурации/обновления извне (CLI, например). У некоторых антивирусов есть возможнось импортировать настройки, за что им огромное спасибо. У большинства (по крайней мере, на тот момент) вся конфигурация жила в кастомных UI. Это касается и серверных компонент из предыдущего пункта.
- Обновление лицензии. Если лицензия кончилась, человек знает, что делать. А для автотестов это, естественно, головная боль.
В конечном итоге, мы автоматизировали тесты только для тех антивирусов, для которых нашли надёжные решения проблем выше (осталось примерно 3-4 штуки). Сам процесс стал другим:
- Установка антивируса на чистую машину.
- Установка/выбор триальной лицензии.
- Обновление модулей.
- Запуск автотестов.
В данном случае получилось ещё избавиться от хранения машин с антивирусами и сэкономить на лицензиях (жаба особенно душила покупать лицензии, чтобы использовать раз в месяц). Но, естественно, пришлось провести анализ модулей, которые присутствуют в триальной лицензии, чтобы понимать, что тестирование совместимости действительно имеет смысл.
Плюс ещё получилось иметь возможность тестировать разные версии одного антивируса (процесс установки редко меняется).
Естественно, этот процесс намного медленнее пункта 1 (обновление антивируса вручную), даже с учётом того, что пункты 2, 5 и 6 (управление снепшотами) больше не нужны.
Надеюсь, достаточно подробно ответил на Ваши вопросы.
Пункты перечислены последовательно, но на самом деле они все должны выполняться параллельно.
Как-то странно написано и сразу же за этим идет последовательность.
Последовательность важна — нельзя вкладываться в ту же инфраструктуру до тех пор пока не будет полностью понятно что и как будет тестироваться. Также должна быть полная определенность с фреймворками, а это зависит от квалификации тех же техлидов — какие фреймворки они вообще знают.
У меня есть очень больные примеры, когда инфраструктура определялась заранее и главное — на нее были потрачены огромные деньги, а потом оказывалось, что она не подходит.
Про электробаги в статье ничего не написано, но тема автотестирования железа — это вообще песня сегодня.
Тут поле непаханное граблей и люди, приходящие из софта, думают, что все это очень легко автоматизировать, так как «питон и фреймворки все порешают». Ага, конечно. Только учти, что вот эту кнопочку надо нажать ручками, а тут у нас хитрый электрический интерфейс на мотор. А саму плату управления мы еще не заказали, но ты же умными тестами гарантируешь ноль багов в прошивке, правда?..
Думают ли автотесты об электробагах