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

1. Общение с заинтересованными сторонами (stakeholders): Это могут быть разработчики, аналитики, менеджеры проекта, заказчики или даже конечные пользователи. Они могут предоставить информацию о целях и задачах проекта, ожиданиях от функционала и критериях его успешности.

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

3. Использование агил-методологий (например, Scrum или Kanban): В таких методологиях требования часто формулируются в виде пользовательских историй (user stories), которые описывают функционал с точки зрения конечного пользователя. Работа в тесном взаимодействии с командой разработки и постоянное уточнение деталей помогают детализировать требования даже без формальной документации.

4. Анализ конкурентов: Изучение продуктов-аналогов может дать представление о стандартных функциях и возможностях, которые ожидаются от аналогичных систем. Это помогает выявить неявные требования, которые могут быть не очевидны изначально.

5. Проведение сессий мозгового штурма: Совместные сессии с командой проекта могут помочь сгенерировать идеи и определить требования, на основе знаний и опыта участников.

6. Прототипирование: Создание прототипов или MVP (минимально жизнеспособный продукт) позволяет на ранних этапах получить обратную связь от пользователей и уточнить требования на основе этой обратной связи.

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

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

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

March 7, 2024, easyoffer