Мыслетрекер

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

Словарь

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

Религия и философия

Прежде чем описывать достоинства и недостатки скриптового подхода, интересные процессные «фишки» и техники, хочу определиться с самым важным: целью тестирования в целом, вне зависимости от его подхода. Для меня в работе важнее всего результат: качество продукта, мнения пользователей, содействие команде, пропуски дефектов. И, как следствие, — успех или неуспех проекта. Я не против поболтать о том, что «интереснее», или «круче», или «правильнее». Но ключевым критерием для выбора подхода я считаю его эффективность, а не «крутость» или личные предпочтения. Я хочу гордиться результатом, а не стыдиться продукта, даже если во втором случае бонусом будет весело проведённое на работе время.

Поэтому, если эффективность тестирования для вас не очень важна, дальше можно не читать.

Что даёт скриптовое тестирование?

Документирование тестов, вне зависимости от их формата, детализации и инструмента для хранения, всегда требует дополнительных затрат. Причём затрат непроизводственных. Сами по себе тесты пользу приносят? Продукт качественнее делают? Сроки на разработку сокращают? Продажи продукта повышают? Нет! Получается, в момент документирования тестов мы тратим время в никуда, создавая промежуточные артефакты, никоим образом не повышающие ценность нашего продукта. И тем не менее во многих компаниях многие менеджеры, неглупые казалось бы люди, принимают решение тесты документировать.

Perche?

1. Документирование тестов возможно только после их детального анализа.

Чтобы кликнуть на кнопку, много думать надо? Не очень. Кликнул на одну, на вторую, на третью, может и бага какая найдётся. Таким подходом руководствуются многие начинающие тестировщики. Вроде бы и про классы эквивалентности с граничными значениями не знает только глухослепонемой, и на вопрос «что такое pairwise?» на собеседованиях даже самые начинающие тестировщики хорошо отвечают. Но только при унылом кликании все эти знания куда-то улетучиваются!

И в итоге горе-тестировщики вместо работы головой начинают работать указательным пальцем, кликающим на мышку, считая такое тестирование «методом свободного поиска».

При чём же тут скрипты? При том, что документирование тестов — финальный этап тест-дизайна, которому неизбежно способствует анализ, создание карты продукта/функционала, разбиение на классы, поиск границ, выбор оптимального подхода для комбинаторики… В скриптовом тестировании необходимо думать, а это, согласитесь, хорошая привычка!

2. Документированные тесты позволяют задействовать коллективный разум

Может быть, кто-то из вас считает себя гуру. Экспертом в тестировании, прикладной области, архитектуре тестируемого продукта… К сожалению, лично я никогда не была в такой ситуации! Всегда в команде есть люди, которые знают больше меня. Аналитики лучше понимают бизнес-задачи пользователей, разработчики — архитектуру продукта, техподдержка — стандартные сценарии использования, руководитель проекта  - текущие приоритеты. И каждый раз, когда я показываю им тесты, они дают МНОГО, очень много полезных комментариев. Таких, которые невозможно выцепить никакими вопросами, ни с конфетками, ни с битой тестировщика.

Вся команда вовлекается в процесс тестирования, обсуждая тесты. Каждый чувствует свою ответственность за качество продукта, хочет помочь, даёт дельные советы, больше понимает «чем мы тут занимаемся». Никакой натянутый искусственный тим-билдинг не сплотит команду так, как процесс обсуждения тестов по новому функционалу.

Здесь можно спросить: а что мешает обсуждать тестирование без тестов? Логичный вопрос! Но вы правда думаете, что я не пробовала? Без наглядной карты нет общего видения и понимания, без конкретных тестов нет оценки «что пропущено», а свежеполученная информация теряется без фиксации на бумаге. В результате ни о какой эффективности и речи нет.

Я могу долго рассказывать о пользе согласования тестов, но это похоже на рассказ о вкусе клубники тому, кто её никогда не ел. Попробуйте хоть раз провести согласование тестов (не для галочки/снятия ответственности, а для повышения качества тестов) — и сразу поймёте, о чём речь!

3. Документы не увольняются и не уходят в отпуск

Если тестируемый вами продукт сложнее, чем калькулятор для дошкольников, то в нём обязательно есть неочевидные моменты. Сложности с настройками, тонкости проведения проверок, неочевидные шаги. «А давайте мы все вместе будем пытаться знать одно и то же!». А зачем??

Документирование тестов позволяет не дублировать информацию в головах, узнавать одно и то же, мучать участников проекта одними и теми же вопросами от разных тестировщиков. Тестировщик узнал, тестировщик задокументировал, тестировщик из головы лишнее выбросил. А тесты помогут это не забыть и будут отличным инструментом для обмена информацией в команде. Значительно эффективнее любых корпоративных wiki, которые всё равно кроме автора мало кто читает!

Даже 11 января, выходя на работу с больной головой, и приступая к тестированию абсолютно незнакомой части функционала (эксперт по которой плох настолько, что на работу выйти не смог), тестировщик сможет протестировать её правильно, если будет использовать заранее подготовленные тесты.

4. Документирование тестов — отличный способ для обучения.

Кого учить? Начнём с простого примера: начинающего тестировщика, который будет по ним проходить. Вышел на работу, почту настроил, продукт проинсталлировал, тесты открыл — и давай баги заводить, не отвлекая всех вокруг излишними вопросами.

А теперь пример поинтереснее. В команде есть несколько сотрудников. Кто-то из них хорошо тесты проектирует, кто-то не очень. И вот они сидят в разных углах, иногда встречаются для сплетен у кофе машины, иногда (ой, что-то не верится!) проводят сессии парного тестирования. Передача информации близка к нулю, развития нет. А теперь представим, что в команде принято документировать тесты. Что происходит в этом случае? Каждый раз, когда готова новая партия тестов, их важно согласовать со всеми участниками, обсудить. В результате неизбежен обмен информацией, обратная связь, полезные комментарии. Тестировщик улучшает свой тестовый набор, видит свои слабые стороны, «провалы». Ему на практике легко и удобно объяснить и техники тест-дизайна, и сложные моменты в прикладной области, и особенности реализации продукта. В скриптовом подходе сотрудники развиваются сильно-сильно быстрее за счёт возможной обратной связи. А как дать обратную связь при тестировании без тестов? Сидеть всё время у человека над душой и смотреть, как он тестирует??

5. Статистическая информация в любых разрезах

«Кто управляет прошлым — тот управляет будущим» (с) Большой брат, «1984″

Какую статистику можно собрать, если у нас есть тесты?

• среднее время прохождения
• % успешных и не очень тестовых прогонов
• тестовое покрытие
• какие тесты находят баги, какие не очень
• и т.д.

В итоге мы получаем массу информации. Конечно, если её попросил большой начальник, и вы нарисовали красивые графики «для галочки», то пользы мало. Но умело используя эти данные, можно непрерывно повышать результативность тестирования! Находить провалы в тестовом покрытии, отбрасывать бесполезные тесты, точнее планировать тестовые циклы, оценивать качество продукта на понятном каждому уровне…

И это всё?

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

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

«Правильное» скриптовое тестирование

Универсальных решений не бывает. Я выделила три ключевых критерия, параметра скриптового тестирования, и влияющие на них факторы.

1. Полнота покрытия тестами

Упс… А кто-то говорил, что тесты должны быть на ВСЁ? Кто угодно, только не я! Совмещение с исследовательским тестированием не просто не плохо, а даже хорошо! Покрытие документированными тестами должно расти, если:

• команда большая и необходима передача информации и/или текучка
• продукт сложный, много неочевидных моментов
• продукт стабильный и тесты не слишком быстро устаревают
• высокая критичность продукта, большая цена пропуска ошибки
• на проекте требуется детальная отчётность и/или точное планирование

2. Уровень детализации тестов

В 90% случаев мне кажется достаточным ведение чек-листов: списков тестовых случаев, которые необходимо проверить, без указания конкретных значений. Где-то с комментариями (в сложных моментах), где-то с конкретными шагами (в очень сложных). И лишь в ~10% случаев необходимы тест-кейсы (пошаговые инструкции, что именно нужно сделать). Когда становится важна глубокая детализация тестов:

• сложный продукт
• невысокая квалификация в группе тестирования
• долгосрочный проект, информация может потеряться/забыться

3. Инструмент для ведения тестов

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

Если у вас мало тестов, небольшая команда — используйте простые таблицы для чек-листов, на сетевом носителе или в google docs (и уж точно не используйте текстовые форматы, в которых невозможно собрать статистику, процветает копи-паст и потеря данных). Шаблоны чек-листов можно скачать здесь: http://wiki.software-testing.ru/Файл:Checklists.xls

Если помимо самих чек-листов вам важны отчётность, деление по ролям и наглядное представление информации - посмотрите на http://sitechco.ru или http://www.gurock.com/testrail/

Если вместо чек-листов вас интересуют подробные тест-кейсы, с возможностью их переиспользования, объединения в разные тестовые сценарии, с разными последовательностями и регулярностями — посмотрите на http://testlink.org

Ну и в крайнем случае, когда у вас большая команда, несколько проектов (спасибо функциям наследования!) и формальные процессы, рассмотрите в качестве кандидата HP Quality Center.

4. И просто несколько необходимых условий для успешного тестирования в скриптовом подходе

• Документирование манки-тестов ничего полезного вам не даст. Или даст 10%, после чего вы скажете «скриптовой подход — отстой!». Документировать нужно грамотно спроектированные тесты. Используйте стандартный алгоритм: карта продукта — классы и границы — конкретные значения — согласование -комбинаторика тестов — документирование тестов — согласование. Почитайте хотя бы Lee Copeland для понимания основ тест-дизайна, и узнайте, как устроен процесс проектирования тестов в успешных проектах.
•  Согласовывайте тесты! Не для галочки, и не обижаясь на критику. Скажите «огромное спасибо» за любую обратную связь, подключайте всю команду, от тестировщиков до РМов, к разработке тестов.
• Избавляйтесь от бюрократии. Если документированные вами тесты хранятся в неоформленных табличках, в которых легко найти всю требуемую информацию, и они успешно выполняют свою функцию — значит, этого вполне достаточно! Оставьте рюшечки для занавесок.
• Учитесь! Если тесты не приносят пользы, то и без документирования вы хорошего тестирования не покажете. Если команде непонятны результаты — узнавайте, что им может помочь. Если не знаете, что улучшать — собирайте метрики по покрытию и смотрите на слабые места. Только не довольствуйтесь тем что есть, пожалуйста — вы всегда можете большее!

Выводы

А выводов много! Скриптовое тестирование очень полезно, хотя обычно его недостаточно (об этом в следующей главе, оде исследовательскому тестированию!). Скриптовое тестирование нужно внедрять правильно: так, чтобы оно соответствовало вашим условиям, ожиданиям, потребностям. Не надо давать оценок подходу в целом, если вы основываетесь только на нескольких неудачных примерах.

И да, я не готова обсуждать вопросы из серии «а как же рутина?». Потому что если вы принимаете решение делать свою работу хорошо, то после выбора подхода вы можете озаботиться вопросами «а как это сделать интереснее?», кстати, об этом я уже вкратце писала. А вот если вы принимаете рабочие решения, руководствуясь интересом, а не эффективностью, то это как минимум непрофессионально, а как максимум ведёт ещё к большей потере интереса. Только не сразу, а позже: когда поймёте, что стоите на месте.