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