8. Идеальный процесс
разработки
• Удобный
• Способствует повышению качества
• Снижает риски
• Ускоряет разработку
• Прозрачен для всей команды
• Максимально автоматизирован
• ?
9. Continuous Integration.
Непрерывная интеграция.
Непрерывная интеграция — это практика
разработки программного обеспечения, которая
заключается в выполнении частых
автоматизированных сборок проекта для
скорейшего выявления и решения
интеграционных проблем.
Википедия
10. Continuous Integration.
Непрерывная интеграция.
"Continuous Integration is a software development
practice where members of a team integrate their
work frequently, usually each person integrates at
least daily - leading to multiple integrations per
day. Each integration is verified by an automated
build (including test) to detect integration errors as
quickly as possible."
M. Fowler
12. Требования к проекту
• исходный код и все, что необходимо для
сборки и тестирования проекта, хранится в
репозитории системы контроля версий
• чекаут из репозитория, сборка и тестирование
проекта автоматизированы
14. Continuous Integration.
Преимущества использования
• Проблемы интеграции выявляются и
исправляются быстро, что оказывается
дешевле
• Немедленный прогон модульных тестов для
свежих изменений
• Постоянное наличие текущей стабильной
версии вместе с продуктами сборок — для
тестирования, демонстрации, и т. п.
16. Система контроля версий.
Version control system
Система контроля версий – инструмент, облегчающий работу
с изменяющимися данными. Предоставляет возможность
хранить несколько версий одного документа, при
необходимости вернуться к более ранней версии, определить
кто и когда внес то или иное изменение, etc.
17. Система контроля версий.
Преимущества использования
• Легкий доступ к коду
• Обеспечивает версионность
• Облегчает совместную разработку
• Возможность автоматизировать процессы сборки,
ревью, запуска тестов
18. Система контроля версий.
Антипаттерны
1. Редкие коммиты -> рискуем потерять часть
изменений, реже интегрируемся
Решение: Частые коммиты в течение дня
2. Массовые коммиты перед уходом с работы
-> рискуем задержать коллег из-за
сломанной сборки
Решение: Не коммитить после N часов
21. Код-ревью.
Code-review
Код-ревью – систематический просмотр кода с целью
найти и исправить ошибки, допущенные на начальном
этапе разработки.
Цель - повышение качества кода и обмен опытом
между разработчиками.
Виды
• Pre-commit review (email/over-the-shoulder)
• Post factum
• Выборочное ревью
22. Код-ревью.
Плюсы и минусы
Плюсы:
• Способствует обнаружению ошибок
• Возможность получить фидбек о стиле программирования и
выборе алгоритмов
• Обмен опытом
• Развивает командность
• Единообразность кода
Минусы:
• Требует инвестиций на начальном этапе
23. Код-ревью.
Типы ошибок
• Ошибки обращения к данным
• Ошибки логических и арифметических
операций
• Использование сложных конструкций
• Ошибки в логике программы
• Стилевые ошибки
• Опечатки
24. Ошибки обращения
К данным
• Проблемы адресации
• Индексы массивов
• Объявление переменных
• Размер и тип
• Именование переменных
• …
33. Автосборка.
Антипаттерны
Редкие сборки -> поздно обнаруживаем баги
Решение: В идеале - сборка после каждого коммита
Допускается сборка по расписанию несколько раз в день, если
сборка+прогон модульных тестов занимает много времени
NB! Возможно, это проблема и с ней надо разобраться отдельно
39. Непрерывная обратная связь.
Continuous Feedback
Необходима автоматическая отправка информации о
состоянии сборки разработчикам.
Средства: Email, SMS, дашборды, нотификация в
мессенджер
40. Обратная связь.
Антипаттерны
Слишком много сообщений о проваленной сборке ->
Письма заносятся в спам-фильтр.
Решение: Сообщения должны быть адресными – тому, кто сломал
сборку.
41. Обратная связь
Антипаттерны
Неинформативные отчеты -> уходит много времени на понимание
проблемы
Решение: В сообщении должна содержаться необходимая и
достаточная информация о проваленной сборке/тестах
43. Требования к CI серверу
• Проверка наличия изменений в репозитории
• Выполнение некоторых действий по триггеру
(наличие изменений, расписание)
• Поддержка нескольких инструментов сборки
• Поддержка нескольких VCS
• Предоставление отчетов, статистики,
отправка нотификаций
• Сохранение истории
• Панель управления задачами
47. Continuous Delivery&
Continuous Deployment
“Continuous Delivery is about keeping your
application in a state where it is always able to
deploy into production.
Continuous Deployment is actually deploying
every change into production, every day or
more frequently.”
M. Fowler
49. Непрерывное развертывание.
Tips&Tricks.
• Автоматизированная выкладка одной командой
• Только полностью готовые к выкладке фичи в production-ветке
• DevOps
• Чистота среды
• Маркировка каждой сборки
• Прогон всех проверок
• Использование обратной связи
• Возможность быстро откатить изменения
52. Мифы о тестировании
• Тестирование увеличивает время до выкладки в
продакшн
• Тестировщики любят находить много багов
• Тестировщики обеспечивают качество
• Тестировщики отвечают за качество продукта
• Тестирование должно быть полностью
автоматизировано
53. Эффективное
взаимодействие
• Тестировщики должны иметь возможность
протестировать приложение
• Процесс разработки должен быть прозрачен для
тестировщика (и наоборот)
• Работа с кодом
• Работа с требованиями
• Работа с багами
55. Тестопригодность.
Testability
Характеристики тестопригодного ПО:
• управляемость: возможность перейти в любое состояние
системы, подавая на вход разные стимулы
• наблюдаемость: в каждый момент времени понимаем в каком
состоянии находится система
• изолируемость: тестируемый компонент может быть проверен в
изоляции
• разделение задач: тестируемый компонент имеет одно, вполне
определенное назначение
• понятность
• автоматизируемость: возможность автоматизировать
тестирование
56. Управление требованиями и
процесс разработки
Тестировщику необходим список изменений ->
Все изменения должны быть отражены в ТЗ/Таск-
трекере.
57. Работа с багами
• Старайтесь относиться позитивно
• Учитесь на ошибках
• Все баги – через баг/таск-трекер
• Не накапливайте технический долг
59. Баги в продакшне:
причины
• Ошибка тестировщика
• Невозможность протестировать все
• Баг воспроизводится нестабильно (гейзенбаг)
• Несоответствие тестовой среды продакшн-среде
• Ошибка при выкладке
60. Баги в продакшне:
действия
• Фикс
NB! Фикс должен быть протестирован перед выкладкой
• Анализ причин
• Меры по предотвращению багов в будущем
61. Резюме
• Процесс важен для достижения результата
• Процесс должен существовать не ради процесса
• Процесс должен быть удобен всем и способствовать
эффективной работе команды
