Слады для выступления на GDG DevFest Бишкек, 2014. https://plus.google.com/events/cgschph5k60ua1ldq0b06i3o3r8 Выступление сделано по книжке "Как тестируют в Google"

3. Зачем тестируют в Гугле
Зачем вообще тестировать?
Зачем пишут об этом книжки, зачем поднимать вопрос?
Тестирование больше чем программирование
Регрессионное тестирование: после каждого изменения
нужно убедится, что ПО всё еще работает.
Масштабы Гугла
- несколько сотен продуктов и сервисов
- тысячи программистов
- 20 коммитов в минуту!

4. Подход Гугла к качеству
Тестирование не создает качество
Невозможно навешать качество как обертку. Качество
следствие инженерных практик.
Делайте все правильно с самого начала
Перестаньте рассматривать разработку и тестирование
по отдельности. Тестирование и разработка идут рука
об руку.
Роковые ошибки Гугла
см. стр. 279 (русское издание)
Тестировщики стали костылём для программистов.
(технический нигилизм)

5. Подход Гугла к качеству
Правильный подход к написанию кода
Чистый код, code review
Правильная среда разработки
Минимум вариаций, однообразный стандартизованный
подход,
Автоматизация тестирования и не только
Непрерывная сборка
Поощрение стремления к качеству
Забота о качестве кода и качестве тестов –
ответственность всех разработчиков.
Культура жрет стандарты на завтрак

6. Uncle Bob

7. Кто тестирует в Гугле?
Разработчики ПО (Software Engineer)
TDD, интегральные тесты, приемочные тесты
Разработчик-тестировщик
(Software Engineer in Test)
Создает среду для автоматического тестирования,
помогает разработчику ПО. (пишет код)
Не подчиняются директору направления
Работают на разработчика ПО.
Инженер-тестировщик (Test Engineer)
Создание плана тестов, методология тестирования,
работает на пользователя (тоже пишет код)

8. Классификация тестов
Малые
Типа unit-tests, одна функция
Средние
Взаимодействие функций, классов
Большие
Пользовательские сценарии, use cases
Огоромные
Весть продукт и взаимодействие продуктов

9. Сертификация проектов
Уровень 1): CI, классификация тестов, smoke-тесты
Уровень 2): прогон тестов перед коммитом, покрытие
50% и 10% малыми, одна фича покрыта
Уровень 3): новые важные фичи покрыты, 50%
малыми тестами, все нетривиальные дефекты
покрываются.
Уровень 4): смоук-тесты < 30 мин и запускаются
перед коммитом автоматически, все важные фичи
покрыты
Уровень 5): анализ, покрытие не менее 60% (40%
малыми)

10. CI в Гугле
20 коммитов в минуту
Все тесты прогонять нереально
Прогонять тесты выборочно
Запускаются только те тесты, которые относятся к
изменениям.
Тесты прогоняются в облаке
Среда запуска тестов позволяет запускать тесты
параллельно.
Нам это тоже доступно

11. Планирование тестирования
100% покрытие экономически невыгодно
(шатл!) Тестировать то, что больше всего нужно
пользователям.
ACC-анализ
Attribute Component Capability
Анализ рисков
Обычные технические и деловые риски.
Вероятность * ущерб
План тестов за 10 минут
За 10 мин можно написать план на 80% рисков.

12. Инструменты
Selenium Webdriver
Родились в Thought Works и переехали в Google
Проект и был начат и вырос на реальных задачах
Buganizer
Bug-tracker, который Гугл под себя сделал
Browser Integrated Test Environment
Создание дефектов из приложения

13. Как тестируют в Гугле?
Также, как и в любой хорошо организованной
компании.
Никакой магии. Надо делать так, как говорят мировые
методологи.
Автоматизировать тесты не сложно
Это такая-же задача, как и другие задачи разработки
ПО. И решаются они в порядке заботы о пользователе и
заказчике.
Нет времени? Нет времени на что?
Это тупая отмазка. Скорость работы в TDD такая-же,
как и без него или даже быстрее. Переучиваться долго.