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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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