OpenQuality.ru
Качество программного обеспечения
И правда, зачем? В своей нашумевшей статье “What is Test Automation” Steve Rowe пишет:
“Test automation is simply an automatic way of doing what testers were doing before”.
Чуть позже Стив счел нужным уточнить свою позицию:
“I am describing test automation, not testing. The two are far from synonomous. Test automation *is* a replacement for what testers once did, but it isn’t a replacement for all of what testers do.”
Но джинн был выпущен из бутылки первоначальной статьей, и затолкать его обратно было не так-то просто. Публикация Стива вызвала немало откликов. Самым разумным из них можно счесть ответ, который опубликовал James Bach. Джеймс пишет:
“Test automation is any use of tools to aid testing. Test automation has been around since DAY ONE of the computing industry. And never in that history has test automation been an “automatic way of doing what testers were doing before”, unless you ignore a lot of what testers actually do.”
Далее Джеймс развивает свою точку зрения и в заключении отмечает (кстати, комментарии к статьям заслуживают отдельного рассмотрения):
“Test automation cannot reproduce the thinking that testers do when they conceive of tests, control tests, modify tests, and observe and evaluate the product. Test automation cannot perform sapient testing. Therefore, automation of testing does NOT mean automation of the service provided by the software tester.
In summary, test automation means applying tools to testing…”
Итак, по мнению Джеймса, автоматизация тестирования есть использование различных инструментов в процессе тестирования приложений. Согласимся с этой точкой зрения и попробуем развить данную тему.
Процесс разработки программного обеспечения может строиться по разным моделям. Наболее известна модель водопада, а самыми популярными на текущий момент являются т.н. “гибкие” технологии. Каждая из моделей предполагает тот или иной метод разработки и добавления новой функциональности. Сравнение методов выходит за рамки данной статьи, поэтому остановимся вот на чем.
Водопадная модель (в базовом варианте) предполагает определенную фиксированную последовательность этапов разработки (Requirements -> Design -> Implementation -> Verification -> Maintenance.) Все требования к продукту утрясаются заранее, а тестированию отводится отдельный этап, в который можно заложить сроки, необходимые для полного тестирования приложения. Выглядит разумно, но мир устроен сложнее. Требования к продукту могут измениться уже в процессе разработки, а конкуренция на рынке делает необходимым оперативный выпуск обновлений к продуктам. В таких условиях agile-технологии выходят на первый план, а выделить на тестирование продукта столько времени, сколько выделялось в водопадной модели, не представляется возможным.
Но мы не хотим жертвовать качеством, верно? Вот здесь на помощь и придут автотесты. Грамотно написанные и отлаженные автотесты позволят оперативно провести регрессионное тестирование функциональности продукта, а у тестировщиков будет время на тестирование новой функциональности, на интуитивный, творческий анализ работы приложения - на тот анализ, на те баги, которые невозможно найти при автоматизированном тестировании, но исправление которых критически важно для качественной работы продукта.
Отметим, что регрессионное тестирование - не единственная сфера применения автотестов. Анализ производительности, стресс-устойчивости, локализация продукта - вот далеко не полный перечень этапов разработки, при которых автотесты будут незаменимы.
P.S. Есть пара минут ?
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Pingback : OpenQuality.ru | Обойдемся без тестировщиков? | October 6, 2008
[…] заслуживает всяческого уважения, и о несомненной пользе автотестов мы уже говорили. Но вот достаточно ли […]
Pingback : OpenQuality.ru | Автотесты: мифы и реальность | October 17, 2008
[…] статье “Автоматизация: зачем это нужно?” была подчеркнута важность подготовки и внедрения […]
Автор комментария : Artour Bakiev | December 8, 2008
Очень животрепещущая тема - что же выбрать в качестве инструментария?
С удовольствием ознакомился бы с обзором, посвящённым конкретным продуктам - например, сравнение TestComplete vs. AutoIt. Что скажет автор?
[Ответить]
Автор комментария : Капитан Аляска | December 9, 2008
Автор скажет: спасибо за интересный вопрос ! :)
Небольшой обзор есть здесь: http://blog.openquality.ru/tool-choice/
Его главная мысль: выбор в соответствии с контекстом будет наиболее эффективным (в статье кратко описано, на что стоит обратить внимание).
Сравнение TestComplete и AutoIt неспортивно: они в разных весовых категориях :) Все-таки, TestComplete - это среда для создания и прогона автотестов, а AutoIt - всего лишь скриптовый язык. Пусть у AutoIt много вкусностей, но это ничего не меняет: его возможности ограничены. В частности, в AutoIt нет exceptions, он видит только common Windows controls, но не видит .Net controls, плохо видит динамические веб-страницы и т.п.
Для меня AutoIt интересен, в первую очередь, быстрым стартом. То есть, если у тебя нет каких-то сверхтрудных задач, и возможности AutoIt покрывают твои нынешние и будущие задачи, то AutoIt - хороший выбор. С ним очень приятно работать: отличная документация с примерами, комфортный подбор функций, даже редактор SciTe понравился - ему, конечно, далеко до студий, но для AutoIt более чем хватает.
Если же проект сложный, то и инструмент нужно подбирать соответствующий - в зависимости от контекста. Возможно, подойдет компромисс - вызов функций AutoIt через Com. Пример здесь: http://blog.openquality.ru/python-autoit/.
Кстати, забавно, что в документации PowerShell библиотека AutoItX - чуть ли не единственная упомянутая “не-Microsoft’овская” библиотека, к которой есть доступ из PowerShell через Com. Это о чем-то говорит :)
В общем, я бы не стал сравнивать TestComplete и AutoIt. Разные инструменты для разных задач.
[Ответить]