Сколько тестер должен знать о внутренних деталях кода?
Насколько полезно, если это вообще возможно, для тестировщиков в группе продукта знать о внутренних деталях кода продукта. Это не означает, что им нужно знать каждую строку кода, но хорошая идея о том, как структурирован код, какова объектная модель, как взаимосвязаны различные модули, каковы взаимозависимости между различными функциями и т. Д.? Это может помочь argubaly помочь им найти связанные проблемы или дефекты, как только они столкнутся с одним. С другой стороны, это может потенциально "сместить" их "ориентированный на пользователя" подход к оценке и сертификации продукта и может повлиять на результаты тестирования в конце.
Я не слышал ни о какой конкретной модели для такого взаимодействия. (Предположим, что продукт, который используют пользователи, потенциально нетехнические, а не фреймворк или API, которые тестируют тестеры, - в последнем случае тестировщикам может понадобиться понять код, чтобы протестировать его, потому что пользователь - другой программист).
14 ответов
Это полностью зависит от типа выполняемого тестирования.
При тестировании функциональной системы тестировщики могут и, вероятно, должны не замечать подробности реализации - если они знают детали, они могут непреднамеренно учесть это в своей стратегии тестирования и неправильно тестировать продукт.
Для тестирования производительности и масштабируемости тестировщикам часто полезно иметь некоторые высокоуровневые знания о структуре кодовой базы, так как это полезно для выявления потенциальных горячих точек производительности и, следовательно, для написания целевых тестовых случаев. Это важно по той причине, что обычно тестирование производительности является широким открытым процессом, поэтому все, что можно сделать, чтобы сфокусировать тестирование на получении результатов, выгодно всем.
Это похоже на предыдущий вопрос: должен ли QA тестироваться с точки зрения "черного ящика"?
Я никогда не видел обстоятельств, когда тестировщик, который много знал о внутренностях системы, был в невыгодном положении.
Я бы утверждал, что существуют самооправданные мифы о том, что информированный тестер настолько же адекватен или даже лучше, чем глубоко технический, потому что:
- Это позволяет менеджерам проектов использовать "случайные ресурсы или ресурсы низкого качества" для тестирования. "Такой же неосведомленный, как пользовательский миф". Если вы хотите этот тип тестирования - попросите некоторых "настоящих" пользователей проверить ваши материалы.
- Тестеры по-прежнему часто рассматриваются как более дешевые и менее ценные, чем разработчики. "Любой может сделать миф о тестировании черного ящика".
- Разработка может отложить надлежащее тестирование на команду тестирования. Два мифа в одном: "нам не нужно обучать тестировщиков" и "только тестирующая команда проводит тестирование".
Здесь вы видите разницу между черным ящиком (без знания внутренних органов), белым ящиком (все знания) и серым ящиком (некоторые избранные знания).
Ответ действительно зависит от цели кода. Тогда для сложных интеграционных проектов, где и как они общаются, даже если это полностью закулисно, позволяет тестировщикам создавать соответствующие нефункциональные тестовые примеры.
Эти контрольные примеры определяют, будет ли компонент корректно обрабатывать отсутствие доступности зависимости. Его также можно использовать для выявления проблем, связанных с производительностью.
Например: как тестер, если я знаю, что компонент веб-интерфейса пользователя откладывает запрос к службе оркестровки, которая выполняет реальную работу, тогда я могу создать сценарий, в котором оркестровка занимает много времени (высокая нагрузка). Если пользователь затем выполняет другой запрос (имитирует нетерпение пользователя), и веб-служба получит второй запрос, пока первый еще продолжается. Если мы будем постоянно повторять это, веб-сервис в конечном итоге умрет от стресса. Не зная основную модель, было бы нелегко найти проблему
В большинстве случаев для тестирования функциональности предпочтение отдается "черному ящику", поскольку, как только вы переходите к нефункциональной или системной интеграции, понимание взаимодействия может помочь в обеспечении надлежащего охвата тестированием.
Не все тестировщики имеют квалифицированную или удобную работу / понимают взаимодействие компонентов или внутренние компоненты, поэтому это зависит от того, подходит ли он для каждого тестировщика / для каждой системы.
Почти во всех случаях мы начинаем с черного ящика и направляемся к белому, как это необходимо.
Существует несколько методологий тестирования, которые требуют проверки кода, а также те, которые этого не требуют.
Преимущество тестирования белого ящика (т.е. чтения кода) заключается в том, что вы можете адаптировать свое тестирование только к тем областям тестирования, которые, как вы знаете (прочитав код), не пройдут.
Недостатки включают потерянное время от реального тестирования, чтобы понять код.
Тестирование черного ящика (т.е. не чтение кода) может быть столь же хорошим (или лучшим?) Для поиска ошибок, чем белое.
Обычно оба типа тестирования могут проводиться в одном проекте, модульное тестирование белого ящика разработчиков и тестирование интеграции черного ящика тестеров.
Тестеру не нужно знать внутренние детали.
Приложение должно быть протестировано без каких-либо знаний о внутренней структуре, проблемах разработки, внешних зависимостях.
Если вы обременяете тестера этой дополнительной информацией, вы толкаете его в определенную схему тестирования, и тестер никогда не должен толкаться в направлении, которое он должен просто тестировать с точки зрения не кодера.
Я думаю, это зависит от того, насколько хороши тесты. Если вы просто хотите здравомыслящим проверить обычные сценарии, то во что бы то ни стало, просто дайте приложению-тестировщику / пиццерию приложение и скажите им, чтобы он сошел с ума.
Однако, если вы хотите иметь возможность находить крайние случаи, проблемы с производительностью или нагрузкой или множество других проблем, скрывающихся в глубине вашего кода, вам, вероятно, лучше нанять тестеров, которые знают, как и когда использовать методы белого ящика.
Ваш звонок.
Если есть время, тестировщик обязательно должен пройти код разработчика. Таким образом, вы можете улучшить свои тесты, чтобы получить лучшее покрытие.
Так что, может быть, если вы пишете свои тесты "черного ящика", глядя на спецификацию, и думаете, что у вас есть время, чтобы выполнить все из них и у вас останется время, просмотр кода не может быть плохой идеей.
В основном все зависит от того, сколько у вас есть времени. Еще одна вещь, которую вы можете сделать, чтобы улучшить освещение, это взглянуть на документы разработчиков. Это должно дать вам хорошее представление о том, как будет выглядеть код...
Преимущество тестеров в том, что они знакомы как с кодом разработчика, так и с кодом теста!
Вот пример ошибки, которую вы не можете найти, если не знаете внутренности кода, потому что вы просто не можете протестировать все входные данные:
long long int increment(long long int l) {
if (l == 475636294934LL) return 3;
return l + 1;
}
Тем не менее, в этом случае было бы обнаружено, если бы тестировщик имел 100% охват кода в качестве цели и смотрел только на достаточно внутренних компонентов, чтобы написать тесты для достижения этого.
Вот пример ошибки, которую вы, скорее всего, не обнаружите, если знаете внутреннюю часть кода, потому что ложная уверенность заразительна. В частности, автор кода обычно не может написать тест, который улавливает эту ошибку:
int MyConnect(socket *sock) {
/* socket must have been bound already, but that's OK */
return RealConnect(sock);
}
Если в документации MyConnect не упоминается, что сокет должен быть связан, то однажды произойдет что-то неожиданное (кто-то назовет его несвязанным, и, вероятно, реализация сокета выберет произвольный локальный адрес). Но у тестировщика, который может видеть код, часто нет желания "тестировать" документацию. Если они действительно не в форме, они не заметят допущения в коде, не упомянутом в документации, и просто примут это предположение. Напротив, тестировщик, пишущий из документации, мог легко обнаружить ошибку, потому что они будут думать, "в каких возможных состояниях может находиться сокет? Я сделаю тест для каждого". Поскольку никакие ограничения не упомянуты, нет никаких причин, по которым они не будут рассматривать дело, в котором произошел сбой.
Ответ: делай оба. Один из способов сделать это - написать набор тестов до того, как вы увидите / напишите код, а затем добавить больше тестов, чтобы охватить любые особые случаи, которые вы вводите в свою реализацию. Это применимо независимо от того, является ли тестер тем же человеком, что и программист, хотя, очевидно, если программист пишет тест второго типа, то только один человек в организации должен понимать код. Можно поспорить, является ли это хорошей долгосрочной стратегией иметь код, который когда-либо понимал только один человек, но это широко распространено, потому что это, безусловно, экономит время на получение чего-то за дверью.
[Редактировать: я отказываюсь говорить, как появились эти ошибки. Возможно, программист первого был клинически сумасшедшим, а для второго существуют некоторые ограничения на используемый порт, чтобы обойти некоторые странные настройки сети, о которых известно, и предполагается, что сокет был создан с помощью некоторых странный API, существование которого упоминается в общих документах по сокетам, но они не требуют его использования. Ясно, что в обоих случаях программист был очень небрежным. Но это не затрагивает сути: примеры не должны быть реалистичными, так как, если вы не поймаете ошибки, которые может сделать только очень небрежный программист, то вы не поймаете все фактические ошибки в вашем коде, если только у тебя никогда не бывает плохого дня, делай сумасшедшую опечатку и т. д.]
Я предпочитаю тестирование черного ящика для режимов окончательного тестирования В идеальном мире...
- Тестеры не должны ничего знать о внутренностях кода
- Они должны знать все, что будет у клиента - то есть иметь документы / помощь, необходимые для использования системы / приложения (это определенно включает описание / документы API, если это какой-то код, который может быть доставлен)
Если тестировщики не могут обнаружить дефекты с этими ограничениями, вы недостаточно документировали свой API/ приложение.
ИМХО, я думаю, что индустриальное мнение тестеров совершенно неверно.
Подумайте об этом... у вас есть два сантехника, один из них чрезвычайно опытный, знает все правила, строительные нормы и правила, и может быстро что-то посмотреть и узнать, выполнена ли работа правильно или нет. Другой сантехник хорош, и выполняет работу надежно.
Какой из них вы хотели бы сделать последнюю проверку, чтобы убедиться, что вы не вернетесь домой в затопленный дом? На самом деле, в какой другой отрасли они позволяют тому, кто практически ничего не знает о проверяемой системе, выполнять проверку?
Я видел, как с годами планка QA поднималась, и это меня радует. Со временем QA может стать тем, к чему стремятся разработчики.
Короче говоря, они не только должны быть знакомы с тестируемым кодом, но и должны иметь понимание, которое конкурирует с архитекторами продукта, а также уметь эффективно взаимодействовать с владельцем (ами) продукта / клиентами, чтобы гарантировать, что создается на самом деле то, что они хотят. Но сейчас я вступаю в отдельный разговор...
Это случится? Вероятно, раньше, чем вы думаете. Мне удалось сократить количество людей, необходимых для проведения QA, повысить общую эффективность команды и повысить качество продукта, просто наняв очень квалифицированных людей с опытом работы в среде разработчиков и архитекторов с сильной склонностью к QA. У меня низкие эксплуатационные расходы, и поскольку качество программного обеспечения выше, я получаю в итоге более низкие затраты на поддержку. FWIW ... Я обнаружил, что, хотя я могу эффективно вернуть ребят из QA в роль разработчика, когда это необходимо, обратное почти всегда не соответствует действительности.
Если они являются преданными тестерами (единственное, что они делают), то я думаю, что они должны знать как можно меньше о коде, который они пытаются протестировать.
Слишком часто они пытаются определить, почему он терпит неудачу, это ответственность разработчика, а не тестировщика.
Тем не менее, я думаю, что разработчики делают отличных тестеров, потому что мы склонны знать крайние случаи для определенных типов функциональности.
Для пользовательского тестирования тестер не должен знать детали внутреннего кода приложения. Им нужно только знать ожидаемую функциональность, бизнес-правила. Когда сообщается об ошибке
Кто бы ни исправлял ошибку, должен знать взаимозависимости между различными функциями.
Я бы сказал, что им вообще не нужно знать детали внутреннего кода. Однако им нужно знать все необходимые функциональные возможности и системные правила, как аналитик. В противном случае они не будут тестировать всю функциональность или не поймут, когда система плохо себя ведет.