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

[Future]

Добрый день коллеги. Возникла следующая задачка, есть ряд тест планов, доставших в наследство от предыдущих тестировщиков, местами они ничего, но местами уже устарели, т.к. писались для старых версий. Сейчас необходимо их "освежить", но прежде чем приступать к работе необходимо оценить, что из них можно взять (может быть стоит лишь дописать тесты на новый функционал и всё), а что нужно удалить. Хочется узнать метрики на эту тему, есть ли какие-то "православные" способы? Свои соображения есть, но они основываются лишь на здравом смысле и ничего более, может быть есть уже какие-то методики на эту тему? Встречал утилитки для анализа кода, но попадались только для дот нета (JetBrains dotCover 2.0), но меня больше интересует бизнес, а не код. Может какую-то книжку полезную почитать? Заранее спасибо за советы.

[aya]

Future, получилось что-то узнать по этому вопросу? Меня тоже этот вопрос сейчас интересует

[Future]

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

[aya]

Если мне нужно оценить насколько покрыта тестами функциональность, то я делаю карту всей функциональности и просто отмечаю на карте, для какой функциональности тесты у меня есть, а для какой нет. Иногда показываю проджект менеджеру / заказчику и спрашиваю: "Ничего ли я не пропустила?".
В XMind выделяю разными значками. См. пример во вложении.

Но всё равно ищу более лучшие способы :)

Прикрепленные файлы

•  map_example.png   169,24К   68 Количество загрузок:

[kitsune]

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

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

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

[Future]

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

[Фрося]

А сам функционал в чем считать будете?
А где-нибудь фиксируются изменения в функционале от версии к версии?

[kitsune]

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

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

Определить приблизительный критерий покрытия одного юнита документации. Например: 1 стори - 10 тест кейсов.

Завести простую табличку:
Имя/ИД стори | Адрес стори | Количество написанных тест-кейсов | Адрес тест-кейсов

Вписать в табличку ту информацию, которая у вас уже есть.
По мере написания тест-кейсов табличку обновлять.