Поделитесь опытом, как на вашей работе устроен процесс тестирования?
Я сейчас единственный тестировщик в команде.
Пришел в проект, изучил функционал, составил чек листы, немного тест кейсов, выделил важный функционал, который тестируется при каждом релизе, автоматизировал регрессию. Сейчас тестирую новые задачи и поддерживаю автотесты в актуальном состоянии.
С документацией и составлением подробных тест кейсов особо не заморачиваюсь, чек листов пока хватает.
Интересно узнать как организован процесс в командах где есть несколько тестировщиков, как выглядит документация и т.п.
Думаю, не раскрою большой тайны, если скажу, что в подавляющем большинстве контор - херово
Все то, что пишут в умных книжках, игнорируется начисто, ибо перефразируя А.Лебедева “Долго и ох…енно дорого”.
Более менее поддерживать стерильно-идеальное состояние можно пока проект только зарождается, а потом он разрастается и начинается хаос.
У нас в команде 4 человека и я один тестировщик.
Фичи с нового сприинта тестируют девелоперы и я (мануально).
На критично важные вещи - пиишу автоматизацию. Вот и весь процесс
какая-то часть (в основном регрессия) покрыта автоматизацией.
Если бывает, что в продакшен уходят какие-то баги, то подправляем чеклисты, чтобы потом не пропускать.
Ну это потому что продукт у нас не такой критический.
До этого я работал в медицинской компании. Наш продукт был одобрен FDA, была ISO сертификация.
Так там у нас было WOP (Work operating procedures), SOP (Standard operating instructions), были traceability matrix: это когда есть список всех requirements, и каждый requirement должен быть покрыт тестами, а в matrix записано какой requirement каким тестом покрыт. Test reports должны быть одобрены как минимум двумя другими участниками, и т.д. и т.п.
По личному наблюдению: вся эта бюрократия и методология в какой-то степени помогает (нет полного раздолбайства), но и при этом у нас всё равно в продакшене оказывались довольно серьёзные баги.
Привет. У нас устроено примерно следующим образом:
В начале спринта создаётся 2 тест-плана: sprint10-new, sprint10-regression
Тестировщик берёт задачу в тестирование и делает на неё чеклист (табличку в Excel), который доступен любому участнику команды. Другие тестировщики и разработчики могут посмотреть её и подсказать какие-то проверки, либо научиться самим чему-нибудь.
Тестировщик идёт по этому чеклисту, выполняя проверки. Когда задача протестирована, он пишет тест-кейсы на ключевой функционал для этой задачи, включая их в тест-план sprint10-new. Это может быть 1-2-5 тестов, не более, хотя есть и исключения. Если задача состояла в том, чтобы цвет кнопки поменять, то ничего не пишем.
Тестировщик отправляет свои кейсы на ревью остальным тестировщикам. Исправляет, если были замечания. В итоге тест-кейс переходит в статус “готово”. Это позволяет избежать проблем на регрессе и в целом получить более аккуратные тест-кейсы.
Тестировщик обновляет документацию, если были изменения в его задаче (API, другие части приложения).
В конце спринта накапливаются тест-кейсы по всем задачам, закрытым в спринт. Они копируются в общий регрессовый тест-план, который был сформирован за предыдущие спринты.
Общий регрессовый тест-план копируется в спринтовый регрессовый тест-план sprint10-regression. Это нужно, чтобы сохранять запуски по регрессам отдельных спринтов.
Из регресса удаляются тест-кейсы по частям приложения, которые не изменялись в текущий спринт. Если состав команды ограничен, то удаляются ещё и неприоритетные кейсы.
Запускаются автотесты и автоматически проставляется результат ручным тест-кейсам.
Разбираются результаты упавших автотестов, другие тесты запускаются тестировщиками.
В процессе регресса могут дофикшиваться небольшие баги.
После регресса идёт установка на препрод + смоук, затем установка на прод.
Автотесты добавляются по мере возможности. Пока не каждый спринт, но мы движемся к этому.
Рекомендации:
Готовь регрессионную модель смолоду. Проект/команда вырастет - не заметишь.
Хороший регресс - половина документации и онбординга нового тестировщика, и в целом вещь полезная в большом количестве случаев. Не ленись, см. пункт 1.
testomat.io управление авто тестами
