Перейти к содержимому

Фотография

Уровень детализации тест-кейсов в огромном проекте не покрытом тестами

тест-кейс тесткейс уровень детализации тестов

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 7

#1 PavelKrivosheev

PavelKrivosheev

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Кривошеев Павел Александрович
  • Город:Пермь


Отправлено 31 июля 2014 - 02:30

Добрый день уважаемые коллеги!

 

Существует некий огромный проект,  с кучей модулей совершенно не покрытый тест-кейсами...

 

Было принято решение - начать покрывать его тестами, но создавая примеры тест-кейсов задумался об уровне их детализации:

 

на сколько они должны быть подробными (учитывая что времени не вагон) ?

и по какому принципу их "дробить"?

создавать на данном этапе только позитивные тесты или сразу парой - негативный+позитивный?

 

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

 

В команде 6 человек, писать тест-кейсы все скорее всего не смогут


  • 0

#2 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 31 июля 2014 - 07:11

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

При этом описаны как позитивные так и негативные тесты, какие-то модули покрыты только санити тестами, какие-то (второстепенные модули) вообще не покрыты тестами пока.

команда из 3-х человек.

Параллельно этой же командой проведена автоматизация 80% разработанных тест кейсов.

 

энтропия должна уменьшаться!

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

  • Прикрепленный файл  testlink.png   61,71К   29 Количество загрузок:

  • 0

#3 ryjii

ryjii

    Активный участник

  • Members
  • PipPip
  • 101 сообщений
  • Город:Санкт-Петербург

Отправлено 31 июля 2014 - 07:32

Было принято решение - начать покрывать его тестами, но создавая примеры тест-кейсов задумался об уровне их детализации:

А кем было принято решение? Какая цель преследуется?

Плясать нужно от этого. Тест-кейсы ради тест-кейсов это перевод кучи времени впустую. Иногда достаточно чеклистов, а иногда и они не нужны.


  • 0

#4 SHINNOK

SHINNOK

    Постоянный участник

  • Members
  • PipPipPip
  • 247 сообщений
  • ФИО:Кравченко Артём
  • Город:Таганрог


Отправлено 31 июля 2014 - 07:46

Было принято решение - начать покрывать его тестами, но создавая примеры тест-кейсов задумался об уровне их детализации:

 

Если нет времени писать подробные тест-кейсы, попробуйте обойтись чек-листами.

 

Но для начала расставьте приоритеты - к чему нужно писать тест-кейсы/чек-листы, а к чему нет. Покрыть надо в первую очередь самые важные фичи, если времени не вагон


  • 2
Второй активно используемый ник - Victim

#5 kirill_222

kirill_222

    Новый участник

  • Members
  • Pip
  • 39 сообщений
  • ФИО:Кирилл

Отправлено 31 июля 2014 - 08:46

 

Было принято решение - начать покрывать его тестами, но создавая примеры тест-кейсов задумался об уровне их детализации:

 

Но для начала расставьте приоритеты - к чему нужно писать тест-кейсы/чек-листы, а к чему нет. Покрыть надо в первую очередь самые важные фичи, если времени не вагон

 

Поддержжу данный тезис.
Рекс Блэк и и его книга "Ключевые процессы тестирования" вам в помощь.
Павел, вы сказали 6 человек. А что эти люди из себя представляют?
Это именно группа тестирования или выделенный ресурс разработчиков? 
Функциональному эксперту достаточно чек-листа, джуниору или ленивому программеру нужен подробный тестовый сценарий.
Как обстоит ситуация с описательной моделью этого вашего огромного проекта? 


 


  • 0

#6 PavelKrivosheev

PavelKrivosheev

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Кривошеев Павел Александрович
  • Город:Пермь


Отправлено 01 августа 2014 - 02:57

Доброго утра и удачного дня всем!

 

Было принято решение - начать покрывать его тестами, но создавая примеры тест-кейсов задумался об уровне их детализации:

А кем было принято решение? Какая цель преследуется?

Плясать нужно от этого. Тест-кейсы ради тест-кейсов это перевод кучи времени впустую. Иногда достаточно чеклистов, а иногда и они не нужны.

 

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

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

 

 

 

Было принято решение - начать покрывать его тестами, но создавая примеры тест-кейсов задумался об уровне их детализации:

 

Но для начала расставьте приоритеты - к чему нужно писать тест-кейсы/чек-листы, а к чему нет. Покрыть надо в первую очередь самые важные фичи, если времени не вагон

 

Поддержжу данный тезис.
Рекс Блэк и и его книга "Ключевые процессы тестирования" вам в помощь.
Павел, вы сказали 6 человек. А что эти люди из себя представляют?
Это именно группа тестирования или выделенный ресурс разработчиков? 
Функциональному эксперту достаточно чек-листа, джуниору или ленивому программеру нужен подробный тестовый сценарий.
Как обстоит ситуация с описательной моделью этого вашего огромного проекта? 


 

 

Занимаются только тестированием.

Люди уровня junior, кто-то сильнее, кто-то слабее, кто-то соображает как делать, а за кого то нужно все продумывать.

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

 

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


  • 0

#7 kirill_222

kirill_222

    Новый участник

  • Members
  • Pip
  • 39 сообщений
  • ФИО:Кирилл

Отправлено 01 августа 2014 - 11:00

Расчлените софтину на ряд областей (категорий рисков). Я решил поступить так как показано на скрине.
edb96d2fab9edcbdbceb127d9be052d0.jpg
В красную выделены области ошибка в которых приведет к отказу программы в продакшене, остановки работы предприятия клиента, падению репутации компании и отзыву релиза с рынка.
В желтую и зеленую группе области которые могут пожить в ожидании исправительного релиза.
В синей мало используемый клиентами или не затрагиваемый разработкой функционал.
Помимо этого в багтрекере, есть данные риски заведены, как отдельный реквизит у бага, поэтому возможно проводить срез и видеть где нужно усиливать покрытие.
Соответственно и тесты с нуля нужно начинать создавать для ключевых зон и дальше вниз по ниспадающей.
Помимо этого эта группировка позволяет определять количество прогонов в разных средах и с разными условиями. (web, gui\ sql, postgresql, oracle\ внутренние опции программы). Соответственно соотношение прогонов 4,2,1, эксплоративное тестирование.
По поводу деления на группы. В принципе это разумно, но почему вы не хотите подтягивать отстающих.
Я бы предложил следующую методику, старшие анализируют документацию и создают Чек-лист с описанием проверок. Вы как руководитель анализируете и проверяете на полноту и если, что дополняете и показываете направления развития, после чего документ летит к младшим и они доводят его до состояния детального тест-кейса. Как верно кто то на форуме выразился, тест-кейс это документ отчетности, дак пусть младшие понимают, что их контролируют. От этого качество тестирования только повысится.


 


  • 0

#8 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 04 августа 2014 - 14:07

 

 

Было принято решение - начать покрывать его тестами, но создавая примеры тест-кейсов задумался об уровне их детализации:

А кем было принято решение? Какая цель преследуется?

Плясать нужно от этого. Тест-кейсы ради тест-кейсов это перевод кучи времени впустую. Иногда достаточно чеклистов, а иногда и они не нужны.

 

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

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

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

Идея что более опытные тестировщики пишут кейсы, а менее опытные потом по ним бегают - достаточно хороша.


  • 0



Темы с аналогичным тегами тест-кейс, тесткейс, уровень детализации тестов

Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных