1.
Спикер:
Тема презентации:
Кокин Роман
Тестирование в больших командах

2.
AGENDA
• The process of testing.
• Fix up testing.
• The Perfect Testing?

3.
The Test Process
Consists of:
• Planning
• Analysis and design
• Implementation and execution
• Evaluating exit criteria
• Reporting
• Test closure activities

4.
Details
Action Objectives
Planning Define Objectives
Analysis & Design Transform objectives into tangible things
Implementation Provide place for testing
Execution Run tests 
Eval. Exit Criteria Assess testing against the defined obj.
Reporting Provide information
Closure Activities Summarize results
Control Compare actual progress against the plan

5.
Items
Object Source
Requirements Email, Docs, Spec Tools
Test Cases HP QC, TestRails, Zephyr
Environment Build + Deploy
Test Run In Scope of Test Case
Bugs Jira, ForBugz, Redmine, UTrac
Version Control SVN, Git, VCS
Reporting Cases + Runs + Bugs
Knowledge In Scope of Requirements

6.
Team Types
Team Dev QA
Small 1-3 1-2
Medium 3-5 2-3
Large 5-7 4-5
Unions 7+ 5+

7.
Small Teams
• Dev: 1-3; QA: 1-2; Other Roles: 0.
• Requirements: Mockups, Docs, Email, Calls.
• Dev Config: BE + FE Developer, Mobile App.
• QA Config: Manual
• Testing Types: Exploratory, AdHoc, Functional, UI
• Tools: Issue Tracker
• Process: Define Req-s -> Approve -> Development ->
Testing -> Release -> Check List -> Acceptance

8.
Medium Teams
• Dev: 3-5; QA: 2-3; Mng.
• Requirements: Shared Spec, PSD, Docs.
• Control Version: SVN.
• Dev Config: BE Dev., FE Dev., Mobile App Dev.
• QA Config: Manual.
• Testing Types: Functional, UI (Cross-Brw), BE + DB,
Smoke, Regression.
• Tools: Issue Tracker + Test Mng Tool.
• Process: Scrum, Several Env-ts.

9.
Large Teams
• Dev: 5-7; QA: 4-5; Mng; BA; Support.
• Requirements: Shared Tool.
• Control Version: SVN, Git
• Dev Config: BE Dev., FE Dev., Mobile App Dev., DB
Dev, DevOps.
• QA Config: Manual + Automation
• Testing Types: Functional, UI (Cross-Brw), BE + DB,
Smoke, Regression, Automation, Performance.
• Tools: Issue Tracker + Test Mng Tool, CI.
• Process: Scrum, Auto-Builds.

10.
Unions
• Dev: 7+; QA: 5+; Mng; BA; Support.
• Control Version: SVN, Git
• Dev Config: BE Dev., FE Dev., Mobile App Dev., DB
Dev, DevOps.
• QA Config: Manual + Automation + Performance +
Security
• Testing Types: Functional, UI (Cross-Brw), BE + DB,
Smoke, Regression, Automation, Performance.
• Tools: Req-ts Mng + Issue Tracker + Test Mng Tool, CI

11.
Differences
• Requirements are separated on Spaces
• Issue tracker on Projects
• The same for Test Management tool
• The processes coordination between
teams
• Integration testing would be more
important
• Some types of testing would be
represented as service

12.
The Perfect Testing?
• Альберто Савоя — директор по
разработке и популяризатор инноваций в
Google.
• Джеймс Уиттакер — технический
директор Google, ответственный за
тестирование Chrome, Maps и веб-
приложений Google.
• Патрик Коупленд — старший директор
направления продуктивности разработки,
вершина пирамиды тестирования в
Google.

13.
The Beginning
• Альберто Савоя присоединился в
2001 году.
• На тот момент в компании было 200
инженеров и целых три
тестировщика.
• TDD
• Случайное тестирование зависящее от
добросовестности разработчика.
• Агитация использовать JUnit.

14.
The Real Changes
• Патрик Коупленд пришел гугл в 2005 году.
• На тот момент в компании было менее 1000 инженеров и 50
специалистов по тестированию.
• Тестирование UI + Exploratory Testing -> AdHoc.
• Основные идеи:
o Google уважает компьютерные технологии и искусство
программирования.
o Команда может сделать качественный продукт только в том
случае, если за качество отвечают все ее участники.
o Тестирование должно перестать просто предоставлять
информацию и начать влиять на качество.

15.
Activities
• Попытка изменить существующие
процессы.
• Наим тестировщиков умеющих писать код.
• Объединение дисциплин разработки и
тестирования.
• Расширение областей деятельности
«службы тестирования».
• Переименование команды на
«направление продуктивности
разработки».

16.
Roles, SWE
Разработчик (Software Engineer, SWE)
• пишет код функциональности приложений
• создает проектную документацию
• определяет структуры данных и общую архитектуру
• проводит код-ревью
• участвует в создании малых, средних и больших
тестов
Разработчик отвечает за качество всего кода, к которому
он прикасается: пишет, исправляет или вносит
изменения.

17.
Roles, SET
Разработчик в тестировании (Software Engineer in Test, SET)
• фокусируется на тестируемости кода и создании инфраструктуры
тестирования
• анализирует архитектуру, уделяет особое внимание качеству кода
и рискам проекта
• выполняет рефакторинг, чтобы сделать код тестируемым
• пишет фреймворки юнит-тестирования и средства автоматизации.
Разработчик в тестировании работает с тем же кодом, что и разработчик,
но больше заинтересован в улучшении качества и тестового покрытия,
чем в добавлении новых фич или повышении производительности.

18.
Roles, TE
Инженер по тестированию (Test Engineer, TE)
• пишут много кода для автотестов
• организуют работу по тестированию, которую
выполняют другие инженеры
• управляют выполнением тестов и интерпретируют их
результаты тестов
Особенно важна их работа на поздних стадиях проекта, когда
напряжение с приближением выпуска растет. Инженеры по
тестированию — это эксперты продукта, консультанты по
качеству и специалисты по анализу рисков.

19.
Org. Structure Usual

20.
Org. Structure Google

21.
Test Types, Small
Малые тесты
• Автоматизируются
• Исполняют код одной функции
• Проверяют типичные проблемы
• Пишут разработчики
• Подставные объекты, имитации
Малые тесты отвечают на вопрос «Делает ли этот
код то, что он должен делать?»

22.
Test Types, Med
Средние тесты
• Автоматизируются
• Покрывают две или больше функций
• Проверяют взаимодействие
• Пишут и сопровождают разработчики
• Могут выполняться вручную инженерами по
тестированию
Средние тесты отвечают на вопрос «Взаимодействуют ли
соседние функции друг с другом так, как должны?»

23.
Test Types, Large
Большие тесты
• Покрывают не меньше трех функций
• Проверяют реальные пользовательские сценарии
• В создание и сопровождение вовлечены все роли
• Могут быть как автоматизированны, так и
выполняться вручную
Большие тесты отвечают на вопрос «Работает ли
продукт так, как нужно пользователю, и дает ли
желаемый результат?»

24.
The Perfect Process
• SWE реализует функциональность
• SET создают средства тестирования, помогают
с юнит-тестами, создают тестовую
инфраструтуру
• SWE пишут малые и средние тесты
• TE отвечают за автоматизацию
пользовательских сценариев в контексте
продукта.
• TE проводят исследовательское ручное
тестирование
• Оценивают универсальность и эффективность
всех действий по тестированию

25.
Result
• Тестирование является в орг. структуре
процесса является независимой дисциплиной
• Тестирование объединено с процессом
разработки и направлено на предотвращение
ошибок, а не на их поиск
• Специалисты по тестированию являются
высококвалифицированными сотрудниками
владеющие кодом не хуже разработчиков
• За качество выпускаемой продукции отвечает
вся команда. Т.е. «шишка» валится на того, кто
произвел баг, а не на того, кто его не нашел

26.
THANKS!