fbpx
Автоматизация тестирования в Украине никому не нужна

ручные тестировщики

Не открою секрет, если скажу, что большая часть разработки в Украине – это чистой воды аутсорсинг. В этом нет ничего ужасного, ведь именно благодаря этому IT рынок так хорошо развился и мы все имеем отличную работу. Мои последние наблюдения и общение с представителями различных компаний четко убедили меня, что автоматизация тестирования никому тут не выгодна… Печально, но факт.

Давайте разберемся с причинами. Как известно, аутсорсинговые компании в большей части зарабатывают на людях. Мы не будем говорить о проектах с фиксированным бюджетом, потому что там ситуация еще печальнее. А это значит, что чем больше ты продал людей и чем больше маржа с каждого из них, тем больше денег ты заработал. И тут вступают в силу первые 2 причины невыгодности автоматизации тестирования.

Во-первых, опытные менеджеры четко понимают понятие “регрессионной спирали смерти”. Со временем развития проекта функциональности для тестирования становится все больше и больше. Какой самый простой способ с этим бороться? Правильно – нанять еще тестировщиков. А потом еще тестировщиков. И прибыли растут, а заказчик соскочить не может, потому что тестирование делается руками и без тестировщиков разрабатывать будет невозможно. А когда тестировщиков становится больше, то вскоре им понадобится QA Lead или QA Manager. А это еще люди и деньги для компании. Зачем автоматизация?

Хороших тестировщиков-автоматизаторов найти непросто и стоят они недешево. За границей хороший инженер по тестированию зарабатывает на уровне с разработчиками. У нас же работу тестировщиков считают вспомогательной и дешевой. Раз их непросто нанимать, то тяжело расширять команду, а значит зарабатывать деньги. И делать это очень невыгодно.

Кому еще невыгодна автоматизация тестирования? Она невыгодна этим самым QA Lead и QA Manager. С ручным тестированием их задача сводится к управлению командой, управленческим обязанностям, почету и уважению. А в команде автоматизаторов гораздо важнее интегрировать их в команду разработки, то есть выделенной команды тестировщиков стоит избегать. Значит некем больше командовать, не автотестами же!

Так почему же автоматизация тестирования есть в Украине в принципе? Тут нам надо благодарить:

  • Компании, занимающиеся аутстаффингом. Требования внедрения автоматизации приходят от зарубежных команд, которые понимают и видят пользу от этого.
  • Распространение Agile подходов, благодаря которым разработчики все больше занимаются тестированием. А они, понятное дело, руками тестировать не будут… 🙂
  • Развитие профессиональных сообществ и конференций, посвященных автоматизации тестирования.
  • Продуктовые и полупродуктовые компании, которые разумно тратят бюджет и понимают, что правильно сделанная автоматизация позволит им сэкономить в итоге.
  • Разумных менеджеров и лидеров команд, которые понимают, что в долгосрочной перспективе без автоматизации никак и внедряют ее, не смотря на невыгодность для компании.

В подтверждение моих слов, взгляните кто поддерживает конференции для тестировщиков-автоматизаторов. Да практически никто. У крупных компаний это не вписывается в “стратегический план развития”. Мелким это просто неинтересно. В итоге, автоматизация тестирования в Украине живет именно благодаря энтузиазму самих автоматизаторов, которого, будем надеяться, хватит еще надолго!

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Обсуждение (18)

В пэйнте вставляю галочки потому что заказчик не согласен оплатить дизайнера. Какие там автотесты?

“Вы по-моему пытаетесь применить немного старомодное мышление: зафиксируем требования, зафиксируем дизайн, статически это протестируем, а уже потом за код сядем. Не работает! Доказано практикой многих лет многими проектами…” – как раз строго наоборот, практика многих лет разработок чего бы то ни было говорит обратное: чем жёстче стандартизация и чем выше требования соблюдать изначальный дизайн от А до Я – тем выше качество результата. То есть если к разработке ПО применить методики разработки, к примеру, марсоходов или ядерных бомб – качество ПО возрастёт.

“В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития.” – и это адовая проблема, отсутствие жёсткого контроля за происходящим порождает беспредел. То есть не просто “контроля” – контроль как бы есть, но есть отличное мнение, что если раз дать откусить палец, то в следующий раз отгрызут руку, поэтому контроль быть жёстким, а отношение таким: налажал – отгребаешь. Я не ошибусь, если скажу, что сча весь код всего десктопного и мобильного софта состоит из говна и заплаток. Из всего софта, что я пользовал за последний год единственным решением, которое не содержало явных и очевидных глюков – это Вин8, причём чисто сама ось+вин эксплорер, без учёта метро-софта и родного десктопного софта – там ещё тот адок. И то – официально уже вроде 20 апдейтов или даже больше встало, но это всё таки ОСь – многкомпонентная система. А так то релизы один глюкавее другого, все соревнуются не в качестве, а в скорости выпуска, в результате софт превратился в бесконечный поток ширпотребного поноса, который вылетает, глючит и обновляется каждый день, потому что “нафига тестировщики нужны?” или потому что “мы всё сделаем по ХР и со Скрамом”. Мир сходит с ума, одни слушают Адель, Бибера и Леди Гагу, другие релизят каждый день новую версию продукта, потому что отладить, отдебажить и месяц-два потестить – нет времени. А о нормальном планировании я вообще молчу. Эхх, нет сча эффективного менеджмента, Ден Кеннеди абсолютно прав.

Тут есть одно весьма строгое допущение – “жёстко формализовать дизайн по всем аспектам”. Если вы про дизайн и архитектуру кода, то сделать это практически невозможно. В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития. Вы по-моему пытаетесь применить немного старомодное мышление: зафиксируем требования, зафиксируем дизайн, статически это протестируем, а уже потом за код сядем. Не работает! Доказано практикой многих лет многими проектами… 🙂

“Какая разница с какого типа проектами использовать Scrum или Kanban? Это процессы, которые позволяют организовать работу над любого рода проектом (даже не IT). ”
дак я понимаю, речь же о том, что на них “мода” и их суют туда, куда нужно и не нужно и это крайне удручает

“По поводу свободы и вариантов реализации вы заблуждаетесь. ” – да ладно, хотите поспорить с Оруэллом? 😉 Вы ж не забывайте, что “незнание – сила” в дополнение к “свобода – это рабство”. То есть правильный подход – это когда те, кто разрабатывают – делают всё в жёстких рамках, а те, кто пользуются – максимально ограничены в возможности выбора и всё закрыто защитой от дурака и нет никакой информации о возможности что-то как-то менять. Шикарный пример – продукция компании Эппл.
“Но вероятнее всего из-за того, что вы не программист” – более того, я тимлид команды ручного тестирования (ибо у нас всё ещё команда автоматизации выделенная, правда это скорее плюс иначе если поменять структуру – весь тот хламовый код автоматизации пришлось бы переписывать с нуля, а там наверное уже даже миллионы, а то и ещё более строчек кода в силке). Продукт – движок и фронтенд распознавания речи, так что о простоте тут и речи быть не может.
“И тут тестирование – это не банальщина, потому что надо оценить насколько решение справляется с поставленной задачей.” – если обрезать все двусмысленности, нечёткие трактовки и детализировать принципы работы системы, жёстко формализовать дизайн по всем аспектам, то реально если не 90, то минимум 80% тестирования, которое требует внешнего контроля (мануальное или полуавтоматическое, всё таки человеческий фактор убрать хрен получится, автотест не скажет “не удобно”) можно перевести в процессы до написания первой строчки кода, причём первая имплементация потребует больше тестирования, но чем дальше в лес – тем меньше будет требоваться прямого тестирования, при этом при планировании нового функционала или обновлений будет намного проще убрать лишние риски и уточнить реально важные детали.

Все по теме. Добавить нечего. Все зависит от целей проекта/продукта. Как правило, в том или ином виде, в том или ином количестве, автоматизация уже присутствует везде. И нет разницы веб или не веб. Так элементарно дешевле – как оригинальные запчасти.

А я предлагаю перестать считать тестированием “прокликивание” GUI (даже автоматическое) и чтение документации. Но это слишком сложная концепция, так что давайте продолжать дальше 🙂

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

Много другого-разного конечно существует, но давайте посмотрим реалиям в лицо. Какая разница с какого типа проектами использовать Scrum или Kanban? Это процессы, которые позволяют организовать работу над любого рода проектом (даже не IT). У вас есть свой процесс, который лучше и помогает вам делать быстро и качественно проекты? Расскажите о нем, напишите.

По поводу свободы и вариантов реализации вы заблуждаетесь. Но вероятнее всего из-за того, что вы не программист или просто ваши проекты были достаточно банальными с точки зрения технологий и решаемых задач. Часто надо перебрать много вариантов, чтобы только выбрать потенциально возможный. И тут тестирование – это не банальщина, потому что надо оценить насколько решение справляется с поставленной задачей.

в этом плане полностью поддерживаю Лёшу Лупана: нужно перестать называть автоматизацию тестирования автоматизацией и поменять подход. Автоматизаторы = программисты. Автоматизация = программирование. “Автоматизацией” должны заниматься программисты. Тестирование – это процесс поиска ошибок в конечном продукте, всё, что нужно – учить людей тестировать, потому что тестирование – это подход, который требует критической оценки кода/продукта и скептического отношения к работе продукта в целом (даже если кажется, что всё хорошо).
Правда вот я что понял: Николай всегда всё про интернеты и интернеты, но кроме “интернет-софта” есть ещё много другого разного и не везде ваши подходы (да и ваще эджайл) применим. А от повальной увлечённости Скрамом и Канбаном просто тошнит уже.
Впрочем я тоже считаю, что чистый Quality Control не нужен, Quality Assurance – то есть когда происходит реальное тестирование до написания первой строчки кода и убирается любая двусмысленность в том что и как нужно реализовывать и в каком порядке – это идеальный вариант. А потом тестирование чисто юнит-тестами и “автоматизацией” + небольшой QC перед релизом и всё ок.
Вообще у программистов должно быть минимум свободы и минимум вариантов для выбора как реализовывать. Свобода – это рабство, жаль, что всякие ратующие за “полёт творчества” в ИТ этого не понимают.

Я рад, что мы наконец-то на одной стороне баррикад. 🙂

Я много проектов видел в которых автоматизировать было сложно. Как правило это такие, где уже многолетний налет кода в котором нет даже и мысли о том, что кто-то его будет тестировать. Но такие динозавры, как правило, страдают проблемами посерьезней проблем автоматизации (хоть и решают их обычно закидыванием человеческими телами, но это вопрос хренового менеджмента, скорее).

На основе наблюдений в нашей компании, согласен по всем пунктам 😉

Я с вами не согласен. Я работал и консультировал на множестве проектов и только один раз мне встретился такой, в котором автоматизировать было сложно. Связан с построением 3D моделей в стоматологии. И смешнее всего, что ребята все равно ухитрялись автоматизировать и успешно. Просто автоматизация, отданная в руки непрофессионалов может быть обречена. Отсюда и печальная статистика. В ведущих мировых продуктовых компаниях успешно применяется автоматизация и ручного тестирования не так много. На Selenium Camp в этом году приедут докладчики с Google, Yandex, Amazon, eBay, Одноклассники, 2ГИС и других продуктовых компаний. Можете у них интересоваться. 😉

Во первых спасибо что не евреи виноваты. Во вторых, вы должны это знать, что автоматизация применима далеко не всегда. В лучшем случае, на 30% проектов. Т.е она применима конечно же на 100% проектов, но полезный выхлоп будет дай бог с 30%. В любом случае рынок диктует свои условия, и на данный момент когда автоматизатор стоит как разработчик, всегда лучше взять разработчика.

Вообще выделенной команды тестировщиков даже без автоматизации стоит избегать

Leave a Reply

Your email address will not be published. Required fields are marked *

Pkv Games BandarQQ Online Terbaik Dengan Deposit Super Modern permainan paling populer di situs poker online terbaik di indonesia di situs bukaqq Poker Online Aman dan Terpercaya slot online