Comments 4
Донести идею, что работать можно по-другому, тем, кто привык к ручному тестированию, — наиболее сложная задача в автоматизации. Эту концепцию необходимо «продать». Как показывает практика, новый подход с большим энтузиазмом воспринимают не все
Я вот тут не понял, если честно.
Если покупатель "услуги" кто-то извне - условно ПМ проекта, то проблем нет. Вы же сами видите, если автотесты в будущем дадут выигрыш в time-to-market и/или в времени, которое затрачивается на тестирование - идея будет продана без проблем. Либо не будет продана, если станет очевидно, что не так уж на конкретном проекте они нужны. Главное суметь подсчитать так, чтобы подом не было мучительно стыдно за свои расчеты. Ну или без них вообще никак, если объем работ просто стремится к бесконечности. Даже может быть ситуация, что к QA придут и скажут, автоматизируйтесь, либо " ... как в анекдоте про корову и ... ну что, сегодня молоко или мясо".
А вот если продать "внутри", т.е. части QA-команды, то это звучит так себе. Просто ... сорри за прямоту, из QA програмисты не очень, и в этих автотестах может быть много ошибок, что множит их ценность на ноль.- Перевести всех из manual в automated - такая себе идея. Обычно можно выделить одного/двух (в зависимости от размера команды), и дать им возможность попробовать. Если пойдет, вот пусть выбранные сотрудники и занимаются. Но может у вас другая команда, и прям все смогли адекватно чего-то там автоматизировать.
А вот если продать "внутри", т.е. части QA-команды, то это звучит так себе.
Хороший комментарий. Все от команды и проекта зависит. Если стоит цель всех ручников перевести в авто и отказаться от ручного тестирования (или свети к минимуму), то сначала продается идея, объясняется ценность и все такое. Составляются ИПР и тд. Кто может и хочет - развивается, а если не может или не хочет, как показывает практика – отчисляется.
А вот "из QA програмисты не очень" – немного не соглашусь =) Тоже, от конкретного человека зависит, кому-то не подходит программирование, ну не его это. Но у меня много примеров есть, кто из QA в разработку ушел.
А смысл всех переводить?
Я смотрю с позиции ПМ/тех. лида/руководителя. Условно "мануал" стоит штуку, автоматизатор 2 с половинкой. Т.е. за одного "сомнительного" автоматизатора я нанимаю двух "мануалов" и одного джуна на вырост. Или просто двух. Даже если я не попаду в одного, то шанс что один сразу будет такой как надо - не маленький.
При этом за затраты в 2 раза больше я должен получить прирост минимум в два раза больше, иначе овчинка не стоит выделки вообще.
Если я линейный руководитель, то мне потом все равно придется либо платить им больше (иначе народ уйдет), либо сокращать каждого второго и закрывать задачи вдвое меньшим числом людей. А зачем? Ну реально, на ровном месте выстрел в обе ноги с кучей "лишних" телодвижений до того.
Т.е. резюмируя:
Мануальные стоят дешевле и так как их больше, банально они будут более эффективны. На крайнем примере, у меня в команде есть один "автоматизатор", которые не работает как надо. Ок, "на улицу" и ищем другого. Это время QA вообще нет :) А если два с половинной мануала - даже при одном Low performer жить как-то можно
Есть большой риск получить кучу багов "роста" команды, так как в самой автоматизации будет куча багов. Ну блин, очевидно, что "автоматизаторы" рпо уровню как джун разработчики будуть говнокодить по полной
Поэтому .. нужна "автоматизация" (я выше описал когда), выделяем кого-то и даем возможность развиться или ищем усиление извне. Не выйдет, ну ладно, можно развивать сразу двух, а поставить на задачу автоматизации одного, а второго вернуть назад в ручное. Тому, у кого выйдет - можно и денег накинуть, чтобы ресурсы в развитие не были потрачены зря (смысл учить, чтобы он ушел?). Но такой резевр в бюджете всегда можно найти.
-----------------------------
Короче я бы такую цель "Если стоит цель всех ручников перевести в авто и отказаться от ручного тестирования" не ставил вообще. Это как всех футболистов в команде заставлять быть Месси. В итоге, почти никто не потянет, и играть будет некому.
Статья перевод из 2018 ?)
Как перейти из ручного тестирования в автоматизированное