Я бы сказал, что у специалиста по тестированию есть все основания для , а не детального внутреннего понимания того, как работает ваше приложение. Сотрудники QA должны обладать примерно таким же уровнем компьютерной грамотности, что и ваша целевая аудитория.
Причина этого проста: чем больше специалист по контролю качества знает о том, как создается ваше приложение, тем больше вероятность того, что он избежит обычных проблем с юзабилити, с которыми столкнутся ваши обычные пользователи.
QA - это не только проверка работоспособности приложения. Следует также проверить, понятен ли он вашему обычному пользователю и, следовательно, действительно применим.
UPDATE
Это становилось слишком длинным, чтобы поместиться в поле для комментариев.
Относительно вопросов @ testerab.
Я определяю ОК как лицо или группу лиц, ответственных за 1. соблюдение бизнес-требований; и 2. функции приложения в отношении этих требований не содержат ошибок. Отсюда и прозвище «Обеспечение качества». Третий пункт, который я считаю связанным с QA, - это просто удобство использования.
Они должны понимать бизнес-требования, что означает, что они должны работать рука об руку с любыми бизнес-аналитиками и конечными пользователями (если таковые имеются). Лучшие члены QA, с которыми я работал, были наняты из этих областей. Худшие члены QA, которых я видел, были разработчиками или обучались как таковые. Люди, которые перешли из службы технической поддержки, также, как правило, становятся хорошими участниками QA, поскольку они точно знают тип мусора, который будет пытаться получить конечный пользователь.
Существует много разных классов приложений. Несомненно, наиболее распространенным из которых является прославленный ввод данных. У вас есть несколько экранов, на которые вводится информация, и нажимаются кнопки. Затем информация сохраняется и / или направляется туда, куда она должна идти. Все от MS Word до CRM попадают в эту категорию.
Поэтому задача QA - сначала убедиться, что приложение примет нужные входные данные и выполнит нужные функции. Вторым шагом является отправка неверных входных данных и подтверждение того, что приложение отвечает желаемым образом. например это не взрывается и не позволяет плохой информации проходить. Инструменты автоматического тестирования отлично работают в этих случаях. В заключительной части принимается решение о том, должна ли эта функция быть скрыта на трех уровнях меню или к ней легче добраться.
Ничто из вышеперечисленного не требует, чтобы специалист по контролю качества читал код или вертелся с битами.
Некоторые системы не имеют компонента пользовательского интерфейса. Для этих целей разработчик должен предоставить средства тестирования, которые позволят команде QA представить данные и проанализировать результаты. Это касается веб-сервисов и любого типа EDI, который вы можете себе представить.
Другие системы сами по себе являются API. Для этого требуется либо специалист по обеспечению качества, обладающий достаточными знаниями для того, чтобы самостоятельно реализовывать такие вызовы API, либо чтобы разработчики могли легко вызывать их и записывать результаты. В этом случае предпочтительно, чтобы команда QA могла заниматься своим собственным программированием, но, опять же, не иметь доступа к базовому коду.
Проблема с просмотром действительного кода заключается в том, что он заставляет человека сосредоточиться только на том, что он видит. Это плохо. Вместо этого они должны быть мысленно свободны от этих искусственных ограничений, чтобы они могли вслепую вводить «ABC» в текстовое поле, которое ожидает ввода чисел.
Что касается «просмотра» кода, чтобы узнать, что тестировать, то это совершенно другая проблема, и ее лучше решать опытным разработчикам в настройках проверки кода. Цель здесь - выявить возможные ошибки, лучшие практики, сбои в системе безопасности и т. Д. Специалисты по контролю качества редко способны на этот уровень анализа, поскольку для этого требуется, чтобы кто-то был активным разработчиком.
Относительно SDET: Если у вашего продукта есть или есть API или основа, которую разработчики используют для создания других вещей, то вам может потребоваться, чтобы один или несколько человек посвятили себя внедрению программного обеспечения вокруг него для поддержки обычной группы обеспечения качества. Я стою на пороге необходимости этой роли и считаю, что это может быть проект по решению проекта.
Я полагаю, что есть две группы, которые лучше подходят для тестирования API. Это конечные пользователи, которые уже внедряют, и другие разработчики в компании, которая его создала. Корм для собак в настоящее время является обычной практикой и очень рентабельным. В конце концов, если он не работает, вы можете быть уверены, что он будет быстро исправлен. Для конечных пользователей, если они воспринимают это как настоящий разговор, в котором команда разработчиков реагирует, они с радостью "протестируют" его для вас.
Я был во всех трех ситуациях, и, как конечный пользователь, я чувствую, что доступ к оригинальным разработчикам - это долгий путь к решению проблем. Особенно, когда они также используют продукт. Количество неправильного перевода в QA, обычно связанное с этими проектами, просто ужасно.
Итак, я работал со всеми типами QA. От тех, кого вы интересовали, как им удалось добраться до работы, до суперзвезд, которые были очень искусны в поиске тех угловых случаев, которые заставляли приложения задыхаться.
Черты лучших были: 1. никогда не были программистами; 2. понял бизнес; 3. точно понимал, что конечные пользователи делали изо дня в день. 4. ЧЕСТНО ЗАБЛЮДЕНО о тех, кто подвергается воздействию программного обеспечения.
Черты худших из них включали: 1. были программистами или думали, что они были; 2. не понял бизнес; 3. никогда не встречал конечного пользователя; 4. слишком часто использовал слово «идиот»; 5. поймал в механике, как это работает, а не было ли оно вообще пригодным для использования.