Артур Орлов, d.ati.su

Подводная часть айсберга

Что делать, чтобы автотесты не превратились в Титаник

Здравствуйте, я - разработчик

более 10 лет в разработке на всех этапах:

‣ выслушивание проблемы

‣ формулировка задач

‣ разработка решения

‣ тестирование (в т. ч. и ручное)

‣ внедрение

‣ поддержка/администрирование

Кейс из жизни

1. Selenium-hero Как порой проходит внедрение автотестов

Selenium? Проще простого!

>>> from selenium import webdriver

>>> browser = webdriver.Firefox()

>>> browser.get(‘http://yandex.ru’)

>>> selector = ‘.search2__input .input__control.input__input’

>>> query_field = browser.find_element_by_css_selector(selector)

>>> query_field.send_keys(‘Selenium is awesome!\n’)

Прямо по курсу - айсберг

Генерация отчетов

Запуск тестов Организация кода

Работа с БД, файлами, etc

Работа с браузером

* Грубая эвристическая оценка

Внедрять или не внедрять?

Ожидания и реальность

Чего стоит ждать от автотестов, а чего нет

Когда автотесты заменят ручную работу?

1. продукт не меняет поведение

2. окружение продукта не меняется(браузер, ОС, устройства)

Когда автотесты заменят ручную работу?

1. продукт не меняет поведение

2. окружение продукта не меняется(браузер, ОС, устройства)

Никогда

Зачем тогда все это надо?

❖ быстрая и дешевая проверка стабильного функционала

❖ тестирование на ранних этапах разработки

❖ тестирование работающего продукта при изменениях в инфраструктуре

Чего следует ожидать

❖ смещение фокуса деятельности в разработку и исследования

❖ работа по поддержанию тестов в актуальном состоянии

❖ больше коммуникаций с разработчиками

Как оценить эффективность?

Производительность не изменится «скачком»:

1. Начните разрабатывать

2. Сделайте постоянной частью процессов

3. Отключите/сломайте/дождитесь проблем с тестами

4. Посмотрите, что поменялось ;)

Итак, вы решились ввязаться…

Сколько стоят автотесты?

Эксплуатационная себестоимость внедрения

Снова про айсберг

Генерация отчетов

Запуск тестов Организация кода

Работа с БД, файлами, etc

Работа с браузером

Снова про айсберг

Эксплуатация

Разработка

Компоненты инфраструктуры

❖ тестовое окружение продукта

❖ машины, где запускаются тесты

❖ браузеры (grid, nodes, собственно браузеры)

❖ утилиты (интеграция в процессы, автозапуск, планировщики, мониторинг, уведомления)

Кто будет следить?

❖ тестировщики?

❖ программисты?

❖ системные администраторы?

Вам нужен devops!

Что придется делать?

❖ обновление selenium (grid/nodes/библиотеки)

❖ контроль за версиями браузеров

❖ адаптация тестов к особенностям версий selenium/браузеров

❖ борьба с деградацией тестов

❖ обслуживание инфраструктуры (место на дисках, ресурсы БД, etc…)

Основные принципы эксплуатационщиков

1. Если неприятность может произойти, она произойдет.

2. Даже если неприятность не может произойти, она произойдет.

3. Из всех неприятностей произойдет именно та, ущерб от которой больше.

Если вы не боитесь сложностей

Велосипеды и колеса

Выбираем инструменты

Фундамент автотестов

❖ Язык программирования

❖ Фреймворк организации кода

Выбор языка: основной язык проекта

+selenium доступен почти во всех языках

+помощь программистов

+готовое окружение

- порог вхождения может быть высоким (C++/C#)

- зависимость от коммуникации с программистами

Выбор языка:Python

+низкий порог вхождения

+большой набор существующих инструментов/библиотек

- окружение придется готовить самостоятельно

- справляться со сложностями тоже придется самостоятельно

Как выбрать?

Исходите из ваших конкретных условий

❖ Сколько людей надо будет учить?

❖ Насколько тесное и комфортное взаимодействие с программистами?

❖ Что с юнит-тестами у программистов?

❖ Какие есть особенности/нестандартные/устаревшие технологии в проекте?

Unittest vs BDD

Выбор фреймворка: unittest-style

+программисты про него знают

+есть много паттернов и способов работы

+можно «вклиниться» в тесты к программистам (при их наличии и использовании языка проекта)

- можно выстрелить себе в ногу

- надо продумывать организацию кода

Выбор фреймворка: BDD-style

+доступность почти во всех языках (python: lettuce, behave)

+удобство

+самодокументруемый код (ценность сценариев даже без учета автоматизации)

+минимизация разработки

+снижение порога вхождения в язык

+легкое вовлечение программистов (при использовании языка проекта)

- не годится для всех случаев (например, тестирование REST API)

- не все программисты знакомы с концепцией, надо будет объяснять

Что выбрать?

Кто руководит внедрением автотестов?

❖ Тестировщик - выбирайте BDD

❖ Программист - что выберет он (но лучше, чтобы BDD)

BDD + основной язык проекта = хорошая, годная схема

Советы

❖ учитесь у своих программистов

❖ используйте общие инструменты

❖ не изобретайте велосипеды

❖ не забивайте гвозди микроскопом

❖ думайте о параллельном запуске сразу(10 сценариев x 2-3 минуты ≈ 30 мин!)

❖ не давайте программистам писать сценарии

О самом главном

Люди Кому и зачем нужны автотесты?

Разговор по понятиям: цель тестирования

❖ Тестировщик: обеспечение требуемого уровня качества

❖ Программист: я пишу код - ты ищешь баги

Coder vs developer

Coder:

- пишет код

Developer:

- думает, зачем писать код;

- пишет код;

- думает, как проверять;

- проверяет код;

- проверяет, решена ли задача

Кто нужен для автотестов

❖ Хотя бы один заинтересованный разработчик

❖ Тестировщики, которые не боятся «не знать»

❖ Тестировщики, которые не боятся глупых вопросов

❖ Тестировщики, которые не боятся программистов

К чему готовить команду

❖ Автотесты - марафон

❖ Стремитесь к early usage (написали тест - используем)

❖ Остановка = деградация

❖ Автотесты - очень специфичный код

Как распределять работу

❖ Тестировщики - думают о том, как тестировать, как строить процессы

❖ Разработчики - создают инфраструктуру, помогают писать код

❖ Тестирование != разработка. Пишите сценарии сами

P.S.

Зачем?

❖ Программистам - инструмент верификации работы

❖ Тестировщики - экономия ресурсов на рутинных процессах

❖ Бизнес - дополнительный инструмент обеспечения качества

Зачем лично вам это надо?