2. О чем мы поговорим Предпосылки Проблема и ее влияние на процесс разработки ПО Методы решения
3. Предпосылки к возникновению ситуации нехватка ресурсов для описания требований главный идейный вдохновитель проекта и человек со стороны заказчика, который управляет проектом, не одно и то же лицо нежелание заказчика тратить деньги на «формальное» описание проекта
4. Описание ситуации и ее влияние на проект различный взгляд на функциональность планирование и оценка возможны только на верхнем уровне извлечение информации
5. Описание ситуации и ее влияние на проект нахождение дефектов мигрирует на более поздние этапы неопределенность критериев приемки продукта заказчиком сложность определения качества продукта
6. Методы решения проблемы анализ требований планирование тестирования проектирование тестов выполнение тестирования передача продукта заказчику
7. визуализация требований (flowchart диаграммы, UML Use Cases, Mind Map) регулярные обсуждения продукта с проектной командой и командой заказчика Анализ Планирование Проектирование Выполнение Передача Анализ требований
8. Анализ Планирование Проектирование Выполнение Передача Планирование тестирования использование высокоуровневых чеклистов информация из конкурирующих продуктов использование опыта из прошлых проектов
9. использование кода, как основы идей для тестовых сценариев Test Plans могут выступать в роли низкоуровневых требований Анализ Планирование Проектирование Выполнение Передача Проектирование тестов
10. умение задавать правильные вопросы использование неформальных техник тестирования: Ad hoc тестирование исследовательское (exploratory) тестирование Анализ Планирование Проектирование Выполнение Передача Выполнение тестирования
11. Ad hoc тестирование импровизированное тестирование без предварительной подготовки преимущество: важные дефекты находятся на ранних стадиях метод для обзора функциональности продукта
12. Исследовательское (exploratory) тестирование переплетение дизайна тестов и выполнения тестировщик узнает продукт в процессе его тестирования особое внимание уделяется творчеству и спонтанности
13. High-Level Check List может выступать в роли требований к продукту обязательное утверждение условий приемки продукта (acceptance test criteria) у клиента передача должна происходить как можно чаще Анализ Планирование Проектирование Выполнение Передача Передача проекта заказчику
14. Решенные проблемы единый взгляд на продукт извлечение данных о продукте нахождение дефектов на ранних этапах детальное планирование критерии приемки продукта заказчиком определение качества продукта Что в итоге? (1/2)
Согласно результатов исследования, проведенного в 2006 году компанией IDC (ведущий поставщик консультационных услуг на рынках информационных технологий), в 70-80% случаев некачественные требования стали причиной неуспешно реализованных ИТ-проектов. Что же делать, если проектные требования отсутствуют вовсе, а тестирование и сдачу продукта заказчику необходимо выполнить. В своем докладе я расскажу об основных предпосылках для возникновения подобной ситуации, опишу ее влияние на процесс разработки программного обеспечения и расскажу, как можно смягчить данные обстоятельства с точки зрения процесса тестирования. Также уделю внимание неформальным техникам тестирования, которые не требуют детального описания и документирования: исследовательское и Ad hoc тестирование. Применение представленных методов позволяет снизить риски при отсутствии проектных требований. Спросить у зала про возможные проблемы в проектах.