Какую систему управления тестами использует ваш QA-отдел?

Просто ради интереса - зачем QA отличаться от простого программера при раьоте с кодом в виде тестов?

sim3x,

Приходит задача: "Мы готовим релиз новой версии АПИ, запилили туда 30 новых задач, надо проверить, что все окей".

Отдел тестирования проверяет, что в релиз вошли все 30 задач. А потом делает проверку, что основные (старые) функции АПИ не отвалились. Естественно, никто не помнит уже, что там было, и с какими особенностями.

Открывается специальная программа TMS, открывается вкладка по типу "Релиз АПИ", там содержатся все кейсы (описание ситуации, описание шагов, описание результата), которые должны работать. Вот тестеры тест за тестов прокликивают все руками и дают прув, что релиз готов.

Естественно, там можно сделать так, чтобы шел авто-тест на селениуме, тесты которые прошли, он автоматически закрывал, а те, что давали ошибку - отмечались файлом. И после окончания автопрогона тестер уже ручками прокликивает то, что упало и дает таски прогерам на фикс релиза.

В общем, система управления тестами - это типа jira + документация + крон для тестеров.

TMS - это не про написание тестов в виде коде, а написание тестов в виде слов и последовательностей.

Сергей Нижний Новгород,
А почему разраб в конце (в начале) своего рабочего дня не отправит задачу на сервак со своей веткой и не прогонит все (те не только со своим кодом) тесты, а потом сам не разгребет ошибки?

sim3x, во-первых, всегда есть вероятность, что упадет что-то "необычным способом", что-то в интеграционном слое, что-то в UI элементе.

во-вторых, чтобы что-то прогнать в конце дня, дня начала это нужно иметь. Но это уже лирика

Сергей Нижний Новгород,
Для UI в любом случае нужно иметь хоть автокликер

Идеальная схема - тестер или менеджер, который разобрался в ТЗ пишет функциональный тест
Коммитит его и пишет задачи
Разрабы расхватывают задачи, пишут юнит тесты, потом код
Вечером - мердж и отправка на тесты
Утром разбор падений

гуглотаблицы, мэээн.
Все плохо...