четверг, 13 декабря 2012 г.

Зачем тестировщику доки читать. Часть 2: И какая от тестировщика польза?

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


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

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

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

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

Самый простой пример из моего недавнего опыта: разрабатывали новую функцию для одного из объектов в системе, детально её проработали и описали. Но только тестировщица во время ревью указала на то, что для подобных функций мы обычно предоставляем возможность вызова их через контекстное меню/специальные кнопки для выбранных объектов. Может показаться мелочью, но за этой забытой функциональностью скрывался значительный кусок работы.

3) Указания на непоследовательности (неконсистентности)
- очень похоже на предыдущий пункт, но в отслеживании последовательности и единообразия реализации решений есть некоторая специфика. Может и не самые критичные замечания, но всё равно важные.

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

4) Замечания, проистекающие из лучшего знания системы или отдельных её частей
- если кому-то может показаться странным, что тестировщик может знать что-то лучше, чем аналитик, то я скажу вам - запросто! Причин тому может быть множество, например, тестировщик на проекте уже много лет, а аналитик по сравнению с ним - недавно, и просто физически не успел узнать столько, сколько знает тестировщик. Да мало ли что ещё... Такие замечания очень полезны.

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

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

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

6) Ну и, конечно, описки, ошибки и опечатки
 - я просто не устаю поражаться, как наши тестировщицы умудряются заметить все мои пропущенные описки и опечатки, это ж как внимательно надо спецификацию читать! Мелочи - а всё равно приятно.

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

Часть 1: А не проще ли у аналитика спросить?
Часть 3: Как? Когда? И немного граблей :)

Комментариев нет:

Отправить комментарий