Home

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

Часть 1
Часть 2
Часть 3
Часть 4

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

В курсе Rapid Software Testing мы говорим, что тестирование – это оценка продукта путем его изучения через эксперименты и исследования, включая вопросы, моделирование, обучение, манипуляции, вмешательства, и т. д. Обучение – неотъемлемая часть тестирования. Тестировщики могут взаимодействовать с множеством артефактов и людей, чтобы начать изучать продукт, и это мы уже обсуждали. Давайте разберемся, почему идея заставить тестировщика работать посредством тест-кейсов не так уж хороша.

Хотя кейсы и навязываются нам как способ изучения продукта, но мой личный опыт гласит, что они не особенно для этого пригодны. Вели ли вы когда-нибудь машину согласно списку инструкций Google Maps, голосу навигатора или инструкциям другого человека? По моему опыту, если моими действиями руководит кто-то другой – это отрывает меня от поиска пути и осмысленных действий. Когда я прибываю в пункт назначения, то не уверен, как я туда попал, и смогу ли вернуться назад.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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