Споры о тестировании программного обеспечения

существуют значительные различия Среди авторов и консультантов по тестированию программного обеспечения в том, что представляет собой ответственное тестирование программного обеспечения. Сторонники контекстно-ориентированного подхода ^[1] считают большую часть написанного о тестировании программного обеспечения доктриной, в то время как другие считают, что это противоречит стандарту документации IEEE 829 . ^[2]

Лучшие практики

Сторонники контекстно-ориентированного подхода считают, что не существует лучших практик тестирования, а скорее, что тестирование — это набор навыков, которые позволяют тестировщику выбирать или изобретать методы тестирования, подходящие для каждой уникальной ситуации. Джеймс Маркус Бах писал: «...нет практики, которая была бы лучше всех других возможных практик, независимо от контекста». ^[3] Однако некоторые специалисты по тестированию не видят проблем в понятии «лучшие практики» и не верят, что этот термин подразумевает универсальность практики. ^[4]

Виды тестирования программного обеспечения

Agile против традиционного

Примерно с 1990 года новый стиль написания статей о тестировании начал бросать вызов тому, что было раньше. Основополагающей работой в этом отношении широко считается «Тестирование компьютерного программного обеспечения » Джема Канера . ^[5] Вместо того, чтобы предполагать, что тестировщики имеют полный доступ к исходному коду и полным спецификациям, эти авторы, включая Канера и Джеймса Баха , утверждали, что тестировщики должны научиться работать в условиях неопределенности и постоянных изменений. Между тем, противоположная тенденция к «зрелости» процессов также получила распространение в форме модели зрелости возможностей . Движение гибкого тестирования (которое включает в себя, помимо прочего, формы тестирования, практикуемые в проектах гибкой разработки ) пользуется популярностью в основном в коммерческих кругах, тогда как CMM был принят государственными и военными поставщиками программного обеспечения.

Однако говорить о том, что «модели зрелости», такие как CMM, получили преимущество в борьбе с Agile-тестированием или противостоять ему, возможно, неверно. Agile-движение — это «способ работы», а CMM — это идея улучшения процессов.

Но необходимо учитывать и другую точку зрения: операционную культуру организации. Возможно, это правда, что тестировщики должны иметь способность работать в мире неопределенности, но верно и то, что их гибкость должна иметь направление. Во многих случаях тестовые культуры являются самостоятельными, и в результате могут быть получены бесплодные и непродуктивные результаты. Более того, предоставление положительных доказательств наличия дефектов может указывать либо на то, что вы нашли начало гораздо более серьезной проблемы, либо на то, что вы исчерпали все возможности. Фреймворк — это тест Тестирования. Он обеспечивает границу, которая может измерить (подтвердить) эффективность нашей работы. Обе стороны доказывали и будут продолжать доказывать достоинства своей работы. Однако доказательством является каждая оценка качества доставки. Систематическое тестирование принесет мало пользы, если вы слишком узко сфокусированы. С другой стороны, обнаружение кучи ошибок не является показателем того, что движущей силой были Agile-методы; возможно, вы просто наткнулись на заведомо плохую работу.

Исследовательский и сценарный

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

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

Ручной или автоматический

Некоторые авторы считают, что автоматизация тестирования настолько дорога по сравнению с ее ценностью, что ее следует использовать с осторожностью. ^[6] Другие, например, сторонники гибкой разработки , рекомендуют автоматизировать 100% всех тестов. Проблема автоматизации заключается в том, что для автоматизированного тестирования требуются автоматизированные тестовые оракулы (оракул — это механизм или принцип, с помощью которого можно распознать проблему в программном обеспечении). Такие инструменты полезны при нагрузочном тестировании программного обеспечения (путем входа в приложение с сотнями или тысячами экземпляров одновременно) или при проверке периодических ошибок в программном обеспечении.

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

Проектирование программного обеспечения и реализация программного обеспечения

^{[ не следует ]}

если тестирование программного обеспечения собирает информацию о продукте или программе для заинтересованных сторон, из этого не следует, что существует выбор между реализацией тестирования или дизайном, т. е. это ошибочное предположение. ^{[ нужны разъяснения ]}В идеале тестировщики программного обеспечения не должны ограничиваться только тестированием реализации программного обеспечения, но также и тестированием дизайна программного обеспечения. При таком предположении роль и участие тестировщиков кардинально изменятся. В такой среде изменится и цикл тестирования. Чтобы протестировать дизайн программного обеспечения, тестировщики проверяют требования и спецификации дизайна вместе с дизайнером и программистом, что потенциально помогает выявить ошибки на более ранних этапах разработки программного обеспечения.

надзор

Один из принципов тестирования программного обеспечения резюмируется классическим латинским вопросом, поставленным Ювеналом: Quis Custodiet Ipsos Custodes (Кто наблюдает за сторожами?), или, как вариант, его называют неофициально, как концепция « Гейзенбага » (распространенное заблуждение, путающее Гейзенберга принцип неопределенности с эффектом наблюдателя ). Идея состоит в том, что любая форма наблюдения — это также взаимодействие, что акт тестирования также может повлиять на то, что тестируется. ^[7]

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

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

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

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

Ссылки

^ «Принципы» . Контекстно-ориентированное тестирование . Проверено 5 октября 2022 г.
^ Бат, Грэм; Винендал, Эрик Ван (13 декабря 2013 г.). Улучшение процесса тестирования: внедрение улучшений и изменений — Учебное пособие для модуля экспертного уровня ISTQB . Rocky Nook, Inc. ISBN 978-1-4920-0133-1 .
^ Бах, Джеймс (8 июля 2005 г.). «Нет лучших практик» . Проверено 5 февраля 2018 г.
^ Колантонио, Джо (13 апреля 2017 г.). «Лучшие практики против хороших практик – разглагольствования с Рексом Блэком» . Проверено 5 февраля 2018 г.
^ Канер, Джем ; Джек Фальк; Хунг Куок Нгуен (1993). Тестирование компьютерного программного обеспечения (Третье изд.). Джон Уайли и сыновья. ISBN 1-85032-908-7 .
^ Пример: Марк Фьюстер, Дороти Грэм: Автоматизация тестирования программного обеспечения. Эддисон Уэсли, 1999 г., ISBN 0-201-33140-3
^ Гарсия, Бони (27 октября 2017 г.). Освоение тестирования программного обеспечения с помощью JUnit 5: комплексное руководство по разработке высококачественных приложений Java . Packt Publishing Ltd. ISBN 978-1-78712-439-4 .

[1] «Принципы» . Контекстно-ориентированное тестирование . Проверено 5 октября 2022 г.

[2] Бат, Грэм; Винендал, Эрик Ван (13 декабря 2013 г.). Улучшение процесса тестирования: внедрение улучшений и изменений — Учебное пособие для модуля экспертного уровня ISTQB . Rocky Nook, Inc. ISBN 978-1-4920-0133-1 .

[3] Бах, Джеймс (8 июля 2005 г.). «Нет лучших практик» . Проверено 5 февраля 2018 г.

[4] Колантонио, Джо (13 апреля 2017 г.). «Лучшие практики против хороших практик – разглагольствования с Рексом Блэком» . Проверено 5 февраля 2018 г.

[5] Канер, Джем ; Джек Фальк; Хунг Куок Нгуен (1993). Тестирование компьютерного программного обеспечения (Третье изд.). Джон Уайли и сыновья. ISBN 1-85032-908-7 .

[6] Пример: Марк Фьюстер, Дороти Грэм: Автоматизация тестирования программного обеспечения. Эддисон Уэсли, 1999 г., ISBN 0-201-33140-3

[7] Гарсия, Бони (27 октября 2017 г.). Освоение тестирования программного обеспечения с помощью JUnit 5: комплексное руководство по разработке высококачественных приложений Java . Packt Publishing Ltd. ISBN 978-1-78712-439-4 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]