Стратегия тестирования крупного проекта в условиях Agile разработки v2

857 views

Published on

Евгений Тян, Аскон (Санкт-Петербург)

Ведущий разработкчик компании Аскон г. Санкт-Петербург. В течении 5 лет занимаюсь разработкой ПО для проектирования в области архитектуры и строительства. Обычно это крупные проекты в которых сроки разработки от 1 года. Сферы интересов: гибкие методологии разработки, контроль качества, 3D графика, алгоритмы, хранение данных, data mining, diving =)
В крупном проекте со временем начинает ломаться то, что раньше работало. На текущей итерации исправляем баги внесенные на прошлых, проект буксует. Необходимо постоянно поддерживать качество продукта, ведь он отдается заказчику на каждом Demo. Существует множество программных средств для регрессионного тестирования, но у всех свои ограничения. Мой доклад об опыте разработки и внедрения системы регрессионного тестирования в компании "Аскон", о том как она встроилась в agile процесс, какие проблемы возникали в ее использовании. Приходите!

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

  • Be the first to like this

No Downloads
Views
Total views
857
On SlideShare
0
From Embeds
0
Number of Embeds
212
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Стратегия тестирования крупного проекта в условиях Agile разработки v2

  1. 1. Стратегия тестированиякрупного проекта вусловиях agile разработки.Разработка и внедрениесистемы регрессионноготестированияЕвгений Тян«Аскон»tyan@ascon.ru
  2. 2. Сложность9!
  3. 3. Сложность 469! 10
  4. 4. Сложность ∞? 469! 10
  5. 5. Наш проект
  6. 6. Наш проектНаш проект Решение для архитектуры и строительства Срок разработки: 3-4 года CLOC > 120 000
  7. 7. 3D Проектирование
  8. 8. Максимальная свобода
  9. 9. Как начинали -Ручное тестирование UI - TDD, Покрытие тестами ~40%IntegrationUnit tests
  10. 10. Unit тестов не достаточноСложно предусмотреть все возможныеварианты использования модуля
  11. 11. Unit тестов не достаточноСложно предусмотреть все возможныеварианты использования модуля
  12. 12. Unit тестов не достаточноСложно перейти от условийошибки к Unit-тесту
  13. 13. Unit тестов не достаточноСложно воспроизвести ошибку
  14. 14. Unit тестов не достаточноИнтеграционные тесты работают сприложением на более высоком уровне
  15. 15. Unit тестов не достаточноИнтеграционные тесты работают сприложением на более высоком уровне
  16. 16. Unit тестов не достаточноИнтеграционные тесты работают сприложением на более высоком уровне
  17. 17. Проект буксует1 итерация
  18. 18. Проект буксует1 итерация 2 итерация
  19. 19. Проект буксует1 итерация 2 итерация 3 итерация 1
  20. 20. Проект буксует1 итерация 2 итерация 3 итерация 1Итерация 4 Итерация 5 1 2 1 3
  21. 21. Проект буксует1 итерация 2 итерация 3 итерация 1Итерация 4 Итерация 5 Итерация 6 1 2 1 3 1 2 3
  22. 22. Стоимость исправлений
  23. 23. Что еще хуже
  24. 24. Что еще хуже
  25. 25. Что еще хуже
  26. 26. КАК ПОДДЕРЖИВАТЬКАЧЕСТВО ПРОДУКТА?
  27. 27. Тестировать руками?У нас нет столько тестеров
  28. 28. Автоматизация?Рассматривали: TestComplete Squish
  29. 29. Автоматизация?Выяснили: Существуют риски с поддержкой технологий Зависимость от GUI Медленно
  30. 30. Автоматизация?Решение: собственнаясистема автоматизации тестирования
  31. 31. Решение. Инструмент
  32. 32. Решение. Инструмент
  33. 33. Решение. Инструмент
  34. 34. Что такое тест?
  35. 35. Инструмент тестера
  36. 36. Решение. Инструмент
  37. 37. Решение. DoDUnit test-ы написаныCode Review проведенКод слит в основную веткуСтарые тесты работаютПриемочные тесты написаны
  38. 38. Автоматизация
  39. 39. Проблемы внедренияХрупкость тестов на раннем этаперазработкиСложность анализа причин поломки тестаДолго не могли привыкнуть поддерживатьтесты
  40. 40. Проблемы внедренияХрупкость тестов на раннем этаперазработки
  41. 41. Проблемы внедренияХрупкость тестов на раннем этаперазработки
  42. 42. Проблемы внедрения. Анализ
  43. 43. Поддержка тестов
  44. 44. Поддержка тестов• Каждый ответственен за то, что его commit не ломает тесты• Если тест нужно исправить, то этим занимается разработчик, который внес изменение
  45. 45. Что получилиСобственная система интеграционноготестирования. Полный контрольСкорость. За счет возможности отвязаться отGUI и запустить интеграционные тесты внесколько потоков. Прохождение 500 тестов ~3-4 мин.Возможность запускать тесты на каждыйcommitСистема записи сценария встроена вприложение – любой пользователь можетзаписать ошибку и отправить нам
  46. 46. 300250200150 Собственная утилита Testcomplete10050 0 Время прохождения 500 сценариев, мин
  47. 47. Что получилиЗатратили времени ~ 2 командо-месяца (5человек)Есть ошибки в самом инструментетестированияПоддержка. Любые хотелки делаем сами(форматы вывода результатов,интерфейсные удобства, средства анализа)
  48. 48. Как сейчас - Ручное тестирование - Автоматизированное тестирование, UI ~500 сценариев UI - TDD, более 1500 unit-тестовIntegration Покрытие ~60% testsUnit tests
  49. 49. Как сейчас UIIntegration UI Unit UI Integration tests Unit tests
  50. 50. Как сейчас1 итерация 2 итерация 3 итерация 1
  51. 51. Как сейчас1 итерация 2 итерация 3 итерация 1Итерация 4 Итерация 5 Итерация 6 2 3
  52. 52. Не нужно оглядываться,смотрим вперед,движемся уверенней
  53. 53. Кому это надо?
  54. 54. Евгений Тянtyan@ascon.ru

×