Ommonick
@Ommonick
qa+dev (scala, golang, ts/js, api, grpc)

Как систематически подойти к тестированию в малой компании разработчиков?

Добрый день. Имеем ситуацию, два веб\мобайл разработчика (скоро три) и один тестировщик.
Тестировщик умеет в написание тест-кейсов, автоматизировать, имеет знания в различных технических областях.
Как ему построить процесс тестирования проектов, какой должна быть тестовая документация, как оформить свою работу таким образом, чтобы она повышала эффективность и качество работы команды, и это было бы отчетливо видно?
второстепенный вопрос:
Как быть с такими проектами, которые приходят\уходят, которые обмозговываются некоторое время, затем быстро реализуются, с ситуацией, когда разработчики пробуют придерживаться agile методологии в работе..
  • Вопрос задан
  • 530 просмотров
Решения вопроса 2
@JuniorNoobie
Сижу в поддержке, пишу мелкие проекты
Переходите на TDD (Test-driven development). Сначала пишутся тесты, потом код. Сложно, нудно, но зато приложение сразу перекрыто автоматическими тестами. Остается лишь следить за "полным" покрытием. Этим может и тестировщик заняться: если ему удалось что-то сломать или найти баг в работе приложения, то ищем где что поломалось и дописываем тесты, исправляем.
Ответ написан
lxsmkv
@lxsmkv
Test automation engineer
систематическое тестирование начинается с наличия детальной спецификации. Если вы работаете по скраму, то при планировании спринта определяется что должно быть протестировано. Я сам в гибкой разработке не участвовал, но осмелюсь предположить по опыту, что на адекватную документацию тестовых сценариев, если тестировщику их придется писать самому, написание автоматизации к ним и отладку этой автоматизации может потребоваться больше времени чем на спринт. Можно попробовать BDD - т.е тест пишется на "естественном" языке и одновременно является и спецификацией, и приемочным тестом, тогда автоматизатору останется только заимплементировать шаги спецификации в коде. От таких спецификаций польза даже в том случае если вы не будете их автоматизировать. Такие сценарии можно проходить и вручную и вам будет ясно все ли сделано. И пользу от такого подхода можно выразить цифрами, например количество сценариев которые не были окончены к концу спринта.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы