Должны ли программисты помогать тестировщикам в разработке тестов?

Насколько программисты должны помогать тестировщикам в разработке тестов?

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

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

Хотя не все, кого я знаю, согласны с этим (и я понимаю некоторые из их пунктов в определенной степени). Что другие думают об этом? Обсуждается ли это где-нибудь в литературе?

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

Я думаю, что разработчики и тестировщики могут мирно сосуществовать в сфере обеспечения качества. :)

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

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

Я думаю, что и тестирование, и разработка являются совместными усилиями, поэтому (IMO) разработчики должны давать тестерам идеи для тестирования. Я не думаю, что это заражает их или портит тестеров вообще. Тестер, конечно, должен улучшить эти тесты многими другими подходами к тестированию.

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

Если вы не рассматриваете это как совместную работу, вам просто нужно «перебросить код» от разработчика до тестирования ... и вы получите более низкое качество. Это правда в моем мире, но (конечно), мммм.

Я вижу это в том, что тестировать мой код не является задачей QA. Задача тестера - убедиться, что мой код отвечает всем требованиям для этой задачи.

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

На моей последней работе у нас был QA с самого начала. Это происходило на сессиях по сбору требований, проектных совещаниях и проектных совещаниях. Они слушали и задавали вопросы, и пока разработчики писали код, они писали свои планы тестирования. Это сработало отлично, и мы поймали много проблем, которые, вероятно, проскочили.

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

Не было никакого "загрязнения", если ваш код не является сырой канализацией, и это было бы по совершенно другой причине.

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

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

Хотя тестировщик, конечно, не должен ограничивать себя тестированием только того, что, по словам разработчика, важно, он не пострадает, если узнает, что разработчики беспокоятся по поводу кода. Иногда они могут точно настроить свой подход, основываясь на своих знаниях о реализации. Только если тестировщик особенно близорук, он примет во внимание мнение разработчика о том, что такое риски, как последнее слово; они не будут полностью исключать то, что разработчик определяет как низкий риск, но они будут вкладывать больше усилий в то, что может оказать большее влияние на клиента.

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

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

Как тестер, у меня нет никаких возражений против того, чтобы программисты предлагали тестовые случаи (хотя это не значит, что я буду придерживаться только этих тестовых случаев) или описывали детали реализации. Иногда может быть очень полезно, чтобы кто-то сказал: «Я думаю, что этот бит может быть рискованным, мне бы очень понравилось, если бы вы протестировали этот бит довольно тщательно». Знание некоторых деталей реализации помогает мне использовать многолетний опыт для выбора тестов, которые, по моему мнению, скорее всего не пройдут. Иногда короткое упоминание означает, что несколько тестов внезапно увеличивают мой список приоритетов.

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

Мне нравится пересматривать планы тестирования и предлагать дополнительные тестовые случаи, о которых QA, возможно, и не думали. Я не уверен, как это «заразит тестеров моими собственными предрассудками».

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

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

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

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