Тест на вшивость

Процессы в разработке софта печальные, тестируются продукты плохо…

Работаю в довольно крупной компании, занимающейся в числе прочего QA (обеспечением качества). Мне таки есть что сказать об автоматизированном тестировании. Большинство решений в кровавом энтерпрайзе — лютый ад. Конечно же, поскольку автотесты — тот же программный продукт, то для них характерны всё те же проблемы, что и для ПО, только всё ещё печальнее.

Во-первых, квалификация автоматизаторов. Почему-то функциональные тестировщики считают, что человек, занимающийся автоматизированным тестированием, «уже не человек, ещё не программист», программисты в лучшем случае считают автоматизаторов «погромистами», в то время как самих автоматизаторов в целом можно поделить на следующие группы:

1) Бывшие функциональные тестировщики. Эти ребята обычно хорошо понимают процессы QA, но плохо понимают, как этого добиться с помощью имеющегося инструментария, а уж тем более как этот самый инструментарий подобрать исходя из задач. Хуже всего — когда они примеряют на себя роль «очень-крутого-парня-который-теперь-лучше-других».

2) Технические специалисты, уровня знаний которых достаточно, чтобы делать грамотные решения автотестов, но недостаточно для разработки. Как правило, далеки от QA и мечтают вырасти или в менеджеров, или в разработчиков.

3) Автоматизатор-единорог: технически подкован, чётко понимает процессы и задачи QA. В природе практически не встречается.

С таким составом, конечно тоже, можно добиться результатов, но это дело практически такое же лёгкое, как и найти работника из третьей категории.

4) Индусы и примкнувшие к ним. Люди, умудряющиеся сделать предположение, что KDT — это Keyboard Driven Testing, рисующие XPath-локаторы вроде //*[@id='some_id'] и т. п.

Во-вторых, мало кто думает о том, что автотесты — это такой программный продукт, исходный код которого будет переписываться чуть ли не чаще, чем тестируемая система, и поэтому поддерживаемость — один из ключевых факторов. К сожалению, в большинстве случаев код, который используется, не сильно отличается от кода, который генерируют модные и сильно платные рекордеры, то есть порой проще сделать заново, чем исправлять то, что есть.

В-третьих, есть неслабая мода устраивать псевдо-agile, когда тесты пишутся по новой функциональности, а подход в разработке не BDD/TDD (или банально не выделяется времени на поддержку тестов в актуальном состоянии).

Отдельным пунктом идёт замкнутый круг: чтобы получать проекты, нужны хорошие результаты в предыдущих проектах, чтобы были хорошие результаты, нужно выделять на это ресурсы, а выделять ресурсы никому не интересно, потому что эффект от, например, рефакторинга — штука, слабо поддающаяся метрикам, хотя иногда крайне необходимая, но деньги уже получены и распи… распределены.

Может, коллеги меня поправят, и всё не так грустно где-нибудь в другом месте. Пожалуйста…