Как тестировщикам получать ответы у программистов. Часть 1

      Каждому тестировщику жизненно необходима информация о ПО, что предстоит тестировать. Мы спрашиваем программистов о том, как работает та или иная функция, советуемся, как лучше её проверять, иногда прибегаем к их помощи в автоматизации и так далее. Без нормального общения тестеров и девелоперов успешная работа над проектом невозможна.
      В какой-то период времени я обнаружила, что в общении с программистами есть грабли, наступание на которые карается раздражением в мой адрес, ухудшением отношений, пустой растратой сил, времени и нервов, бойкотом моих вопросов и просьб и тому подобным. Но с нервами можно справиться; хуже было, когда выяснялось, что из-за нехватки информации или неправильного понимания я тестирую не то или не так. Общение с коллегами показало, что не одна я сталкиваюсь с такой проблемой. Иногда тестировщикам просто мучительно больно добиваться ответов у программистов.
      Поэтому, вдохновившись примером Джоэла Сполски, несколько постов я посвящу тому, как тестировщикам получать ответы у программистов малой кровью :).
      Для начала давайте рассмотрим, какие грабли бывают при задавании вопросов программистам, и разберемся, как избежать наступания на них.

Исследование дефекта

Итак, мы обнаружили проблему. Что дальше?

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

Как быть с минорными дефектами

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

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

Но! 

Тест-дизайн - это удаление тестов

Задача тест-дизайнера - уменьшить множество возможных тестов до их приемлемого количества.

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

"Серебряная пуля" тест-дизайнера

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

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

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

Минусы тестирования по плану

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

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

Доводить действие функции до логического конца

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

Ошибку не доведения действия функции до конца часто совершают начинающие, и я сама не раз на этом попадалась. Тестировщик в первую очередь сосредоточенно тестирует поля ввода в диалоговом окне, например, сохраняются ли галочки на правах у данной группы пользователей. Однако это второстепенно. А первостепенно - отработка этих настроек системой. Действительно ли пользователю доступна запись, если в его настройках прав установлен флаг "Запись"?
Вывод: целесообразно сначала тестировать логику, потом - детали ее реализации в GUI.