Программисты плохие тестеры?

36

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

Джоэл о программном обеспечении - пять основных (неправильных) причин, по которым у вас нет тестеров (выделено мое)

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

И в этом вопросе один из самых популярных ответов говорит (опять же, мой акцент):

Разработчики могут быть тестерами, но они не должны быть тестерами. Разработчики склонны непреднамеренно / неосознанно избегать использования приложения таким образом, чтобы это могло его сломать. Это потому, что они написали это и в основном проверяют, как это должно быть использовано.

Итак, вопрос в том , плохо ли программисты тестируют? Какие есть доказательства или аргументы в поддержку этого вывода? Только программисты плохо тестируют свой собственный код? Есть ли доказательства того, что программисты действительно хороши в тестировании?

Что я имею в виду под «тестированием»? Я не имею в виду модульное тестирование или что-либо, что считается частью методологии, используемой командой разработчиков программного обеспечения для написания программного обеспечения. Я имею в виду какой-то метод обеспечения качества, который используется после того, как код был скомпилирован и развернут в том, что команда разработчиков программного обеспечения назвала бы «средой тестирования».

jhsowter
источник
17
@jshowter Программисты хуже всего тестируют свой собственный код, но великолепно тестируют чужой код. Тестеры (хорошие тестеры) сами по себе являются программистами (поскольку им необходимо понимать логику программирования и ее функциональные возможности) за исключением того, что они не пишут слишком много кода. Я считаю, что это больше связано с психологией, так как я всегда не решаюсь найти сомнения в моей собственной работе, какой бы плохой она ни была.
Ubermensch
6
@ Ubermensch, я не согласен с разработчиками, которые по умолчанию являются блестящими тестерами чужого кода. Некоторые разработчики из-за того, что некоторое время практиковались в тестировании. Это требует другого мышления и другой мотивации, что вообще не очевидно для разработчиков. Многие разработчики, как правило, сосредотачиваются - и получают наибольшее удовольствие - от части кодирования, и могут не понимать - или даже не осознавать - важность других действий в рамках полного SDLC.
Петер Тёрёк
1
@jshowter Если вам нужны неопровержимые факты / данные исследований, я не могу их найти. Большая часть литературы относится к гибкой разработке и не может найти ту, которая соответствует вашему конкретному случаю. Вы можете попробовать в Google Scholar или Scirus.
Ubermensch
3
Мы не плохие тестеры! Это работало на моем компьютере! ;-)
Йорис Тиммерманс
2
@MadKeithV Ха! Это мой аватар JIRA (
средство

Ответы:

39

Кажется, что вопрос задается конкретно о тестировании системы , поэтому я и имею в виду этот ответ.

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

Почему программисты плохо тестируют:

  • Если вы написали код, вы (должны) уже продумали как можно больше способов, чтобы что-то могло пойти не так, и справились с ними.
  • Если обнаружение особенно трудной ошибки означает, что вам нужно пойти и исправить ее, в кодовой базе, которой вы, возможно, устали, это не поможет вашей мотивации.

Почему программисты хороши в тестировании:

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

Почему программисты плохие тестеры:

  • Программисты дороже, чем тестеры (в подавляющем большинстве случаев).
  • Мышление в корне отличается: «Построить (работающий) продукт» против «Эта штука не выходит наружу с какими-то (неизвестными) ошибками».
  • Тестеры, как правило, будут более эффективными - т.е. будут выполнять больше тестов за то же время.
  • Программисты специализируются на программировании. QA профессионалы специализируются на тестировании.
vaughandroid
источник
4
Обратите внимание, что логическое мышление программистов может быть вредом для хорошего тестера. Сколько раз вы видели, как программист реагирует "но это невозможно!" когда столкнулся с найденной ошибкой? Только чтобы узнать, что в своих рассуждениях они упустили что-то серьезное, что сделало ошибку «невозможной».
Йорис Тиммерманс
2
@CraigYoung - ясно, что это ошибочное логическое мышление, но это очень часто (системы сложны). Дело в том, что при тестировании не следует использовать логическое мышление для устранения «ненужных» тестов, и разработчикам, похоже, сложно избежать такого мышления.
Йорис Тиммерманс
3
+1 Отличный, взвешенный ответ. Также объясняется, почему комбинация между автоматизированными модульными и интеграционными тестами, написанными программистами, вместе с тестированием системы QA является лучшей комбинацией.
Дэнни Варод
1
+1 за "мышление принципиально другое". В конце концов, это разные роли со связанными (но разными) наборами навыков.
joshin4colours
3
@MadKeithV Логическое мышление имеет жизненно важное значение при тестировании и поэтому устраняет ненужные тесты. Вы думаете о тестировании «черного ящика» и «белого ящика»? В тестировании «черного ящика» вы разрабатываете тесты из требований, не зная о реализации. Проверить наличие ошибочных предположений, ошибочной логики и т. Д. ИМХО разработчики в этом хороши , если они не знают реализацию. В частности, если они написали код и допустили ошибки, они неизбежно склонны делать те же ошибки в тестах. Системное тестирование должно быть тестированием черного ящика.
MarkJ
19

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

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

Эми
источник
1
Мои два цента. Разработчики обычно тестируют только последние изменения, последнее исправление, последнюю функцию, которую они сделали (я сделал), и, в некоторых случаях, они (мы) немного слепы или ленивы, чтобы протестировать другую функцию.
Андреа Жирарди
11

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

В одном месте программисты, как правило, плохо разбираются в тестировании - это бит «используй пользовательский интерфейс как обычный пользователь» - они не обычные пользователи и не ведут себя как они. Например:

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

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

Уайетт Барнетт
источник
3
Дополнительный пример для вашего первого пункта: наши пользователи имеют тенденцию копировать из MS Word, который вставляет странные вещи, такие как em-dash и умные кавычки, которые иногда ломают даже библиотеки, которые мы не писали. Никто из нас даже не знаком с Word, так что случай использования едва ли приходит нам на ум, не говоря уже о том, что его проверяют.
Изката
1

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

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

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

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

tdammers
источник
1

Из моего опыта да, программисты - плохие тестеры. Слишком часто я видел других, и я сам говорил: «Да, но я проверял это до того, как зарегистрировался!» когда сталкивается с тестером, воспроизводящим ошибку перед вами.

Зачем? Ну, я не уверен, почему это так, но, возможно, это потому, что мы хотим, чтобы все работало. Или мы просто хотим закончить тестирование той или иной функции.

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

Как и в вопросе, тестирование не означает ничего автоматизированного, но на самом деле тестирование с использованием программы.

Morothar
источник
1

Есть несколько уровней тестирования. «Низкоуровневое» тестирование может и должно выполняться разработчиками. Я думаю на единицу тестиг.

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

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

AngeloBad
источник
0

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

Я могу признать, что разработчик, который разрабатывает программное обеспечение, может иметь туннельное зрение, когда дело доходит до того, что должен обрабатывать код, и игнорировать некоторые возможные граничные случаи, которые просто не могли быть рассмотрены. Например, если я создаю веб-форму, которая принимает число n, а затем печатает от 1 до n на экране, я могу пропустить некоторые особые случаи, например, если ничего не введено или что-то, что не является натуральным числом, например, e или pi , Что программа должна делать в этих случаях может быть сомнительным.

Разработка через тестирование будет примером методологии разработки, которая дает тестирование в другом свете, что может дать здесь другое представление.

JB King
источник
Спасибо за вопрос. Я обновил свой вопрос, чтобы сказать, что я считаю тестированием. По сути, тестирование - это то, что происходит после того, как программное обеспечение было построено и развернуто, а не во время разработки (например, модульное тестирование) или как часть методологии разработки (например, рецензирование).
jhsowter
0

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

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

Использование программистов для ручного тестирования просто глупо. Ручное тестирование достаточно глупо само по себе; Заставлять программистов делать это крайне глупо. Это дорого и отгоняет компетентных программистов.

Кевин Клайн
источник
Как бы я ни защищал написание модульных и интеграционных тестов, я не вижу, как TDD (или сначала пишет тесты) исправляет это. Если вы напишите основные сценарии успеха до написания кода, вы, вероятно , не найдете большинство ошибок. Вы должны думать обо всем, что может пойти не так. Написав код, вы можете найти некоторые из них, поскольку вы можете просмотреть ветки и методы, которые вы вызываете, чтобы увидеть, что может их сломать.
Дэнни Варод
Кроме того, многие ошибки, которые я обнаружил, которые пропустили разработчики, были связаны с порядком вызовов API. То, что большинство модульных тестов не охватывает, особенно если вы не знаете, какие другие методы могут быть вызваны, может повлиять на тот, который вы тестируете (и который еще не был реализован).
Дэнни Варод
@Danny: с TDD вы должны писать только ответвления или методы в ответ на неудачный тест, и вы пишете только код, необходимый для прохождения неудачного теста.
Кевин Клайн
Я знаю методологию TDD, я просто не согласен с выводами.
Дэнни Варод
0

Одним из видов тестирования, на котором я особенно видел неудачу devlopers, является тестирование, если требование было выполнено. То, что разработчики думают что-то в требовании, означает, и то, что думают тестировщики, означает, что это часто две совершенно разные вещи.

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

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

HLGEM
источник