Среди авторов и консультантов по тестированию ПО существуют значительные различия в том, что составляет ответственное тестирование ПО. Сторонники подхода, основанного на контексте [1], считают большую часть написанного о тестировании ПО доктриной, в то время как другие полагают, что это противоречит стандарту документации IEEE 829. [2]
Сторонники подхода, основанного на контексте, считают, что не существует лучших практик тестирования, а скорее тестирование — это набор навыков, которые позволяют тестировщику выбирать или изобретать практики тестирования, подходящие для каждой уникальной ситуации. Джеймс Маркус Бах писал: «...нет практики, которая была бы лучше всех других возможных практик, независимо от контекста». [3] Однако некоторые специалисты по тестированию не видят проблемы в концепции «лучших практик» и не считают, что этот термин подразумевает, что практика применима повсеместно. [4]
Около 1990 года новый стиль написания статей о тестировании начал бросать вызов предыдущим подходам. Основополагающей работой в этой области часто считается «Тестирование компьютерного программного обеспечения» Джема Канера. [5] Вместо предположения, что тестировщики имеют полный доступ к исходному коду и полным спецификациям, эти авторы, включая Канера и Джеймса Баха , утверждали, что тестировщики должны учиться работать в условиях неопределенности и постоянных изменений. Между тем, противоположная тенденция к «зрелости» процесса также набрала силу в форме Модели зрелости возможностей . Движение гибкого тестирования, которое включает в себя, но не ограничивается методами тестирования, практикуемыми в проектах гибкой разработки, популярно в основном в коммерческих кругах, тогда как CMM была принята правительственными и военными поставщиками программного обеспечения.
Однако утверждение, что «модели зрелости», такие как CMM, набрали обороты против или противостоят Agile-тестированию, может быть неверным. Agile-движение — это «способ работы», в то время как CMM — это идея улучшения процесса.
Но необходимо рассмотреть и другую точку зрения: операционную культуру организации. Хотя может быть верно, что тестировщики должны уметь работать в мире неопределенности, верно также и то, что их гибкость должна иметь направление. Во многих случаях тестовые культуры являются самоуправляемыми, и в результате могут возникнуть бесплодные, непродуктивные результаты. Более того, предоставление положительных доказательств дефектов может либо указывать на то, что вы нашли верхушку гораздо более крупной проблемы, либо на то, что вы исчерпали все возможности. Фреймворк — это тест Тестирования. Он обеспечивает границу, которая может измерить (подтвердить) возможности нашей работы. Обе стороны продолжают спорить о достоинствах своих подходов, но истинная мера заключается в оценке качества поставки. Систематическое тестирование без более широкого фокуса может быть неэффективным, в то время как обнаружение многочисленных ошибок не обязательно означает, что причиной были методы Agile; это может просто указывать на плохую первоначальную работу.
Исследовательское тестирование означает одновременное проектирование и выполнение теста с упором на обучение. Сценарное тестирование означает, что обучение и проектирование теста происходят до выполнения теста, и довольно часто обучение приходится проводить снова во время выполнения теста. Исследовательское тестирование очень распространено, но в большинстве текстов и тренингов по тестированию оно едва упоминается и, как правило, неправильно понимается. Некоторые авторы считают его основной и необходимой практикой. Структурированное исследовательское тестирование является компромиссом, когда тестировщики знакомы с программным обеспечением. Составляется неопределенный план тестирования, известный как устав тестирования, описывающий, какие функции необходимо протестировать, но не как, что позволяет отдельным тестировщикам выбирать метод и этапы тестирования.
С преимущественно исследовательским подходом к тестированию связано два основных недостатка. Первый заключается в том, что нет возможности предотвратить дефекты, которые могут возникнуть, когда предварительное проектирование тестов служит формой структурированного статического тестирования, которое часто выявляет проблемы в системных требованиях и дизайне. Второй заключается в том, что даже при наличии уставов тестирования трудно продемонстрировать тестовое покрытие и добиться повторяемости тестов с использованием чисто исследовательского подхода к тестированию. По этой причине часто используется смешанный подход скриптового и исследовательского тестирования, чтобы извлечь выгоду, одновременно смягчая недостатки каждого подхода.
Некоторые авторы считают, что автоматизация тестирования настолько дорога по сравнению с ее ценностью, что ее следует использовать экономно. [6] Другие, такие как сторонники гибкой разработки , рекомендуют автоматизировать 100% всех тестов. Проблема с автоматизацией заключается в том, что автоматизированное тестирование требует автоматизированных тестовых оракулов (оракул — это механизм или принцип, с помощью которого можно распознать проблему в программном обеспечении). Такие инструменты имеют ценность при нагрузочном тестировании программного обеспечения (путем входа в приложение с сотнями или тысячами экземпляров одновременно) или при проверке периодических ошибок в программном обеспечении.
Успех автоматизированного тестирования ПО зависит от полного и всестороннего планирования тестирования. Стратегии разработки ПО, такие как разработка через тестирование, в высокой степени совместимы с идеей выделения значительной части ресурсов тестирования организации на автоматизированное тестирование. Многие крупные организации-разработчики ПО выполняют автоматизированное тестирование. Некоторые разработали собственные среды автоматизированного тестирования специально для внутренней разработки, а не для перепродажи.
[ нелогично ]
Если тестирование программного обеспечения собирает информацию о продукте или программе для заинтересованных сторон, то из этого не следует, что существует выбор между тестированием реализации или проектирования - т. е. это ошибочное предположение. [ необходимо разъяснение ] В идеале тестировщики программного обеспечения не должны ограничиваться только тестированием реализации программного обеспечения, но и тестированием проектирования программного обеспечения. При таком предположении роль и участие тестировщиков кардинально изменятся. В такой среде цикл тестирования также изменится. Для тестирования проектирования программного обеспечения тестировщики будут просматривать требования и спецификации проектирования вместе с дизайнером и программистом, что потенциально поможет выявить ошибки на ранних этапах разработки программного обеспечения.
Один из принципов тестирования программного обеспечения суммируется в классическом латинском вопросе, поставленном Ювеналом: Quis Custodiet Ipsos Custodes (Кто наблюдает за стражами?), или, как альтернатива, неформально именуется концепцией « Гейзенбага » (распространенное заблуждение, путающее принцип неопределенности Гейзенберга с эффектом наблюдателя ) . Идея заключается в том, что любая форма наблюдения также является взаимодействием, что акт тестирования также может влиять на то, что тестируется. [7]
На практике инженер-испытатель тестирует программное обеспечение (а иногда и оборудование или прошивку ) с другим программным обеспечением (и оборудованием и прошивкой). Процесс может давать сбои способами, которые не являются результатом дефектов в цели, а скорее являются результатом дефектов (или даже предполагаемых функций) инструмента тестирования.
Разрабатываются метрики для измерения эффективности тестирования. Один из методов — анализ покрытия кода (это очень спорно) — где все могут согласиться, какие области вообще не покрыты, и попытаться улучшить покрытие в этих областях.
Ошибки также могут быть намеренно помещены в код, и количество ошибок, которые не были найдены, можно предсказать на основе процента намеренно помещенных ошибок, которые были найдены. Проблема в том, что это предполагает, что намеренные ошибки - это тот же тип ошибок, что и непреднамеренные.
Наконец, есть анализ исторических показателей поиска. Измеряя, сколько ошибок найдено, и сравнивая их с прогнозируемыми числами (основанными на прошлом опыте с аналогичными проектами), можно сделать определенные предположения относительно эффективности тестирования. Хотя это и не является абсолютным измерением качества, если проект наполовину завершен и не было обнаружено никаких дефектов, то могут потребоваться изменения в процедурах, используемых QA.