Принципы построения наборов тест - кейсов

Принципы построения наборов тест-кейсов

Задача наборов тест – кейсов — повысить эффективность тестирования за счёт ускорения и упрощения выполнения тест-кейсов, увеличения глубины исследования некоторой области приложения или функциональности, следования типичным пользовательским сценариям{или удобной последовательности выполнения тест-кейсов.

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

Наиболее типичные подходы к составлению наборов тест-кейсов:

• На основе чек-листов. Каждый пункт чек - листа можно превратить в несколько тест-кейсов. Получаем готовый набор тест - кейсов.
• По принципу проверки самых важных, менее важных и всех остальных функций приложения (именно по этому принципу составляли примеры чек-листов).
• По принципу группировки тест-кейсов для проверки некоторого уровня требований или типа требований.

группы требований или отдельного требования.

4. По принципу частоты обнаружения тест-кейсами дефектов в

приложении

5. По архитектурному принципу:

Наборы для проверки пользовательского интерфейса и всего уровня

представления, для проверки уровня бизнес-логики, для проверки

уровня данных.

6. По области внутренней работы приложения

Например: «тест-кейсы, затрагивающие работу с базой данных», «тест

- кейсы, затрагивающие работу с файловой системой», «тест-кейсы,

затрагивающие работу с сетью», и т.д.

7. По видам тестирования

Логика создания эффективных проверок

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

Что такое качество? Это потребности и ожидания пользователя/заказчика). Качество — это ценность для конечного пользователя (заказчика). Человек в любом случае платит за использование продукта — деньгами, своим временем, какими-то усилиями.

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

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

Есть простая логика:

• Тесты ищут ошибки.
• Но все ошибки найти невозможно.
• Значит, наша задача — найти максимум ВАЖНЫХ ошибок за имеющееся время.

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

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

В силу множества экономических и технических причин невозможно выполнить все тесты , и ещё многократно — приходится выбирать, что и как будет тестироваться.

Приступая к продумыванию чек-листа, тест-кейса или набора тест-кейсов, задайте себе следующие вопросы и получите чёткие ответы:

• Что перед вами? Если вы не понимаете, что предстоит тестировать, то и не выберите, что проверять.
• Кому и зачем это нужно (и насколько это важно)? Ответ на этот вопрос позволит вам быстро придумать несколько характерных сценариев использованиятого, что вы собираетесь тестировать.
• Как оно обычно используется? Это уже детализация сценариев и источник идей для позитивного тестирования (их удобно оформить в виде чек-листа).
• Как оно может сломаться, т.е. начать работать неверно? Это также детализация сценариев использования, но уже в контексте негативного тестирования (их тоже удобно оформить в виде чек-листа).

Универсальные рекомендации, которые позволяют проводить тестирование лучше:

• Начинайте как можно раньше — уже с момента появления первых требований можно заниматься их тестированием и улучшением, можно писать чек - листы и тест-кейсы, можно уточнять план тестирования, готовить тестовое окружение и т.д.
• Если вам предстоит тестировать что-то большое и сложное, разбивайте его на модули и подмодули, функциональность подвергайте функциональной декомпозиции, —т.е. добейтесь такого уровня детализации, при котором вы можете без труда удержать в голове всю информацию об объекте тестирования.
• Обязательно пишите чек-листы.
• По мере создания чек-листов, тест-кейсов и т.д. прямо в текст вписывайте возникающие вопросы. Когда вопросов накопится достаточно, соберите их отдельно, уточните формулировки и обратитесь к тому, кто может дать ответы.

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

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