"Белоснежка и шесть гномов" или разработчики тоже тестируют
•Download as PPTX, PDF•
1 like•1,112 views
Презентация Алексея Никитина на SQA Days-16 14-15 ноября 2014, Санкт-Петербург, Россия www.sqadays.com
Recommended
Recommended
More Related Content
More from SQALab
More from SQALab (20)
"Белоснежка и шесть гномов" или разработчики тоже тестируют
- 1. "Белоснежка" и шесть гномов или разработчики тоже тестируют Алексей Никитин
- 2. Мы - это • 5 разработчиков • 1-3 тестировщиков • 1 архитектор • 1 системный аналитик • Основной состав команды вместе уже 3 года
- 3. Что мы делаем? • Разрабатываем • Тестируем
- 4. Что мы делаем ещё? • Сами создаём и поддерживаем тестовую среду • Готовим релизную поставку • Поддерживаем админов во время релиза • Поддерживаем пользователей (4 линия) • И многое другое
- 5. 1 тестировщик 6 программистов
- 6. Что делать, чтобы не
- 9. • заниматься тестированием • тестировать рабочий функционал
- 10. • заниматься тестированием • тестировать рабочий функционал • не заниматься регрессом
- 11. • заниматься тестированием • тестировать рабочий функционал • не заниматься регрессом • не писать автотесты
- 12. • заниматься тестированием • тестировать рабочий функционал • не заниматься регрессом • не писать автотесты • не тестировать простой функционал
- 13. • заниматься тестированием • тестировать рабочий функционал • не заниматься регрессом • не писать автотесты • не тестировать простой функционал • не проводить нагрузку, приёмку
- 14. • заниматься тестированием • тестировать рабочий функционал • не заниматься регрессом • не писать автотесты • не тестировать простой функционал • не проводить нагрузку, приёмку
- 15. А что после? • меньше багов
- 16. А что после? • меньше багов • разработчики думают о нас
- 17. А что после? • меньше багов • разработчики думают о нас • сформирована «команда запаса»
Editor's Notes
- Мы одна команда и делаем одно дело и всем необходимо объяснить, что фича запрограммирована и фича сделана - это не одно и тоже. В режиме острой нехватки тестирования в команде есть два варианта: нагнать ещё тестировщиков или справляться теми силами, что есть. Т.к. получить ещё тестировщиков в ближайшей перспективе нам не светило, то оставался один выход - надо справляться самим. И первым шагом к это великой цели был отказ тестировщика заниматься не тестированием. Т.е. на этом этапе необходимо перестать заниматься любой деятельностью, которая не связана с тестированием. Это может быть всё что угодно, чем вы уже долгое время занимаетесь. У нас было настройка билдов и билд-машин, поддержка пользователей и реакция на срабатывания мониторинга и т.п.
- Отказ заниматься не тестированием не может очень сильно повлиять на ситуацию в целом, поэтому необходимо двигаться дальше. Следующий шаг нацелен на сокращение итераций тестирования и уменьшение количества багов, которые заводятся на этапе тестирования. Для этого существует простое решение - smoke-тестирование тасок и багов перед передачей в тестирование. Чтобы на smoke-тестировании было протестировано то, что вы хотели, должны быть тест-кейсы. Они могут быть написаны специально для smoke, это может быть выделенные кейсы из основного набора кейсов для фичи, они просто могут быть описаны в текстовом файле или даже просто обговорены с разработчиком устно.
- Обычно регресс - это либо автотесты, либо уже написаные тест-кейсы. Чаще это бывает смесь этих вариантов. Поэтому в зависимости от того, в какой пропорции эти варианты существуют у вас, вам придётся больше или меньше печенек предлагать разработчикам.
- Если передача smoke- и regress- теситрования разработчикам не помогла и вы всё ещё самое слабое звено в команде и вы пишите автотесты, то следующий шаг - это писать автотесты силами разработки. Вы готовите тест-кейсы, разработчики их пишут. Главное - это чётко продумать, что нужно сделать, чтобы этим кексам можно было доверять. Если у вас уже была отлажена процедура создания и проверки автотестов, то вы просто объясняете её разработчикам и они следуют ей. Если же у вас такой процедуры не было, то её необходимо создать и обговорить как должны будут писаться и проверятся автотесты.
- Если же автотестов вы не пишите или передача их разработчикам не спасает вас от ежедневных переработок, то можно отдать и функциональное тестирование. В этом случае тоже должны быть тест-кейсы в том или ином виде. Главное, чтобы вы точно знали, что и как было протестировано. Ну и конечно не надо тестировать то, что сам написал.
- Приёмочное, нагрузочное и любое другое тестирование тоже можно передать разработчикам, главное чтобы были тест-кейсы.
- Не надо смешивать задачи на тестирование и на разработку