Мысли по организации тестовых сценариев (test cases)

Прежде, чем забить применить новую концепцию отношения к тестовым сценариям (test cases), описанную в посте А так ли нужны test cases ?, я хотел изменить способ хранения этих самых сценариев описанным ниже образом.
Предлагаю оценить возможность использования данного подхода. Конечно, пока это только теория, но как только у меня будет возможность/ресурсы попытаюсь её воплотить в жизнь.

Итак, копия моего предложения с вырезанными project specific местами:

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

Минусы отсутствия твердой структуры с лихвой покрываются возможностью не думать над тем в какую папку засунуть сей документ, когда он с легкостью может быть как в одной папке, так и в другой.
Думаю, что чтото подобное мы можем сделать и с нашими кейсами. Возможно, что полного отказа от типизации и строгости не будет (в базах же присутствуют как типы данных, так и строго заданные таблицы, но непосредственно в файлах все хранится без строгого разграничения)
ЧТО я предлагаю:
------ Требования и организация ---------------
1. Точно определить, что должно быть в полях типа: Module(s), SubModule(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. Страничка с перечислением фич сразу покажет, какие фичи добавлены,  а какие — нет. При этом здесь мы можем попробовать сделать структуру, которая покажет к чему относится конкретная фича.

В этом, ещё не оттестированном подходе много минусов — это я понимаю. Главный вопрос, который меня интересует: будет ли это жить или есть причины, которые видны «не вооруженным» глазом, из-за которых всё сойдет на нет?

Из-под пера Maksim Grinevich

Тэги: , , ,
Нашли ошибку в тексте? Выделите её мышкой и нажмите Ctrl + Enter.

Ещё по данной теме:


2 ответов, оставьте свой...:

  1. Alex Sidorov отметил:

    тесткейсы неплохо ложатся на wiki (в частности, пробовали в Confluence).
    Плюсы такого подхода - практически безболезненное поддержание кейсов в свежем виде.Возможность ссылаться на requirements (если они тоже в wiki).

  2. Maksim Grinevich отметил:

    Alex,

    Спасибо, при случае попробую организовать.