Тестирование без требований

5,003 views

Published on

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,003
On SlideShare
0
From Embeds
0
Number of Embeds
90
Actions
Shares
0
Downloads
41
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Согласно результатов исследования, проведенного в 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 ) является то, что при формальном тестировании выполнение тестов ограничено разработанными и спроектированными тестами.
  • Дописать из примера
  • Тестирование без требований

    1. 1. Тестирование без требований Артем Шаповал, QA/Risk Analyst, GlobalLogic
    2. 2. О чем мы поговорим <ul><li>Предпосылки </li></ul><ul><li>Проблема и ее влияние на процесс разработки ПО </li></ul><ul><li>Методы решения </li></ul>
    3. 3. Предпосылки к возникновению ситуации <ul><li>нехватка ресурсов для описания требований </li></ul><ul><li>главный идейный вдохновитель проекта и человек со стороны заказчика, который управляет проектом, не одно и то же лицо </li></ul><ul><li>нежелание заказчика тратить деньги на «формальное» описание проекта </li></ul>
    4. 4. Описание ситуации и ее влияние на проект <ul><li>различный взгляд на функциональность </li></ul><ul><li>планирование и оценка возможны только на верхнем уровне </li></ul><ul><li>извлечение информации </li></ul>
    5. 5. Описание ситуации и ее влияние на проект <ul><li>нахождение дефектов мигрирует на более поздние этапы </li></ul><ul><li>неопределенность критериев приемки продукта заказчиком </li></ul><ul><li>сложность определения качества продукта </li></ul>
    6. 6. Методы решения проблемы <ul><li>анализ требований </li></ul><ul><li>планирование тестирования </li></ul><ul><li>проектирование тестов </li></ul><ul><li>выполнение тестирования </li></ul><ul><li>передача продукта заказчику </li></ul>
    7. 7. Анализ требований <ul><li>визуализация требований ( flowchart диаграммы, UML Use Cases , Mind Map) </li></ul><ul><li>регулярные обсуждения продукта с проектной командой и </li></ul><ul><li>командой заказчика </li></ul>Анализ Планирование Проектирование Выполнение Передача
    8. 8. Планирование тестирования <ul><li>использование высокоуровневых чеклистов </li></ul><ul><li>информация из конкурирующих продуктов </li></ul><ul><li>использование опыта из </li></ul><ul><li>прошлых проектов </li></ul>Анализ Планирование Проектирование Выполнение Передача
    9. 9. Проектирование тестов <ul><li>использование кода, как основы идей для тестовых сценариев </li></ul><ul><li>Test Plans могут выступать в роли низкоуровневых требований </li></ul>Анализ Планирование Проектирование Выполнение Передача
    10. 10. Выполнение тестирования <ul><li>умение задавать правильные вопросы </li></ul><ul><li>использование неформальных техник тестирования: </li></ul><ul><ul><li>A d hoc тестирование </li></ul></ul><ul><ul><li>исследовательское ( exploratory ) тестирование </li></ul></ul>Анализ Планирование Проектирование Выполнение Передача
    11. 11. Ad hoc тестирование <ul><li>импровизированное тестирование без предварительной подготовки </li></ul><ul><li>преимущество: важные дефекты находятся на ранних стадиях </li></ul><ul><li>метод для обзора </li></ul><ul><li>функциональности </li></ul><ul><li>продукта </li></ul>
    12. 12. Исследовательское (exploratory) тестирование <ul><li>переплетение дизайна тестов и выполнения </li></ul><ul><li>тестировщик узнает продукт в процессе его тестирования </li></ul><ul><li>особое внимание уделяется </li></ul><ul><li>творчеству и спонтанности </li></ul>
    13. 13. Передача проекта заказчику <ul><li>H igh-Level Check List может выступать в роли требований к продукту </li></ul><ul><li>обязательное утверждение условий приемки продукта (acceptance test criteria) у клиента </li></ul><ul><li>передача должна происходить </li></ul><ul><li>как можно чаще </li></ul>Анализ Планирование Проектирование Выполнение Передача
    14. 14. <ul><li>Решенные проблемы </li></ul><ul><li>единый взгляд на продукт </li></ul><ul><li>извлечение данных о продукте </li></ul><ul><li>нахождение дефектов на ранних этапах </li></ul><ul><li>детальное планирование </li></ul><ul><li>критерии приемки продукта заказчиком </li></ul><ul><li>определение качества продукта </li></ul>Что в итоге? (1/2)
    15. 15. Что в итоге? (2/2)
    16. 16. Вопросы ?
    17. 17. Контакты <ul><li>Артем Шаповал </li></ul><ul><li>[email_address] </li></ul><ul><li>[email_address] </li></ul>

    ×