Home

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

Можно научиться методикам и инструментам работы с требованиями. Но для того, чтобы делать что-то эффективно, нужно в первую очередь понимать цель. И только затем – знать методики. Тестировщик должен уметь работать с требованиями, и он должен делать это также осознанно, как процедуру утренней чистки зубов. А то и более ;-)

Бытует мнение, что основная задача тестирования – проверка соответствия разработанного приложения требованиям и поиск ошибок. Но как же часто встречается ситуация, когда сами требования содержат ошибки. Ошибки не функциональные, а логические, ошибки бизнес-логики, недомолвки, двусмысленности.

Когда Филиппа Крухтена спросили, что такое качество продукта, он ответил: «Качество — это соответствие ожиданиям Заказчика/Пользователя».

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

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

В процессе разработки тестировщик дополняет и проверяет работу разработчика. А где же тестировщик может дополнять и проверять аналитика? В тестировании до разработки. В тестировании требований.

Требования – это основной документ, фундамент всей работы по тестированию продукта. Именно поэтому очень важно тестировать этот фундамент. Ведь если он далек от правды, то вся дальнейшая активность по сверке реализации с требованиями теряет смысл.

Аналитики не всегда имеют достаточно времени на детальную проработку требований, не всегда имеют достаточно знаний о нюансах проектирования и реализации приложения. Особенно, если аналитики – люди от заказчика.

Часто встречаются ситуации, когда продукт поступил в разработку с уже готовыми требованиями. Их тем более нужно тестировать. На предмет реализуемости, на предмет тестируемости, на предмет адекватности.  

Что же, если у вас в команде свои аналитики? Соглашусь с высказываением, что каждый должен заниматься своим делом. Действительно, тестировщик никогда не сравнится со «специально обученным» аналитиком. Ну и не нужно равняться. Нужно делать то, что по силам, и то, что работает на улучшение качества программных продуктов. Предотвращение дефектов – это уже не контроль качества (Quality Control), а элементы его обеспечения (Quality Assurance).

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

Оговорюсь, что всему этому конечно же нельзя научиться за 2 часа. Моя цель – показать вам, где мы можем дополнять работу аналитика, и показать вам, что чем более осознанно мы это делаем, тем больше пользы это приносит продукту, команде и нашему профессионализму.

Серию семинаров: «Аналитика для тестировщиков» открывают два первых семинара:

«Работа с требованиями: анализ, тестирование» (10 декабря, 13:00-15:00)

• Когда и зачем привлекать тестировщиков к анализу и тестированию требований.
• Критерии качественного требования.
• Свойства требований.
• Функциональные и нефункциональные требования.
• Явные и неявные требования
• Методики тестирования требований.
• Полномочия и компетенции тестировщиков при работе с требованиями.

«Работа с требованиями: управление изменениями» (24 декабря, 13:00-15:00)

• Требования будут изменяться. Всегда!
• Влияние изменений в требованиях на тестирование.
• Изменения объема.
• Изменения сути.
• Изменения конфигурации.
• Конфликты и гибкость требований и тестов.
• Трассировка изменений требований.
• Повторное использование.

Условия участия в семинарах