Байка-1. Немного о “вреде” тестирования.

В ходе бесед с коллегами выяснилось, что еще минимум пара уважаемых человек (Денис Бесков и Макс Дорофеев) считают, что ценность внедрения тестирования по привычному сценарию “несколько преувеличена”.

Тема интересная и одного круглого стола для ее полного разбора будет недостаточно. Хороший круглый стол получился в Минске в августе. Частично эта проблема озвучивалась мной в январе на совместном семинаре московского отделения PMI и гильдии программных менеджеров. В планах поход в гости к Максу на “побухтеть” и обсуждение этой же темы на SQADays-10. Каждый раз обсуждение с вариациями.

На ближайшую встречу предложена следующие “базовые варианты”:
————————————————————————-
A. Тестировщики тормозят процесс разработки по Agile?
Q. Вопрос сформулирован неверно. Agile, не Agile - это перпендикулярное измерение. В малых проектах выделенный тестировщик тормозит процесс.

A. А в больших?
Q. Слишком часто тоже тормозит. Но по другой причине. В малых проектах имеет место эффект “чем больше команда, тем дольше делаем проект”. В больших же имеем эффект “ограничение системы перенесено на самый дешевый участок”.

A. Тестировщики необходимы.
Q. Не то чтобы необходимы, но иногда полезны. Иногда и только после того, как внедрены другие процессы.

A. Тестировщики нужны всегда!
Q. Меня берет сомнение, что уровень процесса тестирования может быть выше уровня процесса версионного контроля. Если версионный контроль на нуле, то надобность в выделенных тестировщиках вызывает сомнение.

A. Но ведь появление тестировщиков в индустрии принесло огромную пользу.
Q. В том виде, в котором происходило это внедрение - это скорее огромный вред. Модель разделения ролей “РУТ” (разработка, управление, тестирование) порочна.

A. Но без тестировщиков нельзя сделать сложный проект.
Q. Странно. Но делали же. Видимо, пацаны “не знали”.

A. Тестирование позволяет лучше удовлетворить заказчика.
Q. Учитывая, что большая часть дефектов вносится в систему до кодирования, мне кажется, в высшей мере странным ставить ОТК только после кодирования. Контроль до кодирования принес бы куда больше пользы.
————————————————————————-
PS. Этюды для тестировщиков. В этом тексте есть интересная фича не относящаяся к теме обсуждения, которая кажется серьезной багой. Багу найти легко. Описать фичу - сильно сложнее. Welcome.

Комментариев: 12

  1. Sergey Atroschenkov написал:

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

    И да, селф-тесты и юнит-тесты - сугубо фишка разработчиков? О’кей.

    Вообще ощущение тестировщиков складывается, по бухтелкам, как действительно ОТК, которое бракует, а не предоставляет информацию о качестве продукта.

    1. Как можно тормозить процесс? Скорость предоставления продукта конечному пользователю - да, тормозят. Способствуют предоставлению продукта удовлетворяющего пользователя? Да, не на прямую. Снимая этот головняк с программистов и давая возможность свободно творить этим странным ребятам, видящим в коде ЕГО (смысл).

    2. Необходимо тестировние, а не тестировщики, для получения информации - годен продукт или нет к выпуску, продажи. Если это будет бета-тестирование\бесплатная версия - окей. Хотите будет выделенный ресурс, хотите - будет TDD, хотите - будет контроль версий. Смотрим на проект и на рынок.

    3. В индустрии не было выделенных тестировщиков, но вспомните свои первые БК - либо местный гуру гонял программу, либо сами пробовали и проверяли хотя-бы бизнес-случаи. Иначе зачем её писать, если она ничего не делала бы?

    4. Заказчика удовлетворяет менеджмент, маркетинг, продавцы. Тестировщики просто предоставляют информацию о том, что в продукте работает, что нет.
    А на ранних стадиях тестировщиков (аналитиков собирающих грамотные требования) нет?

  2. tapot написал:

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

    И к тому же возникает вопрос - что за привычный сценарий внедрения тестирования?

  3. Sergey Vysotsky написал:

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

    Проблема в том, что многие компании сейчас применяют древний подход к тестированию, сформированный тогда, когда починка бага на стадиии составления дефектов была дешевле починки в разработке и в сотни раз дешевле починки после релиза. Тогда был хардкорный подход где тестирования начиналось с тестирования требований (многие, кстати, этот пункт вообще игнорируют) и до того момента, когда тестировщик фактически запрещал релизить плохой продукт. Фактически вся его работа была в том, чтобы находить баги.

    Тогда и системы и код были сильно проще.

    Фактически это приводило к удорожанию продукта и при этом мы _иногда_ получали очень качественный продукт.

    СЕйчас качество продукта во многих случаях вопрос вторичный. Гугл может себе позволить профукать данные с почты у 150K пользователей и не почешется. Ну да, проблему устранит. Фликр грохнул не те платные аккаунты и тоже пережил без особых последствий. Твиттер - сервис часто падающий и плюющийся китами и роботами вполне всех устраивает. МТС рожает огромные счета из ниоткуда, судится, потом говорит “ой, ошибочка вышла”. Все поржали и разошлись.
    Для ряда компаний (не для всех) выгоднее чинить проблемы по факту обнаружения их пользователями, чем третить бешенные усилия на то, чтобы уничтожить их все. То есть качество само по себе далеко не всегда является единственной ценностью.

    В итоге для ряда кампаний стало проще заниматься тестированием в плане внедрения практик и тестов для улучшения кода. Юнит тесты, санити тесты, бенчи и т.п. Все что быстро, легко автоматизируется и поддерживается, позволяет “поиграться” с системой и очень нравится менеджерам (метрики, покрытие кода и куча всего другого что ничего толком не говорит о качестве кода).
    У этого тестирования есть свои проблемы - все фигачат фреймворки и никто не говорит о том что оно на самом деле делает. Всех волнует время выполнения, количество тестов, инструменты и т.п., но трудно найти что-то о том что делают тесты, кто анализирует результаты и сколько денег они спасли/убили (а про обычных тестировщиков последний пункт волнует всех).
    Так же у него очень неточные результаты, мы рискуем обмануть себя самих этими тестами, т.к. перестаем задумываться над тем что же на самом деле делает приложение и насколько точную информацию мы получили (нас волнуют только красные и зеленые лампочки и мы можем стать “собакой Павлова”). Некачественные тесты так же сильно вредят такому подходу.

    В итоге тестирование может ускорить и удешевить разработку (см. выше), но это уже не то тестирование где сидят дети и жмакают бесцельно или по инструкции кнопочки.
    Можно улучшить качество создавая умные системные тесты там где надо, но это опять не сотни обезъянок с чеклистами.
    Производительность, юзабилити, масштабируемость и прочее прочее - трудно отрицать что оно не нужно, но это опять же не то тестирование, которое завещали нам деды.
    Обнаружение и работы со сложными проблемами, вроде анализа проблем в продакшене, работы с огромными структурами данных и т.п. - ценность опять не в чеклистах, а в людях способных в этом разобраться.
    Можно помочь бизнесу сократить количество машин в дата-центрах. Чем больше проект тем больше очевидного профита.
    Отличные исследовательские навыки и умение задавать правильные вопросы - все по Болтнону, но опять же не укладывается в привычную картинку мира.

    Качество это в первую очередь ценность для кого-то (читать Вейнбюерга). Если тестировщик не может объяснить какую ценность он создает, кроме “ну качество это очень важно” или “мы очень важны для проекта”, то он скорее всего и не создает никакой ценности. Он просто греет воздух.
    Тестирование это поиск информации для того чтобы обеспечить ею решения (читать опять Вейнберга). Если менеджмент/команда/заказчик не знает своих рисков, то тестирование должно или показать ему риски, которые он не учел или убираться, потому что оно греет воздух. Если тестирование не может как-то проинформаировать риски которые менеджмент/команду/заказчика беспокоят - аналогично.

    ЗЫ: Сумбурно получилось, потом в бложике у себя накатаю более развернуто.

  4. kirlionik написал:

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

  5. SALar написал:

    Ограничим дискуссию. Будем рассматривать только:
    * Есть выделенная роль тестировщика.
    * Тестировщики занимается только тестированием и преимущественно black-box тестированием.
    * Кроме тестировщиков таким тестированием больше никто не занимается

    TDD и прочее не рассматриваем.

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

    Это затравка для круглого стола. Вот на нем уже будут обоснованные доводы.

  6. kirlionik написал:

    Жаль не смогу приехать, а так бы с удовольствием присоединился к обсуждению.
    Я из Питера.

  7. SALar написал:

    > Жаль не смогу приехать, а так бы с удовольствием присоединился к обсуждению.
    Я из Питера.
    Это не первый и далеко не последний раз.
    Будет шанс на SQA-10. Кроме того “партию можно играть и по переписке”.

  8. orie написал:

    В тексте поменяны местами “Q” и “A”.

    На фичу не очень похоже, нет ;)

  9. pancakyes написал:

    Sergey Vysotsky,
    >потом в бложике у себя накатаю более развернуто

    А можно ссылку на бложик?

  10. Sergey Vysotsky написал:

    Да нет, отличная фича на самом деле. Учитывая, что вопросы и ответы порой не связаны вообще.

  11. SALar написал:

    > В тексте поменяны местами “Q” и “A”.
    Вы нашли то, что кажется багом. Но ведь только в первых двух парах “A” - это вопрос.
    Осталось найти фичу ;-) .

  12. Sergey Vysotsky написал:

    Тащемта вот: http://goblingame.blogspot.com/2011/10/blog-post_28.html

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.