OpenQuality.ru
Качество программного обеспечения
Здравствуйте.
В статье “Автоматизация: зачем это нужно?” была подчеркнута важность подготовки и внедрения автотестов. Там же зашла речь о подводных камнях, встающих на пути автоматизации тестирования. Рассмотрим их более подробно.
Миф: Автотесты способны полностью заменить ручное тестирование.
Реальность: Оснований верить такому утверждению ровно столько же, сколько верить в существование серебряной пули. Автотесты не могут быть панацеей (и профилактикой) от всех багов, живущих в программном продукте. Верите ли вы в то, что напичканный электроникой робот способен определить все недомогания в человеческом организме и оперативно от них избавить? Вот было бы здорово. Но на самом деле интуицию, опыт, мышление врача такой робот не заменит. Зато он способен избавить эскулапа от выполнения рутинных действий, которые можно четко обозначить и регламентировать. То же самое в тестировании.
Миф: Приобретение коммерческого, использование бесплатного или разработка собственного инструмента для написания автотестов есть гарантия успеха на ниве автоматизации тестирования.
Реальность: Инструмент- это не стратегия и даже не тактика. Необходимо полное понимание того, что именно, как, когда и почему мы хотим тестировать. Каких целей мы хотим достичь помимо “чтобы багов не было”? Ищем подспорье в TDD? Заинтересованы в регрессионных тестах? Какую функциональность, на каком уровне (GUI, API, ядро) мы хотим проверять автотестами в первую очередь? Сколько времени у нас есть и будет? Сколько специалистов? С каким опытом? На все эти и множество других вопросов следует получить ответы еще при выборе инструмента. Одно дело - с легкостью сделать первый шаг (”О, моя прога сама заполняет форму!”) и остановиться на перепутье, другое дело - планомерно пополнять библиотеку автотестов, которые запускаются с каждым билдом. Нельзя автоматизировать хаос. Инструмент - это инструмент, и ничего больше.
Миф: Автотесты позволят существенно сэкономить на тестировании.
Реальность: Да, позволят, ибо не нужно будет проверять одно и то же вручную десятки раз. Однако сыр не бесплатный: затраты на внедрение автотестов могут быть существенными. Автотесты кушать не просят, но нужно подкармливать их создателей :) И еще: создание автотестов следует рассматривать не столько с позиций “сейчас вложусь - потом сэкономлю на тестировании”, сколько с целью повысить качество продукта и скорость его разработки (при условии охвата основной функциональности и регулярных прогонов автотестов). Иными словами, вложения в автоматизированное тестирование - это движение вперед, стремление не столько сэкономить, сколько приобрести.
Миф: Написал автотесты один раз, и можно использовать их до скончания века.
Реальность: Как бы не так. Изменяется продукт - изменяется и автотест. Если автотест завязан на GUI, то изменения в пользовательском интерфейсе могут привести к неработоспособности автотеста. А изменение алгоритмов? А новая функциональность в продукте или переход на другой API? А баги, найденные в автотестах (сюрприз)?
Миф: Грамотно написанные и обновляемые автотесты непогрешимы.
Реальность: Автотесты полезны и архиважны, но за ними нужен глаз да глаз. О ловушках в автотестах мы продолжим разговор в одной из следующих статей. Оставайтесь с нами.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.