t.me/atinfo_chat Telegram группа по автоматизации тестирования

Как на вашей работе устроен процесс тестирования?

design-patterns
test-design
management
testcasemanagement
process
testing
Теги: #<Tag:0x00007f9e37e8c998> #<Tag:0x00007f9e37e8c7b8> #<Tag:0x00007f9e37e8c678> #<Tag:0x00007f9e37e8c538> #<Tag:0x00007f9e37e8c3f8> #<Tag:0x00007f9e37e8c2b8>

(Alex Predewill) #1

Всем привет.

Поделитесь опытом, как на вашей работе устроен процесс тестирования?

Я сейчас единственный тестировщик в команде.
Пришел в проект, изучил функционал, составил чек листы, немного тест кейсов, выделил важный функционал, который тестируется при каждом релизе, автоматизировал регрессию. Сейчас тестирую новые задачи и поддерживаю автотесты в актуальном состоянии.

С документацией и составлением подробных тест кейсов особо не заморачиваюсь, чек листов пока хватает.

Интересно узнать как организован процесс в командах где есть несколько тестировщиков, как выглядит документация и т.п.


(Sergei) #2

Думаю, не раскрою большой тайны, если скажу, что в подавляющем большинстве контор - херово :slight_smile:

Все то, что пишут в умных книжках, игнорируется начисто, ибо перефразируя А.Лебедева “Долго и ох…енно дорого”.
Более менее поддерживать стерильно-идеальное состояние можно пока проект только зарождается, а потом он разрастается и начинается хаос.


#3

Если разрастается и очень быстро :slight_smile:

У нас в команде 4 человека и я один тестировщик.
Фичи с нового сприинта тестируют девелоперы и я (мануально).
На критично важные вещи - пиишу автоматизацию. Вот и весь процесс


(Artur Korobeynyk) #4

Разработчики дают мне тесты, а я ими тестирую. Мечта, а не работа казалось бы


(SlavikF) #5

У нас также:

  • есть чеклисты
  • какая-то часть (в основном регрессия) покрыта автоматизацией.

Если бывает, что в продакшен уходят какие-то баги, то подправляем чеклисты, чтобы потом не пропускать.

Ну это потому что продукт у нас не такой критический.

До этого я работал в медицинской компании. Наш продукт был одобрен FDA, была ISO сертификация.
Так там у нас было WOP (Work operating procedures), SOP (Standard operating instructions), были traceability matrix: это когда есть список всех requirements, и каждый requirement должен быть покрыт тестами, а в matrix записано какой requirement каким тестом покрыт. Test reports должны быть одобрены как минимум двумя другими участниками, и т.д. и т.п.

По личному наблюдению: вся эта бюрократия и методология в какой-то степени помогает (нет полного раздолбайства), но и при этом у нас всё равно в продакшене оказывались довольно серьёзные баги.


(Alex Vershinin) #6

Привет. У нас устроено примерно следующим образом:

  1. В начале спринта создаётся 2 тест-плана: sprint10-new, sprint10-regression
  2. Тестировщик берёт задачу в тестирование и делает на неё чеклист (табличку в Excel), который доступен любому участнику команды. Другие тестировщики и разработчики могут посмотреть её и подсказать какие-то проверки, либо научиться самим чему-нибудь.
  3. Тестировщик идёт по этому чеклисту, выполняя проверки. Когда задача протестирована, он пишет тест-кейсы на ключевой функционал для этой задаче, включая их в тест-план sprint10-new. Это может быть 1-2-5 тестов, не более, хотя есть и исключения. Если задача состояла в том, чтобы цвет кнопки поменять, то ничего не пишем.
  4. Тестировщик отправляет свои кейсы на ревью остальным тестировщикам. Исправляет, если были замечания. В итоге тест-кейс переходит в статус “готово”. Это позволяет избежать проблем на регрессе и в целом получить более аккуратные тест-кейсы.
  5. Тестировщик обновляет документацию, если были изменения в его задаче (API, другие части приложения).
  6. В конце спринта накапливаются тест-кейсы по всем задачам, закрытым в спринт. Они копируются в общий регрессовый тест-план, который был сформирован за предыдущие спринты.
  7. Общий регрессовый тест-план копируется в спринтовый регрессовый тест-план sprint10-regression. Это нужно, чтобы сохранять запуски по регрессам отдельных спринтов.
  8. Из регресса удаляются тест-кейсы по частям приложения, которые не изменялись в текущий спринт. Если состав команды ограничен, то удаляются ещё и неприоритетные кейсы.
  9. Запускаются автотесты и автоматически проставляется результат ручным тест-кейсам.
  10. Разбираются результаты упавших автотестов, другие тесты запускаются тестировщиками.
  11. В процессе регресса могут дофикшиваться небольшие баги.
  12. После регресса идёт установка на препрод + смоук, затем установка на прод.
  13. Автотесты добавляются по мере возможности. Пока не каждый спринт, но мы движемся к этому.

Рекомендации:

  1. Готовь регрессионную модель смолоду. Проект/команда вырастет - не заметишь.
  2. Хороший регресс - половина документации и онбординга нового тестировщика, и в целом вещь полезная в большом количестве случаев. Не ленись, см. пункт 1.

(Александр Литовский) #7

А автотесты в какой момент пишутся ?


(Salciuc Vitalie) #8

ну в обычном случие когда мануальные прошли и все работает


(Александр Литовский) #9

Ага. Я пропустил 13 пункт, искал в середине