Home

Автор: Панкратов Вячеслав

Оригинальная публикация

Для внедрения автоматизации тестирования ПО необходимы всего три вещи:

• Мотивация руководства
• Зафиксированный и работающий процесс тестирования
• Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела

Если чего-то из этого нет – лучше не начинать, на выходе всё равно получится «дохлая лошадь».

Почему?

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

Про тулы я буду говорить совсем мало, потому что это на самом деле не главное: тул или подходит технологически или нет. Если подходит два тула и оба вендора стоят под дверью в костюмах и с толпой «технологических консультантов» - выбирайте более зрелый тул, как если бы выбирали новую машину. Смотрите на частоту выхода новых версий, на количество плагинов и аддонов, торгуйтесь и смотрите, кто больше сбросит (скидка на лицензии до 40% это не сказка), возьмите триал и задайте 5 одинаковых вопросов в саппорт обоих вендоров, попросите дать вам на две недели технического специалиста, который в вашем присутствии напишет и отладит 5-10 скриптов. Ничего сложного, вы же как-то покупаете новый мобильный телефон или новую машину?

Да, ещё в этой статье я не буду доказывать очевидных для меня вещей: можете верить, можете - нет
Поехали.

Зачем нужен процесс тестирования, если мы как раз внедряем инструменты?

Нельзя автоматизировать то, чего нет.

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

На процесс, который строится, ставить автоматизацию сверху нельзя – развалим.

Расписывать не буду – получится глава книги.

Выделенные под автоматизацию люди

Автоматизация тестирования, как и любой другой процесс автоматизации деятельности не внедряется и не применяется по «остаточному принципу».

Нужно выделенное подразделение для функционального тестирования и выделенные люди для нагрузочного тестирования: у них разные задачи, подходы и часто и инструменты. Тест лабы у них тоже разные, угу.

Когда речь идёт об автоматизации бухгалтерского учёта, почему-то никому в голову не приходит картинка вести часть учёта на бумаге, а часть в системе: тут или взлетели или не взлетели, не сойдётся ведь. С тестированием чуть проще: не всё нужно автоматизировать и можно совмещать ручное и автотестирование – поэтому тут надо быть более категоричным, иначе «не взлетит».

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

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

Драйвер процесса

Начнём с близкого и понятного… с фанатов
Фанат дела автоматизации – драйвер процесса, он занимается только этим, но и отвечает головой, премиями и местом. Ему нужно дать все права в рамках подразделения автоматизации и научить огрызаться на любые попытки привлечь его людей куда-то ещё «потому что там горит». Денег надо дать много – тогда будет дорожить местом.

Откуда таких людей брать? Растить внутри или покупать снаружи. Желательно чтобы человек был физически большой (в идеале толстый!) и немного страшный – это только пойдёт на пользу делу: попробуйте спихнуть со стола человека весом более 100 кг, также непросто с ним неаргументированно поспорить.

Зачем и какие права нужны Менеджеру подразделения автоматизации
Как и любому военоначальнику: права возносить, карать и защищать Тут ничего нового с древних времён не произошло и не появилось.

На человеческом языке это звучит так: Менеджер подразделения должен иметь права набирать и увольнять людей, а также давать премии. Если этого нет – он кто угодно, но не менеджер подразделения.

«Все на пожар!»
Толку от такого «тушения пожара» всё равно будет мало – Брукс на эту тему толково пояснил и показал, почему добавление новых людей в опаздывающий проект зачастую только вредит проекту, а вот практика поюзать чужие ресурсы для решения своих проектных проблем удивительно быстро расцветает в любом проектном окружении.

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

Политическая воля и мотивация руководства

Руководство должно являться инициатором и политической волей, которая давить на процесс сверху. Банальный пример – сотрудников занятых в автоматизации никто не должен иметь права взять никто другой.

Тут у меня есть одно серьёзное допущение и шаткий вывод, в который я верю.

Допущение: руководство - люди умные.
Посчитав деньги (вариант, заставив посчитать менеджера по автоматизации или консалтеров вендора) они поймут какой объем автоматизации должен быть, чтобы экономически внедрение было оправданным и придут к выводу, который разделяю я: внедрять автоматизированное тестирование с честным приобретением лицензий и поддержкой нужно в промышленных условиях, хотя бы в 5 проектах среднего размера в рамках одной компании. Если ваше хозяйство меньше – городить огород можно только в случаях, когда заказчик жить без автоматизации тестирования не может и готов за это дело хорошо платить.

Лошади дохлые, обыкновенные

Разновидности «лошадей» могут быть разными – от формального «ТУЛ установлен на всех компах тестеров» (и что?) до «по результатам пилотного применения на 20 проектах выбран 1, на котором автоматизация достигает 10% тестового покрытия» (то есть покупка лутов и усилия по внедрению не окупяться никогда) – роднит этих лошадей только одно: класс «дохлых».
Если вас не устраивает скачка на «дохлой лошади» - скакать можно, только пахнет не розами – то снова посмотрите в самый верх статьи – условия то простые. Не получается, нафиг её такую автоматизацию, коллеги.

Собственно всё
Удачи на взлёте!

Обсудить на форуме