How I lost my QA job
•
2 likes•1,051 views
At Smartling we're taking quality seriously. At Smartling we don't have a QA team. Are we contradicting ourselves? This talk will cover evolution of processes in our team since major change of switching to Continuous Deployment. I’ll share our experience of adopting TDD and lessons learned from it, how come there left no place for QA engineers and where is testing. Target audience: anyone interested in improving, experimenting and introducing new practices in their team.
Recommended
More Related Content
What's hot
What's hot (18)
Similar to How I lost my QA job
Similar to How I lost my QA job (20)
Recently uploaded
Recently uploaded (20)
How I lost my QA job
- 1. Katya Kameneva How I lost my QA job #SmartlingDevLove @katookatoo
- 2. Cloud-based enterprise software platform for translation management #SmartlingDevLove @katookatoo
- 5. #SmartlingDevLove @katookatoo Continuous Delivery Developer owns the feature Find out requirements Develop solution Implement Test Release Monitor
- 7. #SmartlingDevLove @katookatoo TDD Scale Keep fast delivery Raise internal quality
- 8. Sell it #SmartlingDevLove @katookatoo Problem → Solution Individual attention
- 9. Reach Common Understanding #SmartlingDevLove @katookatoo Discussions Find Expert Pair Programming
- 10. Raise Expertise. Build Habit. #SmartlingDevLove @katookatoo Promoters Pair Programming Code Review
- 11. Raise Expertise. Build Habit. #SmartlingDevLove @katookatoo AlexA AlexB AlexC Jun 1 Jun 8 Jun 15 AlexA AlexB AlexC CR1 CR4 CR3 CR7 CR5 CR2 Pair Programming Sessions Code Reviews
- 12. Lessons Learned #SmartlingDevLove @katookatoo It takesTime and Effort Requires Expertise It’s Peopleware Collaborative work helps
- 13. Signs of Progress #SmartlingDevLove @katookatoo # ofTests grows Test coverage grows
- 14. LOC +30% Tests +120% Coverage +12% 10 Months
- 15. Signs of Progress #SmartlingDevLove @katookatoo High usage of words ‘Tests’ and ‘Refactoring’ TE should feel change
- 18. #SmartlingDevLove @katookatoo Sources Of Issues Requirements Design Code
- 19. #SmartlingDevLove @katookatoo PreventiveTherapy Requirements Design Code Prototyping Architecture review Code review Estimation sessions TDD Continuous IntegrationPair Programming Regular Communication
- 20. Should DEV test? #SmartlingDevLove @katookatoo Shorter feedback loop Focus on priority tasks Faster Delivery Embedded testing Cross-functional team Less waste
- 21. Thank you #SmartlingDevLove @katookatoo Podcasts “IsTDD dead” bit.ly/isTDDdead Trish Khoo “Scaling up with EmbeddedTesting” http://youtu.be/K6gIQYfXn5Q?t=11m25s Theory of Constraints “The Goal:A Process of Ongoing Improvement” by Eliyahu M. Goldratt katya@smartling.com
Editor's Notes
- DEV ответственные за фичу: разработка, тестирование, запуск, жизнь. TE - фреймворк для системных тестов, ручное тестирование выборочно.
- DEV ответственные за фичу: выяснение требований-вместе с PO, разработка, тестирование, запуск, жизнь. TE - фреймворк для системных тестов, ручное тестирование выборочно, консультации. Т.к. на разработчиках много всего - начали развитие тулзов в помощь разработчикам -> DevOps team
- Решили делать TDD
- С тестами легче разбираться в коде Не бояться делать изменения и рефакторинг -> не создавать технический долг
- Goal: everybody committed. Top to Bottom. Large team. Senior team. Люди разные, с разной мотивацией, покажите им персональную выгоду. Уделите внимание каждому отдельно, выслушайте, поймите. Это Peopleware. Напр: время разработки увеличится. Если bottom->top: получить поддержку менеджмента. Не бойтесь критиков. *Ошибка: не доконца проработанные индивидуумы. особенно лиды. Не согласившийся лид будет тормозить всю свою команду.
- Начали делать - появились вопросы и расхождения во мнениях. Обсуждения не были эффективными. Лучше рассматривать конкретную практическую проблему чем коня в вакууме. Надеялись на парное программирование как метод синхронизации: много людей, разные проблемы в парах. Не хватало авторитетного эксперта. В небольших командах с экспертом может сработать. Возможно внешний тренингом был бы лучшим решением. *Ошибка - недооценка сложности синхронизации в понимании практики.
- Goal: everybody knows how to do it. everybody actually does it. Need DEVs-promoters to lead the effort. Распространять практику, набрать критическую массу. Enforcement: Each feature is done in TDD. If not - bring it up. CR checklist updated [set build threshold for test coverage] How to track progress? Individual assessment: by pair programming, by code review.
- How to track? Individual assessment: by pair programming, by code review LessonsLearned: it takes resources to make them track, talk to individuals with slow progress Т.к. Code Review был одним из инструментов внедрения TDD: увеличение покрытия изменений CR, сокращение времени жизни CR. *Ошибки: не достаточно promoters - медленный процесс, более активно вовлекать новеньких. итого
- Будьте готовы к затратам. Проект замедлится не только из-за перехода на новый стиль разработки, но и за счет того, что кто-то в команде занимается продвижением. Это Проект - лид, время, эксперты. Привлеките к распространению тех, кто умеет работать с людьми. Те кто мало зависит от других, работает один над фичей - потребует больше времени на адаптацию. Чем более плотная командная работа - тем лучше. Pair Programming в идеале. Нужна взаимозависимость. Легче со здоровой доверительной атмосферой в команде.
- Количество тестов никак не относится к их качеству. - ссылка на Лешин ивент. Общий показатель покрытия не имеет смысла. Оценивайте покрытие changesets. Жалобы на код без тестов - хорошо. Если новый код - есть над чем работать.
- Тренд по багам.
- Жалобы на код без тестов - хорошо. Если новый код - есть над чем работать. TE лучше всего знают DEV.
- TE1->DevOps; TE2->PO Какой поход к заботе о качестве в таком
- Что если работать над причиной появления багов? Откуда берутся баги?
- Пофилактика На самом деле это - тестирование в каждой активности + командная работа.
- передача между людьми: координация, простои, очереди меньше незаконченной работы