Выбираем инструмент для автоматизации тестирования. Базовый подход

Встречаю довольно много информации по прикладному применению автоматизированного тестирования, но вот такой банальный вопрос, как критерии выбора инструмента для автоматизации тестирования остается по большей части в области проб и ошибок. Замечаю, что некоторые при выборе даже не отдают себе отчета, какой тип автоматизированного тестирования они собираются применять и, по сути, упираются лишь в один вопрос: платный инструмент или бесплатный? Но это лишь верхушка айсберга. Неправильный выбор даже бесплатного инструмента для автоматизации тестирования в итоге будет Вам стоить денег в виде затрат на бесплодные попытки успешно применить то или иное решение именно к Вашему проекту. Я не рассчитываю вызвать на дискуссию "зубров" автоматизации, хотя, добро пожаловать, если кто-то усмотрит спорные моменты, но считаю, что новичкам предложенный подход в выборе окажется полезным.
При выборе инструмента для автоматизации тестирования я придерживаюсь следующего базового алгоритма выбора:

1. Определите типы тестирования которые вы собираетесь применять:
• Functional Testing
• Performance Testing
2. Определите какие тесткейсы (сценарии) Вы планируете автоматизировать, а какие нет, и для каких компонентов Вашего продукта
3. Определите технологии и протоколы, которые используются или планируются к использованию в ближайшем будущем компонентами Вашего продукта, тестирование которых подлежит автоматизации
4. Составьте список требований к инструментам автоматизированного тестирования на основании вышеизложенных критериев
5. Выбирайте инструменты на основании составленного списка требований. Если какие-то из них имеют ограничения по этим требованиям - сразу оцените их критичность, и если ограничения критичны - откажитесь от таких инструментов

Я считаю, что типы тестирования, которые планируется применять и ограничения по технологиям используемым в проекте - это ключевые критерии, по которым стоит выбирать инструмент. Все остальные критерии вторичны. Поэтому, когда кто-то просит посоветовать лучший интрумент для автоматизированного тестирования или утверждает, что то, чем он пользуется - the best, я попросту не вижу предмета разговора.

Выбор инструмента для автоматизированного тестирования зависит в первую очередь только от требований проекта, а потом от всего остального. Панацеи нет. Также как и нет гарантии что через какое-то время в проект не будут включены новые технологии, поддержка которых в уже использующемся инструменте не предусмотрена, или произойдет отказ от старых технологий или то и другое вместе, что потребует поиска нового инструмента в дополнение или для замены существующего со всеми вытекающими последствиями.

Выбор из оставшихся для рассмотрения инструментов сводится в общем к следующим критериям, некоторые из которых могут оказаться для кого-то менее, а для кого-то более важными:

6. Usability:
• Удобство (и знание) скриптового языка (если язык незнаком и сложен для понимания или наоборот примитивен, то наверняка разработка и поддержка скриптов на нем окажется довольно проблематичной). Хорошим признаком будет считаться поддержка скриптов с синтаксисом сходным с известными языками программирования, такими например как VB, java, c# и т. д. Тогда высока вероятность того, что больше людей в проекте смогут понимать код ваших скриптов
• Поддержка технологии Data-Driven Testing очень желательна, я бы даже сказал обязательна в случае работы с многочисленными наборами данных
• Возможность выполнять скрипты по сети на компьютерах тестовой лаборатории посредством тестовых агентов
• Построение и сохранение удобных отчетов по результатам выполнения скриптов
• Наличие автоматической записи скриптов и качество и удобство кода генерируемого ею, возможность вставки переменных и проверок в скрипт непосредственно в момент записи
• Наличие техподдержки
• Наличие развитого комьюнити по инструменту очень важно если он бесплатный
• Интеграция с уже имеющимися у Вас средствами управления тестами (Test Management) и тестовыми лабораториями (Lab Management) или теми, что Вы можете себе позволить ;) Например, в случае, если функционирование некоторых компонентов Вашего продукта зависит от версии операционной системы, а набор поддерживаемых операционных систем состоит из десятка, то Вам предстоит вручную подготавливать каждую машину из вашей тестовой лаборатории, набор скриптов для запуска на ней и хранилище отчетов выполнения скриптов. Каждый запуск такого тестового цикла и анализ результатов выполнения будут представлять массу рутинной работы, а при наличии готовых решений и этот процесс будет автоматизирован.
7. Цена/качество
• Отзывы на профильных форумах, а не только на форуме производителя ;)
• Цена одной копии среды разработки скриптов и одного агента для выполнения скриптов
• Цена сопутствующих средств Test Management и Lab Management

Чего бы я никогда не рекомендовал делать:

• Верить кому-то наслово, что есть инструмент, который подходит любым проектам, потому что поддерживает множество различных технологий
• Верить, что если инструмент отлично подходил Вам на предыдущем проекте, то подойдет и на всех последующих
• Верить, что если где-то в Вашей компании успешно используется один инструмент, то он будет успешно использоваться и в остальных
• Вообще, принимать на веру чье-либо мнение, каким бы авторитетом советчик не пользовался
• Принимать окончательное решение о выборе инструмента не протестировав его на применимость к Вашему проекту
• Часто менять инструменты для автоматизации тестирвания, т. к. результат никогда не окупит ни финансовых, ни временных затрат на автоматизацию.

Если имеется несколько небольших проектов, сходных по критериям, которые могут быть обслужены одной командой автоматизации, то, возможно, из экономических соображений и в ущерб преимуществам некотрых инструментов в отношении отдельных проектов, из всего множества инструментов имеет смысл выбрать тот инструмент, что подходит по выбранным критериям и результатам тестирования большинству проектов. В этом случае подобие подходов к автоматизации, управлению тестами и отчетами о тестировании и общий синтаксис скриптового языка могут дать свои плоды в рамках единой команды.

To blame or not to blame, that is the question...

... или Мое ли это дело - постить "чужие" баги?

Читатель t-gra затронул весьма интересные вопросы которые, между прочим, живо интересовали меня самого еще на заре моей QA карьеры. Разобью их на два основных:

1. Хочу поинтересоваться твоим мнением по поводу разделения продукта на области с назначением ответственным за каждую область отдельного инженера. Что, все так делают?

2. И если инженер видит баг (даже, положим, критический баг) в другой области - это повод для него закрыть на этот баг глаза, либо это повод обвинить "хозяина" области в том, что он не нашёл баг первым?

На первый вопрос ответить сравнительно легко.
Да, все, как правило, разделяют области продукта между инеженерами, если инженеров в команде больше чем 2. Причем разделение по областям примерно симметрично тому, что делается в команде программистов. Зачем это делается? В основном преследуются следующие цели:

1. Инженер становится опытным специалистом в cвоей области продукта, что однако не освобожает его от знания других областей, хотя-бы на базовом уровне. Что это дает?:
• более глубокое (профессиональное) тестирование
• более предсказуемое планирование тестирования, т.к. специалист более адекватно оценивает объем и время необходимого и достаточного тестирования
• при правильном управлении тестами и планировании тестирования само тестирование может проводиться любым другим инженером команды, не специализирующимся на этой области, по готовым тестам, написанным специалистом
  
2. Симметричность распределения областей позволяет работать инженеру и программисту как-бы в паре. Таким образом это улучшает уровень коммуникции между командами, что в свою очередь приводит к:
• установлению определенной степени доверия между программистом и инженером
• быстрому обмену информацией между ними, а следовательно, меньшим временным затратам на изучение новых фич и планировие тестирования
  
• лучшему пониманию каждым специфики работы другого
  
• и, как итог - сокращению времени жизни дефекта
  
3. Распределение областей в больших проектах служит одним из способов нематериального поощрения. Ты лучше работаешь - заслужил более сложную и ответственную область.

Более того, в очень больших проектах, по областям специализируют не только отдельных инженеров, но и целые команды.

А вот второй вопрос, бывает, учит меня чему-нибудь и по сей день.

Примерно 5 лет назад, я начинал инженером в команде, тестировавшей патчи для корпоративного продукта. Казалось-бы, продукт протестированный, продается, что там еще такого можно найти? Но находились существенные дефекты и помимо регрессий связанных с патчами. Я тоже поначалу не знал тогда что делать в такой ситуации. Понимал только, что оставлять без внимания это нельзя, но и подставлять "хозяев" области не горел особым желанием. Поэтому, я обращался к ним с описанием проблемы - а они говорили: "...да, серьезная проблема, мы о ней ничего не знаем, оформляй дефект..."... и все... никакого шума или паники. Никто не говорил мне - "...да ты ничего не понимаешь! ищи дефекты в своей области..." - и не пытался потом этот дефект оформить задним числом и т.д., никто не боялся того что дефект оформит кто-то другой и это может послужить причиной последующего обвинения в недостаточном качестве тестирования. А чего, собственно, паниковать-то? Этот дефект никто кроме меня до сих пор не обнаружил, никто из пользователей еще не жаловался, продукт продается как и продавался, для проекта ничего не изменилось, просто нашли еще один, очередной дефект, и он будет устранен как и все остальные в порядке приоритета.

Значит, как бы ни был серьезен дефект, решил я, грамотные инженеры считают, что скорее его обнаружить и исправить более важно, чем замять и пытаться "не попасть под раздачу". Поэтому, я взял за правило, если обнаружил дефект в чужой области - обязательно оформлять. При этом проконсультпроваться на предмет дефекта с хозяином области бывает очень полезно. Он быстро ответит, известный дефект или нет, есть ли связанные с ним дефекты, поможет лучше понять и изучить проблему, и оформить дефект профессиональнее, кто как не он, в конце-концов, знает свою область лучше других. А Вам это сэкономит время, даст новое знание об этой области, и поможет поддерживать командный дух в себе и других. Информационный поток внутри команды, проекта - это его движущая сила, кто выбивается из него - делает ошибку.

Ни в коем случае не пытайтесь отделаться отпиской по электронной почте типа: "...я тут у тебя нашел проблему, вот описание, разберись...". Электронная почта никогда не заменит надежности даже самой примитивной багтрэкинг системы. Вы будете уверены что "выполнили свою миссию", а адрессат этого письма не получит или не поймет что вы там наспех написали и отложит напотом, потому что не сможет адекватно оценить сходу важность или принадлежность проблемы. Ему придется воспроизвести дефект снова, чтоб описать правильно, снять скриншоты, логи,... и где гарантия что ему удастся его воспроизвести по той информации, что вы предоставили неформально в тексте своего письма?

У пилотов ВВС США есть правило, действующее в зоне боевых действий - обнаружил вражескую систему ПВО - уничтожь, независимо от того, какая у тебя боевая задача. Помните, что хуже пропущенного дефекта - потерянный дефект, т. к. у Вас остается иллюзия, что этот дефект зарегистрирован, а на самом деле... Нравится Вам это или нет, но в конечном счете, ответственность за оформление дефекта всегда лежит на том, кто его обнаружил.

А как же быть с обвинениями, наверное, спросите вы?

Многое зависит от цели, которую преследует обвинитель, от того, что стоит у него на первом месте.

Я считаю, что дефект следует в первую очередь адекватно оценить, отреагировать на него соответсвенно оценке и проконтролировать его исправление, а не раздувать, потому что Вы его нашли первым. Мы ведь не в гонках участвуем. Безусловно, если проект на пороге релиза, а Вы находите критический дефект в чужой области, то надо немедленно сообщить о нем хозяину области и его тимлиду, но нет смысла раздувать шумиху по всем инстанциям. Если до релиза действительно не так много времени, то это только помешает. Найденная проблема может оказаться действительно серьезной и чреватой дополнительными затратами на тестирование и может повлиять на дату релиза. Поэтому реагировать на нее надо быстро. Надо локализовать причину, понять нет ли еще других таких же проблем связанных с этой, оценить риски и быстро скорректировать планы на тестирование. В компаниях, разрабатывающих коммерческое ПО, среди вопросов "Кто виноват?" и "Что делать?" на первом месте стоит "Что делать?", потому что в противном случае виноваты будуь все, и вполне справедливо, т. к. в тот момент пока мы разбираемся "Кто виноват?" мы упускаем драгоценнейшее время на ответ на вопрос "Что делать?". А ответ на вопрос "Кто виноват?" оставьте хозяину области и его начальству.

Принцип "Где? Что? Когда?"

В ходе работы с дефектами часто сталкиваешься с тем, что приходится обращать внимание инженеров на необходимость более четкой формулировки summary дефекта. Причем, со временем это повторяется снова и снова. Та же ситуация наблюдается на интервью с соискателями на должность инженера по тестированию. Многие компании уделяют этому недостаточно внимания, но в сколь-нибудь большом проекте это может стать проблемой требующей решения.

Так почему же мы снова и снова пишем неправильные summary?
Во первых, нет четко сформулированного правила построения summary. Все знают что оно должно быть коротким и понятным и настроить человека, читающего его на правильное восприятие собственно описания самого дефекта. Многие соглашаются с тем, что оно должно быть уникальным, чтобы облегчить поиск дубликатов, которые в свою очередь, есть признак потерь продуктивности работы команды, но при этом все задаются вопросом, а какова тогда должна быть степень уникальности. В общем случае дубликаты могут рождаться по трем основным причинам:

1. Summary дефектов в большинстве своем нечетки. Это приводит к тому, что при поиске дубликатов своего дефекта инженер не может распознать дефект по summary и вынужден часто читать описание каждого подобного дефекта, что серьезно увеличивает время создания каждого отдельного дефекта в базе. Поэтому, скорее всего, он не будет перечитывать описание тщательно, чтобы не снижать свою продуктивность.
2. Инженеры еще недостаточно хорошо освоили сам продукт и связанную с ним предметную область, поэтому создают дефекты с различными неполными описаниями, но имеющими один и тот же источник.
3. Неправильное планирование тестирования (например когда области тестирования 2-х независимых инженеров сильно перекрываются, а поиск дубликатов к тому же затруднен причиной № 1).

В общем случае дубликаты - достаточно серьезная проблема, приводящая к снижению продуктивности как команды тестирования, так и программистов. Поэтому каждую причину надо устранять в отдельности. Способы устранения причин № 2 и № 3 достаточно очевидны. Причина № 2 устраняется дополнительными тренингами с формальным отведением времени под них при планировании либо естественным путем - инженеры со временем разберутся в продукте на достаточном уровне сами (метод решения зависит от степени влияния причины на проблему). Причина № 3 устраняется путем более четкого планирования тестирования с явным указанием областей ответственности инженеров в точках интеграции смежных компонентов). А вот причина № 1 системная, и ее устранение состоит в систематическом усвоении норм построения summary, которые должны стать частью вашего процесса и при этом не усложнять его, а упрощать.

Во вторых, если правила построения summary сложны и нечетки - они так или иначе в рутинном потоке заданий инженерами частично или полностью забываются.

Есть разные способы построения summary на сегодня. Вот, к примеру, два из них.

Первый способ:

1. Напишите сначала описание дефекта.
2. Посмотрите на него внимательно и выделите из него ключевые моменты.
3. Попробуйте сложить эти ключевые моменты вместе.

То что у вас получится в итоге и будет составлять summary вашего дефекта.

Второй способ:

Напишите описание дефекта по следующей схеме:

1. Шаги воспроизведения
2. Ожидаемый результат
3. Полученный результат

Если Вы построили описание правильно, то "Полученный результат" и будет summary вашего дефекта в общем виде. При необходимости можно добавить в него недостающие детали.

Я предлагаю другой способ или так называемый принцип "Где? Что? Когда?". Именно в таком порядке, не путайте с названием популярной телепередачи :)

В чем этот принцип состоит?
Составьте предложение, в котором факты дефекта изложены в следующей последовательности:

1. Где?: В каком месте интерфейса пользователя или архитектуры программного продукта находится проблема. Причем, начинайте предложение с существительного, а не предлога.
2. Что?: Что происходит или не происходит согласно спецификации или вашему представлению о нормальной работе программного продукта. При этом указывайте на наличие или отсутствие объекта проблемы, а не на его содержание (его указывают в описании). Если содержание проблемы варьируется, все известные варианты указываются в описании.
3. Когда?: В какой момент работы программного продукта, по наступлению какого события или при каких условиях проблема проявляется.

Почему последовательность должна быть именно такой?
В таком виде незнакомые дефекты удобнее сортировать по summary как показывает практика (ведь, скорее всего, именно среди дефектов других инженеров будет производиться поиск дубликатов). Если вы другого мнения - придумайте свою последовательность, но она должна стать единой для всех без исключения членов проекта, иначе вы не добьетесь необходимого результата.

Вот пример такого summary.
Допустим, у Вас есть диалог "Преобразовать данные" с кнопкой "Преобразовать".
И при нажатии этой кнопки появляется сообщение об ошибке "Ошибка №...".
Тогда summary дефекта будет состоять из следующих частей:

1. Где?: Диалог "Преобразовать данные"
2. Что?: показывается сообщение об ошибке
3. Когда?: при нажатии кнопки "Преобразовать"

Итоговое summary будет иметь следующий вид:

Диалог "Преобразовать данные" показывает сообщение об ошибке при нажатии кнопки "Преобразовать"

Все остальные детали должны быть указаны в описании дефекта.