Должен ли QA тестировать строго с точки зрения "черного ящика"?

Предполагая, что модульные тесты обрабатываются разработкой, есть ли какая-либо причина того, что QA должен знать информацию о том, как работает продукт? Под этим я имею в виду, нужно ли им знать, что происходит в фоновом режиме, и должны ли они тестировать сегменты продукта без использования обычного пользовательского интерфейса? Например, было бы целесообразным, чтобы тестер заходил в базу данных и вручную менял значения, чтобы узнать, что произойдет? РЕДАКТИРОВАТЬ: Предположим, что мы работаем с приложением, которое будет использоваться не разработчиками, мы не работаем над чем-то с присоединенным API.

7 ответов

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

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


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

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


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

Black-box test - полезная и необходимая техника, но знание немного о том, что происходит под капотом, облегчает определение действительно интересных тестовых случаев.

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


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

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


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


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

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

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

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

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

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

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

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

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

Ни одно из вышеизложенного не требует, чтобы человек QA читал код или сворачивал с битами.

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

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

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

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

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

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

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

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

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

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


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

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

licensed under cc by-sa 3.0 with attribution.