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