Зачем тестировщику доки читать. Часть 1: А не проще ли у аналитика спросить?

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

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

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

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

Кстати, есть очень простая аналогия с работой тестировщика: вот нашли вы баг, внесли его в багтрекинговую систему - потратили время, чтобы описать ясно, чётко, понятно, по делу, со скриншотами и т.п. А к вам приходит программист и говорит: "Ну, расскажи мне, что там не так по багу номер NN?" Приятно? Зачем, спрашивается, тратили время на описание в багтрекере?

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

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

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

Часть 2: И какая от тестировщика польза?
Часть 3: Как? Когда? И немного граблей :)