На основании чего составляются тестовые сценарии?

Question

[Alexey Matal]

Добрый день!
Суть вопроса - на основании чего составляются тестовые сценарии?
Я понимаю, что в сущности по тз, но реализация может включать множество деталей, которые в тз могут описаны неявно или вообще не описаны.
На предыдущем месте работы отдел тестирования был совмещен с отделом аналитики - они сразу готовили анализ по тз и покрывали его тестовыми сценариями. Сейчас такой роскоши нет - целого отдела для этих нужд, но необходимость тестировать готовые приложения есть.
Скажите, как лучше организовать процесс составления тестовых сценариев? Кто должен утверждать их? Руководитель проекта?
Компания небольшая, есть разные проекты - мобильные/настольные приложения.
Подскажите, что почитать на тему :)
Спасибо!

Answer 1

[Тим]

Считаю, что тестовые сценарии пишутся по ТЗ если цель - приемочное тестирование. Если же цель Quality Assurance, то тестовые сценарии пишутся на основе опыта самого инженера тестирования, а он в свою очередь отталкивается от своих личных предпочтений и лучших практик по рынку или по сегменту. Для примера, в ТЗ могут не описываться ошибки валидаций на POST запросы, а хороший QA может их придумать сам уже на уровне кейсов, при этом подкинув работы разработчикам но и увеличив качество продукта в итоге. Вот я вижу эти два пути. Приемка и Quality Assurance.

Comments

[Alexey Matal]

Спасибо за Ваш ответ! Дает направления как думать дальше!

Answer 2

[ruGuardian]

Ответ на подобный вопрос зависит от ответственности ПО. Вообще сценарии составляются на основе требований. Не абстрактных лозунгов, которые обычно пишутся в ТЗ, а требований с однозначными техническими характеристиками. Если проект ответственный, требующий сертификации (ПО для транспорта, например), это вопрос регулируется соответствующими стандартами, по которым производится сертификация. В частности для гражданской авиации, есть документ DO-178 (российский перевод - КТ-178 и менее требовательный аналог ГОСТ-51904), определяющий например, что на основе требований к системе, разрабатываются требования верхнего уровня к ПО (параллельно - к железу), на основе которых создаётся дизайн и требования нижнего уровня, на основе которых уже код, а тестировщики пишут тесты верхнего уровня по требованиям верхнего уровня (проверка функционала всего приложения) и тесты нижнего уровня по требованиям нижнего уровня (юнит тесты). Получается реализация и независимая верификация по общим исходным данным для программиста и тестировщика. Причём здесь не нужно полагаться на опыт и изощрённость тестировщика, он просто достигает цели по явным критериям, это прозрачно и управляемо. Но это очень дорого и долго.
В вашем случае, конечно, процессы разработки будут гораздо проще, но здесь вы должны понимать, что усиление процесса верификации неизбежно потребует затрат. Чудес не бывает, как и тестировщиков которые без документации покрывают как боги. Здесь явно требуется бОльшая формализация, а значит хотя бы ещё один уровень детализации после ТЗ. Насколько детализировать - зависит от того, сколько вы готовы на это потратить. Процент выгребания багов будет соответствующий.

Comments

[Alexey Matal]

Спасибо за Ваш ответ! Очень развернуто.