Если при выполнении проекта с использованием BDD со 100% охватом пользовательских историй автоматизированными приемочными тестами, какую роль будет выполнять специалист по тестированию / обеспечению качества?
Я предполагаю, что разработчики напишут приемочные тесты совместно с владельцем продукта, дайте мне знать, если это кажется глупым предположением.
Ответы:
Может быть, я слишком старомоден, но даже самые современные методы разработки или разработки не могут заменить другой набор глаз, свежие глаза, прежде чем выпустить продукт для вашего клиента.
Даже если ваш продукт является просто API для другого разработчика, вы можете использовать QA, чтобы думать как пользователь API, предоставляя сценарии тестирования / использования, о которых вы или ваш клиент не думали заранее.
Если ваш продукт основан на пользовательском интерфейсе, определенно вы хотите, чтобы другой человек (это не вы или кто-то из вашей команды) смотрел на конечный результат перед отправкой его клиенту.
Как и любое другое модное слово в нашей отрасли, BDD - даже со 100% покрытием - не является серебряной пулей .
100% охват - это не то же самое, что 100% тестирование.
В проекте ATDD я видел бы специалиста по обеспечению качества как человека, который помог бы написать тесты и выполнить другие виды тестирования, которые все еще существуют. Т.е. UI Тестирование, тестирование на разрушение и нагрузочные / стресс-тесты.
Но я никогда не разрабатывал проект ATDD.
Задача QA - сломать приложение, а задача разработчика - не сломать его. Поэтому они пишут свои тесты с другой точки зрения. Например, разработчики пишут тесты, чтобы увидеть, происходит ли ожидаемое поведение, QA пишет тесты, чтобы увидеть, что происходит, когда пользователи делают то, что разработчик никогда не посчитает, что пользователь сделает. Кроме того, разработчики часто неверно истолковывают требования, и тесты QA поймут, когда их интерпретация отличается от того, что разработчик думал, что это означает, и затем соберутся с заинтересованными сторонами проекта, чтобы определить, какая интерпретация является правильной. Тесты, написанные разработчиками, которые написали код, часто имеют большие слепые пятна, потому что у разработчика была большая слепая зона. Например, он может проверить, что происходит в 97% случаев, но не в крайних случаях.
У предыдущего работодателя роль QA состояла не в том, чтобы тестировать продукт, а в том, чтобы гарантировать, что разработчики, по сути, сделали то, что, по их словам, они собирались сделать в отношении ранее определенных приемочных испытаний, которые были определены QA.
С другой стороны, владелец продукта не имел никакого отношения к тестированию. Работа с тестированием на любом уровне ИМХО не является ролью владельца продукта.
В какой-то момент вы должны быть уверены в своих сотрудниках; система сдержек и противовесов хороша, но вам не нужно навязывать решение в рамках цикла разработки, которое на самом деле должно учитывать лишь небольшую часть трудовой этики сотрудников.
В идеальном мире я вижу, что сотрудничество с dev и QA оформляется совместными усилиями с написанием приемочных тестов. QA должен внести другой аспект в таблицу, как и команда разработчиков. QA должен держать руку в пироге в младенчестве продукта и оставаться вовлеченным в течение всего цикла. Владелец продукта, с другой стороны, должен затем нанять QA для понимания того, каково текущее состояние продукта, риски и т. Д. И сосредоточиться на продукте в целом; не конкретные нюансы, которые составляют продукт.
Из моего опыта: мы использовали модульный тест, чтобы покрыть более 90% кода. Были также интеграционные тесты и почасовые сборки. jБыть тесты на BDD.
Роль QA: - принятие пользовательских историй для тестирования; - написание кода за шагом; - тестирование исследования с использованием плагина RestClient для IDEA (таким образом, мы обнаружили некоторые серьезные ошибки).
Часть BDD применяет подход 3 Amigos, когда заинтересованные стороны сотрудничают, чтобы выработать критерии приемлемости. QA / Dev может написать код шага, чтобы сценарии выполнялись как приемочные тесты. Где значение QA для выполнения вручную тех же приемочных испытаний, которые инструмент BDD будет выполнять автоматически? Ценность дополнения QA состоит в том, чтобы проверять эти приемочные тесты и выполнять предварительные тесты вручную вне сценариев приемочных испытаний. Дублирование обычно дает тот же результат.
Разработчики не переписывают требования и спецификации, QA не переписывает код приложения ... QA может не выполнять те же самые скриптовые тесты, которые разработчики выполняют как приемочные тесты. Настало время для разработчиков надеть шапку QA!