Сообщений в теме: 11

[Case]

Эссе о критериях
Автор: Алексей Баранцев
Библиотека / Тестирование

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

[Imbecile]

ОФФ:
Навеянно эссе:
"Математику уже за то учить надо, что она ум в порядок приводит." © Ломоносов

Понравилась статья. Позволила лучше структуировать часть набора знаний из области тестирования. Спасибо.

[Green]

Алексей,

мои поздравления! Отличная статья!
Сразу виден подход истинного ученого.


У меня есть только три добавления по тексту статьи.

1. "Критерий начала тестирования"

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

Впрочем, далеко не у всех этот момент четко обозначен.

2. Критерии окончания тестирования (специально не стал использовать слова "заверешения" и "прекращения" - решайте сами, какой больше подходит).

Мой любимый вопрос на собеседовании. ;-)
Я могу назвать как минимум еще 2 условия.

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

Кстати, возможен вариант когда закончились специалисты, выделенные на тестирование (вариант в). Например, идет внутренний проект. На него ресурсы выделяют по остаточному принципу. Вдруг... никого не осталось. Вуаля! Тестированию - каюк.


3. Три плохие метрики

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

Метрики максимально информативны, когда они рассматриваются в динамике и в комплексе. Характеризуют "ровность" протекания проекта и способствуют выявлению (а так же прогнозированию) проблем на проекте.

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


Алексей,

про аналогию с музеем отдельное спасибо! Просто в самую точку!

[barancev]

ОФФ:
Навеянно эссе:
"Математику уже за то учить надо, что она ум в порядок приводит." © Ломоносов

Математика? В моей статье? Хм... Неужели?

[barancev]

to Green:

1. Вовсе необязательно критерием начала тестирования является прохождение смоки-тестов.

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

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

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

[Case]

Сергей, привествую

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

Я наверное не до конца уловил идею высказывания. А зачем так рассматривать тестирование?

[SALar]

Хорошая статья, спасибо. Даже критику писать не хочется.

----------------
PS. Частый критерий прекращения тестирования: "Можно ли проводить тесты дальше".
- Мы бы с удовольствием потестили дальше, но к сожалению остальные тесты заблокированы .

[Green]

Сергей, привествую 

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

Я наверное не до конца уловил идею высказывания. А зачем так рассматривать тестирование?

Мысль была в том, что термин "тестирование" многогранен и не имеет однозначного толкования без уточняющего контекста (собственно, об этом и статья). Я хотел уточнить, какое именно тестирование я имею ввиду- деятельность тестировщика по выявлению багов.
:-)

[shisha_hwguy]

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

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

[Darkus]

Спасибо большое за статью. К сожаленью вот только добрался до прочтения её.
У меня появились вопросы и есть некоторые мысли :)
1. Не совсем ясна фраза вот в этом разделе
"Критерии прекращения и завершения тестирования"
....
" А что делать, если выполнятся оба критерия вместе? В данном случае это означает, что критерии выбраны неудачно. Не может продукт быть одновременно настолько плохим, что требуется доработка, и настолько хорошим, чтобы пропустить его в эксплуатацию."

Это следует читать как:
- "Не может продукт быть одновременно настолько плохим, что требуется доработка", и "настолько хорошим, чтобы пропустить его в эксплуатацию"?
или
- "Не может продукт быть одновременно настолько плохим..., и настолько хорошим..."?

2. Началом тестирования можно считать ту точку времени, когда есть что проверить. Возможно, что когда есть набор требований, готовых к тестированию (может быть даже 1 требование) + команда "Старт", то можно считать что вот и Началось тестирование.

3. Очень ценная метрика - "количество выполненных требований". Остальные у меня тоже вызывают сомнения. :)

[barancev]

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

Итак, вот камень преткновения:

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

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

Предположим, мы выбрали такие критерии:
-- если в продукте обнаружено не менее 2-х ошибок уровня критичности 1, то его следует отправить на доработку, внедрять в эксплутатацию такой продукт нельзя.
-- если выполняются все тесты утверждённой полгода тому назад ПМИ, то продукт может быть принят в эксплуатацию.

А теперь представим, что выполняются ОБА эти критерия -- все тесты ПМИ проходят, но в продукте есть несколько критических ошибок, которые обнаружены другими тестами. Что делать? Какое решение принять?

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

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

[SALar]

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

Если читателям непонятно какое то место статьи есть несколько вариантов:
* поправить статью
* сослаться на сторонние материалы
* написать еще одну статью

Вы привели в форуме прекрасное объяснение, просто вставьте его в статью.

PS. Мне было все понятно, но от разжевывания, статья для меня не потеряет в оценке.

Простое правило:

Не объясняйте редактору то место, которое он не понял. Исправьте это место в статье так, чтобы его понял любой читатель.