Интерактивное тестирование — стоит ли овчинка выделки

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

Если кому интересно — прошу под кат.

На моей (теперь уже) прошлой работе, а точнее, в моей команде весьма высоким спросом пользуется интерактивное ревью кода — это когда ревьювер садится к автору и исполнителю написанного, и ревью происходит вживую — автор показывает и объясняет смысл изменений, а ревьювер смотрит и делает замечания (если оные появляются). Связано это в основном с тем, что система контроля версий (к слову сказать, своя собственная) не предусматривает «откладывания на полочку» изменений и отправку их на ревью до фактического коммита в репозиторий. Посему выкручиваемся способами, кто на что горазд (кто сорцы по имейлу отправляет, если коллега находится забугром, но зачастую (благо, основная часть разработчиков территориально находится на месте) делается именно так). Это может показаться с какой-то стороны неудобным, но с другой — зачастую сокращает время и уменьшает риски, т.к. выявленные в процессе ревью проблемы будут решены до того, как код попадет в репозиторий и тьфу-тьфу сломает сборку или функционал.
И вот подумалось нам с одним разработчиком в свое время — а не применить ли подобный подход и к тестированию? Идея точно так же проста: тестировщик садится за машину программиста и «по свежим следам» производит тот или иной уровень тестирования. Далее, если все свиду хорошо, код коммитится в репозиторий, и тестировщики ждут официальной сборки (ревью кода, естественно, было уже сделано до).
У нас с ребятами на эту тему были неоднократные дебаты, и, по правде говоря, большинство является противниками подобного подхода. Ниже я попробую привести все «за» и «против», которые оформились в процессе дискуссий и практики.

Итак, плюсы:

• Сокращается время между фактическими изменениями в коде и получением тестировщиками сборки, которую они могут, собственно говоря, щупать. Здесь, само собой, ключевую роль играет время сборки, а также близость дэдлайна. У нас сборка занимает в среднем 2-2.5 часа. Добавим к этому еще полчаса-час на установку. Итого — 2.5-3.5 часа. В обычное время это может быть не критичным, но когда за окном релиз (либо же банальный конец спринта (кто работает по scrum, тот в курсе)), даже час может играть роль. А представьте, что билд по какой-то причине (не связанной с данными изменениями) свалился — вам придется ждать еще больше.

• Как показывает опыт (мой личный), самые критичные проблемы обнаруживаются в первые 15-20 минут (зависит, опять же, от сложности задачи и прочего, но возьмем усредненный вариант). Учитывая пункт первый, представьте, сколько времени экономится, если это тестирование производится до коммита в репозиторий. Неоднократно бывало, что, садясь за машину разработчика, я находила за 15 минут около 2-3 критичных и еще около 5 некритичных, но тем не менее неприятных проблем.

• «Свежий» глаз всегда впрок. Если это — новая фича или изменение в UI, взгляд со стороны (а тем более тестировщика) пойдет только на пользу. Даже если все было обсуждено и обговорено ранее (дизайн доки, мокапы и т.п.), всегда может найтись место мнению, что на деле оно выглядит и не так хорошо для пользователя, как могло бы. Плюсом будет, если есть возможность тут же предоставить свои сомнения product owner’у (в моей практике это было несложно, т.к. оный находился в пределах физической досягаемости). В итоге — изменение текста сообщения или вида окошка занимает немного времени, и проще это изменить тут же, минуя тягостный и длительный процесс сборки, фэйла тикета (либо заведения нового) и тому подобного.

Но есть, конечно же, и минусы:

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

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

• Далеко не каждый разработчик пустит чужого человека (пусть и тестировщика из его команды) за свою машину. Уж не знаю, с чем это связано, но люди есть всякие — кто-то некомфортно себя чувствует, даже если сзади за спиной периодически проходят люди, а другой спокойно дает тебе свой доменный пароль. Это естественно, и с этим стоит смириться.

• В основном подобные практики, как мне кажется, могут быть применимы исключительно людьми, которые не просто работают свою работу, не просто переживают за плоды своей деятельности, а являются в той или иной мере фанатиками своего дела:)

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