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

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

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

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

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

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

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

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

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

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

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

Обсуждение (
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
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%. В любом случае рынок диктует свои условия, и на данный момент когда автоматизатор стоит как разработчик, всегда лучше взять разработчика.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

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