We catch your bugs!)

Цель тестирования — помочь сделать качественный продукт

Заметьте, тут не идет речь о поиске багов, метриках и прочем. Цель — это точка, куда нужно попасть. А какую дорогу мы для этого выберем и сколько остановок сделаем по пути — это уже не так важно. Это решать нам, главное — добраться до цели за оговоренное время.

Почему «помочь»?

Потому что тестировщики — не единственные, кто делает продукт. Еще есть менеджеры, разработчики, системные инженеры, аналитики, маркетологи и прочие. Все вместе делают продукт. Тестировщики — делают часть работы, я назвал это «помогают» 

Что значит «сделать качественный продукт»?

• Качественный — значит соответствующий ожиданиям того, кому этот продукт предназначается.

Как можно убедиться, что продукт будет соответствовать ожиданиям?

• Для этого нужны требования к продукту.

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

Хороший пример — валидация и верификация.

Верификация — проверяем все, что написано в SRS. Система работает так, как написано в SRS? — Pass. Система работает не так? — Fail

Валидация — проверяем, то ли делает наша система, что от нее хотели заказчики? Выполняет ли она те функции, которые от нее ждут конечные пользователи? Если да — Pass, если нет — Fail.

Как понять, что система соответствует ожиданиям конечных пользователей или заказчиков (сделать валидацию)?

• Тут нужны use cases, user stories, PRS, sketches и прочие документы. Все, что удалось получить от людей, которые делали анализ или которые будут этой системой пользоваться. Обычно на крупных проектах в крупных компаниях есть группа, которая занимается подобными вещами и является прокси-сервером между компанией, разрабатывающей систему и реальным пользователями, которые будут этой системой пользоваться

Так, ушел в дебри. Начинал с целей, а закончил use case-ами 

Можно и дальше задавать вопросы: «Как на базе неполных юз-кейсов можно составить тестовое покрытие для валидации?», «Кто и как должен делать валидацию?» и т.п. Углубляться можно очень долго… Я на этом пока остановлюсь.

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

В нашем случае, это выглядит так:

• Чтобы понимать, что такое цель тестирования — нужно понимать, что означает слово «качественный»
• Чтобы понимать, что такое качественный — нужно понимать, что такое требования и какие они бывают
• Чтобы говорить о требованиях с точки зрения тестирования — нужно представлять, как тестировать сами требования и продукт, основанный на этих требованиях
• Дальше все распадется на тест-планы, техники тестирования, метрики, типы тестов и т.д.

Чтобы понимать цель тестирования — нужно понимать все тестирование. Вот этим и закончу

http://testingforall.com/blog/?p=32