Содержание
- 2. Цикл (процесс) разработки ПО (software development life cycle) — это путь от идеи до поддержки готового
- 3. Формирование и анализ требований Проектирование Реализация Тестирование продукта Внедрение Эксплуатация и сопровождение Жизненный цикл ПО
- 4. Давайте попробуем определить Когда начать тестировать?
- 5. Тестирование требований на вменяемость/ осуществимость Тестирование функциональной спецификации Создание предварительных тестовых сценариев на основе требований Формирование
- 6. Тестирование документов, описывающих архитектуру (product architecture) и дизайн (product design) Тестирование плана проекта Проектирование
- 7. Тестирования кода и модульное тестирование Тестирование результатов итерации разработки Регрессионное тестирование Реализация
- 8. Тестирование готового приложения и приемочное тестирование Тестирование продукта
- 9. Тестирование совместимости продукта с существующей инфраструктурой заказчика (типы серверов, окружение и т. д.) Сбор и обработка
- 10. Обработка отчетов об ошибках от пользователей во время эксплуатации Верификация исправления ошибок Обработка запросов новой функциональности
- 11. Давайте попробуем определить Когда прекращать тестирование?
- 12. Эвристики – это быстрые, недорогие способы решения проблемы или принятия решения Эвристики
- 13. Эвристика «Время вышло!». Для многих специалистов по тестированию это наиболее распространенная эвристика: мы останавливаем тестирование, когда
- 14. Эвристика пиньяты (The Piñata Heuristic). Мы прекращаем ломать программу, когда начинают выпадать конфеты – мы останавливаем
- 15. Эвристика «мертвой лошади» (The Dead Horse Heuristic). В программе слишком много ошибок, так что продолжение тестирования
- 16. Эвристика «Задание выполнено» (The Mission Accomplished Heuristic). Мы останавливаем тестирование, когда найдены ответы на все поставленные
- 17. Эвристика «Отмена задания» (The Mission Revoked Heuristic). Наш клиент сказал нам: «пожалуйста, прекратите тестирование». Это может
- 18. Эвристика «Я зашел в тупик!» (The I Feel Stuck! Heuristic). По какой бы то ни было
- 19. Эвристика «освежающей паузы» (The Pause That Refreshes Heuristic). Вместо прекращения тестирования мы приостанавливаем его на некоторое
- 20. Эвристика «Отсутствие продвижения» (The Flatline Heuristic). Что бы мы ни делали, мы получаем тот же самый
- 21. Эвристика «Привычного завершения» (The Customary Conclusion Heuristic). Мы останавливаем тестирование тогда, когда мы обычно останавливаем тестирование.
- 22. Больше нет интересных вопросов (No more interesting questions). В этот момент мы решаем, что не осталось
- 23. Эвристика уклонения/безразличия (The Avoidance/Indifference Heuristic). Иногда людей не интересует дополнительная информация, либо они не хотят знать,
- 24. «Колхоз» против «Процесса» Методологии разработки
- 25. Быстрота выполнения работ и четкая координация команд Качественное исполнение и контроль качества Сокращение издержек Основная задача
- 26. Большой объем параллельных проектов Большая предсказуемость объема работ и результата Отличия от «Кустарного производства»
- 27. Роли Активности Артефакты Фазы и критерии их начала/окончания Методология описывает
- 28. Руководитель проекта (Project Manager) Архитектор (Architect/Designer) Бизнес-аналитик (Business Analyst) Разработчик (Developer) Тестировщик (Test Engineer/Tester) Типичные роли
- 29. Каскадная модель (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит
- 30. Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей Waterfall
- 31. Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап
- 32. Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после
- 33. Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных
- 34. Итеративный подход (англ. iteration, «повторение») в разработке программного обеспечения — это выполнение работ параллельно с непрерывным
- 35. Agile
- 36. Снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение
- 37. Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile
- 38. Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее
- 39. Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения Приветствие изменений требований даже в
- 40. Scrum (от англ. scrum «схватка») — методология управления проектами, активно применяющаяся при разработке информационных систем для
- 41. Скрам (Scrum) — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и
- 42. Спринт (Sprint) — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован
- 43. Резерв Проекта (Product backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих
- 44. Резерв спринта (Sprint backlog) — содержит функциональность, выбранную владельцем проекта из резерва проекта. Все функции разбиты
- 45. История спринта (Sprint Story) — Требуемая функциональность, которую добавляют в резерв, часто называют историей. Зачастую история
- 46. По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «кур».
- 47. «Свиньи» - основные роли. Вовлечены в проект полностью «Куры» - второстепенные роли. Вовлечены в проект частично
- 48. «Свиньи» полностью включены в проект и в скрам-процесс. Скрам-мастер (ScrumMaster) — проводит совещания (Scrum meetings) следит
- 49. Пользователи (Users) Клиенты, Продавцы (Stakeholders) — лица, которые инициируют проект и для кого проект будет приносить
- 50. Планирование спринта (Sprint Planning Meeting) Происходит в начале новой итерации Спринта Из резерва проекта выбираются задачи,
- 51. Ежедневное совещание (Daily Scrum meeting): Начинается точно вовремя Все могут наблюдать, но только «свиньи» говорят Длится
- 52. Обзор итогов спринта (Sprint review meeting) Проводится после завершения спринта: Команда демонстрирует инкремент функциональности продукта всем
- 54. Скачать презентацию