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

Question

[amazed]

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

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

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

Вопрос: насколько практика подобных итераций сдачи сырого результата на тестирование является распространенной и насколько она нормальна?
Второй вопрос - какова наилучшая альтернатива?

Comments

[edward_freedom]

Программист backend выполняет свою часть работы и примерно проверяет. Детально без UI ему проверить сложно.

бекенд и не должен проверять фронтенд

[raiboon]

Это не нормально.
Увольняйся и пусть они долбятся, как хотят.
Любой возврат задачи по флоу - эксцесс, который нужно разбираться - кто не досмотрел.

[amazed]

raiboon, В данном случае я могу это изменить, потому что я и есть тимлид. Вопрос только в том, стоит ли менять, или пусть работают как привыкли.

Answer 1

[Александр Прохорович]

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

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

И самое главное - все очень сильно зависит от уровня разработчиков в команде. К сожалению, часто в том же бэке не видят дальше своего носа, отсюда и проблемы в духе "купи молоко, если будут яйца, возьми десяток"...

Comments

[amazed]

Это нормальная практика, когда тестировщик итеративно смотрит сырые варианты.

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

И самое главное - все очень сильно зависит от уровня разработчиков в команде. К сожалению, часто в том же бэке не видят дальше своего носа, отсюда и проблемы в духе "купи молоко, если будут яйца, возьми десяток"...

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

[Александр Прохорович]

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

Потом это мнение разбилось о "кодеров" - программистов, тупо и слепо выполняющих ТЗ, даже не вникая, как это будет работать. И, как показывает практика, таких кодеров на рынке подавляющее большинство. И их, в отличие от "настоящих" программистов, нужно постоянно контролировать. Начиная от максимально продуманного ТЗ и заканчивая постоянными тестами человеком, понимающим как все должно работать.

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

[amazed]

Александр Прохорович, Спасибо!

[Vitaly Karasik]

Александр Прохорович, но в описанной картине получается что тестировщик это на самом деле интегратор, который наравне с архитектором понимает все end-to-end в отличие от программистов.
Если действительно так, то все неплохо, кроме того что все завязано на него.

[amazed]

Vitaly Karasik, Тестировщик в данном случае - это обычно инженер который не то что бы эксперт по предметной области, но где-то близко к ней работал. Навыков архитектора у него точно нет. Он не понимает задачу так же хорошо как аналитик или даже тимлид, но не него нет выбора отказаться от вникания в суть задачи, который есть у программистов. Программисты в данном случае этим пользуются, чтобы упростить себе жизнь. Хотя на деле ИМХО код без понимания бывает даже сложнее написать, чем с пониманием.

[Dimonchik]

"купи молоко, если будут яйца, возьми десяток"...

неисчисляемое существительное и условие. - может не сработать
с булкой хлеба более канонiчно

Answer 2

[batyrmastyr]

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

Comments

[amazed]

В вашей ситуации, видимо, проще повысить тестировщика до тестировщика-аналитика: сперва отдаёте ТЗ ему, он пишет тестовый план и в процессе уточняет ТЗ с его автором, берёт с кодеров подписку, что им всё понятно, и только потом они идут кодить.

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

Answer 3

[Saboteur]

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

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

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

Comments

[Дмитрий Беляев]

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

Answer 4

[Dmtm]

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

Comments

[amazed]

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

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

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

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

[mkone112]

В смысле дешевле? Кто сказал что разработчик экономит на этом время? Вместо того чтобы сделать задачу и взять другую - она постоянно прилетает ему обратно.

[Dmtm]

mkone112, разработчик сначала экономит время не отслеживая все возможные случаи, а потом, все что найдет тестировщик - приходит обратно с описанием воспроизведения, и это второй раз экономит время разработчика

[amazed]

Dmtm, Возможно это экономия времени разработчика. Но в этом случае разработчик никогда не задается вопросами типа "а все ли я учел? " и "а будет ли все это вместе корректно работать?".
Тестировщик не видит кода и менее квалифицирован, поэтому ему сложно задаться этими вопросами.
При этом некоторые проблемы так и останутся не решенными. Проблемы будут накапливаться и этот хаос будет тормозить работу всех, включая тимлида. Не говоря уже о качестве в итоге.

Answer 5

[mkone112]

Нет не нормально, нормально это когда формализуется тз, на него пишутся тесты, а под них код. Только после этого код идет тестировщику.

Comments

[amazed]

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

И еще: проблема в том, что идеально формализованное ТЗ - это и есть код.

[mkone112]

amazed, налицо полное непонимание tdd, я ничего не говорил про обкладывание кода, его же еще нет. Код пишется уже на проверенные тесты.

[amazed]

mkone112, Я спрашивал про наиболее распространенные практики, как это бывает. Довольно странно экстремальные методики программирования называть "нормальными" для неизвестной области и неопределенного круга задач.

[mkone112]

amazed, tdd и есть наиболее распространенная практика. По крайней мере в компаниях где крутятся деньги - это только так и работает.