Пособие для консалтеров, внедряющих автоматизацию тестирования ПО.
Для внедрения автоматизации тестирования ПО необходимы всего три вещи:
- Мотивация руководства
- Зафиксированный и работающий процесс тестирования
- Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела
Если чего-то из этого нет - лучше не начинать, на выходе всё равно получится "дохлая лошадь".
Небольшой дисклеймер
Я решил всё-таки написать это неформальное руководство, так как часто рассказывал и рассказываю заказчикам, коллегам и просто менеджерам, которые взялись внедрять автоматизацию тестирования ПО с чего надо начинать и когда автоматизацию внедрять противопоказано. Всё что я пишу, работает для средних и больших проектов. Стартапы и проекты "одного тестировщика" я в этом материале не рассматриваю (угадайте почему).
Про тулы я буду говорить совсем мало, потому что это на самом деле не главное: тул или подходит технологически или нет. Если подходит два тула и оба вендора стоят под дверью в костюмах и с толпой "технологических консультантов" - выбирайте более зрелый тул, как если бы выбирали новую машину. Смотрите на частоту выхода новых версий, на количество плагинов и аддонов, торгуйтесь и смотрите, кто больше сбросит (скидка на лицензии до 40% это не сказка), возьмите триал и задайте 5 одинаковых вопросов в саппорт обоих вендоров, попросите дать вам на две недели технического специалиста, который в вашем присутствии напишет и отладит 5-10 скриптов. Ничего сложного, вы же как-то покупаете новый мобильный телефон или новую машину?
Да, ещё в этой статье я не буду доказывать очевидных для меня вещей: можете верить, можете - нет 
Поехали.
Зачем нужен процесс тестирования, если мы как раз внедряем инструменты?
Нельзя автоматизировать то, чего нет.
Процесс тестирования должен существовать, работать, поддаваться изменениям и анализу, а для этого процесс должен быть зафиксирован письменно и любые процессные изменения должны фиксировать тоже письменно.
На процесс, который строится, ставить автоматизацию сверху нельзя - развалим.
Расписывать не буду - получиться глава книги.
Выделенные под автоматизацию люди
Автоматизация тестирования, как и любой другой процесс автоматизации деятельности не внедряется и не применяется по "остаточному принципу".
Нужно выделенное подразделение для функционального тестирования и выделенные люди для нагрузочного тестирования: у них разные задачи, подходы и часто и инструменты. Тест лабы у них тоже разные, угу.
Когда речь идёт об автоматизации бухгалтерского учёта, почему-то никому в голову не приходит картинка вести часть учёта на бумаге, а часть в системе: тут или взлетели или не взлетели, не сойдётся ведь. С тестированием чуть проще: не всё нужно автоматизировать и можно совмещать ручное и автотестирование - поэтому тут надо быть более категоричным, иначе "не взлетит".
Возможно, где-то есть умельцы, автоматизирующие левой рукой и выписывающие налоговые накладные правой, но это исключения: я не играю в лотереи и вам не советую.
Всё, других аналогий не будет - есть желание проверить и доверить автоматизацию "всем по чуть-чуть" - проверяйте, но пока ни у кого из тех кого я знаю-видел не получилось.
Драйвер процесса
Начнём с близкого и понятного… с фанатов
Фанат дела автоматизации - драйвер процесса, он занимается только этим, но и отвечает головой, премиями и местом. Ему нужно дать все права в рамках подразделения автоматизации и научить огрызаться на любые попытки привлечь его людей куда-то ещё "потому что там горит". Денег надо дать много - тогда будет дорожить местом.
Откуда таких людей брать? Растить внутри или покупать снаружи. Желательно чтобы человек был физически большой (в идеале толстый!) и немного страшный - это только пойдёт на пользу делу: попробуйте спихнуть со стола человека весом более 100 кг, также непросто с ним неаргументированно поспорить.
Зачем и какие права нужны Менеджеру подразделения автоматизации
Как и любому военоначальнику: права возносить, карать и защищать Тут ничего нового с древних времён не произошло и не появилось.
На человеческом языке это звучит так: Менеджер подразделения должен иметь права набирать и увольнять людей, а также давать премии. Если этого нет - он кто угодно, но не менеджер подразделения.
"Все на пожар!"
Толку от такого "тушения пожара" всё равно будет мало - Брукс на эту тему толково пояснил и показал, почему добавление новых людей в опаздывающий проект зачастую только вредит проекту, а вот практика поюзать чужие ресурсы для решения своих проектных проблем удивительно быстро расцветает в любом проектном окружении.
Отсюда ещё одно требование к человеку на роль менеджера подразделения автоматизации (скорее уже личного характера, хотя неплохо бы это и зафиксировать в описании позиции и каком-то формальном "статусе подразделения"): умение послать халявщиков из других проектов у которых "горит". Если проект горит - это проблема менеджера проекта, у которого он горит. В нашем бизнесе никого за срыв проекта не расстреливают - так что не протянуть руку помощи не приравнивается к "неоказанию первой неотложной помощи при аварии", а если погорельца "штрафанут" то это обычно исключительно прочищает мозги и заставляет шевелиться.
Политическая воля и мотивация руководства
Руководство должно являться инициатором и политической волей, которая давит на процесс сверху. Банальный пример - сотрудников занятых в автоматизации не должен иметь права взять никто другой.
Тут у меня есть одно серьёзное допущение и шаткий вывод, в который я верю.
Допущение: руководство - люди умные.
Посчитав деньги (вариант, заставив посчитать менеджера по автоматизации или консалтеров вендора) они поймут какой объем автоматизации должен быть, чтобы экономически внедрение было оправданным и придут к выводу, который разделяю я: внедрять автоматизированное тестирование с честным приобретением лицензий и поддержкой нужно в промышленных условиях, хотя бы в 5 проектах среднего размера в рамках одной компании. Если ваше хозяйство меньше - городить огород можно только в случаях, когда заказчик жить без автоматизации тестирования не может и готов за это дело хорошо платить.
Лошади дохлые, обыкновенные
Разновидности "лошадей" могут быть разными - от формального "ТУЛ установлен на всех компах тестеров" (и что?) до "по результатам пилотного применения на 20 проектах выбран 1, на котором автоматизация достигает 10% тестового покрытия" (то есть покупка лутов и усилия по внедрению не окупяться никогда) - роднит этих лошадей только одно: класс "дохлых".
Если вас не устраивает скачка на "дохлой лошади" - скакать можно, только пахнет не розами - то снова посмотрите в самый верх статьи - условия то простые. Не получается, нафиг её такую автоматизацию, коллеги.
Собственно всё