Является ли порочной практика итеративных попыток сдачи тестировщикам сырых результатов работы?

Суть проблемы в следующем. Представьте работу команды, реализующей некую фитчу.
Тимлид (пусть он же аналитик и он же product owner) описал требования для разработчиков - по серверу и UI.
В требованиях есть user story, но это прикладная разработка и он довольно сложный для понимания программистами.
Еще в требованиях есть примерное описание как это все реализовывать - элементы UI и общее описание принципов работы API.
Программист backend выполняет свою часть работы и примерно проверяет. Детально без UI ему проверить сложно.
Программист UI выполняет свою часть работы, в целом проверяет что с API его UI живой, но правильные ли данные ему шлет сервер он не вникает. И дальше оба закрывают требования.

После этого тестировщик берется за тестирование и для начала обнаруживает, что логики в поведении продукта нет вообще. Он начинает ходить между программистами, вместе они начинают пытаться все поправить. В итоге оказывается что во-первых было очень много багов, и во-вторых, требование программисты поняли не так, прочитали не все, да и в требованиях прямо каждая мелочь не была учтена. Программисты правят то что не нравится тестировщику и цикл повторяется снова и снова, пока вся команда не поймет задачу одинаково и результат не станет похожим на ожидаемый в требованиях. После этого задача попадает на проверку к тимлиду, который уже анализирует насколько то что получилось соответствует ожиданиям.

Т.е. здесь мы используем тестировщика на этапе, когда по сути еще вообще ничего не готово. Ему итеративно передаются сырые варианты, а он сперва сражается с багами, координируя по сути программистов и затем сражается с недопониманием требований, выполняя отчасти работу аналитика.

Вопрос: насколько практика подобных итераций сдачи сырого результата на тестирование является распространенной и насколько она нормальна?
Второй вопрос - какова наилучшая альтернатива?
  • Вопрос задан
  • 394 просмотра
Решения вопроса 2
alexgp13
@alexgp13
Руководитель ИТ-проектов
Это нормальная практика, когда тестировщик итеративно смотрит сырые варианты. В определенных ситуациях это лучше, чем сделать готовый вариант, отладив программистами все баги и понять, что надо то было совсем другое.

Во избежание таких ситуаций неплохо посвящать программистов хотя бы в общих чертах в бизнес-логику, а тестирования и отладку выполнять совместно, т.е. бэк-программист, фронт-программист и тестировщик смотрят работу системы в комплексе.
Еще хорошей практикой в такой ситуации будет задействовать аналитика и архитектора, которые смогут увидеть потенциальные проблемы еще на этапе постановки задач программистам.

И самое главное - все очень сильно зависит от уровня разработчиков в команде. К сожалению, часто в том же бэке не видят дальше своего носа, отсюда и проблемы в духе "купи молоко, если будут яйца, возьми десяток"...
Ответ написан
batyrmastyr
@batyrmastyr
Ваш вопрос стоит поделить на две части.
1. Итеративная сдача и проверка тестировщиком сама по себе порочной не является, если программисты говорят "часть страницы входа готова (вывожу поля почта и пароль, проверяю пока только что они не пустые, и почта похожа на почту, а проверку по базе ещё не делаю)" или "исправил падение если в почту вбить 1@1@localhost" и тестировщик проверяет, что заявленное сделано как надо + выборочно проверяет, что не сломано то, что работало на предыдущей итерации. Если исправить нужно 10 ошибок, а его после каждой заставляют проверять всё, то нужно давать таким свинтусам по шее.
2. Подход "сделаем какую-то чушь, пусть наша нянька для даунов (тестировщик) разбирается" абсолютно порочен.
В вашей ситуации, видимо, проще повысить тестировщика до тестировщика-аналитика: сперва отдаёте ТЗ ему, он пишет тестовый план и в процессе уточняет ТЗ с его автором, берёт с кодеров подписку, что им всё понятно, и только потом они идут кодить.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
saboteur_kiev
@saboteur_kiev Куратор тега Организация работы
software engineer
В итоге оказывается что во-первых было очень много багов, и во-вторых, требование программисты поняли не так, прочитали не все, да и в требованиях прямо каждая мелочь не была учтена. Программисты правят то что не нравится тестировщику и цикл повторяется снова и снова, пока вся команда не поймет задачу одинаково и результат не станет похожим на ожидаемый в требованиях.


После этого задача попадает на проверку к тимлиду, который уже анализирует насколько то что получилось соответствует ожиданиям.

Эм, если все настолько плохо, что надо повторять цикл снова и снова, то где все это время был тимлид, который давал изначальную задачу?
Его привлекать в первую очередь, чтобы он либо переобъяснил разработчикам все, либо поправил свои требования, чтобы они были понятнее.
В моем понимании тимлид - это один из разработчиков, который ежедневно контролирует их работу, а не ждет пока ему принесут готовое через месяц.
А так да, тестировщик помогает разработчикам правильно понять требования, но он не должен биться головой об стену в одиночку. Если разработчикам что-то неясно, они могут и сами поднять жёпку и сходить к тимлиду, к аналитикам, к тестировщикам чтобы понять задачу правильно.
Ответ написан
@Dmtm
Android
время тестировщика обычно намного дешевле времени разработчика, поэтому спамить ему сырой код -вполне допустимо, но вся логика и тз должны быть уже отработаны аналитиком до начала разработки и если тестировщик работает за аналитика, то в проекте проблемы с аналитиком
Ответ написан
@mkone112
Начинающий питонист.
Нет не нормально, нормально это когда формализуется тз, на него пишутся тесты, а под них код. Только после этого код идет тестировщику.
Ответ написан
Ваш ответ на вопрос

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

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