Тестирование веб-проектов в Agile
Download as PPTX, PDF2 likes691 views
Документ обсуждает тестирование веб-проектов в рамках методологии Agile, подчеркивая важность взаимодействия между разработчиками и тестировщиками. Он описывает специфику тестирования, включая итеративный подход, регрессионное тестирование и роль заказчика в управлении качеством. Также рассматриваются методы автоматизации тестирования и вызовы, с которыми могут столкнуться команды в процессе разработки.
Тестирование веб-проектов в Agile
- 1. Тестирование веб-проектов в AgileАсхатУразбаев, ScrumTrek
- 2. СодержаниеСпецифика веб-проектовКоротко об AgileТестирование в AgileВиды качестваПрактики тестирования
- 3. Специфика веб-проектовКороткий цикл выкладкиДеплой на сервера (без обновления клиентских машин)Легкие технологии, относительно простая архитектураОтносительно невысокая связанность кода
- 4. Специфика тестированияНизкий уровень документированияТестирование на разных броузерахTesting Environment <> Production Environment
- 5. Немного об Agile и Scrum
- 9. Цикл тестированияDevelopmentКаждый разработчик делает свою фичу
- 10. Цикл тестированияDevelopmentЕсли не успевают – не успевают все три!
- 11. Цикл тестированияDevelopmentФичи делаются в порядке приоритетаТри разработчика делают одну фичуФичи тестируются сразу
- 12. Цикл тестированияDevelopmentНе успеваем только низкоприоритетные!
- 13. «Все в порядке, сейчас пофиксим!»
- 14. Программисты против ТестировщиковПрограммисты слишком полагаются на тестировщиковСнижается ответственность за код
- 15. Структура командыКоманда состоит из разработчиков и тестировщиковЗа качество отвечает вся командаЗначит и за объем работ отвечает вся команда
- 16. ТестировщикТестировщик – член командыУчаствует в планировании итерацийТесно общается с заказчикамиПомогает документировать требованияк кодуЧастично берет на себя функции аналитика
- 17. Цикл регресионноготестированияDevelopmentTestingПронос на Test Environment в конце итерацииСоздается ветка(branch) «Test»Тестирование Баги исправляются в основной ветке и делается merge в Test (или наоборот)
- 18. Цикл регресионноготестированияDevelopmentTestingА если баги в Production?
- 19. Цикл регресионноготестированияDevelopmentTestingТестирование не прекращается никогдаВыберите удобный ритм тестированияРаботать в одной ветке
- 21. Качество с точки зрения заказчикаКачеством управляет заказчик!В этой итерации сделайте самую простую версиюБудем исходить из 10000 пользователей в деньПока просто текстбокс, AJAX потом добавим
- 22. Качество заказчикаЗаказчик осуществляет приемку каждую итерациюПостоянная обратная связь от рынка
- 23. Баги должны приоритезироваться!Разработчики НЕ должны исправлять все баги, найденные тестерамиБаги должны быть приоритезированыProduct OwnerРеальные ошибкиУлучшения – фичиНе баги
- 24. Внутреннее качествоКачество кодаПростота, читаемостьКачество архитектуры и дизайнаAgile:Внутренним качеством управляет команда!Внутреннее качество должно быть высоким
- 25. Затраты на качество продуктаРазмер продуктаЗатраты на полное регресионное тестированиеАвтоматизация тестированияСнизить стоимость измененийСократить цикл тестирования
- 26. Какие препятствия вы можете преодолеть не снижая скорости?
- 27. ТестированиеContinuous IntegrationСборка после каждого коммита, прогон Smoke Unit Tests (=Build Acceptance Tests)Nightly BuildsНочная сборка для всей системы, прогон всех Unit Tests и интеграционных тестовRegression TestingЧастое регрессионное ручное тестирование всей системы
- 28. Виды автоматизации тестированияUnit TestsДешевые в создании, быстрые при прогонеНе используют базу данных и сетьИнтеграционные тестыБолее дорогие в создании, медленнее при прогонеПроходят весь цикл, включая работу с БД и сетьюТесты пользовательского интерфейсаПроходят через пользовательский интерфейсНеустойчивые, медленные
- 30. Независимый отдел тестированияСлабая связь разработчиков и тестеровНизкий уровень документирования=>Низкое качество и производительность тестирования(например, тестеры находят в основном баги верстки)
- 31. СПАСИБО!