Гибкие методологии разработки набирают всё большую популярность среди команд разработчиков. Одним их основных инструментов достижения результата при этом является TDD - программисты стараются покрыть юнит-тестами как можно больше своего кода. Зачем тогда нужны тестировщики в гибких командах? Если все же нужны, то сколько? И как они должны тестировать? А как тестировать нетестируемое? В докладе разбираются данные вопросы на примере трех разных проектов. По материалам конференции .NET разработчиков http://www.dotnetconf.ru/Materialy/Postroenie_procesa_testirovaniya

1. Вторая конференция .NET разработчиков Построение процесса тестирования Руслан Сафин IndyCode twitter.com/razonrus

2. twitter #dotnetconf

3. Нужно ли тестирование? А тестировщики? А сколько? А как они должны тестировать?

4. Нужны ли тесты?

5. Да! TDD!

6. Нужны ли тестировщики?

7. если у вас стопроцентное покрытие тестамиНЕТно 100% не бывает

8. Когда нет тестировщиков Программист сам ответственен за свои баги Единственный вариант выжить – это 100% покрытие.

10. приложение состоит из одного модуля

12. Баги! В интерфейсе Во взаимодействии модулей В непокрытом тестами коде

13. Тестировщики все же нужны!

14. Сколько? vs

15. Интеграционные и нагрузочные тесты Технологии: Selenium Auto It

16. Интеграционные и нагрузочные тесты Методики: Nightly build Staging

17. А если еще сложнее?

18. Проблемы в тестировании Совмещение процесса создания тестовых сценариев и их программирования

19. Нужно больше тестировщиков! Нужен другой подход к тестированию!

20. Возрастает Скорость написания тестов Покрытие функциональности системы Качество тестовых сценариев

21. Минус Наличие тестировщиков расслабляет!

22. Как протестировать нетестируемое? (или так называемую серую зону)

23. Логировать Мониторить состояние системы Уведомлять об отклонениях от нормы

24. Тестирование необходимо. Тестировщики необходимы. Сколько – зависит от проекта. А не от числа программистов. Как – оптимально покрывая всю функциональность

25. Где границы? Разделение между уже протестированным и еще не протестированным Наличие багов в production Скорость написания тестов

26. И помните! Эффективное тестирование — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых

27. В итоге 0 тестировщиков 1 тестировщик Много тестировщиков TDD TDD + Интеграционные тесты TDD + Интеграционные тесты + Сценарии Логирование и мониторинг

28. Спасибо за внимание Руслан Сафин IndyCode ruslan.safin@indycode.ru twitter.com/razonrus