Green

Сторонникам концепции, согласно которой тестирование имеет своей целью поиск дефектов, настоятельно рекомендую почитать вот эту заметку, чтобы попытаться понять позицию противоположной стороны: http://www.questioni...of-testing.html

Первично то, что у нас есть задача и ее реализация. Нам нужно сравнить то что получилось с тем, что должно было получиться. Другими словами, сложить 2+2 и получить 4. Если мы складываем 2+2 и получаем 5, то это ошибка. В случае программы - дефект. Цель тестировщика - сравнить левую и правую части уравнения и сделать вывод о наличии или отсутствии ошибки. Если этот процесс не является поиском дефектов, то что это?

Теперь представим, что есть нечто сложнее, чем 2+2=4. Допустим по требованиям/спеке дано f(x)=y. По результатам эксперимента получается, что f(x)=2y. Где ошибка?
Если механически сравнить левую и правую сторону, то ошибка всегда получается в программе. А может ошибка в спецификации и правильно f(x)=2y, что и подтвержденено результатами эксперимента. Надо чуть чуть думать, просто сравнить не получается.
...

Вначале 2 LeshaL,
а кто сказал, что часть уравнения, с которой нужно сравнивать, - это программа?
А думать нужно всегда, даже когда просто гвоздь в стену заколачиваешь.


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

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

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

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


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

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

Правильно! Сто раз правильно!

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

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

Привет!

вот что я могу сказать по этому поводу:
сам раньше работал с багтреккером в котором было только severity, этим полем задавалась и критичность бага (импрувмента, ЦРа и т.п.), и его приоритет. теперь же я на проекте, где эти поля разделены. честно говоря, поначалу я не въезжал что к чему и какая между ними разница (раньше ведь я с таким разделением не сталкивался). но понаблюдав как работает моя проектная команда с этими понятиями, я чётко усвоил вот что: severity - это критичность бага, именно критичность по отношению к самому приложению; а вот priority - это приоритетность выполнения (фикса, имплементации, инвестигейшна...), т.е. приорити относится не к приложению, а к процессу работы.

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

вот такая практика используется сейчас на моём текущем проекте.
на мой взгляд довольно рационально и гибко!

Выставляя severity тестировщик оценивает влияние дефекта на работоспособность приложения. Чем выше severity, тем масштабнее негативные последствия данного дефекта.

Priority - это инструмент менеджера по планированию работ. Чем выше priority, тем быстрее нужно исправить дефект.

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

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

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

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

Далее начинаем обратный путь.

1. Находим среднее время (я встречал рекомендации - 2/3) для каждого теста (успешного и неуспещного варианта)
2. Суммируем все полученные результаты (средние для каждого теста)

Получаем предположительное время тестирование системы при условии соотношения багов к тестам - 1/2 (т.е. баг обнаруживается в каждом втором тесте).

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

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

SALar хорошо расписал принцип написания отчета. Хочу только немного дополнить.

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

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

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

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

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

Может ли кто-нибудь поделиться опытом организации процесса Юнит тестирования в компании?

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

Основная идея может быть сформулирована следующим образом:
If we can measure it we can control it.

Спасибо.