Кому следует писать автоматические тесты?
Apr. 6, 2011•0 likes•3,940 views
Download to read offline
Report
Education
Запись презентации Minsk Automated Testing Community www.autotest.by от 06.04.2011
Igor KhrolFollow
Recommended
Повышаем надёжность тестов через JavaScriptIgor Khrol
Test Automation Wargaming SQA Days 17Igor Khrol
“Можно ли перевернуть пирамиду?” – автоматизируем тестирование с меньшим числ...Igor Khrol
Тестировщик в Agile - кто он?Igor Khrol
Автоматизация тестирования: доступна каждому или удел избранных?SQALab
Web driver история одной миграцииIgor Khrol
More Related Content
What's hot
Grail - CodeFest'2015Igor Khrol
Qa Automation - отбрасываем лишнее и тестируем сутьIgor Khrol
Автоматизация визуального тестирования адаптивного дизайна на примере Galen F...COMAQA.BY
Автоматизация тестирования ролей и привилегийSQALab
Webium: Page Objects in PythonIgor Khrol
The fast and the continuousSQALab
Similar to Кому следует писать автоматические тесты?
Test management printMichael Karpov
Automation OverviewKiraKeiss
Шаги мануальщика к автоматизации на крупном проектеSQALab
Как перестать бояться и начать автоматизироватьSQALab
First click тестирование. История одного теста.Дмитрий Силаев
Introduction to Automation TestingReturn on Intelligence
More from Igor Khrol
SeleniumCamp 2016Igor Khrol
Agile.by Gathering – 23 января 2016Igor Khrol
Increase selenium tests stability via java scriptIgor Khrol
Why test automation projects are failingIgor Khrol
Типичные ошибки начинающих писать тесты на WebDriverIgor Khrol
Автоматизация Тестирования - Почему умирают проекты?Igor Khrol
Кому следует писать автоматические тесты?
- 1. Кому следует писать автоматические тесты? Игорь Хрол, EPAM Systems
- 2.
- 3.
- 4.
- 5.
- 6.
- 7. Как эти навыки распределены?
- 8. Результаты Функциональный тестировщик Автоматизатор Потратить время на обучение автоматизации Необходимо потратить ресурсы на изучение продукта Уменьшение ресурсов на ручное тестирование Требуется чётка формализация поставленной задачи Выходной продукт скорее всего не будет соответствовать ожиданиям, в виду того, что функциональный тестировщик делает её первый раз Выходной продукт может не соответствовать требованиям, в виду того, что подрядчик/новый сотрудник не до конца понимает потребности проекта
- 9.
- 10.
- 11.
- 12. Процесс работы
- 13.
- 14.
- 15.
- 16. Вопросы???
Editor's Notes
- Добрый день, уважаемые коллеги. Меня зовут Игорь Хрол. Я занимаюсь автоматизацией тестирования уже около трёх-четырёх лет, в данный момент работаю с командой инженеров по автоматизации тестирования на одном из проектов в компании ЭПАМ Системз. Фокус в основном на автоматизацию тестирования пользовательских интерфейсов и сегодня я буду говорить в основном именно в этом контексте. Что же сподвигло меня прийти сегодня сюда и о чём будет идти речь?
- В данный момент существует множество технологий для автоматизации тестирования: дорогих от ведущих вендоров как HP или IBM, не очень дорогих от менее известных поставщиков. Также есть открытые инструменты для автоматизации тестирования UI. Но после решения об необходимости автоматизации тестирования на том или ином проекте, кроме технологического вопроса об инструментарии, встаёт вопрос о том, а кто конкретно будет заниматься автоматизацией. Мы сегодня попробуем рассмотреть усреднённый проект Х, на котором понадобилось автоматизировать тестирование. Подумаем над тем, какие навыки и умения нужны для выполнения этой работы. Посмотрим на имеющиеся альтернативы в виде функционального тестировщика и специально обученного инженера по автоматизации. Далее на основе вышесказанных посылок мы попробуем найти наиболее эффективный путь работы на нашем проекте Х. Ну и под конец узнаем, можно ли это сделать технически.
- Рассмотрим некоторый проект, в котором встала задача автоматизировать некоторую часть функционального тестирования. Пусть проект сейчас уже частично разработан, частично протестирован. Возможно, сейчас ведётся разработка какой-то следующей версии. Кто есть на проекте: менеджер проекта, разработчики и тестировщики, которые тестируют наш продукт вручную, через пользовательский интерфейс, как чёрный ящик. И вот мы решили внедрять автоматизацию.
- Какие нужны навыки тому человеку, который будет автоматизировать? Он должен знать продукт. Или хотя бы бизнес-область, в которой этот продукт будет работать. Например, финансы, если мы разрабатываем систему для финансовой организации. Он должен знать методологию ручного тестирования. Виды тестов, типы дефектов – всё что связано с тестированием. Так как он должен знать, что именно он будет автоматизировать. Он должен знать методологии и подходы к автоматическому тестированию. Без этих знаний результат автоматизации будет довольно непредсказуем, так как автоматизация будет выполняться наобум. Он должен уметь пользоваться инструментами по автоматизации. Или хотя бы иметь навыки программирования, так как в любом случае автоматизация тестирования – это программирование, пусть и для специфических целей.
- Рассмотрим самый первый вариант внедрения автоматизации, который приходит в голову: отдать её на откуп текущим функциональным тестировщикам. Вспомнив, кто у нас уже есть на проекте, выбор невелик: либо разработчики, либо тестировщики. Разработчики отпадают, так как у них и свой работы хватает, которую никак не можем успеть. Да и не всякие разработчики возьмутся за автоматизацию тестирования, так как эта работа считается неинтересной. Кто такой наш функциональный тестировщик? Он уже давно работает на проекте, все его знают по багам, которые он вносит. Возможно, он уже подустал тестировать одно и то же, и хочет как-то автоматизировать то, что он делает или хотя бы попробовать что-то новое. Он умеет и знает: Знает продукт. В курсе методологий тестирования. Слышал об инструментах по автоматизации и о подходах в ней. Опыта в автоматизации нет.
- Следующей альтернативой в том, кому отдать автоматизацию тестирования – это отдельно обученный человек, который будет ей заниматься. Как наиболее распространённый случай, будет рассматривать человека, до этого внешнего по отношению к проекту. Что он умеет делать: Он не знает продукта. В лучше случае знаком с бизнес-областью. Например, мы пишем очередную социальную сеть, а он по вечерам, в свободное от работы время, сидит «в контакте». Он имеет базовые навыки в тестировании. Владеет методологией автоматизации. Знает инструменты для автоматизации и умеет с ними работать.
- Суммируя навыки функционального тестировщика и инженера по автоматизации получаем примерно следующую картину, как наши требования по умениям распределены у этих людей. Функциональный тестировщик больше знает то, что сверху. Инженер по автоматизации – то, то снизу. Всего не знает никто. Какой из этого мы получаем результат?
- Функциональный тестировщик: Нужно будет учить человека автоматизации тестирования, программированию. Вкладывать на будущее, так сказать. У нас станет меньше ресурсов на ручное тестирование. В будущем, возможно, это окупится, если автоматизация будет успешной. Скорее всего с первого раза ничего не получится, так как работа будет делаться первый раз. Как говорится, первый блин комом… Пока мы будем пробовать следующий и следующий разы, мы получим уже выпущенный продукт, где мы не успели потестировать пользовательские интерфейсы автоматически. Если смотреть на инженера по автоматизации: Мы тратим время на обучению его продукту и внутренним процессам на проекте. Для автоматизации тестирования чего-либо нам потребуются очень чётко описанные тестовые сценарии. Если у нас их не будет, наш инженер просто не будет знать, что автоматизировать. На выходе всё будет либо слишком долго, так как всё будет выполняться по чётки инструкциям / тестовым сценариям. Или другой вариант – мы получим не то, что хотели, так как человек со стороны поймёт всё по-другому. Через какое-то время мы, возможно, и получим то, что хотели, но скорее всего мы продукт к этому времени уже просто зарелизим.
- Как же нам сделать так, чтобы всё было как можно быстрее и дешевле? Давайте позволим каждому заниматься тем, что у него лучше всего получается: автоматизаторам – работать с автоматическими инструментами и программировать, тестировщикам – разбираться с требованиями и писать тестовые сценарии.
- Предложение следующее – давайте позволим автоматизаторам не вникая в детали проекта, разрабатывать фреймворк для написания тестов. Пусть они работают над технической имплементацией на том или другом инструменте для автоматизации. Пусть они сделают фреймворк и скажут фунциональным тестировщикам, как надо писать тесты.
- С другой стороны функциональные тестировщки сделают следующее: Сделают требования к автоматизации: какие действия типичны для нашего проекта, в каком формате хранить данные… Дождутся реализации этого от автоматизаторов и будут писать тесты на готовом фреймворке.
- Схема работы следующая: Функциональные тестировщики анализируют то, что они делают руками и выдают список того, что им нужно, чтобы автоматизировать тот или иной функционал. Например, нужны следующие функции для работы с интернет-магазином: а) Логин на сайт, которому нужно передать имя пользователя и пароль. б) Поиск продукта в) Положить найденный продукт в корзину г) Купить продукт из корзины, используя кредитку 2. Передают требования инженерам по автоматизации. 3. Автоматизаторы реализуют эти функции и отдают результат функциональным тестировщикам. 4. Функциональные тестировщики, используя готовые функции, пишут автоматические тесты.
- Плюсами такого разделения труда является следующее: Мы минимизируем обучение. Во-первых, функциональных тестировщиков автоматизации, а автоматизаторов – бизнес-логике продукта. Из-за того, что каждый участник сфокусирован на отдельной части, мы увеличиваем скорость разработки автоматических скриптов. Ну и функциональные тестировщики имеют возможность пописать код, а не только тестировать всё руками.
- К минусам же можно отнести: Схема работы сложнее, нежели если один человек выполнял бы задачу целиком. Требуется вовлекать людей из функционального тестирования, которые вполне могут быть перегружены задачами по ручному тестированию. Или можно встретить сопротивление команды функционального тестирования, которые могут сказать о том, что «у нас есть автоматизаторы, пускай они автоматизацией и занимаются». Если мы имеем команду автоматизации, которая является отдельной структурой и подразделением, то вполне вероятно сложно будет забрать часть работы у них, ввиду сопротивления самой команды и её руководства.
- В заключение можно сказать, что данный подход был опробован на 2-х инструментах для автоматизации тестирования HP QuickTest Professional и Selenium в связке с Java. В обоих их есть механизмы, позволяющие отделить действия по бизнес-логике, которые пишутся инженерами по автоматизации от тест-скриптов, которые пишутся функциональными тестировщиками.