"Test is out или тестирование без требований"

Тестирование - это в первую очередь проверка соответствия требованиям, не так ли? А что если я скажу вам, что на проекте требований нет и они навряд ли появятся? Подобная ситуация очень популярна и часто ставит начинающего QA в тупик. Тем не менее, тестировать без требований можно, нужно, и сегодня мы с вами разберемся как это делать.

Первый вопрос, с которым мы разберемся, это - "Что вообще тестировать или с чего начать?” Для того, чтобы на него ответить, есть несколько приемов:

Представьте себя пользователем

Есть такая шутливая техника тест-дизайна “есть еду своей собаки”, простым языком это значит “использовать приложение, которое вы тестируете в реальной жизни, как будто вы его пользователь”. Это первый и самый мощный прием для тестирования без требований. Начните со списка флоу или фич, которые вы бы точно использовали. Чтобы сделать эту технику еще более эффективной - выходите за рамки привычные только вам. Важно понимать, что каждый пользователь уникален и имеет свое видение системы. Дайте попользоваться ПО кому-то из знакомых, обращайте внимание на нестандартные вам шаги, на последовательности наиболее вероятных действий пользователя, на user flow другого человека.

Используйте Business flow

Задайтесь вопросом “как заказчик будет зарабатывать на этом приложении?” - это и будет основой вашего тестирования, определит самый приоритетный функционал ПО и опираясь на него вы сможете выстроить стратегию тестирования. Используйте бизнес-флоу для определения набора действий, которые должны выполнить пользователи, чтобы получить желаемый результат.

Декомпозируйте функционал

Декомпозиция - это разбиение всей системы на отдельные функциональные части и их подчасти. Декомпозировать можно что угодно, не только сайт или приложение. Декомпозировать можно даже роман или фильм. Отличным инструментом декомпозиции являются так называемые mind map (coggle.it, mindmup.com, miro.com). После того, как вы декомпозируете функционал вашего приложения, выстроите все взаимосвязи и расставите приоритеты, вам будет легко понять с чего начать тестировать.

Используйте Exploratory тестирование

Исследовательское тестирование особенно полезно в сложных ситуациях тестирования, когда мало что известно о продукте, или как часть подготовки набора сценариев тестов. Чтобы систематизировать исследовательское тестирование можно использовать идею exploratory tours. Тур - это план исследовательского тестирования, на который будет опираться тестировщик при проведении тестирования. Джеймс Виттакер использует метафору, что тестировщик – это турист, а тестируемое приложение – это город. Обычно у туриста (тестировщика) мало времени, поэтому он выполняет конкретную задачу в рамках выбранного тура, ни на что другое не отвлекаясь. Больше почитать про туры можно тут.

Спросите!

Задавайте вопросы, спрашивайте у коллег, если у вас есть сомнения или вы оказались в тупике. В современном IT мире, навыки командной работы иногда ценятся больше чем hard skills, поэтому не бойтесь коммуницировать. Если так сложилось, что вы один тестировщик на проекте, то советую поддерживать тесную связь с разработчиками. Так-же существует уйма форумов и профессиональных чатов где можно спросить совета.

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

---

Второй вопрос, который стоит задать “Как понять что это БАГ, если без требований не понятно как должно быть?”

Уточните у команды или заказчика

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

Исследуйте best practices

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

Используйте опыт и самоощущения

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

Все что вам бросается в глаза и вызывает хоть долю сомнений скорее всего баг. Тут потребуется ваша внимательность к деталям и скрупулезность. Кстати говоря, это must have soft skills при приеме на работу.

---

Таким образом, тестировать без требований можно и даже нужно! В таком случае ваш глаз не замылен проверками конкретных use кейсов, вы можете обнаружить действительно критичные баги и задать важные вопросы. Не забывайте, что в любом случае нужно будет убедиться, что вы on the same page с заказчиком и командой, все понимают, что вы тестируете и почему, так что коммуникация, коммуникация. И еще раз, коммуникация :)