Тестировщики — роль второго плана?

В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана:
  • На роль тестировщика готовы брать кого угодно, кто умеет достаточно уверенно нажимать на кнопочки
  • Тестировщики редко участвуют в судьбе проекта, принимают решения по требованиям и срокам
  • Тестировщиков стараются подключать как можно позже, когда надо «покликать» и «поикать ошибки»
  • За исключением небольшого числа продуктовых компаний, большинство работодателей предлагают тестировщикам зарплату в 1,5-2 раза ниже, чем разработчикам.

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

Давайте экономить на зарплате

Здесь всё понятно. Чтобы проект приносил больше прибыли, его надо лучше продавать и сокращать производственные затраты.
ОК, давайте наймём недорогого специалиста по тестированию (чаще всего, студента или свежего выпускника), который будет тыкать на кнопки и регистрировать ошибки в систему. Когда объёмы работы вырастут, и он перестанет справляться — наймём второго, и постепенно выстроим целый отдел тестирования. На первый взгляд всё кажется вполне хорошо, если бы не некоторые мелочи:
  • Неквалифицированные тестировщики заводят баги без детального анализа. Такие ошибки сложно локализовывать и исправлять. Допустим, на каждую из 50 заводимых в неделю ошибок разработчики в среднем тратят лишние 15 минут на анализ. Сущие незаметные мелочи! Всего-то, 600 человекочасов разработчиков в год — или 3,5 человекомесяца!
  • Со временем, когда у вас разрастается объём поддерживаемого кода, вам требуется регулярное регрессионное тестирование, дабы проверить, что ничего не сломалось. Ваши студенты-тестировщики целенаправленно и методично выполняют одни и те же тесты от релиза к релизу, изредка находя ошибки (привет, эффект пестицида!) Когда кому-то в голову (чаще всего, РМ'у) придёт идея об автоматизации, эти ребята напишут вам несколько сотен скриптов копипастом — и потом, вместо ручного тестирования, будут каждый релиз обновлять автотесты. В какой-то момент, чтобы всё это счастье поддерживать, вам потребуется больше тестировщиков: что-то между много и очень много. А много это всегда дорого.
  • В конце концов, несмотря на рост численности тестировщиков, вы будете сталкиваться с ошибками на продуктивной среде. Ругаться с пользователями, терять доверие, тратить своё время. В общем, вы продолжите тратить избыточные ресурсы.


И в какой-то момент, рано или поздно, все РМ'ы приходят к пониманию, что тестировщики должны быть достаточно квалифицированными, и находят себе в команду ребят посильнее (которые, правда, уже не всегда могут наверстать упущенное и расхлебать весь этот багаж бардака, который для них накопили). Тем не менее, появляются нормальные тестировщики, которые и тесты адекватно проектируют, и фреймворк автоматизации готовят подходящий. И всё хорошо, только ведь тестировщики — это всего лишь тестировщики. Поэтому,

Тестировщиков не надо пускать к продукту слишком рано

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

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

Тестировщики не могут влиять на качество продукта

При наличии должных сил и желаний, тестировщики могут его оценить. При достатке коммуникативных навыков — обосновать важность тех или иных изменений. Но повлиять на результат?
Медицине пока не известны случаи, чтобы аппарат УЗИ что-либо вылечил, а тестирование — это лишь диагностика. И на этом этапе, если в вашей команде тестирования ещё есть достаточно грамотные и незабитые сотрудники, начинаются новые «тёрки»:
  • Для более грамотной автоматизации, в продукте нужны легко поддерживаемые локаторы — пфффф! «Опять тратить лишнее время на тестирование!», — скажет РМ, и отложит задачу до тех никогда-не-наступающих-времён-когда-команде-будет-нечего-делать.
  • Чтобы точнее оценивать тестовое покрытие и его слабые зоны, нам нужны детализированные декомпозированные требования — пфффф! «Хватит разводить бюрократию, у нас аджайл!»
  • Нам нужно лучше понимать пользователей и привлекать целевую аудиторию на этапе проработки бизнес-сценариев, оценивать юзабилити — пффффф! «Это отложит релиз на 2 недели, лучше потом переделаем по отзывам пользователей!»

Постепенно, все хорошие начинания улетают в трубу, и вместо обеспечения качества максимум, что могут делать тестировщики — это своевременно сообщать о найденных ошибках. Декларирующие потребность в повышении качества РМ'ы на практике не готовы в него инвестировать, и наступает потихоньку коллапс. Поддержка старого функционала стоит всё больше и больше. Разницу в распределении ресурсов команды во времени в двух подходах я постаралась изобразить на схеме:

И чем раньше вы начинаете вкладывать ресурсы в обеспечение качества и работоспособных процессов, тем больше, в конечном счёте, у вас остаётся на разработку нового функционала! Как бы неожиданно это ни звучало.

Выводы


Срезюмирую:
  • Разработчик автотестов — это разработчик. Тест-аналитик — это аналитик. Если вы набираете людей в тестирование, предъявляя к ним меньше квалификационных требований, чем к разработчикам и аналитикам, то постепенно вы роете яму всей свей команде.
  • Тестирование — это часть разработки, а не следующий за ней этап.
  • В тестировании и обеспечении качества не могут участвовать только тестировщики. Продукт и процесс должны способствовать возможности тестирования и улучшений, и если вы не вкладываетесь в это с самого начала, то потом приходится платить значительно больше — на сложностях с поддержкой, внесении изменений, тестировании и общении с клиентами.

Всё ещё редко, но в ex-СССР начинают встречаться толковые процессы обеспечения качества. А вы готовы менять что-то в лучшую сторону?
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 81

    +8
    Отличные выводы. С мыслью доклада согласен.

    А давайте попробуем развить мысль (просто так, без обид):
    Разработчик автотестов — это разработчик. Тест-аналитик — это аналитик.

    Тестировщики заводятся не из за багов в продукте, а из за багов в людях и процессах.
    Когда аналитик не выполняет часть работы по анализу требований, когда разработчик не думает о архитектуре… И тут появляется тестировщик, который занимается отладкой и работой с требованием — то есть тем, чем должны заниматься другие, но почему-то не делают этого.

    Получается, что тестировщик — неправильное решение проблемы, а надо работать с программистами и аналитиками?
      0
      Нет. При разработке (особенно архитектуры) как правило много вариантов развития, и выбор оптимального редко очевиден. Бизнес требования довольно часто меняются, порой значительно для системы и без права на корректировку архитектуры. Нельзя сделать идеальный продукт раз и на всегда. Очень часто одним из ключевых критериев создания является скорость, что негативно влияет на качество. Да и задач на программистах не по одной и держать детали реализаций всего и вся в голове невозможно. К аналитикам это скорей всего относится в равной степени.
      Это самое очевидное, но есть еще к примеру различные ракурсы у различных участников проекта, что тоже вносит влияние.
        0
        Это понятно, что идеально сразу ну никак. Я высказал гипотезу, что лечить неидеальное лучше программистами и аналитиками, а не тестерами.
          +2
          Опять же нет. Частично исходя из различных взглядов у каждого. Разработчик даже с семью пядями будет видеть только проблемы разработки. Аналитик будет видеть только проблемы бизнеса. Функциональный тестировщик и автоматизатор смотрят уже со стороны потребителя продукта. Области конечно перекрываются, но крайне слабо. Все 3 группы (можно обособленно поставить еще инженеров по производительности и тех кто связан с планированием мощностей, но они отдельная песня) говорят на разных языках и плохо понимают друг друга в виду различных контекстов «обитания». Вместе они могут составить некое необходимое для разработки целое.

          Оставить только две группы нельзя. Потому что тяжело видеть одному человеку угол в 180 градусов, не вращая головой.
            0
            Аналитик будет видеть только проблемы бизнеса.

            За бизнес болеет ПМ. А вот аналитик как раз — думает за потребителя. ПМ-аналитик-разработчик — чем не три столпа?

            Предлагаю дальше не спорить :)
            У меня в профиле, кстати, написано «О себе: Работаю тестировщиком».
              +1
              Да я не спорю. Лишь ответил на вопрос.
              По сему не могу успокоиться и еще раз нет) Задача ПМа — отправить лебедя, рака и щуку в одну сторону (ну хотя бы так чтоб вектора усилий не давали 0). Для осуществления проекта нужна толпа народу (с чего наш диалог и пошел), которые нередко и в глаза друг друга не видели. Кто-то должен их координировать и направлять.
                0
                которые нередко и в глаза друг друга не видели

                Лучше все-таки чтобы видели и общались, потому что ПМ часто не в курсе о мелких технических недопониманиях и проблемах, либо в курсе, но не может сам нормально объяснить.
                  0
                  Испорченный телефон не нужен конечно. Его задача не общаться, а сводить к общению.Ставить приоритеты, следить за сроками. Можно даже переименовать в координатора проекта. Работы у него хватает и работу эту не выкинуть, когда организация большая. Да и в небольшой организации тоже, где люди не умеют самостоятельно держать сроки и следовать приоритетам. (сейчас речь об идеальном ПМе)
                  Можно привести контр пример в виде Valve, но чего то их результаты удручают в плане доступности и качества сервиса. Других компаний без управленцев я не ведаю.
              0
              На мой взгляд то, что разработчик видит только проблемы разработки не есть хорошо. Вернее это и есть основная проблема.
              Если каждый участник проекта будет думать о том, как его действия повлияют на других, то будет счастье.
                +2
                Не выйдет.
                Мышление складывается из того, чем приходится заниматься и с кем приходится общаться, а интересы и задачи у всех разные. Невозможно быть всевидящим и всеобъемлющим. Просто времени не хватит. Хорошо уже, когда люди находят общий язык. Это данность, которую надо учитывать.
          +1
          Тестирование — это задача, которая является следствием невозможности выполнить что-то хорошо и правильно с первого раза, без взгляда со стороны.

          Как будут называться люди, её выполняющие — неважно.

          Я видела примерно следующую схему работы, результаты которой были просто отличными:
          * Аналитики, общаясь с пользователями, выясняют требования. Любое требование проходит тщательное ревью другим аналитиком.
          * Разработчики пишут код и проводят ревью кода «соседа», регрессия полностью покрывается юнит- и GUI-тестами, которые пишутся разработчиками.
          * Аналитик, разработавший требование, финально проверяет реализацию «своего» функционала.

          В итоге, тестирование размазано по этапам и по должностям, выделенных «тестировщиков» нет, но суть от этого не меняется.
            +3
            Такая схема потенциально может работать, но имеет ряд существенных проблем (в зависимости от типа проекта):

            Объективные:

            — на аналитике повисает достаточно большое количество манкиджоба. В итоге «человек за много денег» делает работу, которую «человек за половину много денег» сделает не хуже. Т.е. неоправданный рост издержек.
            — схема очень плохо работает, когда автоматизация GUI (а если быть более точным — функциональных тестов) дорогая.
            — основная беда тестов, которые пишутся разработчиками — coverage. Для юнит-тестов можно сравнительно дешево его измерить и оценить, для более-менее сложных сценариев нужна сторонняя экспертная оценка.

            Субъективные:
            — команде разработчиков может быть банально неинтересно писать тесты. Да, это плохая практика, да, мало ли что кому неинтересно, но это факт — во многих командах эту активность не любят и всячески саботируют.
              +1
              1) Не надо делать манкиджоб и нанимать манкилюдей. Манкипроблемы потом расхлёбывает весь проект, об чём и речь.
              2) Функциональные тесты (в том числе через GUI) легко поддерживаются, если обеспечить достаточно хороший уровень тестируемости проекта на ранних этапах.
              3) Code Coverage можно легко померить и на ручном и на функциональном (а-ля selenium) тестировании. Ищите подходящий инструмент.
                +2
                Функциональные тесты (в том числе через GUI) легко поддерживаются

                А речь не про «поддерживаются», к сожалению. Речь про «пишутся». Вот простой сценарий из личного опыта: есть приложение для планшета. Что оно делает — не суть важно, но имеет десяток экранов, на каждом — под тридцать независимо работающих контролов. А теперь — внимание, фокус — ID конкретного контрола из приложения мы получить не можем. Вообще никак. Потому что рисуем приложение через OpenGL. Уже на этом уровне начинаются мысли «три-пять мануальных тестировщиков», ещё до того, как понимаем, что таргет-устройств — минимум семь, разрешение тачскрина не совпадает с разрешением дисплея, причем тачскрин квадратный, а дисплей — нет (по координатам, не физически), что дизайнеры будут перерисовывать рисуемые контролы раз в неделю и ещё раз в неделю — менять лэйаут ихний, так что ни кликеры, ни компьютервижн нормально работать не будет. И мы не можем «сначала дизайнить, а потом кодить», потому что мы не Valve и делать продукт по принципу when it's done нельзя. Вот это я называю «дорогая автоматизация».

                Code Coverage можно легко померить
                Code coverage — да. А вот вопрос о покрытии именно затребованных сценариев — и детализации этих сценариев, вдобавок — это вопрос, который на откуп самим разработчикам отдавать опасно. Грубо говоря, кто проверит, что пара десятков тестов, по заверению команды разработки, тестирующих некий user story:
                — действительно тестируют его, а не какую-нибудь рядом лежащую функциональность?
                — тестируют все аспекты, важные в разрезе определенной стори?

                и на ручном и на функциональном (а-ля selenium)
                Функциональное — это не «а-ля селениум». Функциональное — это то, которое проверяет, выполняет ли приложение заданные функциональные требования. И оно может быть как ручным, так и автоматизированным, в зависимости от того, что выгоднее в данный момент.
                  +1
                  1) Т.е. в вашем продукте не была заложена testability, и теперь вам сложно разрабатывать тесты? Вся статья примерно об этом.

                  2) Функциональное бывает не только ручным и автоматизированным, оно ещё и не обязательно через GUI делается. Вот ваше приложение для планшета: где основная бизнес-логика, на сервере или на клиенете? Если на сервере — может, тестировать запросами, а на клиенте руками только интеграцию GUI проверять? Если на клиенте много логики — можно ли вытащить API для тестовой версии, чтобы опять же, в GUI только глазками вёрстку смотреть и вызов нужного функционала?

                  Я сталкивалась с мыслями про «дайте много тестировщиков» и на планшетах, и на множестве поддерживаемых платформ, и на терминальных приложениях. Слава богу, каждый раз работа мозгом позволила избежать лишней работы руками.
                    +1
                    Т.е. в вашем продукте не была заложена testability
                    Т.е. не во всех задачах автоматизация дешевле ручной работы. Понимаете, сделать можно вообще все — при наличии бесконечных денег и бесконечного бюджета. Но есть задачи, где автоматизация будет стоить, грубо говоря, 30 килодолларов, а ручное тестирование — 20, при сопоставимом качестве (просто в случае автоматизации просядут одни показатели, а в случае ручного тестирования — другие). И нужно понимать, что нужно в данный конкретный момент, сколько оно стоит и какого результата с его помощью можно достичь.

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

                    оно ещё и не обязательно через GUI делается
                    Нет, не обязательно. Но в рамках неких acceptance test-ов он должен проверяться достаточно часто (и как можно раньше) именно в рамках «сценария пользователя», т.е. когда проходится вся схема, сверху донизу, а не некоего API. Иначе есть много рисков, что ситуация на интеграции пойдет, как в известном анекдоте — «точности не гарантируем, на крайняк будет два туннеля». Но тут есть извечный конфликт практик разработки — в одних случаях предпочитают разрабатывать «снизу вверх», когда вначале пишется некоторое ядро функционала, а в других — «сверху вниз», когда сначала обеспечивают продергать все возможности, пусть даже реальный функционал и забит заглушками.

                    Слава богу, каждый раз работа мозгом позволила избежать лишней работы руками.
                    Я в свое время на основе всего, что попадалось в руки нашей тест-тиме, вывел для себя список критериев, которые свидетельствуют про то, что, скорее всего, лучше будет тестировать мануально. Правда, он включал в себя такие критерии, как «проект пишут уже больше N месяцев и архитектуру менять нельзя» и «частота изменения сигнатур в API — больше 10 методов в неделю» :)
                      +2
                      Я думаю, что самый главный критерий вложений в автоматизацию — это длительность последующей поддержки и развития продукта. Если мы над ним работали 5 лет, а впереди 10, то есть смысл вносить изменения в продукт для улучшения тестируемости и придумывать идеи по совершенствованию фреймворка автотестирования. Если же через полгода мы об этом проекте не вспомним, и на других проектах наработки переиспользовать не сможем, то почти всегда ручного тестирования достаточно и автоматизация будет пустой тратой.
                    0
                    рисуем приложение через OpenGL

                    а зачем, если не секрет, такое нужно?
                    игровой интерфейс?
                      0
                      К сожалению, NDA. Все что могу сказать — не игры, скорее proof-of-concept достаточно перспективного решения :)
                0
                Как заставляли разработчиков писать и, главное, поддерживать GUI-тесты?
                  0
                  После слова «заставить» уже наверное никак :)

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

                  Если общее светлое будущее от автотестов непонятно, а сама задача неинтересная, то конечно никто ничего делать не будет.
                    0
                    Автотесты автотестам рознь. Я не зря сказал именно про GUI. С трудом представляю, как кому-то может быть интересно писать тесты на то, что кнопочка переместилась на 10 пикселей влево, как того захотел заказчик вчера, а завтра исправлять на 20 пикселей вправо, потому что заказчик неправильно оценил где право, а где лево.
                      0
                      Ну автотесты через GUI могут быть интеграционными функциональными, а могут проверять вёрстку.

                      Вообще, я сильно против проверки вёрстки и отображения автоматизированно, такие вещи всегда лучше смотреть глазками.
                        0
                        По мне автотесты через GUI и автотесты GUI — две большие разницы. В первом случае мы GUI тестируем поскольку постольку — либо активируем какой-то контрол по его id, селектору или ещё какому признаку, либо «кликаем» в точке с какими-то координатами — этот способ по сути функциональный тест. Во втором нам нужно убедиться, что контрол виден, что он находится в нужном месте экрана, что активен, имеет нужный цвет и т. п. — это тест приемочный.
                          0
                          Если есть возможность сделать «эталонные скриншоты», например для регрессии, то дальше автоматизация довольно тривиальна и не требует много механического труда — благо существуют sikuli и imagemagick. Вопрос только в поддержании её в актуальном состоянии.
                            0
                            Но это уже не будет «тру» TDD.
                              0
                              И? Наличие на проекте TDD должно заставить игнорировать любые другие практики относительно тестирования?
                +1
                Действительно, вот этим ребятам тестировщики явно почти не нужны, они сами что хочешь классно протестируют.

                image

                Но где ж их набрать в нужном количестве? Вот и приходится как-то учиться…
                  0
                  тестировщики явно почти не нужны
                  Верно оговорились =)
                    0
                    Отсюда мораль: не читай Хабр во время работы. А уж тем более не пиши туда.
                0
                Где их взять только? :)
                  +1
                  Странная диаграмма у вас про распределение времени между тестированием, поддержкой и разработкой нового. Из нее получается, что если больше ресурсов выделить на тестирование, то поддержка старого функционала (доработка по требованиям заказчиков, адаптация к изменяющимся бизнес-требованиям и так далее) куда-то пропадает.

                  Между тем бывает ведь по-разному. Иногда разработка нового не ведется вообще. Иногда продукт замораживается и не поддерживается в пользу перевода ресурсов на полный проект.
                    +1
                    Ой, это я может не очень понятно выразилась. Когда что-то меняем по требованию заказчика, это всё-таки новая разработка и новый функционал.

                    Но если у нас нет юнит-тестов, если у нас говнокод, то вносить изменения становится очень сложно, всплывают дурацкие баги, и на это всё уходит впустую куча времени — его я серым и изобразила.
                      0
                      Тогда лучше поправьте терминологию :)

                      Доработка по требованию заказчика — это далеко не всегда новый функционал.
                        0
                        но это всегда change request, и для этого надо всегда начинать полный цикл
                      0
                      По-моему, это у вас с терминологией проблемы. Доработки и адаптации — это новая функциональность, реализация фичереквестов, введение в систему того, что в ней не было и быть не должно было. Поддержка же — это багфиксинг, реакция на багрепорты, введение в систему того, что в ней не было, но должно было быть или удаление того, что было, но не должно было быть.

                      Задачи классифицируются по отношению к требованиям, а не по коду. Если мне говорят, что теперь «Отчество» необязательное поле, то я заношу этот таск в фичи, если мне говорят, что «Отчество» обязательное, хотя не должно быть таким, то я заношу этот таск в баги. А код, закрывающий таск, будет одинаковый. Просто в первом случае требование об обязательности было озвучено, а во втором — нет, а может даже было озвучено противоположное.
                      +8
                      ответ на вопрос — да, тестировщик — роль второго плана.
                      роль нужная, но не первоприоритетная.
                        +1
                        Не совсем. Тестировщик роль, как правило, на ровне с программистам или чуть по-важнее.

                        Оно конечно понятно, что для того чтобы продать что-то должен быть тот кто это «что-то» будет делать. Но Вы не совсем правильно понимаете процесс монетизации продукта.

                        Достаточно часто программист является или второстепенным или третьестепенным. На первом месте все-таки support и marketting unit именно они знают «Какой скриншот нужно разработать?». Далее идет все-таки тестировщик. Потому что он предотвращает возможную встречу бага с пользователем. Если пользователь найдет найдет критическую багу, то в лучшем случае мат и рефаунд(просьба вернуть деньги обратно), а в худшем потеря имиджа из-за чего и происходит снижение продаж, а это напрямую отражается на зарплатах, тимбилдингах и др.

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

                        В мире разработки все более-менее похоже на ситуацию с покупкой машины с царапиной. Все также! Если продукт «с царапиной», то его покупать не будут! Почти всегда покупателю не важно как много программист знает паттернов проектирования или идиом разработки. Но зато покупатель очень часто видит продукт «с царапиной» или без нее и ему это очень важно!

                        Для того чтобы продажи не падали, пользователи не искали другие продукты и решения, и покупали продукты сейчас, а не когда починятся баги и как раз и нужны тестировщики.

                        Подытожу:
                        1) Сначала надо знать ЧТО делать
                        2) Затем знать КТО это купит
                        3) Далее надо понять как долго это ЧТО-ТО будет делаться
                        4) Принять решение делать это ЧТО-ТО или не делать.
                        5) Если все-таки делать, то сделать это ЧТО-ТО
                        6) Проверить это ЧТО-ТО, т.к. КТО-ТО из п.2 может отказаться от покупки! Зачем ему это ЧТО-ТО с царапиной?
                        7) Продать это ЧТО-ТО

                        Уверяю Вас п.5. не самый Важный. Более-того я написал довольно упрощенную схему, более опытные и практикующие люди смогут ее существенно дополнить.
                          0
                          я совсем правильно понимаю процесс монетизации продукта.

                          роль тестировщика не важнее роли програмиста. мягко говоря не важнее.
                          а уж какие роли (из остальных) более важны чем роль программиста вообще не важно.
                          «Потому что он предотвращает возможную встречу бага с пользователем.» и тут он спускается со второй роли на третью.

                          пример с машиной бесполезен и не приводит адекватных аналогий.

                          продукты пользуются спросом не потому что в них отсутствуют косяки, это может быть результат маркетинга, уникальный функционал, вероисповидание, отсутствие конкурентов, более выгодная цена, требования регулятора и тысяча других.
                            0
                            >>отсутствие конкурентов
                            Не факт. У меня были случаи, когда люди обладали временем шли на фриланс биржу и получали то что они хотели не сильно переплатив! Все потому что продукт может содержать в себе N фич, а человеку может быть нужно всего-то 1-2. Так что если нет конкурента сейчас, не факт что его не будет завтра

                            >>продукты пользуются спросом не потому что в них отсутствуют косяки
                            Нет. Вы видимо ни разу не присутствовали на собраниях по выбору чего-либо Купить у фирмы-1 или же фирмы-2. Очень часто выбирают именно из-за более стабильной работы.

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

                            А Вы говорите что стабильность и не косячность не важна! К примеру я в свое время после нескольких падений снес со своих компов Google Chrome и стал пользоваться Mozilla FireFox-ом из-за его большей стабильности.

                            Стабильность продукта это очень важно! Иногда это единственный критерий который выдвигается к продукту. Еще одна ситуация: протектор исполняемых файлов накладывает защиту на исполняемый файл, в результате вдруг получается файл который предлагает пользователю дебажить приложение. Будет ли команда девелоперов применять такой протектор? Возможно, если вдруг альтернатив нет, но если вдруг есть пулей сбежит к конкуренту и попросит вернуть деньги.
                              0
                              — Это один из тысячи поводов использовать конкретный продукт с багами. Остальное лирика.
                              — Я присутствовал в тендерных комитетах, где цена и сроки\поддержка ВСЕГДА были важнее стабильной работы, а это 99% прикладных решений. Очень мало сфер, где (например) доступность должна обеспечиваться не 99.9%, а 99.9999% и обеспечивается это не тестированием как таковым, а сложными процессами контроля качества, в которых тестирование это всего лишь одна из составляющих.
                              — Это не математика, тут не может быть неправильного мнения. Мне не интересны близкие программистам примеры, но этот тоже бесполезен и абсолютно не отражает жизненных реалий.

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

                              Стабильность важна, в некоторых случаях определяюще важна. Но это единственный критерий для 1% (округлено в большую сторону) ситуаций.
                            +2
                            Лучше всё-таки машина с царапиной, чем отсутствие и машины, и царапины :)

                            Поэтому, на нашем рынке, где народ пока готов покупать царапаные машины (а софт у нас обычно не просто царапаный, а битый), разработчики важнее и это ОК.

                            На высококонкурентных продуктовых западных рынках софта роль тестировщика соответствует значимости разработки.

                            Но врядли когда-либо тестирование будет важнее, т.к. нет разработки — нет машины :)
                              0
                              Ну для кого-то может машина с царапиной и хороший вариант, но я лично проследую к другой машине или совсем в другой автосалон. Ведь мы знаем, что машина теряет в цене сразу же после того как она покинула пределы салона, а царапина еще больше обесценивает стоимость машины. Ведь не исключена ситуация когда мне надо будет продать машину, а машина с царапиной стоит дешевле! ;)

                              >>нет разработки — нет машины
                              Да. В своем комментарии как раз и отметил этот факт во втором предложении. Но я о другом. К примеру два продукта с примерно одинаковой функциональностью и вам нужна одна из фич, которая есть в одном из них. Допустим на сайте каждого вендора выложены демо-версии. Мы перед покупкою скачиваем и видим что у Вендор1 интересуемая нас фича не работает, а у Вендора2 работает. При тех же деньгах, том же списке фич, той же цене к кому Вы пойдете? Неужели к тому вендору у которого демо-версия не работает?
                                +1
                                Правильно. Всё зависит от конкурентности рынка, т.е. от наличия «нецарапаных» вендоров :)

                                У майкрософта SDET'ов чуть больше, чем разработчиков (SDE). В некоторых компаниях с известными мировыми именами, в которых я работала, тестировщики зарабатывают больше разработчиков. Т.к. каждый мелкий баг, про который напишут в PC Magazine, стоит сотни тысяч долларов убытков.

                                Но это исключения, т.к. в основном рынки софта пока что — это рынки царапаных машин :)
                                0
                                Поэтому, на нашем рынке, где народ пока готов покупать царапаные машины

                                мне всегда на это рассказывали историю Васи и Пети:
                                Жили да были Вася да Петя, и решили они делать один программный продукт. Вася был сторонник вылизывания всех фич, предварительного тестирования, написания юнит тестов и т.д, Петя был сторонник быстрого прототипирования и выдачи заказчику. Поссорились они на этом и разбежались. Прошло полгода, Вася всё ещё писал продукт, вылизывая фичи и интерфейс, покрывая код тестами. В это время Петя, за первый месяц выпустил сырую версию продукта, без половины функционала и собрал первые отзывы покупателей, через 2 месяца выпустил вторую версию, закрывающую большую часть функционала и добавив новый по запросам пользователей, собрал отзывы и на вырученные деньги нанял двух программистов и они целиком переписали продукт под требования пользователей, и через 3 месяца выпустил уже третью версию с которой снял хороший барыш. Вылизанный продукт Васи стал не актуален, т.к. не было отзывов пользователей и он не знал, что идёт не туда с чем и пролетел. В итоге Петя купил Васин код, включил его в свой и продаёт версию 4, ездит на порш-каене и доволен жизнью, а Вася работает на Петю за обычную зарплату.
                                  0
                                  Ну тут всегда будет вечный спор, и любые крайности плохи.

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

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

                                    0
                                    справедлино
                                    но надо понимать, что заказчик не любит, когда ему отдают «что-нибудь хоть как работающее»
                                    в данной истории функционал был, хоть и не полностью требуемый заказчикам
                                      0
                                      Разница в том, что в истории про Васю и Петю речь идет о условно-«коробочной» разработке, а не о заказной и тем более — об аутсорсе-аутстаффе.
                                    0
                                    Без половины функциональности всё же не значит с неработающей функциональностью. Про баги ни слова в истории :)
                                  +1
                                  Если продукт «с царапиной», то его покупать не будут!

                                  Продажи кучи продуктов это опровергают. Самый известный пример, наверное, Windows.

                                  Отсутствие предрилизного тестирования может снижать продажи, в некоторых случаях до нуля, отсутствие разработки продажи обязательно снизит до нуля — тупо нечего будет продавать (мошеннические и близкие к ним схемы не берём). Разработчики — необходимое звено, тестировщики — опциональное.
                                    0
                                    >>Самый известный пример, наверное, Windows
                                    Вы ее покупали? ;) Я лично нет и не собираюсь! Вокруг меня вращается достаточно много технарей как программеров так и админов и др. Но не могу назвать ни одного человека, который бы себе купил Windows ;) Более того, знаю человека который ходил в Microsoft с целью написания заявления вернуть денег за предустановленную систему при покупке ноутбука.
                                    Также могу отметить, что среди моих знакомых охотнее возьмутся админить, сопровождать систему Linux или что-нибудь из BSD-лагеря, чем Windows. Да и далеко ходить у нас(где работаю) почти все на Linux.
                                    Еще могу заметить что среди моих знакомых не технарей, которые задумываются что-то развернуть у себя в конторе почему-то первым задают вопрос «У тебя есть знакомые которые понимают в Linux?». Очень часто находятся и Windows Server решения не ставятся!

                                    >>в некоторых случаях до нуля
                                    Да и любой владелец бизнеса должен такое предусмотреть и иметь финансовую «подушку безопасности» в случае таких вот форс-мажоров. Но не у всех это получается. Имеются в памяти примеры, когда программисты просто вставали и уходили к другим работодателям. Лично я услышав «Зарплата будет задержана на месяц» не пойму, хоть что-то да попрошу, ибо семья, др. обязательства и расходы. Также думают и многие другие. «Доведение до нуля» даже в «некоторых случаях» оочень опасно для бизнеса!
                                      +1
                                      Рассказ про линукс vs виндоус только характеризует тебя как религиозного фанатика, но ничего не добавляет к дискуссии.
                                        0
                                        Все? Аргументы закончились? Когда не нанашлось аргументов сразу же пошло в ход «религиозный фанатик»? ;) Смешно. Вынужден Вас огорчить сижу на Windows :) В данный момент на Seven, собираюсь бежать на 8.1. На работе тоже Seven. Так что настоящие «религиозные фанатики» про меня бы сказали закоренелый виндузядник ;)
                                          +1
                                          Человек привел в пример виндоус, которая массово популярна (с багами), а ты, зачем-то, начал рассказывать про то, что ты не знаешь людей которые покупают виндоус, про человека который хотел вернуть виндоус, про знакомых не айтишников, которые хотят не виндоус.

                                          Вокруг меня вращается огромное количество технарей и большая часть сидит на винде, но это бесполезная информация.
                                +1
                                Согласен с тезисом, что тестировать нужно сразу. Очень много спорил с экс-коллегой, который упорно не хотел отдавать тестировщикам первую версию продукта, пока сам может найти хоть один баг, и как итог — громадный срыв сроков, тестирование в последний день и куча безусловных try-catch в коде, которые находятся иногда до сих пор. Успел уволиться :)
                                  +1
                                  Очень красивые графики, но на чем они основаны? Можно посмотреть на исходную статистику?
                                    0
                                    Это иллюстрация в свободном стиле :) Графики основаны на опыте работы ТМом, РМом и консультантом в десятках компаний, и отражают лишь моё субъективное восприятие проблемы.
                                    +4
                                    Сисадмин — роль второго плана?
                                    Почему такое происходит, вполне понятно: мало кто вживую встречал квалифицированных сисадминов, сисадмины не делают полезный результат (продукт не пишут), да и вообще у нас принято экономить на всём, на чём только получается. Интересен другой вопрос: что получается благодаря такому подходу?

                                    Сюда какую специальность не подставь — все подойдет. Логично ведь, если компания специализируется на разработке, то в ней разработчик — роль первого плана, остальные — второго, и менеджеры и бухгалтеры и юристы. Если компания юридическая, например, то юрист — роль первого плана, остальные второго и тд.
                                    Дня меня это выглядит как слегка завистливый пост на тему, почему другие зарабатывают больше чем я?
                                      0
                                      Кстати о заработке. Не такая уж и редкость встретить функциональщика, который получает побольше многих разработчиков. Естественно это не аутсорсинг и не студенты.
                                        +2
                                        Тест-автоматизатор при примерно равном уровне владения одним и тем же языком программирования с девом, практически всегда будет получать больше. Даже в аутсорсе (меряю по киевским наблюдениям).
                                          0
                                          В Мск аналогично. Связано с большим дефецитом кадров.
                                        +1
                                        Вот на что мне грех жаловаться, так это на зарплату :)

                                        А вот за некачественные продукты в случаях, когдя я не могу на это повлиять — обидно!
                                        +5
                                        Уже почти все описанное в статье испытал. Бонус еще есть — когда руководители понимают, что все уже ОЧЕНЬ плохо, находят чувака по-дороже, но по инерции каждый встречный-поперечный пытается учить делать его работу «более лучше». Что-то вроде «ну он же тестер, наверняка и wireshark пользоваться не может». И когда ты автоматизируешь вход с модифицированной gina, а тебе под руку дают капитанские советы «как nat в vmware настроить», это просто бесит. В замечательнейшем докладе Дмитрия Петунина, про 1001 заблуждение(очень советую) про это отношение к тестерам замечательный стихотворный эпиграф. Куча времени уходит на пруфы, что ты не верблюд. Но основная проблема мне видится в отсутствии простых способов повышения качества. Невозможно просто взять студента и провести анализ багов за год, создать единые тестовые среды, сформировать требования, провести code review.
                                        Чтобы уж совсем не депрессовать расскажу о хорошем — о мотивации, почему люди работают тестерами, несмотря на все: just for fun. Нет, реально, тестировать — это довольно весело. IT вообще одно из немногих направлений человеческой деятельности, где можно зарабатывать, что-то изучая большую часть рабочего времени, и тестирование в IT — сплав разработки, администрирования, внедрения, менеджмента позволяет узнать гораздо больше.
                                          0
                                          Всегда, когда читаю или слышу подобное, испытываю такое удовольствие! Спасибо богу айтишников, что в нашей отрасли есть такие люди! :)
                                          0
                                          Некоторое время назад упразднил в своей команде роль автотестировщика и перешел на сторону разработки.

                                          Самое сложное — привить разработчикам мысль на уровне подсознания, что больше нет никакого волшебного человечка, который все еще раз перепроверит (или даже просто проверит, ведь «зачем, там и так все будет работать, я поправил одну строчку»), а также искоренить мнение, что разработчику не к лицу писать функциональные тесты.

                                          В целом, пока все еще устаканиваем новый процесс работы, но конечная цель — команда без слабых звеньев («ой, а у нас тестировщик заболел») с вовлеченностью каждого в обеспечение качества — стоит того, чтобы это попробовать.
                                            +2
                                            Расскажите об итогах после релиза и отзывов клиентов.
                                              0
                                              Рассказать уже можно, поскольку релизы у нас примерно раз в месяц. Чудес не бывает, сразу все гладко не пошло. Чем больше я погружался в разработку, тем меньше времени у меня оставалось напоминать коллегам, не просмотреть отдельные нюансы и учесть их в тестах и при финальной проверке. В результате постоянно были ситуации, когда ошибки обнаруживались при подготовке к демонстрации. Пару ошибок мы-таки пропустили в релиз :-( Но мы знаем, что нужно делать и корректируем свой процесс.
                                                0
                                                1. Не получится ли, что исключая звено тестировщиков, вы погружаете разработчиков в большую детализацию работы и тем самым повышаете зависимость от каждого конкретного человека (Bus factor)?
                                                2. Насколько тяжело дается отработка кейсов человеку, который делает систему? Нет ли замыливания глаз?
                                                3. Во время работы тестировщиков, разрабы обычно берутся за реализацию других задач. Получается некое распараллеливание. В вашем случае разработчик делает все сам, плюс ему больше придется общаться с пользователями и аналитиками. Что со временем? Не придется ли в итоге нанимать дополнительного разработчика?
                                                  0
                                                  1. Безотносительно процесса тестирования всегда хорошо, когда в решении задач из одной и той же области кроме признанного в ней эксперта участвует кто-то еще из команды. В традиционном подходе таким «кем-то еще» становится тестировщик (на уровне понимания бизнес-домена и нюансов реализации с точки зрения пользователя/конфигурации), в нашем случае им становится другой разработчик (на уровне понимания бизнес-домена, нюансов реализации с точки зрения пользователя/конфигурации и нюансов реализации с точки зрения кода).

                                                  2. Пока есть сложности с этим. Пробуем решать командным ревью результатов анализа (анализ включает составление кейсов) и ревью собственно реализации.

                                                  3. Безусловно, навешивание на разработчиков полного цикла задач по обеспечению качества увеличивает общую скорость решения задачи разработчиком. С другой стороны, исчез пинг-понг и переключение между новой задачей и той, что вчера была передана в тестирование.

                                                  А насчет общения, уверен, что разработчикам полезно больше общаться с пользователями и аналитиками для улучшения понимания ценностей, целей, задач бизнеса компании и бизнеса ее клиентов. Лично меня очень расстраивает, что некоторым совершенно неинтересно это знать («я лучше код порефакторю, чем поеду на экскурсию на объект клиента» ©).
                                                    0
                                                    увеличивает общую скорость решения задачи разработчиком

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

                                                Функциональные (дернули событие/запрос по ид или ещё чему — проанализировали изменения данных/ответ) куда не шло, но каждый раз после «сделайте кнопочку побольше» исправлять тесты этой кнопочки, что у неё ширина 147 пикселей, что не появляется прокрутка на куче разрешений, что другие элементы не уплыли и т. п… Не то, что не к лицу, а очень скучно — можно найти занятия и поинтереснее.
                                                  0
                                                  Нам повезло и наша функциональная область чаще всего позволяет рассматривать GUI только как инструмент для совершения нужных действий с минимальной необходимостью валидации (есть/нет, включен/отключен).
                                                  0
                                                  Напишите, пожалуйста, чем все закончилось? Два года прошло уже, достаточный срок для анализа.
                                                    +1
                                                    Идея, что разработчики сами закроют функциональное тестирование не взлетела.

                                                    Перед тем, как уйти на новый проект, мне пришлось взять в команду толкового автотестировщика, чтобы не уронить качество.

                                                    В то время, когда разработчики пишут функциональные тесты, они не пишут код. Как следствие:
                                                    1. разработчики хотят писать код, а не тесты;
                                                    2. бизнес хочет, чтобы разработчики писали код, а не тесты;
                                                    3. никто не хочет тесты.

                                                    В моей новой команде выделенная роль автотестировщика была запланирована сразу.
                                                  0
                                                  > «поикать ошибки»

                                                  Отличное описание работы тестировщика!
                                                    0
                                                    В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана
                                                    Так может быть перестать называть специалиста, занимающегося повышением качества ПО «тестировщиком», и начать называть, скажем, «инженером по качеству» (программных продуктов)? Ну, конечно, от одного изменения названия мало что поменяется, но это — необходимое условие. Как там говорили — «в африке — живут негры», вот и выходит, что «тестировщик — тестирует». А не повышает качество.

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

                                                    Ну и отдельное спасибо за тэг ROI.
                                                      0
                                                      Получается, что тестировщики определённо нужны. Но из-за мнения работодателей, что тестировщики — это роль второго плана, платят им значительно меньше, чем должны были бы. Хотя, в последнее время, есть тенденция к увеличению зарплаты.
                                                        0
                                                        Хороший тестировщик кушать всегда будет, а очень хороший еще и на машине ездить!
                                                          0
                                                          Безусловно, но по-моему, очень хороший программист ещё и летать куда-нибудь будет.

                                                      Only users with full accounts can post comments. Log in, please.