- PVSM.RU - https://www.pvsm.ru -
Хочу поделиться опытом по организации процесса тестирования, который охватывает 3 года моей работы и создание нескольких крупных систем. Описание будет затрагивать только автоматизацию «ручного» тестирования без пересечения с другими аспектами разработки ПО.
Я думаю стоит сразу упомянуть, что на всех этапах мы использовали:
Везде, где я буду говорить про автоматизацию тестирования, речь будет идти про тестирование интерфейса с подключением к внешним ресурсам (БД, файловая система, сервисы и т.п.).
На первом крупном проекте, в котором я участвовал, не было тестировщиков. Разработчики перед заливкой на боевой сервер сами проверяли основные части системы. При таком подходе частенько вылезали баги.
Для всех было очевидно, что программисты любят свой код и без особого энтузиазма подходят к тестированию только что написанной фичи. Про тестирование ранее написанных фич, да еще и другими разработчиками, вообще говорить не приходится. Программисты сами не станут заново прогонять всевозможные сценарии работы с системой и заходить во все вкладки всех страниц.
На самом деле на этом проекте мы могли себе позволить подобный подход. Наши пользователи сидели в зоне досягаемости. Это был проект по внутренней автоматизации компании. Операторы и менеджеры, которые работали с Системой, могли подойти к нам и обсудить функциональность, указать на ошибки. Соответственно мы могли сделать быстрый фикс и залить исправленную версию.
Отчеты об ошибках сводились к крикам за стенкой. Потери при багах были незначительные, ситуация всех устраивала.
Судя по опросу, который я проводил Как у вас устроен процесс тестирования? [2] большинство может позволить себе именно такой подход к тестированию.
Мы начинали делать новую систему, которой должны были пользоваться не только люди за стенкой, но и сторонние пользователи. Появилась необходимость нанять тестировщика, который бы уберегал нас от плохих релизов.
Я нанял тестировщика и для начала мы решили, что тестирование должно быть автоматизированным, как запуск модульных тестов. Автоматизация должна была избавить тестировщика, от постоянного повторения одних и тех же сценариев.
Идея была проста и для всех казалась решением проблем. Мы хотели, чтобы CI запускала ночью набор интеграционных тестов. Утром мы приходим, если тесты все зеленые, то значит можно делать релиз. Если есть красные тесты, значит исправляем, снова запускаем весь набор тестов и т.д. пока все тесты не станут зелеными.
Для записи тестов попробовали разные варианты, остановились на Selenium [3]. Сначала тесты писали на API самого Selenium. Со временем начала создаваться обертка над низкоуровневым API и эта обертка превращалась в некий DSL для тестирования.
Пока тестировщик разбирался с продуктами для тестирования и налаживал процесс автоматизации тестов разработка не останавливалась. Мы должны были выпускать новые версии после каждой 1-2 итераций. Тестировщик постоянно находился в стадии погони за программистами. Его цель была 100% покрытием сценариев, чтобы мы могли спокойно выпускать новые версии не боясь багов.
Проблемы с автоматизацией тестирования оказались для нас неожиданными. Фактически мы не были к ним готовы.
Чем больше была система, тем больше мы писали тестов. Тесты начали работать реально медленно. Если они проходили за 14 часов — это была невероятная удача. Со временем тесты перестали укладываться в промежуток между 18.00 прошлого дня и 9.00 текущего дня. Мы не получали от тестов обратную связь, возникали простои в работе. Бывало еще, что свет выключат или сервер перезагрузится, тогда потери времени были слишком большие.
Зелеными тесты не были никогда. Правда один раз были, 30 декабря они запустились и выдали результат как 100% зеленые. Наверное это был их подарок нам на Новый год. Больше такого за всё время не было.
Почему они не были зелеными? Для этого было несколько причин:
Из-за нестабильности тестов и того, что мы не успевали актуализировать их, нам пришлось:
У нас была цель — увидеть зеленые интеграционные тесты и, не боясь багов, залить на боевой сервер. Фактически мы этой цели так и не достигли.
Как итог, первый же запуск системы в реальных условиях показал, что автотесты пропускают множество багов. Эти баги мы нашли, когда вручную потыкали систему. За 10 минут ручного тестирования были обнаружены самые критичные баги.
Я волевым решение отменил работу по всем интеграционным тестам и ввел ручное тестирование с написание тестовых сценариев в Google Docs. После этого мы добили основные баги и тестирование отлично встроилось в Kanban поток.
В данный момент в моей компании мы с командой тестировщиков придерживаемся подхода: ручное тестирование + написание тестовых сценариев в Google Docs. Тестировщики вручную протыкивают все сценарии перед заливкой.
Тестовые сценарии считаются частью артефактов проекта и отдаются заказчику вместе с исходным кодом.
По факту это дает отличные результаты. В релизах у нас только минорные баги, либо баги, которые на самом деле фичи.
Надо понимать границы применимости подхода к автоматизации тестирования. Например, если вы пишите жука, который отлавливает ошибки 404 и 500 на живом сервере, то трудозатраты оправданы.
Если у вас несложное приложение, которое иногда меняется, то есть смысл сделать для него набор интеграционных тестов, но совместить это с ручным тестированием.
Если вы хотите заменить ручное тестирование автоматическим на 100%, то подумайте, как избежать проблем описанных выше. Возможно нам надо было сначала использовать ручное тестирование, а потом, автоматизировать те части, автоматизация которых даст максимальный эффект без необходимости поддерживать эти тесты.
Буду рад услышать, как развивалось тестирование в вашей компании.
Ссылки
Top Five (Wrong) Reasons You Don't Have Testers [6], Joel Spolsky
The Joel Test: 12 Steps to Better Code [7], Joel Spolsky
Обезьянки против роботов. Часть I (TestLabs09) [8], Максим Дорофеев
Обезьянки против роботов. Часть II (TestLabs09) [9], Максим Дорофеев
Обезьянки против роботов. Часть III (TestLabs09) [10], Максим Дорофеев
Организация работы команды в Agile: разработка + тестирование [11]
Автор: AlexanderByndyu
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/9705
Ссылки в тексте:
[1] ScrumbanXP: http://www.dotnetconf.ru/Materialy/Praktika_raboty_s_krupnimi_proektami_ot_scrum_xp_k_kanban
[2] Как у вас устроен процесс тестирования?: http://habrahabr.ru/post/122252
[3] Selenium: http://seleniumhq.org
[4] SpecFlow: http://www.specflow.org
[5] Приемочные тесты на огурце: http://www.dotnetconf.ru/Materialy/Priemochnie_testi_na_ogurce
[6] Top Five (Wrong) Reasons You Don't Have Testers: http://www.joelonsoftware.com/articles/fog0000000067.html
[7] The Joel Test: 12 Steps to Better Code: http://www.joelonsoftware.com/articles/fog0000000043.html
[8] Обезьянки против роботов. Часть I (TestLabs09): http://www.slideshare.net/Cartmendum/testlabs09-part-i?from=ss_embed
[9] Обезьянки против роботов. Часть II (TestLabs09): http://www.slideshare.net/Cartmendum/testlabs-part-ii?from=ss_embed
[10] Обезьянки против роботов. Часть III (TestLabs09): http://www.slideshare.net/Cartmendum/test-labs09-dorofeev-m-part-iii?from=ss_embed
[11] Организация работы команды в Agile: разработка + тестирование: http://www.dotnetconf.ru/Materialy/Organizacia_raboty_komandy_v_agile_razrabotka_testirovanie
Нажмите здесь для печати.