Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи: http://www.developsense.com/blog/2018/06/test-cases-and-coverage/
Перевод: Ольга Алифанова.

Тест-кейсы – это не тестирование! И хоть это и истинно, досужие разговоры об этом не особенно вам помогут. Позвольте предложить альтернативный способ размышлять о ваших задачах в терминологии тест-кейсов.

В начале проекта вы еще не знаете, как его тестировать. Чтобы разработать релевантную стратегию тестирования, вам нужно изучить продукт. Это можно сделать множеством различных способов – например, посещать совещания, беседовать с людьми, просматривать проектные планы, изучать дизайн или макеты. У вас даже может быть возможность напрямую поработать с продуктом – с его предыдущей версией, мокапом или прототипом – или же с частью продукта.

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

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

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

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

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

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

Сессии – это периоды практически непрерывной работы тестировщика, основанные на миссии или чартере. Временной период для сессии намеренно не определяется точно – и мы называем его "практически непрерывным", потому что в реальности крайне маловероятно, что работа вообще не будет прерываться. Планируя сессию, мы основываем свой чартер на мысли, что он займет около полутора часов. В реальности сессия может продлиться от 45 минут до 2,5 часов, потому что мы можем определить, что бы мы хотели уместить в сессию, но нашим знаниям о том, что реально произойдет во время сессии, не хватает уверенности.

К примеру, баги, на которые вы наткнетесь во время сессии, повлияют на то, сколько вы успеете покрыть на ее протяжении. Баги требуют изучения и оформления, и покрытие от этого страдает. Поэтому после сессии чартер может измениться, чтобы отражать то, что реально произошло во время сессии. Разницу между тем, что вы надеетесь сделать и тем, что вы реально сможете сделать, сложно предсказать заранее – поэтому предположите, сколько сессий вам потребуется, чтобы покрыть все, что вам известно. А затем удвойте это количество.

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

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

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

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

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

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

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

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

Обсудить в форуме