Много лет назад, в коридоре на одной конференции, мы с неким менеджером по тестированию сравнивали наши подходы. «Если мне не скажут, что должна делать программа, я не смогу ее протестировать, — хмурилась Франсина, моя собеседница. — Поэтому я им так и говорю — не начну тестировать, пока мне не дадут детальное ТЗ». Мои брови взлетели вверх.

Я в то время работала в компании — производителе пользовательского ПО из Силиконовой Долины. Если бы я всякий раз до начала тестирования ждала исчерпывающей спецификации, мне пришлось бы ждать вечно. И меня бы уволили по причине полной бесполезности в проекте. Я сказала что-то на этот счет, и Франсина лишь покачала головой. Она и представить не могла, что детальной спецификации может не быть. А я не могла представить, как это — держать в заложниках целый проект, пока мне не дадут документацию. Неспособные понять точку зрения друг друга, мы пожелали друг другу хорошего дня и разошлись в разные стороны.

Споры — бесконечные и яростные

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

В прошлом я была всецело на стороне исследовательского подхода. Большую часть своей карьеры я работала в компаниях, которые предпочитали иметь минимум документации, поэтому мы обычно не писали детальных тестовых планов. Даже если компания хотела придерживаться полных пошаговых сценариев тестирования, я была согласна с Джеймсом Бахом, который говорил, что четко следовать скрипту — это как играть в «Двадцать вопросов», где вам приходится задать сразу все вопросы наперед. (У нас похожая игра называется «Данетка», где нужно с помощью наводящих вопросов разгадать запутанную, часто детективную историю, — прим. пер.).

Однако, моя точка зрения на данный спор сменилась в последние несколько лет, когда я начала работать с Agile-командами, которые ценят все формы тестирования. Я стала понимать, что старая дискуссия о том, что лучше — тщательная проверка по предопределенным скриптам или исследование, — это как вопрос, что лучше — соль или перец, клей или скобы, ремень или подтяжки. Это ложная дилемма и бессмысленный спор.

Проверка

Как и большинство Agile-команд, команды, где я работала, использовали легкие пользовательские истории в качестве «повода для разговора» о требованиях. Этот разговор происходит, когда команда готова начинать разработку истории. В этот момент команда собирает все детали об ожиданиях и критериях приемки. Перед тем, как мы сочтем, что история выполнена, нам надо проверить, что то, что реализовано — это как раз то, что владелец продукта имел в виду. Все эти годы, вспоминая тот разговор с Франсиной, я снова слышу ее слова: «Пока мне не скажут, что должна делать программа, я не могу ее протестировать». Если мы чуть-чуть перефразируем это высказывание, получится: «Пока мне не скажут, что программа должна делать, я не могу проверить, что она делает именно это.» В этом есть смысл.

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

ДАНО: я не залогинен в тот момент, КОГДА я иду на страницу «Редактировать профиль». НАДО: перенаправить меня на страницу «Войти в систему», и ЗАТЕМ, когда я залогинюсь, — перенаправить на страницу «Редактировать профиль». (Этот пример представлен в стиле «Дано/Когда/Затем», популяризированный в BDD-коммьюнити (BDD — разработка на основе поведения) и связанный с инструментами BDD, такими, как Cucumber).

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

Поскольку Agile-команды ценят быструю обратную связь, а необходимость запуска регрессионных тестов возникает очень часто, мы автоматизировали эти проверки, чтобы нагрузка оставалась на том уровне, когда с ней можно справиться. Когда команда придерживается данного подхода — собирать критерии приемки в форме тестов — то можно еще более перефразировать позицию Франсины: «Пока мы не знаем, как собираемся проверять функцию, мы не знаем достаточно для того, чтобы ее разработать.» Этот небольшой, но значительный сдвиг переносит тесты вперед, вместо того, чтобы ставить их в самом конце цикла. Результат этого сдвига в том, что тесты не просто связываются с требованиями — они становятся выражением требований. Они превращаются в спецификацию — поскольку указывают, какое поведение ожидается от системы. Будучи автоматизированы, они становятся исполняемыми спецификациями.

Исследование

Неважно, насколько тщательно мы разрабатываем заданную историю, простой проверки, что история соответствует ожиданиям, мало, чтобы удостовериться, что мы охватили всё. Всегда существует риск, что мы не учли какое-то условие или взаимодействие, которые могут привести к нежелательному поведению. Исследовательское тестирование — в особенности сессионное исследовательское тестирование, в том виде, как оно определено Джеймсом и Джоном Бахами — дает нам структурированный способ изучить систему на предмет рисков и уязвимостей.

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

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

К примеру, в одном из проектов я во время таких изысканий обнаружила, что поле в форме, которое предполагалось доступным лишь для чтения, на самом деле можно редактировать. Маленький знак, что что-то упущено, но указывал он на куда большую проблему. Это поле представляло собой группу, к которой принадлежал пользователь. Я выяснила, что, не имея прав системного администратора, я могу назначить администратором себя, меняя значение в этом поле. А это уже, конечно, проблема. И если бы она осталась не найденной, у нас была бы большая дыра в безопасности приложения.

Протестировано = Проверено и исследовано

Методология Agile подчеркивает необходимость создавать законченные функции каждую итерацию или спринт как минимум ежемесячно. А прежде, чем мы скажем, что история закончена, ее надо протестировать. Вспомним тот разговор с Франсиной и рассмотрим наши различные подходы к тестированию. Франсина подчеркнула важность проверки, я — важность исследования. Наши подходы — это две стороны тестового равенства:

• Проверка: делает ли система то, что должна?
• Исследование: есть ли риски и уязвимости, которых мы не учли?

Оглядываясь назад, я вижу, что мы с Франсиной обе были правы. И обе ошибались. Каждая из нас указала на важный аспект тестирования, но ни одна не увидела целую картину. Чтобы получить достаточно информации для того, чтобы объявить историю сделанной, мы должны и проверить ее, и исследовать. Обе стороны тестирования — и проверка, и исследования — критичны для создания высококачественного ПО.

Оригинал: http://www.agileconnection.com/print/art[...]-software-testing-checking-and-exploring

Об авторе: основатель и президент Quality Tree Software, Inc. Элизабет Хендриксон написала свою первую строку кода в 1980. Спустя несколько мгновений она нашла и первый баг. С тех пор Элизабет занимала должности тестировщика, разработчика, менеджера и директора по качеству в самых разных компаниях — от маленьких стартапов до мультинациональных предприятий. Будучи членом Agile-коммьюнити с 2003 года, Элизабет работала в совете директоров Agile Alliance. Она является соорганизатором программы Agile Alliance «Инструменты функционального тестирования». Сейчас она делит свое время между преподаванием, лекциями, писательством и работой в Agile-командах, с тест-инфицированными программистами, которые ценят ее помешательство на тестировании. Она ведет блог testobsessed.com, кроме того, ее можно найти в Твиттере на странице @testobsessed.

Перевод: Александра Родсет

Еще интересные статьи на эту тему:

• Что за тестировщик без команды по контролю качества?
• Повышение отдачи от тестировщиков на ранних этапах
• Трассировка автоматизированных тестов
• Тестирование: ручное или автоматизированное
• Переход к гибкому (Agile) тестированию