Сегодня поговорим о тех, кто помогает более качественно наносить пользу заказчику. Эти смелые люди не боятся говорить правду. Им ничего не стоит опустить вас на землю словами “А как это будет работать, если…?”. Их не напугаешь многостраничными спецификациями и инструкциями пользователя. И вы уже, наверняка, догадались, что речь идеть о специалистах обеспечения качества, другими словами, о тестировщиках.

Чем же занимаются тестировщики?

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

Т.е. фактически эти люди помогают не упасть в грязь лицом разработчикам и аналитикам. Поэтому не стоит предвзято относиться к этой профессии.

Тестировщик — это лучший друг аналитика (да и разработчика). Цените их, ведь именно они укажут вам на неточность в требованиях, на их неполноту, помогут убедиться, что разработчики поняли все правильно.

Аналитику полезно понимать, какие задачи стоят перед тестировщиком и как тот с ними справляется.

Рекомендуем ознакомиться с основными понятиями и артефактами тестировщика. Некоторые из них отлично описаны на этом сайте.

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

1. Функциональное тестирование

2. Нефункциональное тестирование

3. Тестирование, связанное с изменениями

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

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

Когда же речь заходит об изменениях требований, мы слышим нецензурные высказывания и пожелания крепкого здоровья всем, кто с этими изменениями связан. Более стойкие и опытные тестировщики заранее готовятся к таким моментам: затачиваются ножи распределяется зона ответственности между тестировщиками (если их больше одного на проекте), тестовые сценарии пишутся так, чтобы их легко можно было найти и поправить, используется различный уровень детализации. Ах да! Друзья-аналитики, а вы разве не знали, что любые изменения, которые вы делаете в спецификации (либо в рамках критериев приемки в пользовательской истории), наверняка, повлекут за собой изменения и в документации, создаваемой тестировщиками, а не только регрессионное тестирование (это как раз один из видов тестирования, связанного с изменениями)?

Что ожидает тестировщик от аналитика?

• Требования будут описаны в полном объеме.
• Изменения будут внесены в спецификацию своевременно и согласно правилам проекта.
• Аналитик всегда будет доступен для ответов на вопросы.
• Аналитик объяснит цели проекта и предметную область.
• Аналитик поможет решить разногласия с разработчиками на тему “Считать багом или функциональной особенностью?”
• Аналитик знает ответы на все вопросы. =)
• Аналитик проявит уважение по отношению к тестировщику.

Что ожидает аналитик от тестировщика?

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

Особенности взаимодействия

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

Тестировщик также старается разобраться в предметной области заказчика, поэтому ожидайте множество вопросов и на этот счет. Также для тестировщика, как, впрочем и для всей команды, важно понимать терминологию, артефакты, задачи аналитика. Убедитесь, что ваши коллеги в курсе того, что такое “use case”, чем бизнес-правило отличается от нефункционального требования — словом, сделайте все, чтобы говорить на одном языке.

Вместо заключения

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

Статьи по теме:

0. «Аналитик и..»

1. «Аналитик и» Проектный Менеджер

2. «Аналитик и» Эксперт в предметной области

3. «Аналитик и» Cпонсор проекта

4. «Аналитик и» Пользователь