В общем для планирования времени и красивых Burn down диаграмм в компании поголовно призывают созадвать сабтаски в Jira на виды деятельности более 1 часа. Например “настроить окружение”, “написать тесткейс такой то”, “выполнить тесткейс такой то”, “написать новый cucumber test”, “запустить автотесты и проверить их результат” (CI еще не толком не настроен, но автотестов уже много, так что запускаем пока вручную).
И есть у нас система тест менеджмента Zephyr. Тестировщики в даннымй момент создают пустой тест для каждой юзерстори, просто линкуют. Потом в ходе тестирования пишут его, выполняют. Думаем, то ли сделать эти тесты сабтасками, но с другой стороны это вроде бы не полное соотвествие и немного отличная по смыслу вещь. Так как есть еще и test execution тикет в Zephyr, и он нужен для построения некоторых отчетов по test coverage и т.д.
Создание дополнительных “пустых” сабтикетов для треканья времени и для планирования времени на тестирование в таком случае выглядит немного бюрократично и излишне.
Хочется услышать кто как работает у себя, какие плюсы и минусы в том или ином подходе.
На мой взгляд все что вы написали выглядит излишне бюрократично. Вам нужно задать вопросы Зачем? и Что это даст? Для чего я это делаю?
Для планирования времени вам помогут сабтаски? Ради красивых диаграм все сотрудники будут делать бесполезную работу аля создать пустой тест? У вас так жестко подходят к треканью времени?
У меня возникло больше вопросов, чем ответов.
У нас на каждую таску писали много мелких тестов. Создавать на каждый тест сабтаску - нереально, их просто линковали.
Далее, делали сабтаску с типом Test Execution, и в ней отмечали время и результаты.
Разбивать на сабтаски не более 1 часа, имхо, лишняя работа, т.к. burndown-чарты прекрасно получаются, если просто в одной таске на несколько часов поэтапно списывать использованное время.
Зачем - для планирования и оценки времени, чтобы ничего не забыть, чтобы все процессы по тестированию были видны и учтены, чтобы времени хватало и нас не заставляли в одном спринте тестировать объем задач условно на два спринта.
Имелось в виду на 1 фичу (user story) делать разные subtasks. И разработчикам и тестировщикам. Сабтаски менее 1 часа не указывать, может быть даже менее 2 часов и более часов. Просто не знаем что тогда с тестами делать, которые и так линкуются к каждой фиче, но просто как “related”, а не сабтаска, таким образом время трудозатрат на сабтаску не совсем правильно считается. Бюрократия не нужна, но какой то порядок и процесс нужен.
Очень трудно будет по тестам считать трудозатраты, т.к. они не равноценные.
У нас точно так же внутри фичи создавали отдельные сабтаски на разработку разных кусков, на тест-дизайн, тестирование и местами на автоматизацию.
Оценка работала так: на митинге по планированию задачам ставился Estimated time на основании опыта тестировщиков, потом ежедневно отмечали потраченное время. Конечно, в итоге были расхождения. Но фичи были более-менее одного типа, и очень быстро научились давать адекватные эстимейты.
Спасибо за ответ, можно еще раз подробней и может даже со скринами? =)))
У вас какая тест-менеджмент система была? Тоже Zephyr? Тесты из тестменеджмент системы вы сделали сабтасками или к юзер стори у вас был сабтаск и уже в ходе его выполнения вы линковали тесткейс готовый к стори? А test execution тикеты вы использовали? В общем в идеале поподробней напишите, прямо все-все-все =)
таски, подтаски, зефиры, и.т.д. это инструменты, которые нужны вам для учета и анализа
а для планирования всех активностей нужно: начинаем с тест плана, где указано в целом какие тестовые активности будут на проекте, и в последствии эстимейт каждой задачи - вот с этим у вас и проблемы, как мне показалось. Как делать эстимейт? что в него входит? Сейчас создаётся впечатление, что на планнингах вы делаете эстимейт задачи основываясь только на времени выполнения проверок. А есть время на дизайн тестов, на документацию, закладывается риски и.т.д. Думаю вам нужно рыть в эту область и тогда станет яснее как это отображать в Зефире.
Я не хочу отображать все-все-все в Зефире, я хочу его использовать только как репозиторий тестов и их прогонов (может быть, это тоже немного под сомнением). На планировании мы учитываем все, и настройку окружения, и написание тескейса и изучение новой фичи. Но теперь надо научится это правильно разбивать на подзадачи, без лишней головной боли. Проект не сервисный, внешнего заказчика нет, спринты по 2 недели.
Простите, Татьяна, но я наоборот специально стараюсь писать самые очевидные моменты, потому что раскрывать детали процессов не имею права.
У нас полностью кастомизованная джира, и админы настраивают любой процесс на заказ. Но по описанию, в плане организации тестов и формирования заданий на тестирование, Zephyr позволяет делать очень похожие вещи.
testomat.io управление авто тестами