Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова
Предыдущая статья

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

Что, если они захотят, чтобы другой человек прогнал мои тесты, если я недоступна?

- Ваши тесты, или ваше тестирование? – спросил я.

- Насколько я понимаю, мои тесты. Я несогласна с этим, но пытаюсь посмотреть на вопрос с их точки зрения, - ответила Фрида.

Интересно, что бы произошло, если бы мы спросили их "А что будет, если вашу менеджерскую работу должен будет сделать другой менеджер в случае, когда вы недоступны?" Или "Что произойдет, если вы захотите, чтобы другой разработчик приступил к программированию, если наш разработчик недоступен?" Наверное, в последнюю очередь они бы предложили разработать набор менеджмент-кейсов или разработко-кейсов. Так откуда взялась эта одержимость тест-кейсами?

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

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

Тест-кейсы помогают сделать беспорядочную, сложную, ветреную картину разработки и тестирования удобопонятной, читабельной, внятной, измеримой. Тест-кейс или падает (проблема!), или проходит (нет проблем!). Благодаря тест-кейсу поведение тестировщика кажется предсказуемым и понятным – настолько понятным, что тестировщика можно и машиной заменить. В начале проекта мы создали 782 тест-кейса. Когда мы прогнали 527 из них, тестирование завершено на 67,39%!

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

Эти программы становятся "вашими тестами". Назовем их "вашими проверками" – где под проверкой понимается механический процесс применения правил принятия решений к наблюдениям за поведением ПО.

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

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

Исследование может управляться или находиться под влиянием множества альтернатив тест-кейсам:

• Чеклисты
• Планы покрытия
• Таблицы данных
• Ментальные карты
• Списки рисков
• Эвристики деятельности
• Юзер-стори и рассказы
• Существующие заметки о тестировании или сессионные таблицы
• Исходный код для автотестов
• Чартеры сессий
• Сборники сценариев
• Предыдущие отчеты о тестировании
• Полевые отчеты о багах.

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

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

Но что, если в вашей ситуации необходимо создавать тест-кейсы для аудиторов или контролирующих органов?

Отличный вопрос. Поговорим об этом в следующий раз.

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