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

Фотография

Как донести информацию о покрытии тестами


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

#1 Wolonter

Wolonter

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

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 02 ноября 2012 - 10:10

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

Дано:
  • 400 качественных требований в вики
  • баги и таски ведутся в JIRA
  • 600 тестов через интерфейс (Selenium, Java, git)


Задача группы: полное покрытие требований тестами через интерфейс.
Состояние проекта автоматизации: на каждое требование есть тест
Дальнейшие действия: усложнять сценарии.
Вопрос: Как расставить приоритеты?

Я хочу, чтоб на этот вопрос мне ответили аналитики и ручные тестировщики. Они, в свою очередь, спрашивают: "А на что уже есть тесты?"
Проблема: каким образом организовать коммуникацию? Как рассказать всем, на что уже есть тесты?

Уже сделано:
1. Пишутся тесты на дефекты, на области где дефектов много.
2. У каждого теста есть JavaDoc сценарий со ссылкой на требование в вики.
2.1. В требования автоматически проставляются ссылки на работы в JIRA, которые на это требование ссылаются.
2.2. Скоро в каждое требование будет автоматически подтягиваться список тестов на него.

Этого мало.

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

Но у вас наверняка есть свои версии на все эти счета?:)
  • 0

#2 kitsune

kitsune

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

  • Members
  • PipPip
  • 137 сообщений
  • ФИО:Полина Антипова
  • Город:Санкт-Петербург

Отправлено 02 ноября 2012 - 13:44

Магические слова - матрица покрытия требований.

Как бы я решала задачу.
У нас есть три списка:
* Список1 документы-требования в вики
* Список2 документы-требования в джире
* Список3 - тесты (еще где-то)

Нужно:
* В любой момент получать статистику для скольких элементов из списков 1 и 2 есть элементы в списке 3
* Из любого элемента списков 1 и 2 попасть в элемент списка3

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

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

Минус хранения в списке3 в том, что не будет статистики по документам-требованиям, на которые тестов еще нет.
  • 0

#3 negro

negro

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

  • Members
  • PipPip
  • 102 сообщений
  • ФИО:Себастьян Переро
  • Город:Скотопригоньевск

Отправлено 02 ноября 2012 - 18:47

Дано:400 качественных требований в вики;баги и таски ведутся в JIRA;600 тестов через интерфейс (Selenium, Java, git)
...
Задача группы: полное покрытие требований тестами через интерфейс.

1. Хорошо если ваши 400 качественных требований ассоциированы c use-case (ранжированы по рискам, важности и т.п.), ещё лучше, если ваши 600 тестов ассоциированы с test-case, совсем прекрасно если вы и все тестеры отлично знаете прикладную область, архитектуру системы, её информационную структуру, событийную модель интерфейса... Раз вы сказали, что ваши требования качественные, - это здорово, - значит вы их протестировали и как минимум уже заготовлены чек-листы...
2. Похоже ваша система сложная. А вы уверены, что ваша задача полного покрытия требований достижима? Хорошо себе представляете расчёт метрики, не путаете с покрытием функциональности, опирающейся на покрытие кода?
3. Что будет с вашей первой сигнальной системой, если смешать зелёный и жёлтый? Однако, какие капризные у вас тестеры и аналитики...
  • 0

#4 Wolonter

Wolonter

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

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 03 ноября 2012 - 11:14

* Список2 документы-требования в джире


В JIRA только такси и баги. Таска = часть требования. Или два требования. Или две части требования. Мне надо было уточнить.

Нужно:
* В любой момент получать статистику для скольких элементов из списков 1 и 2 есть элементы в списке 3


Вот! Это максимум того, что мы придумали.

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

Этого мало? Этого достаточно? Ящетаю, что все равно нужен анализ теплым человеком с целью определения достаточности покрытия и рисков. И этот человек - не разработчик и не автотестер.
  • 0

#5 Wolonter

Wolonter

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

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 03 ноября 2012 - 11:22


Дано:400 качественных требований в вики;баги и таски ведутся в JIRA;600 тестов через интерфейс (Selenium, Java, git)
...
Задача группы: полное покрытие требований тестами через интерфейс.

1. Хорошо если ваши 400 качественных требований ассоциированы c use-case (ранжированы по рискам, важности и т.п.), ещё лучше, если ваши 600 тестов ассоциированы с test-case, совсем прекрасно если вы и все тестеры отлично знаете прикладную область, архитектуру системы, её информационную структуру, событийную модель интерфейса... Раз вы сказали, что ваши требования качественные, - это здорово, - значит вы их протестировали и как минимум уже заготовлены чек-листы...
2. Похоже ваша система сложная. А вы уверены, что ваша задача полного покрытия требований достижима? Хорошо себе представляете расчёт метрики, не путаете с покрытием функциональности, опирающейся на покрытие кода?
3. Что будет с вашей первой сигнальной системой, если смешать зелёный и жёлтый? Однако, какие капризные у вас тестеры и аналитики...


1. Ассоциированы. По рискам не ранжированы. В каждом требовании есть пустое поле TestCase (лень заполнять). Прикладную знают аналитики. Архитектуру программисты и автотестеры. Информационную структуру тестеры и аналитики. Событийную модель автотестеры, аналитики и разработчики. Чеклисты не создавались, но это не моя кухня.
2. Система для меня - сложная. Полное покрытие недостижимо, но стремиться надо, для минимизации риска рекгрессии, который высок, так как связность кода высокая, следавательно покрытие кода мало кореллирует с покрытием функциональности.
3. Эээ, будет синий?:) Самые капризные - автотестеры.
  • 0

#6 negro

negro

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

  • Members
  • PipPip
  • 102 сообщений
  • ФИО:Себастьян Переро
  • Город:Скотопригоньевск

Отправлено 03 ноября 2012 - 21:17

1. ...Архитектуру программисты...
2. Система для меня - сложная. Полное покрытие недостижимо, но стремиться надо, для минимизации риска рекгрессии, который высок, так как связность кода высокая, следавательно покрытие кода мало кореллирует с покрытием функциональности.

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

#7 Wolonter

Wolonter

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

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 05 ноября 2012 - 08:43

Допустим вам ответ очевиден, но не замахнуться ли вам на рефакторинг?


Я лид автотестеров, я не хочу замахиваться на рефакторинг приложения, я хочу кейсы, по которым надо писать тесты.
Ну то есть вернуться к изначальной задаче - "Как донести информацию о покрытии тестами".
  • 0

#8 neman

neman

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

  • Members
  • PipPip
  • 142 сообщений
  • ФИО:Антон


Отправлено 05 ноября 2012 - 13:08

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

Ну, изначальная то задача о приоритезации тестов на требования. В связи с этим вопрос - почему нельзя спросить у тех автотестеров, кто еще вчера работал ручным тестировщиком, благо такие у вас есть? 400 требований-то не вчера появились, так что use-cases первого приоритета вряд ли сильно поменялись. Вот вам и "междумордие" (классное слово кстати).
  • 0

#9 negro

negro

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

  • Members
  • PipPip
  • 102 сообщений
  • ФИО:Себастьян Переро
  • Город:Скотопригоньевск

Отправлено 06 ноября 2012 - 00:17

Задача группы: полное покрытие требований тестами через интерфейс.
Состояние проекта автоматизации: на каждое требование есть тест
Дальнейшие действия: усложнять сценарии.
Вопрос: Как расставить приоритеты?
Я хочу, чтоб на этот вопрос мне ответили аналитики и ручные тестировщики. Они, в свою очередь, спрашивают: "А на что уже есть тесты?"
Проблема: каким образом организовать коммуникацию?
...Моя версия - выделить специально обученного мануал тестера, обучить тест дизайну для автоматизации и сделать его междумордием...


Судя по вашим словам ни аналитики, ни ручные тестеры о вашей автоматизации ранее ничего не слышали, вы с ними свою деятельность не согласовывали, им ваша автоматизация по-барабану.
Из этого следует вопрос: для чего/кого существует и кому в помощь были созданы 600 тестов?
И почему вдруг сейчас, когда вам захотелось усложнять сценарии, расставить какие-то приоритеты... с какого перепугу это за вас должны сделать аналитики и ручные тестировщики, на хрена им надо это и ваша навязчивая коммуникация?
Междумордие - это между вашей и чьей? Не распространяйте самооценку на других людей, особенно на тестеров - это такие ребята, на которых как сядешь, так быстро и слезешь.
  • 0

#10 kitsune

kitsune

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

  • Members
  • PipPip
  • 137 сообщений
  • ФИО:Полина Антипова
  • Город:Санкт-Петербург

Отправлено 06 ноября 2012 - 07:56

В JIRA только такси и баги. Таска = часть требования. Или два требования. Или две части требования. Мне надо было уточнить.

Это без разницы, называйте элемент из списка тестируемых элементов как угодно.
В данном случае "требование" - некая сущность НА КОТОРУЮ пишутся тесты. Каждый тест проверяет "требование" или часть "требования". Требования внутри себя могут делиться на какие угодно типы, для рисования матрицы покрытия это не оч. интересно.


Нужно:
* В любой момент получать статистику для скольких элементов из списков 1 и 2 есть элементы в списке 3


Вот! Это максимум того, что мы придумали.

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


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

Тогда нужный Вам анализ смогут делать люди, не вникая в список полностью.

Вообще, я бы хотела матрицу такого формата (в экселе, конечно же).

ID + cабжект "требования" | Дата последнего обновления "требования" | ID + сабжект теста | Дата последнего обновления теста

+ две кратких инструкции - как по ID локализовать любой из элементов матрицы (буквально, на какой url пойти и что искать).

Если при этом список "требований" содержит еще и непокрытые - всё оч шоколадно.
У Вас естественным образом появляется три списка:
  • непокрытые требования
  • требования, требующие обновления (дата последнего обновления больше чем у тестов)
  • требования, требующие анализа качества покрытия (вот тут как раз - достаточно ли сюда 6 тестов, не много ли это - 6 тестов)

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

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

#11 kitsune

kitsune

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

  • Members
  • PipPip
  • 137 сообщений
  • ФИО:Полина Антипова
  • Город:Санкт-Петербург

Отправлено 06 ноября 2012 - 08:00

Есть у меня проблема, хочу спросить совета в решении.

Задача группы: полное покрытие требований тестами через интерфейс.
Состояние проекта автоматизации: на каждое требование есть тест
Дальнейшие действия: усложнять сценарии.
Вопрос: Как расставить приоритеты?

Я хочу, чтоб на этот вопрос мне ответили аналитики и ручные тестировщики. Они, в свою очередь, спрашивают: "А на что уже есть тесты?"
Проблема: каким образом организовать коммуникацию? Как рассказать всем, на что уже есть тесты?


Я перечитала изначальный вопрос.

Эмм, приоритеты чего Вам должны расставить аналитики и ручные тестировщики?
  • 0

#12 Wolonter

Wolonter

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

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 06 ноября 2012 - 09:23

почему нельзя спросить у тех автотестеров, кто еще вчера работал ручным тестировщиком, благо такие у вас есть?


Таких нет. Так уж сложились обстоятельства.
  • 0

#13 Wolonter

Wolonter

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

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 06 ноября 2012 - 09:26

Судя по вашим словам ни аналитики, ни ручные тестеры о вашей автоматизации ранее ничего не слышали, вы с ними свою деятельность не согласовывали, им ваша автоматизация по-барабану.
Из этого следует вопрос: для чего/кого существует и кому в помощь были созданы 600 тестов?
И почему вдруг сейчас, когда вам захотелось усложнять сценарии, расставить какие-то приоритеты... с какого перепугу это за вас должны сделать аналитики и ручные тестировщики, на хрена им надо это и ваша навязчивая коммуникация?
Междумордие - это между вашей и чьей? Не распространяйте самооценку на других людей, особенно на тестеров - это такие ребята, на которых как сядешь, так быстро и слезешь.


Для программистов, все автоматизированное тестирование происходит до попадания билда в руки тестеров и аналитиков.

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


Простые кейсы исчерпаны.

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


Не должны. Но мы всесте пилим продукт и хотим сделать хорошо.

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


Я вас чем-то задел? Извините.
  • 0

#14 Wolonter

Wolonter

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

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 06 ноября 2012 - 09:28

Вообще, я бы хотела матрицу такого формата (в экселе, конечно же).

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


Спасибо, интересно, я подумаю.
  • 0

#15 Wolonter

Wolonter

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

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 06 ноября 2012 - 09:30

Эмм, приоритеты чего Вам должны расставить аналитики и ручные тестировщики?


Все тех же требований - на какие постановки стоит первыми начать сложные кейсы.
  • 0

#16 ch_ip

ch_ip

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

  • Members
  • PipPipPipPipPipPip
  • 1 097 сообщений
  • ФИО:Павел Абдюшев
  • Город:Москва


Отправлено 06 ноября 2012 - 19:59

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

Как вариант, сделать ID гиперссылками сразу.
Если делать не в экселе, а в гуглодоках будет легко расшарить документ на всех и редактировать совместно.
  • 0

#17 kitsune

kitsune

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

  • Members
  • PipPip
  • 137 сообщений
  • ФИО:Полина Антипова
  • Город:Санкт-Петербург

Отправлено 07 ноября 2012 - 08:01

Если делать не в экселе, а в гуглодоках будет легко расшарить документ на всех и редактировать совместно.


В моем идеальном мире матрица собирается автоматически, ее вручную редактировать не надо, надо редактировать элементы, из которых она состоит.
  • 0

#18 kitsune

kitsune

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

  • Members
  • PipPip
  • 137 сообщений
  • ФИО:Полина Антипова
  • Город:Санкт-Петербург

Отправлено 07 ноября 2012 - 08:18

Все тех же требований - на какие постановки стоит первыми начать сложные кейсы.


На вопрос "что кому-то другому делать?" очень сложно ответить.

Можно зайти с другой стороны.

У тестеров попросить инфу, какие области наиболее рискованные ("В какой функциональности в каждом релизе Вы находите больше всего багов? В какой функциональности Вы находите больше всего критичных багов?")

У четырех сотен вики-требований наверняка есть свои родные приоритеты. Принять их как данность.
Если их нет, выбрать для себя приятный порядок следования (по алфавиту, по дате добавления, начиная с наиболее свежих, итд.) и пойти по нему.

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

#19 _Yura

_Yura

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

  • Members
  • Pip
  • 50 сообщений
  • ФИО:n/a

Отправлено 07 ноября 2012 - 19:31

Если делать не в экселе, а в гуглодоках будет легко расшарить документ на всех и редактировать совместно.

С Google spread_shit_ есть одна проблема - сейчас он поддерживает аж полтора события :( - onOpen и onEdit, так что если есть возможность работать с расшаренным экселевским, я бы выбрал его
  • 0

#20 negro

negro

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

  • Members
  • PipPip
  • 102 сообщений
  • ФИО:Себастьян Переро
  • Город:Скотопригоньевск

Отправлено 11 ноября 2012 - 21:24

kitsune, чтобы, не флудить, типа:

У тестеров попросить инфу, какие области наиболее рискованные ("В какой функциональности в каждом релизе Вы находите больше всего багов? ...")

будьте внимательнее, например, следует увидеть в постановке/описании вопроса автора:

Уже сделано: 1. Пишутся тесты на дефекты, на области где дефектов много.

То, что вы советуете автору о расстановке приоритетов (упорядочить) требованиям:

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

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

Продумать, как мотивировать выбранный порядок

мне непонятно, кто заслужил такое счастье - мотивировать и быть мотивированным для достижения этой нетривиальной мысли.
Нет ли в вашем идеальном мире ещё каких-нибудь парадоксов?
  • 0


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

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