Как стать автором
Обновить

Комментарии 23

Наверно, в процессе грумминга вы удостоверяетесь насколько задачи соответствуют DoR и DoD? А то из текста следует, что вы для каждой задачи свои DoR и DoD составляете.
Привет! У нас есть шаблонные DoD и DoR для задач, но на грумминге мы определяем есть ли еще что-то, что туда можно добавить.
Спасибо за статью!
Мы используем MBT и graphwalker.
— сразу распишите, какие модули допиливать в самом graphwalker, т.к чистый инструмент нас не устроил и пришлось дорабатывать.
Плюс про визуализатор обхода.
почти уверен, что они дорабатывали все)))
Да, конечно напишем. Работа была проделана не маленькая.
Спасибо за рекомендацию, попробую!
Статья ни о чем… «У нас есть грумминг, mind maps и заглушки». Да, да, как и в других 100500 компаниях.
Спасибо за отзыв. Я правильно понимаю, что вам не хватило конкретики в статье?
Не хватило новизны, нестандартности, интересных решений — всего того, что хочется почерпнуть на Хабре. Ваша статья больше похожа просто на пиар Автотеки — мы есть, мы тестируем.
В остальном мы используем обычные инструменты для тестирования: API тесты связкой Kotlin+JUnit+RestAssured

Чем обусловлен выбор этого стека? Во-первых, компилируемый язык плохо подходит для тестов, во-вторых, джавы в холде на техрадаре.

Почему вы считаете, что компилируемый язык плохо подходит для тестов?
Java в холде на техрадаре, но есть Kotlin (пынь).

Есть, но в андроиде, тут же речь не о нем, как я понял.


Почему вы считаете, что компилируемый язык плохо подходит для тестов?

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

На вкус и цвет, как говорится. Некоторым нравится использовать «знания об огромном джава мире» в тестах. К тому же, часто стек автоматизации подбирают под стэк разработки. Чтобы плотнее могли взаимодействовать девелоперы и тестеры.
часто стек автоматизации подбирают под стэк разработки

Да, это хороший аргумент. Но в данном случае как раз джавы/котлина в стеке нет

По поводу техрадара, там нет раздела QA, он на этапе формирования. Спасибо за замечание.
По поводу стека для api тестов, выбор был обоснован, по большей части, уже имеющимися UI тестами на Kotlin (к моменту моего прихода в компанию) и моим собственным опытом разработки подобных фреймворков с использованием этого языка.
На счет обязательного использования скриптовых языков для написания тестов — не соглашусь, но думаю любые мои аргументы в пользу компилируемых языков неизбежно приведут к холивару который закончится ничем.

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


А что за UI тесты на котлине? Graphwalker+Android или ещё что-то?


На техрадаре нет раздела QA, потому что его оттуда выпилили и он там, имхо, не нужен. Все можно закинуть в имеющиеся разделы.


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

Если честно — не увидел хорошего аргумента, не могли бы его привести?

Про UI тесты на Котлине с использованием Graphwalker будет отдельная статья. Пока не буду спойлерить.

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

Что вы имеете ввиду под формулировкой — такие же тесты?
Запускаем через Teamcity.

Я про вот этот комментарий


Не думаю, что добавлять технологии используемые в тестировании в раздел Backend или еще…

Я бы просто не стал отделять тестирование от разработки.


Что вы имеете ввиду под формулировкой — такие же тесты?

Функциональные e2e. Апи или UI – не так важно.


Запускаем через Teamcity.

В тимсити только кнопка нажиматся, главная магия всегда не в нем :)

Я бы просто не стал отделять тестирование от разработки.

Неплохой вариант.

Функциональные e2e. Апи или UI – не так важно.

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

В тимсити только кнопка нажимается, главная магия всегда не в нем :)

Да, все именно так. С помощью Maven запускаем тесты с использованием JUnit. Тимсити JUnit report отлично умеет парсить и показывать в читаемом виде, того что здесь написано — хватит для первоначальной настройки.

Привет

Наткнулся на ваш форк GraphWalker и на эту статью. Вижу что форк давно не обновлялся, плюс статьи про MBT так и не было. Подскажите пожалуйста как у вас сейчас с этим обстоит.

Здравствуйте! Отказались от MBT в итоге из-за высокой сложности и порога входа. То есть условно, для маленького проекта, каким была Автотека на тот момент - это было норм. Но для Авито например, или даже для текущей Автотеки это слишком сложно поддерживать, а профита сильного нет по сравнению с обычным подходом.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий