« Я тестер ! »

• «Тестировщики должны были найти эту ошибку»
• «Тестирование – слабое место проекта»
• «У нас слишком много ошибок»
• «Тестирование занимает слишком много времени»
• «Тестирование должно быть завершено сейчас.»

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

• Успешное управление рисками: хорошо. Одна ошибка смогла пройти незамеченной. Достаточно честно. Теперь давайте поговорим о том, что команда тестировщиков работала на протяжении последних двух недель и при этом они смогли найти 15 блокирующих ошибок, 19 критичных и 54 ошибки с приоритетом Normal. Если мы хотим, чтобы эта область была протестирована, мы должны уделить меньше времени другим областям. Итак, какой из 15 блокирующих тасков вы бы хотели, чтобы мы пропустили, потратив время на эту функциональность?
• Проблема коммуникации (общения): Мы не можем проверить все возможные комбинации входных данных, поэтому мы вынуждены их сортировать, выбирая более представительные. В данной ситуации мы ошиблись с выбором правильной выборки. Теперь, когда мы знаем о возможны проблемах, мы постараемся уделить больше внимания данной функциональности при тестировании. В будущем, если аналитики, программисты или другие участники проекта будут знать о возможных проблемах, они должны сообщать это команде тестирования.

Я подумал, что мы могли бы отойти от идеи хранить кейсы полностью в строгой структуре. Почему?

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

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

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

ЧТО я предлагаю:

------ Требования и организация ---------------

1. Точно определить, что должно быть в полях типа: Module(s), Sub—Module(s) . Если с остальными всё более менее ясно, то в этих полях каждый тестер пишет то, что ему вздумается. Следующим шагом будет переименование этих полей соответственно тому, что в них будет находится.

2. Добавить поле Feature. Куда для ВСЕХ записей будет записываться фича, которую проверяет данный конкретный кейс. Если кейс точно нельзя определить, как проверяющий конкретную фичу, то там будем писать что—то типа Global или Main. Это поле должно разрешать вписывать несколько значений через запятую(так сейчас у нас хранится инфа о конфигурациях для конкретного кейса).

3. Список  стоит вынести на отдельную страницу и при добавлении новых кейсов для новой фичи, название фичи добавлять в этот список. И там же связывать ещё раз, в каких конфигурациях эта фича МОЖЕТ быть активизирована.

4. Нужно создать дефолтовый документ, куда будут вноситься все дополнения и изменения. А так же пустой документ, но с готовой структурой, сюда должно быть удобно скопировать кейсы из дефолтового дока. 

5. Правильно настроить фильтрацию, возможно понадобится написать пару VBScript'овых макросов.

------- Как этим пользоваться ----------

1. Если нужно проверить конкретную конфигурацию.

1.1. Выделяем с помощью автофильтров необходимые кейсы. Копируем их в пустой приготовленный и производим тестинг. Сохраняем результаты в отдельный файлик.

Или

1.2. После фильтрации создаем новую версию Results for build_version и производим тестинг. На все остальные кейсы, которые не нужно проверять в рамках этого тестирования ставим статус Not required 

2. Если нужно сделать из наших кейсов Acceptance cases. Опять таки фильтруем данные. Можем уже ничего никуда не копировать.

------------------------------------

В чем наша выгода:

1. Нам не нужно напрягаться о порядке дабавления кейсов даже для одной фичи. Фильтрация по имени фичи точно покажет все кейсы, которые её касаются.

2. Страничка с перечислением фич сразу покажет, какие фичи добавлены,  а какие — нет. При этом здесь мы можем попробовать сделать структуру, которая покажет к чему относится конкретная фича.

«У проекта разработки ПО сегодня не три, а четыре фактора успеха:

...

4. Каждый участник команды уходил с работы в 18:00 с чувством успеха.»