Любая продуктовая компания, которая выпускает какое-то новое ПО, так или иначе, будет сталкиваться с определенными заблуждениями пользователей и сообщества.
А если программное обеспечение не просто новое, а концептуально новое — подобных заблуждений и мифов становится в разы больше.
Касательно ПО Allure TestOps легенд и мифов достаточно.
В некоторые стоит верить, а некоторые будут развенчаны в данной статье.
Далее разберем 4 наиболее популярных мифа.
Инструмент Allure TestOps
Allure TestOps – это очередная TMS
Наиболее популярный миф.
Традиционно, подобная точка зрения высказывается пользователями, которые не изучали ПО в деталях.
Действительно, традиционной набор функций среднестатистической TMS присутствует в ПО Allure TestOps: разработка тест-кейсов, менеджмент планами тестирования, процедуры назначения тикетов на соответствующих разработчиков/тестировщиков, процедуры прогона тестов и анализ по итогам их выполнения.
Всё это прекрасно функционирует для ручных тестов, а под автоматизацию припасены наборы API-интерфейсов, с которыми запросто можно создавать базовые интеграции для применяемых технологий.
Правда в том, что в случае с Allure TestOps данная функциональность не является основной.
Принципы Allure TestOps выстраиваются на общепринятых основах проверки ПО на основе классического DevOps:
- Все что можно автоматизировать, нужно автоматизировать: начиная с тестов и заканчивая анализом проверок;
- Постоянная обратная связь. Если автотест претерпел изменения, все редакции должны отображаться в технической документации;
- Прозрачность. Каждый прогон проверки должен быть доступен для ознакомления всей команды; документация по тестам должна храниться в хорошо структурированной иерархии.
Подобные основы, которые в полной мере реализованы на основе Allure TestOps, позволяют выстраивать проверку ПО с существенным заделом на будущее.
Использование Allure TestOps означает отказ от использования привычного инструментария
Подобное мнение зачастую рождается выводом из первого мифа — если считать Allure Ops традиционным TMS, рано или поздно придется переезжать с одной системы управления тестами. Но это не так.
Вся правда в том, что хоть больше половины пользователей реально переезжают на TestOps в полной мере, некоторая часть продолжает использовать традиционные инструменты для управления ручным тестированием.
Allure TestOps категорически не подходит командам с ручным тестированием
Мир тематического ПО для тестировщиков еще очень юн и молод.
Масса QA-инженеров уверена, что приобретение всех полезных инструментов — дорогое удовольствие.
Касательно Allure TestOps стоит отметить, что цена данного ПО колеблется в районе 30 долларов в месяц за один персональный аккаунт (один аккаунт — один пользователь).
Дорого ли это?
Далее постараемся разобраться, почему данная оценка кажется вполне приемлемой, через сравнение с некоторыми другими популярными продуктами:
| Название | РРЦ | Цена | Выпуск/Подписка |
|---|---|---|---|
| Allure TestOps | $30 | $300 | Профессиональная |
| TestRail | $34 | $340 | TestRail 1-20 пользователей |
| Qase | $36 | $360 | Бизнес |
| PractiTest | $39 | $390 | Профессиональная |
Любая команда может сама создать свой собственный Allure TestOps
Не очень популярный миф, но он также порой всплывает при упоминании данного ПО.
Но есть существенный нюанс, и кроется он в том, что Allure TestOps выстроен на базе Allure Report, а значит, дабы выстроить что-то подобное, придется:
- Найти подходящую модель информации. Пользователю придется на постоянной основе работать с тест-кейсами, его содержанием и контекстом. Подбор необходимой модели информации является крайне важным шагом, который может существенно повлиять на весь процесс разработки в будущем;
- Создать commons API для обеспечения стабильной интеграций нужными информационными данными. Крайне важно выстроить его универсально, дабы пользователь мог заточить его на проверку back-office, протоколов и их операционного взаимодействия;
- Свыкнутся с надобностью погружения в задачи параллелизации, так как прогнать все автотесты за один поток и спринт не получится.
Итоги
Наш перечень мифов подходит к концу. В завершении хочется дать универсальный совет: как и с любой сложно системой, подбирать операционную платформу для процесса управления качеством необходимо под конкретные цели и задачи.
Но если ваше руководство, либо же вы сами нацелились на Allure TestOps — стоит для начала в тестовом режиме опробовать ПО, и только потом принимать на вооружение.
Оставить комментарий