Когда следует прекратить разработку и начать QA?

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

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

Мои вопросы: на каком этапе разработчики должны прекратить кодирование под рукой команде QA? Не слишком ли много просить разработчиков проверить свой код в соответствии со спецификацией, прежде чем передать его команде QA?

Это не должно!

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

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

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

Это тонкая грань, потому что если код поставляется в соответствии со спецификацией, то для меня это означает, что ошибок нет (и нет необходимости в QA!). Тот факт, что код обычно не доставляется в спецификацию, является причиной того, что мы делаем QA в первую очередь.

Но на самом деле я не думаю, что это то, о чем ты говоришь. То, что вы имеете в виду, это то, что команда разработчиков кажется слишком ленивой с их кодированием, и есть большие очевидные вещи, которые, кажется, не работают. Предварительное определение того, что модульные тесты должны присутствовать для каждой из функций A, B и C (в спецификации), а затем независимое рассмотрение кода и тестов (руководителем группы или менеджером) должно помочь решить проблему такого рода. ,

Я бы сказал, что, по крайней мере, разработчики должны были протестировать «счастливый путь». Что если они вводят ожидаемые данные, то это делает то, что спецификация говорит, что должно делать. Разработчики, которые не делают так много, должны быть допрошены.

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

Однако, если это не указано в спецификации, если разработчик ограничивает имя только заглавными и строчными буквами, но забывает, что некоторые имена имеют апострофы, или допускает дату 29 февраля 2011 года - это немного более понятно , Если они не делают одну и ту же ошибку раз за разом.

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

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

Если доставляется функциональность, которая не работает, то проблема не в разработке и обеспечении качества, а в разработке и владельцах продукта.

Владельцы продукта и разработчики должны быть частью одной команды и должны работать вместе, чтобы определить, что нужно сделать, чтобы считать функцию «выполненной», и убедиться, что код удовлетворяет этой потребности.

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

(Если у вас есть профессиональные тестировщики, они должны быть частью команды и должны участвовать на каждом этапе.)

У нас есть процесс проверки проектов, в котором мы просим разработчиков предоставить пошаговое руководство / демонстрацию их кода, прежде чем он войдет в QA. Мы включаем не только тестировщиков QA, но и бизнес-владельцев кода, службы поддержки клиентов и маркетинга / дизайна. Это имеет тенденцию сосредотачиваться на разработчиках, по крайней мере, на простых случаях использования, и иногда итоговое обсуждение между различными командами приводит к изменениям в спецификациях и задержке входа в QA. Когда мы можем, мы вовлекаем QA намного раньше в процесс, который помогает исправлять ошибки, пока код еще не прогрелся, - но мы все еще выполняем пошаговое руководство до начала «официального» QA.

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