Следует ли QA тестировать строго с точки зрения черного ящика?

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

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

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

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

Для тестировщиков имеет смысл знать как можно больше о реализации программного обеспечения. Это поможет им лучше тестировать.

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

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

В проектах, в которых я участвовал, QA тестировался с точки зрения пользователя, а их тесты проводились с точки зрения соответствия требованиям. Их тестирование было тестированием черного ящика. Разработчики провели тестирование «белого ящика». Мы никогда не ожидали, что специалист по контролю качества откроет инструмент запросов к БД и вручную изменит значения. За это отвечали модульные тесты разработчика.

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ
Это слишком долго, чтобы поместиться в поле для комментариев.

Относительно вопросов @testerab.

Я определяю QA как человека или группу, отвечающих за 1. выполнение бизнес-требований; и, 2. Функции приложения в отношении этих требований не содержат ошибок. Отсюда и прозвище «Гарантия качества». Третий пункт, который, как мне кажется, принадлежит QA, - это простота использования.

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

Есть много разных классов приложений. Несомненно, наиболее распространенным из них является ввод данных. У вас есть несколько экранов, на которых вводится информация и нажимаются кнопки. Затем информация сохраняется и / или направляется туда, куда ей нужно. В эту категорию попадает все, от MS Word до CRM.

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

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

В некоторых системах нет компонента пользовательского интерфейса. Для них разработчик должен предоставить средства тестирования, которые позволят команде QA отправлять данные и просматривать результаты. Это касается веб-сервисов и любого типа EDI, который вы можете себе представить.

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

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

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

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

Я считаю, что есть две группы, которые лучше подходят для тестирования API. Это конечные пользователи, которые уже внедряют, и другие разработчики в компании, которая его построила. Корм для собак в настоящее время является обычной практикой и очень рентабелен. В конце концов, если это не сработает, вы можете быть уверены, что это быстро исправят. Для конечных пользователей, если они видят в этом реальный разговор, в котором команда разработчиков реагирует на запросы, они с радостью «протестируют» это для вас.

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

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

Отличительными чертами лучших из них были: 1. никогда не были программистами; 2. понял свое дело; 3. точно понимал, что конечные пользователи делают изо дня в день. 4. Честно ЗАБОТИТСЯ о тех, кто подвергается воздействию программного обеспечения.

Черты худших из них: 1. были программистами или считали себя программистами; 2. не разбирался в деле; 3. никогда не встречал конечного пользователя; 4. слишком часто употреблял слово «идиот»; 5. разбирался в механике того, как это работает, вместо того, чтобы его вообще можно было использовать.