QA Automation, часть 3: Стратегия автоматизации тестирования
| July 12, 2012 | Posted by Andrey Rebrov under Практики, Статьи |
Вот и нашлось у меня время, чтобы продолжить серию постов про автоматизацию тестирования. Предыдущий можно найти тут.
Когда вопрос с тем, автоматизировать или не автоматизировать тестирование уже решен встает вопрос, а что именно и как автомпатизировать. Если такой вопрос встал перед вами, то это статья для вас, потому что в ней я постараюсь рассказать про стратегию автоматизации тестирования.
Начать стоит с возврата к agile testing quadrants
Здесь мы видим, что для тестировщика актуальна автоматизация в квадратах 2 (functional tests) и 4 (“ility” testing)
При этом данное тестирование будет непродуктивным, если разработчики не занимается юнит и интеграциионным тестирование.
Все это приводит нас к следующей диаграмме, которая показывает как зависимость тестов друг от друга, так и их относительный объем.
Реализация тестов на слое Acceptance tests делится между разработчиками и тестировщиками и тестировщики берут на себя так называемое “pre-GUI testing”. Как можно увидеть из диаграммы, ручные тесты все равно остаются, но их не так много и все чаще, когда говорят о ручном тестирование в agile, то говорят об exploratory testing, но о нем в другой статье.
Итак, из чего состоит процесс внедрении автоматизации тестирования:
- внедрение невозможно при отсутствии процесса тестирования – те, кто будут заниматься автотестами должны понимать принципы и подходы в тестировании, а это достаточно большой пласт знаний, которым разработчики обладают в единичных случаях;
- при внедрении автотестирования надо учесть затраты и выгоды – при этом стоит помнить, что сюда надо включить время на выбор обучение сотрудников, ведение документации по тому, как происходит автотесы, как затраты и повышение квалификации сотрудников, уменьшение время на регрессию как выгода;
- правильно выбрать инструмент для автоматизации (об этом ниже);
- понять, что должно быть автоматизировано полностью, что лишь частично, а что вообще не стоит автоматизировать – цель покрыть все автотестами плохая, потому что не несет пользы продукту;
- определить правила и гайдлайны, как мы подходим к автоматизации – автоматизация это тоже написание кода, поэтому здесь надо соблюдать устоявшиеся инженерные практики.
- позволять начать писать тесты сразу же – порог вхождения должен быть минимальным;
- позволять отделить логику тестов от реализации – в случае чего мы сможем сменить инструмент и реализацию, но сами тесты оставить нетронутыми;
- позволять и подталкивать к использованию известных практик разработки;
- позволять использовать существующие языки программирования и IDE – не надо изобретать велосипеды, в языках разработки многие вещи (например, работа с базой данных) уже давно реализованы;
- имеет активное сообщество.
- Keep It Simple (“KISS”) – не стоит писать сложных структур и кода на будущее, решайте текущие задачи;
- тесты надо чаще запускать для того, чтобы чаще иметь результат – а то будет как с гантелями, которые многие из нас покупают и хранят в шкафу;
- в процесс автоматизации должна быть вовлечена вся команда – хорошие тесты это задача всей команды, а не только тестировщиков;
- чтобы сделать правильно нужно время – не стоит сдаваться, как только возникают какие-либо проблемы, если что нас спасет активное сообщество или коллеги из предыдущего пункта;
- больше практики, меньше теории – проще написать тест и проверить что все ок, чем читать книги и форумы.
-
CaPsULe Mind
