Цели И Задачи Тестирования По Опции

[Case]

Давно я не стартовал сам новых тем в нашем форуме :)

Цели и задачи тестирования ПО в разрезе задач обеспечения качества ПО и некоторые мысли по автоматизации тестирования ПО.

Источник: Переход к автоматизированнуму тестированию

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

Все!

Не согласен с приоритетами в целом, но соглашусь с некоторыми выводами в разрезе задач автоматизации тестирования ПО.

Постараюсь кратко, но не обещаю:
1. Выявление ошибок не есть цель тестирования ПО.
2. Основной задачей тестирования ПО является получение информации о статусе готовности заявленной функциональности системы или приложения.
3. Задача получения статуса готовности обычно реализуется как проверка сценариев использования системы в валидных и невалидных условиях использования, которые формируются наборами входных данных и состояний, операций или пеолучаемых тестируемым функционалом данных и набором выходных данных и состояний системы.
4. Выявленные ошибки это побочный результат отработки задачи тестирования ПО, так как напрямую не являются нужной и полезной Заказчику тестирования информацией.
5. Количество найденных в процессе тестирования ошибок никак не характеризует уровень качества конечного продукта, а может выступать метрикой качества или зрелости самого процесса разработки ПО.
6. Количество найденных в процессе тестирования ошибок никак не характеризует целесообразность затрат ресурсов на проведение тестирования, так как напрямую зависит в основном от состояния продукта на момент начала тестирования и в меньшей степени от степени подготовленности/спланированности тестирования.

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

Автоматизировать можно и нужно только то, что автоматизации требует, а не те функциональные модули, где автоматизацию можно применить.

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

Что значит целесообразность внедрения на практике.
Модульное тестирование
Прогон всех модульных тестов на интеграционном окружении во время сборки версии системы является первым этапом автоматизации. Имеет ли смысл вкладывать ресурсы в модульное тестирование?

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

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

Автоматизация набора регрессионных тестов
Я не совсем понимаю этузадачу как вид тестирования и для себя не выделяю, но формулировки в форумах встречаются именно такие. Для меня структура тестов любого функционала примерно следующая:
1. Полный или основной тестовый набор, покрывающий всю функциональность тестовой области. Ревьювится перед каждым прогоном полного цикла тестирования на предмет изменений в спецификациях и критических исправлений/доработках. Обновляется/актуализируется по результатам ревью.
2. Короткий список (обычно только позитивные тесты основанные на наиболее приоритетных сценариях использования). Включается в цикл дымового тестирования или другими словами в набор тестов приёмочной фазы тестирования. Составляется в процессе создания тестового набора. Ревьювится перед каждым прогоном набора приёмочных тестов, по сути перед каждым раундом тестирования при выкатке новой версии. Обновляется/актуализируется в момент актуализации основного тестового набора. Удобно вести в том же артефакте что и основной тестовый набор с возможностью автоматизированного включения в тестовый набор дымового/приёмочного тестирования.

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

Иногда в планы автоматизации может вмешиваться задача автоматизации тестирования какого-то выделенного компонента, например от стороннего разработчика, функционал которого как бы оборачивается прослойкой автоматизированных тестов, для снижения рисков связянных с неполным контролем качества поставляемого этим разработчиком модулей или компонентов. Если таким компонентом является что-то, что используется в системе несколькими модулями системы, скорее всего прийдётся идти по принципу точечной автоматизации именно в разрезе автоматизации тестирования этого выделенного списка функций. Например, уровень работы с базой данных может стать таким узким местом, если кому-то пришлось отказываться от поставляемых в составе СУБД драйверами.

Что попадает в набор тестов для автоматизации определяется всё тем же основным принципом экономической рациональности и в каждом конкретном тестовом наборе.

[SALar]

Слав, Сергей пишет о задачах, ты о целях. В чем спор то? Это ж разные вещи.

[SALar]

Буду отвечать по пунктам.

1. Выявление ошибок не есть цель тестирования ПО.

Согласен. Гринкевич говорит тоже самое.

2. Основной задачей тестирования ПО является получение информации о статусе готовности заявленной функциональности системы или приложения.

Смысл понятен и с ним я согласен, но нужно полностью переформулировать.

3. Задача получения статуса готовности обычно реализуется как проверка сценариев использования системы в валидных и невалидных условиях использования, которые формируются наборами входных данных и состояний, операций или пеолучаемых тестируемым функционалом данных и набором выходных данных и состояний системы.

Э-э-э... ну в общем нет.

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

Не согласен.

5. Количество найденных в процессе тестирования ошибок никак не характеризует уровень качества конечного продукта

Согласен.

, а может выступать метрикой качества или зрелости самого процесса разработки ПО.

Категорически не согласен.

6. Количество найденных в процессе тестирования ошибок никак не характеризует целесообразность затрат ресурсов на проведение тестирования, так как напрямую зависит в основном от состояния продукта на момент начала тестирования и в меньшей степени от степени подготовленности/спланированности тестирования.

Согласен. Но этот пункт лучше разбить.

PS. Ах, да. Все вышенаписанное Мое Скромное Мнение (IMHO). Никакой связи с классиками не ищите.

[SALar]

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

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

А в остальном почти согласен.

Может skype-стол проведем?

[Case]

Слав, Сергей пишет о задачах, ты о целях. В чем спор то? Это ж разные вещи.

Хорошо, я перефразирую.

Задача тестировщика не поиск ошибок, и уж тем паче не первая в списке.

[Case]

Буду отвечать по пунктам.

А аргументация? А то ромашка - тут верю, тут не верю :)

[Case]

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

Скорее это клиника и отмывание бабок :)

Может skype-стол проведем?

У меня сейчас перестало появляться время, я лучше тут.

[SALar]

Буду отвечать по пунктам.

А аргументация? А то ромашка - тут верю, тут не верю :)

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

[Green]

Слав, Сергей пишет о задачах, ты о целях. В чем спор то? Это ж разные вещи.

Хорошо, я перефразирую.

Задача тестировщика не поиск ошибок, и уж тем паче не первая в списке.

Case,

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

Дык вось,
тестировщик ищет баги в программе для достижения некоторых целей. Вот список главных целей тестирования (на мой взгляд):
1. получить адекватную и актуальную информацию о состоянии проекта (что и в каком объеме реализовано)
2. определить степень готовности продукта к выпуску
3. снизить риски финансовых и не финансовых потерь (как заказчика, так и исполнителя)

Этих целей невозможно достичь без тестирования программы!

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

Однако, даже если тесты определят отсутствие дефектов, это не означает, что они бесполезны или что тестировщик зря потратил время. Нет!

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

Результаты работы тестировщика являются исходными данными для определения степени достижения целей:

1. получить адекватную и актуальную информацию о состоянии проекта (что и в каком объеме реализовано)
- сопоставляем данные traceability matrix: требование - тест кейс - результат теста - баг

2. определить степень готовности продукта к выпуску
- показатели defect tracking system характеризуют степень готовности

3. снизить риски финансовых и не финансовых потерь (как заказчика, так и исполнителя)
- гипотетическая цель, достигается через нахождения максимально возможного количества дефектов и не соответствий программы

[Green]

Слава,

я в ссылочном посте уже писал про автоматизацию. Не хотелось бы повторяться.

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

[Green]

Автоматизировать можно и нужно только то, что автоматизации требует, а не те функциональные модули, где автоматизацию можно применить.

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

Что значит целесообразность внедрения на практике.
Модульное тестирование
Прогон всех модульных тестов на интеграционном окружении во время сборки версии системы является первым этапом автоматизации. Имеет ли смысл вкладывать ресурсы в модульное тестирование?

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

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

Автоматизация набора регрессионных тестов
Я не совсем понимаю этузадачу как вид тестирования и для себя не выделяю, но формулировки в форумах встречаются именно такие. Для меня структура тестов любого функционала примерно следующая:
1. Полный или основной тестовый набор, покрывающий всю функциональность тестовой области. Ревьювится перед каждым прогоном полного цикла тестирования на предмет изменений в спецификациях и критических исправлений/доработках. Обновляется/актуализируется по результатам ревью.
2. Короткий список (обычно только позитивные тесты основанные на наиболее приоритетных сценариях использования). Включается в цикл дымового тестирования или другими словами в набор тестов приёмочной фазы тестирования. Составляется в процессе создания тестового набора. Ревьювится перед каждым прогоном набора приёмочных тестов, по сути перед каждым раундом тестирования при выкатке новой версии. Обновляется/актуализируется в момент актуализации основного тестового набора. Удобно вести в том же артефакте что и основной тестовый набор с возможностью автоматизированного включения в тестовый набор дымового/приёмочного тестирования.

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

Иногда в планы автоматизации может вмешиваться задача автоматизации тестирования какого-то выделенного компонента, например от стороннего разработчика, функционал которого как бы оборачивается прослойкой автоматизированных тестов, для снижения рисков связянных с неполным контролем качества поставляемого этим разработчиком модулей или компонентов. Если таким компонентом является что-то, что используется в системе несколькими модулями системы, скорее всего прийдётся идти по принципу точечной автоматизации именно в разрезе автоматизации тестирования этого выделенного списка функций. Например, уровень работы с базой данных может стать таким узким местом, если кому-то пришлось отказываться от поставляемых в составе СУБД драйверами.

Что попадает в набор тестов для автоматизации определяется всё тем же основным принципом экономической рациональности и в каждом конкретном тестовом наборе.

Не вижу здесь никаких противоречий. Полностью с тобой согласен. (IMG:style_emoticons/default/friends.gif)

"Экономика должна быть экономной!"

[Green]

4. Выявленные ошибки это побочный результат отработки задачи тестирования ПО, так как напрямую не являются нужной и полезной Заказчику тестирования информацией.
5. Количество найденных в процессе тестирования ошибок никак не характеризует уровень качества конечного продукта, а может выступать метрикой качества или зрелости самого процесса разработки ПО.
6. Количество найденных в процессе тестирования ошибок никак не характеризует целесообразность затрат ресурсов на проведение тестирования, так как напрямую зависит в основном от состояния продукта на момент начала тестирования и в меньшей степени от степени подготовленности/спланированности тестирования.

В этом я придерживаюсь другого мнения.

Выгода заказчика может быть в двух случаях:
1. заработать больше
2. сэкономить больше

По пункту 4.

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

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

По пункту 5.
Все правильно. Баги - это не только "ценный мех...". (IMG:style_emoticons/default/crazy.gif)

эффективные метрики основа управления качеством -> эффективное управление качеством основа получения качественного продукта -> качественный продукт основа удовлетворенности клиента -> удовлетворенный клиент (в рамках бюджета проекта) основа новых заказов

По пункту 6.
Мысль твою не понял, но не согласен. (IMG:style_emoticons/default/lol.gif)

[SALar]

Сергей, с тобой я согласен почти по всем пунктам.

Слав, Сергей пишет о задачах, ты о целях. В чем спор то? Это ж разные вещи.

Хорошо, я перефразирую.
Задача тестировщика не поиск ошибок, и уж тем паче не первая в списке.

Case,

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

Совершенно верно. Эта тонкая грань очень важна.

Этих целей невозможно достичь без тестирования программы!

Чем больше я об этом думаю, тем больше начинаю сомневаться. И эта тема сейчас мне очень интересна.
* Можно ли проконтролировать качество, не прибегая к тестированию? Какие аспекты качества? Какими методами? На каких проектах / с какими командами другие методы будут более эффективны?
* Как можно снижать риски, не прибегая к тестированию? Какими методами? Какой набор видов деятельности наиболее эффективен для каждой конкретной ситуации? Как его определить?
* Допустим, мы получили информацию о том, что состояние характеристик продукта удовлетворяет требуемому диапазону. Означает ли это, что продукт готов к выпуску? У меня получается, что нет.

Однако, даже если тесты определят отсутствие дефектов, это не означает, что они бесполезны или что тестировщик зря потратил время. Нет!

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

[KaNoN]

Ну что ж, опять, SALar, вы "выворачиваете наизнанку" устоявшиеся нормы и опровергаете то, что вроде бы как было чуть ли не аксиомой. В принципе, все подвергать сомнению зачастую полезно. Именно на этом принципе делается множество открытий и просто достижений, когда находится один, который берет на себя смелость пойти против устоев, убеждений, верований, канонов и т.п. (яркий пример подобного движения вопреки - "Черный квадрат" Казимира малевича). Это похвально. Возможно, каждая из подобных идей со временем найдет свое воплощение в будущем, но в настоящем этому будет много противников. Ну и я в том числе (IMG:style_emoticons/default/crazy.gif)

Итак:

Этих целей невозможно достичь без тестирования программы!

Чем больше я об этом думаю, тем больше начинаю сомневаться. И эта тема сейчас мне очень интересна.
* Можно ли проконтролировать качество, не прибегая к тестированию? Какие аспекты качества? Какими методами? На каких проектах / с какими командами другие методы будут более эффективны?

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

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

То есть, исходя из моего определения, на первый из вышеприведенных вопросов по данному пункту можно ответить "нет", причем достаточно уверенно. Если же нет, то приведите свое определение тестирования и можно рассмотреть вашу точку зрения уже в разрезе вашего определения.

Какие аспекты качества? Какими методами?
Вот тут уже можно подумать. Естественно, это некоторые оценки, которые можно получить без непосредственного использования данного продукта. Возможно стоит копнуть в анализ требований, причем системных. Например, если тестируемое приложение портируется на систему, в которой доступно всего, допустим, 10Мб, то вполне логично, что проукт весом в те же 15Мб нас не устроит.

* Как можно снижать риски, не прибегая к тестированию? Какими методами? Какой набор видов деятельности наиболее эффективен для каждой конкретной ситуации? Как его определить?

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

* Допустим, мы получили информацию о том, что состояние характеристик продукта удовлетворяет требуемому диапазону. Означает ли это, что продукт готов к выпуску? У меня получается, что нет.

Если не получается, то тогда есть какие-то характеристики, которые вы не учли или ваши расчеты по полученным показателям не верны.

Однако, даже если тесты определят отсутствие дефектов, это не означает, что они бесполезны или что тестировщик зря потратил время. Нет!

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

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

[Case]

Главная задача тестировщика - найти баг!

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

Я часто задавал на тренингах простой пример на решение. Есть форма ввода данных и кнопка валидации. Если введённое значение от 0..9 включительно то форма говорит ДА, если что-то другое то она говорит НЕТ. Надо составить тесты в порядке выполнения основываясь на определение задач и целей тестирования. Попробуй отталкиваясь от задачи "найти баги" идти :)

[Galina]

Ох какая дискуссия!

И всё-таки Сергей я примкну к лагерю противников заявления:

Главная задача тестировщика - найти баг!

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

Я бы задачи тестирования поставила таким образом:
1. убедиться, что программа удовлетворяет требованиям
2. убедиться, что программа служит намеченной цели
3. найти ошибки

(IMG:style_emoticons/default/blush.gif)

[Green]

Коллеги!

Честно говоря, нет никакого желания переубеждать вас. Оставайтесь при ваших заблуждениях (как и я останусь при своих).
(IMG:style_emoticons/default/fool.gif)

Но я попробую...
(IMG:style_emoticons/default/focus.gif)


Излагаю ход своих мыслей.

Тестирование это деятельность по проверке того, что программа делает то, что она должна делать и не делает того, что она делать не должна.

Зачем проводиться тестирование?
Что бы убедиться самим и убедить заказчика, что он получает именно то, что заказывал.

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

Любое несоответствие или расхождение между продуктом и спецификацией - дефект, который может быть исправлен.

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

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

Как ни крути, а тестировщик тестирует программу (сравнивает спецификацию с реализацией) и выявляет отклонения (дефекты). И в этом (в выявлении дефектов) заключается его ГЛАВНАЯ ЗАДАЧА (другими словами, то, что он делает ежедневно).

Далее начинаются детали.

Аксиома: протестировать программу на 100% (или выявить 100% отклонений от спецификации) невозможно.

Следствие 1:
Применяются различные методологии тестирования, что бы ресурс (люди, время, деньги) был потрачен максимально эффективно.

Следствие 2:
Применяются всякие методики по управлению рисками и вероятностный анализ, что бы выявить наиболее опасные (с точки зрения бизнеса) отклонения от спецификации.

Следствие 3:
Применяются методики по сбору метрик и управлению качеством, для обеспечения максимального качества в рамках выделенного бюджета (соотношение цена-качество).

И т.д.

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



Теперь пару слов о том, что тестировщик не должен видеть свою задачу, как нахождение дефектов.

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

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

[SALar]

Мои аплодисменты, Сергей.
(IMG:style_emoticons/default/clapping.gif) (IMG:style_emoticons/default/clapping.gif) (IMG:style_emoticons/default/clapping.gif)

Примерно так я и видел одну из своих статей. Теперь остается только проситься в соавторы. И то, возьмут ли...

[SALar]

Добавлю еще немного.
Тестирование не единственный способ контроля качества ПО.
И не всегда самый эффективный.

Впрочем, это другая сказка.

[Green]

Добавлю еще немного.
Тестирование не единственный способ контроля качества ПО.
И не всегда самый эффективный.

Впрочем, это другая сказка.

SALar,

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

Тестирование - это единственный и самый эффективный способ контроля качества.

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

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