Как мы НЕ автоматизировали тестирование

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

Итак, ситуация: большой проект, написанный на JAVA; большая распределённая команда - бОльшая часть разработчиков и тестеров на нашей стороне, аналитики и практически всё начальство (тестерское и не только) на стороне немцев. 

О первой идее внедрить автоматизацию я знаю мало, т.к. она появилась до моего прихода на проект. Я услышала о ней случайно и в общих чертах узнала, что: у нас вроде как должна быть автоматизация; для неё немцами был куплен инструмент - QARun (который, говорят, не слишком нам подходил, т.к. не поддерживал какие-то наши компоненты). Вот только не было никаких явных указаний и никакой генеральной линии партии в смысле автоматизации. Поэтому я установила себе QARun, немного с ним поразбиралась, немного что-то для себя пописала, но т.к. у меня хватало другой работы, а автоматизацию никто явно не требовал, этим всё для меня почти и закончилось (были ещё какие-то трепыхания, но ничего особо выдающегося или интересного). Так что из этой попытки я делаю для себя такие выводы:

Вывод-1 (элементарный): если автоматизацией не заниматься, то никакой автоматизации не получится, даже если специально для неё купить инструмент :)

Вывод-2: при выборе инструмента важно оценить, насколько он подходит (или может быть адаптирован) под тестируемое приложение.

Вторая попытка была гораздо интереснее, возможно, потому, что инициатива исходила не от немцев (но с их одобрения). В качестве инструмента был найден Marathon - бесплатный и, вроде, заточенный под Java. Также был выделен программист, который не только писал скрипты сам (по предоставленным ему сценариям), но и описывал какие-то общие и доступные всем функции и методы. На нас никто не давил, мы могли писать скрипты по своим нуждам и своему разумению, и  - о, чудо! - даже заработали несколько первых моих скриптов. К сожалению, продлилось это всё недолго - сначала на проекте перешли на новые версии компонентов, и скрипты начали ломаться; а потом об автоматизации снова заговорили немцы и Marathon сразу забраковали, поскольку он бесплатный, что как минимум означает потенциальное отсутствие поддержки данного инструмента. И выделенного программиста по каким-то причинам забрали. Примерно так вторая попытка и закончилась, а выводы мои таковы:

Вывод-3: не всегда хорошо, когда используемый инструмент бесплатен; в определённых условиях бесплатные инструменты могут быть сочтены неприемлемыми.

Вывод-4: хорошо, когда созданием фреймворка для автоматизации занимается человек, имеющий представление о программировании.

Вывод-5: автоматизация должна быть своевременной (либо глобальные изменения в проекте должны быть своевременными :) )

Итак, третья попытка - началась с того, что про автоматизацию снова заговорили немцы. Ими был выбран и куплен инструмент - теперь TestPartner. И они даже вызвали несколько наших тестеров в Германию - для прохождения обучения. Звучало неплохо, однако по приезду какой-то немецкий практикант, разбиравшийся с этим инструментом уже около месяца, рассказал нам, как TestPartner установить и запустить, на чём обучение, можно сказать, было закончено :) До конца командировки от нас потребовалось показать немцам, что мы в принципе можем написать какие-то скрипты. И какие-то скрипты мы написали :)

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

Итого - у нас были разнообразные трудности, при этом немцы постоянно требовали от нас результаты. Самым реальным в данной ситуации казалось начать с того, чтобы объяснить немцам, что на автоматизацию нужно выделенное время. И в конце концов немцы отреагировали - приняли решение снять задачу автоматизации с нашей группы и возложить её на каких-то немецких практикантов - насколько мне известно, временных и бесплатных :) 

С тех пор судьба автоматизации стала для меня загадкой - происходящее на проекте никогда не было прозрачными для всех. В некогда регулярных отчётах немецкого начальства я встречала информацию о количестве автоматизированных сценариев - почти неизменном и незначительном. Возможно, кто-то что-то автоматизировал, и возможно - даже на том уровне, который немцев и удовлетворил, однако меня по этому поводу терзают смутные сомнения :) А я делаю для себя следующие выводы:

Вывод-6: хорошо, если сотрудники проходят обучение перед началом внедрения автоматизации, но важно, чтобы обучение было настоящим.

Вывод-7: будущим автоматизаторам желательна хотя бы минимальная подготовка в смысле программирования.

Вывод-8: необходимо, чтобы у автоматизации были чётко поставленные цели.

Вывод-9: желательно автоматизировать сценарии, пригодные для автоматизации.

Вывод-10: на реализацию автоматизации необходимо специально выделенное время.

Вывод-11 (главный): к автоматизации следует подходить серьёзно, это по сути самостоятельный проект, успешная реализация которого требует значительных усилий и хорошей организации.

P.S. Ох и сложно после отпуска войти снова в обычное русло, тем более - начать писать что-то чуть менее легкомысленное, чем впечатления от отпуска в своём ЖЖ :)