Про чеклисты - используйте excel или поищите плагин для Jira. Управлять и поддерживать актуальность чеклистов на порядок проще чем выполнять всё то же для тест кейсов. Поскольку кроме Вас никто не читает тест план, то и забудьте про TMS, тем более в agile. Если желание понаступать на грабли не исчезло - устанавливайте MS Test Manager.
Две рекомендации: раз часто ошибаешься со временем, логично будет в будущем называть оценку + ошибку; при выполнении важных задач как только понимаешь что в срок не уложиться, сообщай об этом начальству с объяснением причин (перечисляй факты, которые не были учтены).
Про виртуоза то понятно, никто из нас тут не Паганини =) А вот из профессионалов Вы себя зря вычеркиваете, тем более с таким настроем как "хочу чтобы моя работа приносила еще больше пользы". Еще несколько вопросов для лучшего видения вашего процесса:
- чем куют программисты? Visual Studio?
- какие management системы уже используются в проекте? Task Management, scrum management, bugtracker.
- в каком агрегатном состоянии пребывают требования? твердом, жидком или газообразном?
- кто кроме Вас смотрит тестовую документацию? Программисты, менеджеры, директора, заказчики?
- как быстро меняется код/требования/продукт(ы)?
PS: на данный момент мое впечатление такое:
1. Вам НЕ нужен TMS
2. Вам нужно заменить тест кейсы на чеклисты, при этом в тест кейсы переводить только часть неизменных идей (для внешней отчетности)
3. Для уменьшения bugrate'а Вам нужно улучшать процесс, желательно без привлечения дополнительных программных средств (типа TMS). Для этого сначала проанализируйте и запишите источники дефектов и проблем в проекте.
4) Эта задача решается без TMS. Поясню. TMS неспособно посчитать эффективное время выполнения теста. Время на чай для неё ничем не отличается от времени работы с тестируемым приложением. Всё что она сможет - это зафиксировать время старта и окончания прогона теста (либо метка времени на каждый шаг теста). По моим наблюдениям на практике эта информации бесполезна, т. к. если даже Вы не пьете чай, то отвлекаться на баги или просто уходить в сторону от сценария приходится почти всегда в ручных тестах. Таким образом один и тот же тест может гоняться час, два или целый день. Мой совет - классифицируйте тесты по времени выполнения на этапе их создания. Причем разбивайте грубо, точность до минут никому не нужна при таких погрешностях: 1 час, полдня, день, долгие тесты. Тогда не составит труда вычислить временную сложность тест плана или отдельной секции. Дальше - больше. Приоритезируйте тесты хотя бы на: критичные и необязательные, тогда получите и минимальное время на прогон плана. Это действительно полезная информация.. А на вопрос "сколько займет времени тестирование новой версии" лично я всегда отвечаю "от пары минут до бесконечности" =) Каков вопрос, таков и ответ. Итого: не нужно Вам с помощью TMS отслеживать среднее время прогона тестов, вместо этого клеймите тесты метками временной сложности еще на этапе создания.
5) Ну если так, то подходящий ответ - "Все умеют это". В смысле все TMS имеют поля для заголовков/целей/ID/авторов/статусов и пр., а также плюсики для добавления шагов. Вероятнее всего в любом из существующих UI Вы найдете плюсы и минусы, тут просто дело привычки. Итого: забейте на данный критерий. Он условно выполним для всех TMS.
@Lerg для объективной оценки посмотрите на ценник и со стороны исполнителей на uTest - за признанный баг дают от 5$. А вообще для независимого разработчика краудтестинг априори не по карману.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.