Для того чтобы ускорить тестирование крупных приложений, как правило, проверки вручную сочетают с автотестами. После их прогона SDET-специалисты разбирают успешные и «упавшие» тесты – их нужно проверить вручную и зафиксировать результаты, например, в Confluence.

Рассмотрим на примере, как можно ускорить экспорт этих данных, если вы работаете с некоммерческой версией Allure Framework. При использовании Allure-EE такие доработки не нужны – информацию по ручному прохождению кейсов можно хранить в самих отчетах. 

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

Всем привет. Как часто вам нужно разрабатывать сотни авто тестов и предоставлять заинтересованным лицам отчеты с результатами? Лично мне очень часто. В этом мне помогает Anna.

Привет. Меня зовут Николай, я QA Automation Engineer в мобильной платформенной команде Delivery Club. Эта статья будет о том, как мы интегрировали Allure TestOps (далее Allure TO) в регрессионное тестирование нескольких мобильных приложений и ушли от TestRail. Альтернативу TestRail выбирали мои коллеги, и эту часть мы упомянем вскользь.

Этот материал будет интересен тем, кому предстоит интегрировать мобильные автотесты в Allure TO и хочется узнать про потенциальные проблемы. А также, возможно, тем, кому не полностью подходят стандартные сценарии использования этой TMS. Цель статьи — не дать конкретное решение, а продемонстрировать наш сценарий использования нетипичных возможностей TMS с небольшими вставками кода.

Совсем недавно я услышал замечательную историю о проекте внутри крупной российской IT-компании, ищущей руководителя в отдел тестирования. Задача была простая: есть отдел из 20 человек, которые за последние несколько лет наколбасили несколько тысяч автотестов и спроектировали пачку тестов ручных. В целом все работало, но СТО на собеседовании сказал примерно следующее: “Ваша задача — выкинуть все это к чертям собачьим и сделать нормально. А то когда предыдущий QA Lead ушел, мы поняли, что вся эта инфраструктура у нас нигде не используется.” 

Ситуация невообразимая. Так не бывает. У нас точно не так. У нас же не так? 

Проблема “works on my machine” и “ответственность за нерабочий код лежит на том, кто его деплоит” ровно о том же. И пока разработчикам рассказывали про спасительный DevOps, тестировщики и QA-специалисты как-то со стороны смотрели на это “не шаля, никого не трогая, примус починяя”. Ну что, пришло время набросить и на этот вентилятор.

В этой статье мы с Артемом Ерошенко из Qameta Software попробуем разобраться, что такое “делать тестирование нормально” в новых проектах и какие инструменты могут в этом помочь.