Download to read offline
Uploaded byDataArt
Роман Кокин «Организация тестирования в больших командах»
Документ обсуждает процесс тестирования в больших командах, выделяя этапы тестирования и различия между малыми, средними и большими командами, а также типами тестов. Он подчёркивает важность интеграции тестирования в процесс разработки, где качество продукции зависит от всех участников команды. Также рассматриваются конкретные роли и задачи, связанные с тестированием, вместе с примерами применения этих методов в компании Google.
More Related Content
Similar to Роман Кокин «Организация тестирования в больших командах»
Роман Кокин «Организация тестирования в больших командах»
- 1. Спикер: Тема презентации: Кокин Роман Тестированиев больших командах
- 2. AGENDA • The processof testing. • Fix up testing. • The Perfect Testing?
- 3. The Test Process Consistsof: • Planning • Analysis and design • Implementation and execution • Evaluating exit criteria • Reporting • Test closure activities
- 4. Details Action Objectives Planning DefineObjectives 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 DevQA 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 areseparated 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 Разработчик (SoftwareEngineer, SWE) • пишет код функциональности приложений • создает проектную документацию • определяет структуры данных и общую архитектуру • проводит код-ревью • участвует в создании малых, средних и больших тестов Разработчик отвечает за качество всего кода, к которому он прикасается: пишет, исправляет или вносит изменения.
- 17. Roles, SET Разработчик втестировании (Software Engineer in Test, SET) • фокусируется на тестируемости кода и создании инфраструктуры тестирования • анализирует архитектуру, уделяет особое внимание качеству кода и рискам проекта • выполняет рефакторинг, чтобы сделать код тестируемым • пишет фреймворки юнит-тестирования и средства автоматизации. Разработчик в тестировании работает с тем же кодом, что и разработчик, но больше заинтересован в улучшении качества и тестового покрытия, чем в добавлении новых фич или повышении производительности.
- 18. Roles, TE Инженер потестированию (Test Engineer, TE) • пишут много кода для автотестов • организуют работу по тестированию, которую выполняют другие инженеры • управляют выполнением тестов и интерпретируют их результаты тестов Особенно важна их работа на поздних стадиях проекта, когда напряжение с приближением выпуска растет. Инженеры по тестированию — это эксперты продукта, консультанты по качеству и специалисты по анализу рисков.
- 19.
- 20.
- 21. Test Types, Small Малыетесты • Автоматизируются • Исполняют код одной функции • Проверяют типичные проблемы • Пишут разработчики • Подставные объекты, имитации Малые тесты отвечают на вопрос «Делает ли этот код то, что он должен делать?»
- 22. Test Types, Med Средниетесты • Автоматизируются • Покрывают две или больше функций • Проверяют взаимодействие • Пишут и сопровождают разработчики • Могут выполняться вручную инженерами по тестированию Средние тесты отвечают на вопрос «Взаимодействуют ли соседние функции друг с другом так, как должны?»
- 23. Test Types, Large Большиетесты • Покрывают не меньше трех функций • Проверяют реальные пользовательские сценарии • В создание и сопровождение вовлечены все роли • Могут быть как автоматизированны, так и выполняться вручную Большие тесты отвечают на вопрос «Работает ли продукт так, как нужно пользователю, и дает ли желаемый результат?»
- 24. The Perfect Process •SWE реализует функциональность • SET создают средства тестирования, помогают с юнит-тестами, создают тестовую инфраструтуру • SWE пишут малые и средние тесты • TE отвечают за автоматизацию пользовательских сценариев в контексте продукта. • TE проводят исследовательское ручное тестирование • Оценивают универсальность и эффективность всех действий по тестированию
- 25. Result • Тестирование являетсяв орг. структуре процесса является независимой дисциплиной • Тестирование объединено с процессом разработки и направлено на предотвращение ошибок, а не на их поиск • Специалисты по тестированию являются высококвалифицированными сотрудниками владеющие кодом не хуже разработчиков • За качество выпускаемой продукции отвечает вся команда. Т.е. «шишка» валится на того, кто произвел баг, а не на того, кто его не нашел
- 26.