Пользователь
0,0
рейтинг
20 июня 2010 в 20:02

Разработка → Живут, как тестировщик с программистом

картинка для привлечения внимания

Часто задают вопрос: как быть с тем, что программисты не любят тестировщиков, считают их работу второстепенной, пишут неряшливо – «все равно ведь проверят» либо мстят за каждый найденный баг и пытаются не признавать их за баги.
Или наоборот, программисты жалуются, что тестировщики злорадствуют, найдя баг, и считают личным достижением, если программист наделал много ошибок.

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

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

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

Как раз сейчас я краем глаза смотрю запись гран-при Канады Формулы 1.

Феноменальный пример слаженной, однонаправленной командной работы. Есть 2 части команды: собственно, перформер, пилот, человек, который на виду, который пожинает лавры в глазах публики, но который на каждой пресс-конференции говорит про работу всей команды, и есть та самая команда-тыл, которая смотрит на его работу на трассе, анализирует её и говорит в шлемофон: «Кубица сменил резину на жесткую, Барикелло тоже, не дай себя обойти». А теперь представьте, что команда отлавливает ошибки пилота и злорадно сообщает ему «Из-за того, что ты не сменил резину на прошлом пит-стопе, потерял 2 секунды во время дождя». Как только части команды начинают работать друг против друга – она обречена на провал!

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

Признаки того, что ваши программисты и тестировщики не Правильные:

— от тестировщиков всерьез звучат фразы «наколбасил им багов, пусть теперь разгребают»

Это идет от старших тестировщиков и от общей атмосферы в коллективе. Я ещё не видела ни одного неопытного тестировщика, который бы думал так с самого начала.
Если старший коллега хочет вырастить злобное чудовище, которое радуется при нахождении бага не потому, что теперь пользователь получит на одну ошибку меньше, а потому, что насолил программисту, то ему стоит продолжать в духе «Давай, сынок, покажем этим кодерам, что за какашку они выпустили бы без нас ». Но если он хочет, чтобы тестирование работало не против программирования, а совместно с ним на качество продукта, и ведет себя соответственно, то никогда в его команде не будет такого.

— от программистов слишком часто звучит презрительное «это не баг»

Это значит, что каждый баг воспринимается как личный тычок: «Это твоя личная ошибка, слышишь? Ты непрофессионал. Хорошие программисты пишут без ошибок, а ты баг сделал, эх, ты». Думаю, что здесь проблемы надо искать в личности такого специалиста. Адекватный человек, направленный на развитие, использует любую критику для совершенствования, а не для обид. Тем более, когда критикуют работу, воспринимать это как личную критику – выглядит, как болезнь.

— программист не проверяет результат своей работы перед передачей в тестирование

«Моё дело писать код, а их дело проверять», «Ну а их-то зачем понанимали?» — можно услышать в таких командах. Это элементарное отсутствие гигиены, работа ради «отписаться». Где вы видели журналиста, который не перечитывает свою статью перед тем, как передать её в редактуру? Если в коллективе есть программист, который проповедует такой подход, его нужно как можно скорее ликвидировать. Какой бы он ни было классный специалист.

— тестировщики заносят баги, не интересуясь их дальнейшей судьбой

Это позиция «с моей стороны пуля вылетела» с другой стороны.
Цель тестирования – найти как можно больше ошибок в приложении, безусловно, имеет право на жизнь на определенных этапах тестирования. Только в этом определении не хватает второй части. Исправить. В силах тестировщиков донести важность важных багов до программистов и честно сказать про низкий приоритет низкоприоритетных. Если программисты знают, что их тестировщики зря хайприорити не поставят, то они серьезно относятся к каждому такому багу. А вот массированная атака багами без интереса к их дальнейшей судьбе, без подвижек в сторону облегчения их локализации, действительно является результатом работы только на себя.

— эффективность работы тестировщиков измеряется количество найденных багов, а мера качества работы программистов обратно зависит от этого количества

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

В то время, как только подход «максимум найти и тот же максимум обезвредить» эффективен, на мой взгляд, и работает действительно на цели продукта.

Уверена, что список можно продолжить.

При этом, чувствуете? В первом и четвертом случае корень проблемы в Просто Тестировщиках, во втором и третьем — в Просто Программистах, а в пятом — в Просто Менеджерах. Оказавшись в одной из таких команд, первым делом нужно понять, от кого исходит этот вирус и искоренить его. Либо уйти. Потому что продуктивной работы все равно не получится.
Юля Нечаева @jnechaeva
карма
114,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (116)

  • +11
    Чтобы не «грызлись» тестировщики и программисты, должен быть правильный управленец — опытный, мудрый и правильно просчитывающий минимум на ход вперед. Иначе — «Когда в товарищах согласья нет — на лад их дело не пойдет и выйдет из него не дело, а только мука...»
    • 0
      Знаете, пара моих хороших знакомых (один ведущий QA, другой — программист-разработчик, тимлид) независимо между собой считают, что между тестировщиками и программистами должно быть некое «противостояние».
      Всему, безусловно, надо знать меру — т.е. это не должно быть конфликтом; но вот замечено, что когда отношения между разработкой/тестированием немного «в контрах» — это очень эффективно сказывается на рабочем процессе в целом. Возможно потому, что появляется некий азарт или личная заинтересованность сделать работу лучше.
      • 0
        Вы же согласитесь, что здоровая «контра» подразумевает «Ну что, ребята, прочешем продукт вдоль и поперек, чтоб ему жарко стало», а не «щас я им багов наколбашу и домой уйду, а они пусть разбираются, если нормально кодить не могут».

        Наоборот тоже: «Ого, молодцы, сколько всего понаходили» против «опять багов навалили, достало уже»
        • 0
          Вот знаете — нечто среднее на самом деле оптимально :-)
        • 0
          Добавлю. Всё это должно происходить под контролем тим лида проекта. Который не будет оставлять разность во взглядах тестировщиков/программистов на самотек, а сможет грамотно сказать, чья точка зрения тут правильная (баг это или фича, например, можно ли закрыть баг-таск или сменить его категорию, и т.п.)

          Вообще, на 99% конфликты возникают там, где людям находящимся на одном уровне компетенции говорят «ну вы там как-нить сам договоритесь». Иногда они договариваются, но в очень, очень многих случаев возникает конфликт — из-за того что непонятно, чье мнение главнее.
    • 0
      Согласна.
      Рыба с головы подгнивать начинает.

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

      В любом случае исправить или привентировать ситуацию в силах только менеджер/тимлидер/нанимающий на работу.

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

      Ну и терки на тему «я нафигачил тыщу багов за день в коде который вы месяц рожали» всегда отжирают кучу времени. Если менеджер не в состоянии эти «утечки» обнаруживать и грамотно локализовывать, то команде это и подавно не нужно.
  • +1
    — от тестировщиков звучат фразы «наколбасил им багов, пусть теперь разгребают»

    Немного некрасиво, но ничего страшного в этом нет. Это лишь личное мнение человека, который выполнил свою работу, а остальное его не волнует. Это нормально.

    — от программистов слишком часто звучит презрительное «это не баг»

    В это случае пинать нужно менеджера, так как скорее всего такой ответ программиста означает, что тесткейс, с которым в данном случае работал тестировщик, неверен. Соответственно нужно изменить тесткейс. Если же все же это дефект, то пусть уже менеджер разбирается с тимлидом, это не проблема тестировщика. Он лишь проверил тесткейс и зарепортил проблему, за это ему платят.

    — программист не проверяет результат своей работы перед передачей в тестирование

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

    — тестировщики заносят баги, не интересуясь их дальнейшей судьбой

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

    Если же процесс привязывает тестировщика к каждому дефекту, то тут да, волей-неволей придется интересоваться судьбой дефекта. иначе он не будет закрыт. В таком случае бороться с теми, кто не интересуются судьбой дефектов, очень просто — достаточно завести любую более-менее продвинутую программу трекинга дефектов, и менеджеру все будет видно как на ладони.

    — эффективность работы тестировщиков измеряется количество найденных багов, а мера качества работы программистов обратно зависит от этого количества


    В то время, как только подход «максимум найти и тот же максимум обезвредить» эффективен, на мой взгляд, и работает действительно на цели продукта.


    Не нужно специально искать максимум дефектов. Если тестировщики нашли ноль дефектов, это не значит, что они плохие. Тестировщику достаточно проверить все тесткейсы по тестплану, и отрапортовать «все OK» или «такие-то тесткейсы проходят неверно, вот скриншот и логи».

    В общем, команда тестирования не должна нести ответственность за дефекты в продукте. За это отвечают разработчики. Команда тестирования несет ответственность только за то, что их репорт соответствует действительности. То есть они прошлись по всем тесткейсам, и напротив каждого написали в отчете «проверено с таким-то результатом».

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

    Да, бюрократия конечно… но именно это и будет наиболее полезно для продукта. И конфликты с разработчиками сведутся к минимуму, так как разработчику глупо обижаться например на программу автотестирования (JMeter, и т.д.), а при правильно организованном процессе тестировщик сам по себе играет роль как раз такой программы.
    • +3
      А откуда берутся тест-планы? Их составляют и модифицируют все те же QA-инженеры. Всем вроде ясно, что априори невозможно составить достаточно полный тест-план, что тест-план эволюционирует вместе с продуктом по мере уточнения требований.

      Если тестировщик достаточно трепетно относится к продукту, то он будет сообщать о проблемах не зафиксированных в тест-плане. Так же как и программист будет заботиться о всяких мелочах, даже если их нет в спецификации.
      • +1
        Да, работа с тест планом должна быть частью процесса. Но вовсе не обязательно, что их составляют те же QA-инженеры, что и проводят тестирование. Часто их составляют аналитики, разработчики (тимлиды), да и сами менеджеры тоже могут подключаться. Держит под контролем этот процесс QA менеджер, который несет ответственность за соответствие тест-плана проектным спекам.

        Например, часто IT компании в Европе пишут тестпланы силами своих штатных сотрудников, а непосредственно тестирование проводят компании-аутсорсеры из Индии.
    • +5
      >> Немного некрасиво, но ничего страшного в этом нет. Это лишь личное мнение человека, который выполнил свою работу, а остальное его не волнует. Это нормально.

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

      >> Cоответственно нужно изменить тесткейс. Если же все же это дефект, то пусть уже менеджер разбирается с тимлидом, это не проблема тестировщика.

      Я здесь говорю о явном отфутболивании, которое является клиническим случаем. А проблема это или не проблема тестировщика — зависит от того, как он относится к проблемам команды и проекта. Можно действительно делать то, за что платят, и спокойно переоткрывать баги по несколько раз, пока менеджер не придет, а можно самому прийти к менеджеру и сказать: «че за фигня? Я время трачу на разборки, хотя мог бы погонять приложение эксплоративно или чего ещё полезное сделать»

      >>Это, конечно, плохой признак. Но в любом случае, это проблема команды программистов, а не тестировщиков.

      то же самое, что и в предыдущем пункте

      >>Тут все зависит от процесса тестирования.

      Согласна. Но в гибком процессе эффективнее, чтобы тестировщики были в курсе дальнейшей судьбы дефектов.

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

      Если говорить о том, что "«нефиг заниматься не своим делом, за это не похвалят» — то тут у меня такое мнение: все, чему ты учишься, добавляет тебе стоимость (карму, если хотите). В этом проекте тебя считали выскочкой и шикали — в другой компании тебя с руками оторвут и денег дадут больше, и ответственности.

      Такой момент: набирая себе людей (я руковожу отделом тестирования), я смотрю на то, в каких проектах им доводилось работать. Если в таких, как Вы описываете, то мне такие не нужны. Мне дорого держать 10 исполнителей и менеджера-координатора над ними. Лучше взять 5 специалистов, которые будут не только тесты проходить, но и писать их, и приоритеты расставлять, и метрики собирать, и с программистами коммуницировать, и с дизайнерами, и с пользователями.
      Мой выбор такой, именно поэтому и атмосфера у меня в отделе такая, что ничего из описанного в посте нет.

      • 0
        Я здесь говорю о явном отфутболивании, которое является клиническим случаем. А проблема это или не проблема тестировщика — зависит от того, как он относится к проблемам команды и проекта. Можно действительно делать то, за что платят, и спокойно переоткрывать баги по несколько раз, пока менеджер не придет, а можно самому прийти к менеджеру и сказать: «че за фигня? Я время трачу на разборки, хотя мог бы погонять приложение эксплоративно или чего ещё полезное сделать»

        Не нужно ходить к менеджеру и говорить «че за фигня». Если отфутболивание имеет место, то тестировщику нужно просто повторно ассигнить дефект не на программиста, а на самого менеджера.

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

        Уставший человек в конце рабочего дня поставил жирную точку, и высказал своим коллегам свое мнение о состоянии проекта. Лучше было бы промолчать, но мы же все люди, что тут такого? Если кого-то неопытного он с толку этим и сбил, так это нормально, пусть неопытный учится, и становится опытным. В любом случае, на работе это не должно сказаться вообще никак.

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

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

          мы об одном и том же
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Это ты к чему?
      • +10
        Может его благодаря этой статье настигло озарение?
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Так и знал что вы тестер!
      • +4
        Значит не настигло.
  • 0
    Ну это происходит на корпоративном уровне.
    А на уровне OpenSource всё обстоит гораздо лучше. Тестеры пишут багрепорты, программеры выпускают багфиксы. В итоге все довольны.
    • +2
      С коммерческой разработкой нельзя сравнивать. В OpenSource обычно нет жестких сроков, начальство не прессует ни разработчиков, ни тестировщиков, ответственности тоже особой ни у кого ни перед кем нет. Кто-то зарепортил дефект, программисты ему сказали спасибо. Все спокойно, никого зарплаты не лишили, но никто ничего и не получил. Чего волноваться-то и конфликтовать? Что-то или кто-то не нравится — иди в другой открытый проект.

      P.S. Я не имею в виду OpenSource проекты, которые выкуплены коммерческими компаниями и фондами. Там люди работают за деньги, часто немалые, и там-таки тот же прессинг и такие же дедлайны, что и в коммерческих разработках, со всеми вытекающими.
    • 0
      Тестеры в опенсорсе? Не так много проектов где все так радужно, чаще картина другая: Какой то пользователь нашел баг и отписался о баге на локальном форме или хабре. А то и вовсе забил. Разработчик случайно уивидел багу и подумал что когданить починит. Кто сознательный отметил в багтрекере. И это не факт что разработчик сразу пойдет ее фиксить, у него как правило, куча фич интересных еще не написано.
      Когда же техпроцесс выходит на серьезный уровень за исключением оперативности выхода патчей, все становится очень похожим на корпоративную разработку. Разве что иногда чуток бюрократии поменьше.
    • 0
      Эээ
      По-моему точно так же обстоит, только программисты еще могут на многие баги забивать, ибо они просто не могут их воспроизвести. Ну например мне лично тяжеловато воспроизводить баги, возникающие в Макоси
  • +2
    Главное чтобы в команде было понимание того, что у тестера и программиста одна общая задача — предоставить качественный продукт клиенту, которым можно гордиться всем сотрудникам принимающим участие в разработке и тестировании.
    • +1
      вот да, именно!
  • +10
    Девушка-программист, да еще и смотрит Гран-При Формулы 1. Вы замужем?
    • +9
      да, а что?
      • +23
        в вашем ответе лишнее либо «да», либо «а что»…
        • +4
          Это оператор IF. ))
          • +1
            ? да: а что;
        • 0
          это гибкий метод исключение бага!
      • НЛО прилетело и опубликовало эту надпись здесь
      • +2
        — Девушка, вы заняты сегодня вечером?
        — Да, а что?
    • +4
      поправка — тестировщик и менеджер
      замужем, потому и смотрю :)
    • +4
      Девушки тестеры редко не замужем бывают Ж)
      • –3
        ))))))
  • +4
    А вообще я видел не раз ситуации с конфликтами меджу тестировщиками и программистами, и даже сам не раз участвовал по молодости, причем с обоих сторон. Стандартное решение менеджера в таком случае: тестировщики все дефекты ассигнят не на разработчиков напрямую, а на менеджера, а менеджер уже ассингит на того или иного программиста (обычно на тимлида). Разборки при этом между программистом и тестировщиков не допускаются, каждая сторона работает с менеджером.

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

      Буквально сегодня рассказывали историю, как в одну успешную компанию не взяли гениального архитектора потому, что он прямо на собеседовании заявил: «Я не приемлю изменений. Ни одно изменение ни приводит к добру в проекте. Всегда с ними жестко боролся и буду»

      Это sofy skills, которые тоже очень важны при найме специалиста.

      В моей прошлой компании приходилось набирать по 20 человек за месяц на новые проекты, сложно было смотреть ещё и на отношение человека к работе, потому что на рынке специалисты вообще дефицит. Но, тем не менее, отказывали потенциальным вирусам.

      И исходить правильное отношение к работе и к коллегам должно от менеджера, в первую очередь. Если он, конечно, не координатор работ, а действительно человек, отвечающий за свой проект.
      • –1
        Буквально сегодня рассказывали историю, как в одну успешную компанию не взяли гениального архитектора потому, что он прямо на собеседовании заявил: «Я не приемлю изменений. Ни одно изменение ни приводит к добру в проекте. Всегда с ними жестко боролся и буду»

        Вы мыслите категориями менеджера, а теперь пожалуйста посмотрите на это категориями бизнеса. Если архитектор действительно гениален, значит это известный человек, его можно показывать заказчикам, брать под его имя проекты по очень высоким рейтам, и т.д. И заказчики будут счастливы платить, еще бы, ведь их проект будет проектировать сам Х!

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

        Но речь не об этом. Моя мысль в том, что правильно организованный процесс разработки, включая процесс тестирования, способен свести на нет влияние подавляющего большинства вирусов и тараканов в головах. Не нужно требовать от людей полной лояльности, любви к проекту, и т.д. Но нужно их обеспечить четкими инструкциями что делать в тех или иных случаях. Вот где-где, а в QA это сделать на порядок проще, чем в программизме. То есть, нужно построить машину, работающий механизм, а строить в офисе комфортный санаторий — это уже вторично, хотя тоже не помешает.
        • 0
          Вы в аутсорсинге работаете?

          Я мыслю категориями бизнеса, только другого. Если этот продукт моя компания выпустит под своим именем, то ей критичен каждый вздох каждого члена команды. Гениальная архитектура не спасет продукт, если команда будет противостоять изменениям, которые требует рынок от продукта.

          Про четкие инструкции — повторюсь: «Мне дорого держать 10 исполнителей и менеджера-координатора над ними. Лучше взять 5 специалистов, которые будут не только тесты проходить, но и писать их, и приоритеты расставлять, и метрики собирать, и с программистами коммуницировать, и с дизайнерами, и с пользователями.»

          Конечно же, зависит от бизнеса компании, Вы правильно заметили. В аутсорсинге продается предсказуемость. В продуктах — решает лояльность и любовь к продукту.
          • –1
            Работаю не в аутсорсе, раньше работал. Последние два года работаю на клиента, у которого как раз свой продукт, и этот продукт уже более 10 лет на рынке.

            Если команда противится изменениям, значит нужно выслушать обоснования, почему она противится. Очень вероятно, что эти обоснования весьма весомы, и к ним нужно прислушаться. Далее. Маловероятно, чтобы «рынок требовал» от продукта изменения в архитектуре. Рынок обычно диктует бизнес-требования. И если архитектор действительно опытен, но его архитектура достаточно гибка, чтобы можно было расширять продукт согласно этим требованиям.

            Далее, я не предлагаю нанять 10 исполнителей + менеджера над ними. Я предлагаю построить процесс таким образом, чтобы существующие 5 специалистов могли работать так, чтобы конфликтоопасные ситуации не возникали. Вы же предлагаете возложить на людей тяжкий груз борьбы с возможными проблемами… Не лучше ли таких ситуаций не допускать вообще? Давать спецам и писать документы, и тестить, и общаться с кучей разного народа конечно можно, но это должно быть организованно, системно, ходы должны быть просчитаны. Это вполне возможно сделать, и делается.

            Лояльность и любовь к продукту, конечно, не помешает, но нельзя требовать это от людей. Нужно признать, что все работают за деньги, то есть продают компании свое рабочее время, и за перспективы. Только в этом случае процесс будет стабильным. Лояльность и любовь к работе/компании/продукту, как говорят на западе, это способ платить меньше денег, и при этом требовать больший объем работы. Это не хороший путь, на это нельзя делать ставку.
            • +2
              Оставим в покое архитектора. Я вполне понимаю, почему в этой конкретной компании такой специалист бы принес больше вреда, чем пользы. А разговор о сферическом архитектора не имеет смысла.

              >> Лояльность и любовь к продукту, конечно, не помешает, но нельзя требовать это от людей.

              Требовать постфактум нельзя, конечно. Но можно а) не брать таких, для которых это противно по природе, и б) создать и поддерживать такую атмосферу.

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

              Оба имеют право на жизнь. В обоих важно не запустить один раз и полагаться, что само выживет, а постоянно ревизировать, выявлять проблемы, оздаравливать.

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

              В обоих вариантах, кстати, клиники, которую я описываю в посте, как проблемы не возникнет.

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

          • –1
            В продуктах — решает лояльность и любовь к продукту

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

            Но на все проекы это нельзя проецировать. Как думаете, интересно ли программисту из года в год заниматься одним и тем же бухгалтерским пакетом? Стоит ли ожидать любви к такому продукту? А ведь таких продуктов большинство. Так что IMHO все же системный подход решает.
            • +3
              если Вы про Иннову, то на сегодня мы не разрабатываем игры, а лишь паблишим. там совершенно про другое все.
              >> Тестировщикам тоже может быть интересно рубить орков целый день, изредка отчитываясь о дефектах…

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

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

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

              >>Так что IMHO все же системный подход решает.
              если Вы системным подходом решаете проблему, о которой я говорю, отлично!

              • 0
                Им интересно решать задачи. Рефакторить для совершенствования. Предлагать решения. (Конечно же, с ограничением, чтоб не разрабатывать ради разработки).

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

                Вообще, Вы пишите очень правильные вещи, заметен высокий уровень знаний. Очень даже. Так что я даже боюсь вступать в спор… Просто по моим наблюдениям те команды, которые делают ставку на энтузиазм, лояльность, и интерес к работе, обычно имеют весьма и весьма серьезную текучку кадров. Ибо это все весьма нестабильно. И наоборот, команды с проработанным процессом и формальными отношениями в работе (вплоть до бюрократизма) весьма стабильны, и в большинстве классов задач очень эффективны. Конечно, на, скажем, рисковых проектах класса «стартап» такое работать не будет, это ниша для фанатов… но всему свое место.
                • +1
                  >Вы, вероятно, говорите о программистах, с ними проще немного. Но в данной теме речь идет и о тестировщиках. Неужели они любят такой продукт, причем настолько, что эта любовь все решает и принципиально важна для работы, как Вы написали выше?

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

                Думаю достойно отдельного поста :)
                • +1
                  принято, сделаю ))
                  • 0
                    спасибо, ждём :)
              • 0
                >Я рассказывала на майской конференции по тестированию о том, что на самом деле делают мои ребята (те, что играми занимаются) на работе. Если интересно — могу рассказать подробнее.

                Думаю достойно отдельного поста :)
                • 0
                  упс, дабл пост «Some error… We know...»
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        На самом деле это основное, для чего он и нужен :)

        Впрочем, учитывая, что менеджер имеет больше рычагов влияния на подчиненных, включая финансовый, вероятность возникновения конфлакта в данном случае уменьшается на порядок.
    • +1
      вот ещё, что подумалось:
      >>Стандартное решение менеджера в таком случае: тестировщики все дефекты ассигнят не на разработчиков напрямую, а на менеджера, а менеджер уже ассингит на того или иного программиста (обычно на тимлида).

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

      К примеру, у нас баг, найденный на продакшне, как правило, фиксится и выкатывается в тот же день. Это означает быстрый фикс и быстрое регрессионное тестирование. Тут нельзя работать через менеджера.

      В то же время, я знаю системы, где запрос на хотфикс от поступления до попадания в следующий билд живет полгода.

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

      • 0
        Сходу:

        — Критичные дефекты можно постить с более высоким приоритетом. Вы же пользуетесь программами-багтрекерами, знаете, какие возможности они предоставляют?
        — Можно установить правила, по которым дефекты разных релизов автоматически назначаются разным адресатам, например критичные дефекты продакшена — напрямую разработчику (с обязательной копией всем задействанным лицам и руководсту.
        — Разработчика и тимлида можно включить в CC при постинге дефектов, и им будет идти письмо с описанием дефекта и ссылкой на него. То есть даже если менеджер протормозит, то информацию по дефекту они все ранво получат.
        — Менеджер может просматривать дефекты не раз в день, а раз в час-два.
        — И т.д., масса технических и административных решений.

        Да, это все — лишний некоторый напряг для менеджера (с другой стороны, зачем нужен менеджер, который не находит время периодически узнать состояние проекта?), но если он допустил в своей команде войну между отделами, то пусть расхлебывает, а не кофе пьет, и не заедает на бесполезных многочасовых митингах, или где там он тратит время, что не может в багтрекер глянуть, получив сообщение с высоким приоритетом.
  • +3
    А фотка не этого сезона. Сейчас дозаправок нет :)
    • –1
      поправка. сейчас дозаправки есть.
      • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Можете уточнить? Насколько мне известно, дозаправок с этого сезона нет.
        Да, да, теоретически можно дозаправить в крайнем случае, но с использованием машин низкого давления. То есть не в гоночном режиме.
        • 0
          именно так. в регламенте запрещены заправочные автоматы кроме тех, которые дают стандартное давление (около 0.5 л/сек, если я правильно помню). раньше формульная бензоколонка выдавала 12 литров в секунду.
          • 0
            А, ну хорошо. А то я уж думал, что чего-то не понимаю.
            Вы уж меня извините, но это бувоедство — говорить «поправка. сейчас дозаправки есть». Ясно, ведь, что человек имел в виду такие «правильные» дозаправки, которые на фотографии изображены.
            Тем более (если уж буквоедствовать до конца), что если они разрешены, это не значит, что они есть, т. е. используются.
            • 0
              был шанс, что Virgin придётся использовать их в начале сезона.
    • 0
      Феррари под номером 1 последний раз ездила в 2004 году:))
      • 0
        В 2005-м. В 2004-м Шумахер выиграл титул => в 2005-м у него был номер «1».
        • 0
          Кими забыли))) Чемпион 2007.
      • 0
        Это F2003 с Шумахером за рулём. подозреваю, что ещё не в модификации GA — на тестах в межсезонье, например.
  • +1
    А почему перед тестировщиком с программистом не может стоять цели выпустить качественный продукт в минимальные сроки?
    Я просто с тестерами ни разу не работал. Сам у себя баги ищу.
    • +2
      Почему же не может? Может и нужет. Если это действительно нужно.

      Просто бывает, когда нужно «тупо отработать бабки», тогда эффективность невыгодна. Страдает продукт, страдают люди. Страдают следующие хорошие продукты, в которые эти испорченные люди потом придут работать.

      Мне рассказывали про программистов, которые прямо так и говорят на полном серьезе: «Я сегодня делал баги, пусть ищут».

      Про заставить программистов тестировать — это вообще отдельная песня. Стереотип потому что, что занятие это второстепенное. Но в выпуске продукта второстепенных задач нет, Вы согласитесь, я уверена. Потому что Вы ответственность за свой продукт чувствуете.
  • +3
    Интересно, это у меня одного возникают вопросы типа:

    — Это же через какую задницу надо построить работу в коллективе, чтобы такие проблемы вообще появлялись?
    — Это же как так надо набирать людей, чтобы потом огрести таких проблем?

    Я работал тестировщиком два месяца. Почему-то мне хотелось, чтобы продукт нормально работал. Я работаю программистом третий год. Что со мной не так, что меня в принципе не возмущает никакой баг, репортнутый клиентом или тестером, вне зависимости от того, ерундовый он по своей сути или нет?

    За 3 года работы в фирме ни в своем отделе, ни в других не видел даже похожей ситуации.

    Менеджеров по персоналу надо набирать по количеству извилин в голове, а не по длине ног. Чтобы потом не хвататься за голову, что каждый второй работник не умеет работать в команде.

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

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

      А извилины менеджера по персоналу тут вряд ли помогут. Если они не сталкивались с такими проблемами, они не смогут идентифицировать их на собеседовании.
      • 0
        Когда-то были ситуации вида «это не баг».
        Де факто это проблема постановки тест кэйса. в этом виноват кто угодно, но не тестер.
        • +1
          «не баг» — нормальная ситуация.
          много «не баг» — ненормальная ситуация, у которой 2 причины:
          1) это действительно не баги, тогда смотрим на тесты, на тестеров, на требования, в ту сторону вобщем
          2) со второго раза программист признает, что это таки-баг. И если это тенденция, то это не здорово. Я об этом. Отфуболивание.
          • +1
            Та права. После полугода я стал уделять больше времени описанию изменений с точки зрения пользователя.

            Я прогер.
    • 0
      Ваша позиция не удивляет: вы были по обе стороны «фронта» (:
      А вот те, кто не обладает такой профессиональной политкорректностью — и строят такие команды, и участвуют в таких конфликтах.
  • 0
    Тестировщик лучший друг человека программиста, потому как именно он, может стать тем кто спасет программиста от позора. Даже у лучших бывают ошибки, а человек который помогает сделать код лучше, в принцепе не может быть врагом.
    • +1
      программиста от позора, продукт от провала, компанию от банкротства :)
      всем вместе над этим нужно работать, в этом суть

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

          Ну раз так то да, это более справедливо. Хотя непонятно, если над каким-то кодом работало человек пять, что, специальное расследование проводится, кого из них премии лишать?
          • 0
            Нет. Над новой функциональностью обычно работает 1-2 программиста, они за нее и отвечают. Потом тестеры тестят написанное, после чего программисты исправляют найденные баги. Это может повторяться в особо сложных случаях несколько раз, и затрагивать другие тестпланы… Но это отдельная песня :)
            Короче, рано или поздно код попадает к клиенту и проходит процедуру «тестирования при принятии» (acceptance tests). Если клиент находит во время процедуры больше багов, чем положено — то тестер и программист, вероятно, лишатся нескольких сот евро в конце года. Пока что, бог миловал, такого у нас не было. Но сам принцип в качестве фактора, объединяющего программистов и тестеров, работает очень неплохо.
            То, что клиент найдет после того, как принял функциональность — на размер премии не влияет.
            • 0
              Кстати, а как быть, если программист и тестер например устроились на работу в январе, уволились в ноябре, потом этот код будет дорабатывать другой, новый программист, и тестировать новый тестер… а недели через три, в конце года, заказчик найдет кучу багов (в коде первого программиста), то кто-то финансово пострадает?

              Извините за такие вопросы, просто интересно, теоретически, как такая система может работать… я не могу себе представить, чтобы это было жизнеспособно. Возможно я ошибаюсь.
              • 0
                Не знаю :) у нас текучки почти нет.
                Чисто теоретически, если такое произойдет, думаю что будет сорвана поставка, пострадают финансово все, даже те, кто не разрабатывал этот код, так как премия еще и от размера прибыли зависит, и от других показателей. Но функциональность прийдет к покупателю тогда, когда количество багов в ней согласно тест-плану будет стремиться к нулю.
                Вообще, у нас все по плану, по процессам сделано. Очень четко, размеренно и неожиданностей не бывает.
                • 0
                  Согласен. Если сторона заказчика тестит по тому же тест-плану, что и ваши тестеры, тогда да, почти никаких шансов, что они какие-либо дефекты вообще обнаружат.
                  • 0
                    Когда продукт сложный — бывает всякое… двусмысленности, недоразумения. На это закладывается некоторое количество багов, за которые никто не спросит. Если не будет багов вообще — премию даже увеличат на какой-то процент.
              • 0
                Такого еще не может быть потому, что другому, новому программисту тушить пожар никто не даст, дадут опытному и проверенному, вероятно что тим лиду, который более-менее знаком со всем, что делают все, кто у него в подчинении. С вероятностью в 90%, я думаю, что все в этом случае будет как всегда: хорошо, качественно и в срок.
          • 0
            Узнать кто отвечает за функциональность против которой клиент нашел баги — дело одной минуты. Никакого расследования не требуется. Более того, в конце года в ходе процедуры определения и получения премий — надо делать самооценку и честно писать сколько и по чему было найдено багов. Радость та еще, но, знаете ли, очень менеджерам жизнь облегчает.
      • 0
        И у нас такая система работает, я вам как программист говорю.
  • 0
    Не понимаю где вы таких программистов видели. (Точнее как вы их не выгнали ещё на испытательном сроке.)

    Хороший программист понимает, что сам он протестировать не может, просто в силу своей природы. (Любой программист, будет искать доказательство того что багов нет, а тестировщик наоборот, доказательство того что они есть. А они там есть, это аксиома.)

    По этому работая с хорошими программистами (которые и сами стараются и к тестировщикам прислушивается) не будет этих проблем. (Это конечно только ИМХО, но мой опыт это подтвердил не один раз.)
    • +1
      у нас они не работают. Если даже такой проскочит собеседование, не приживется.
      а ситуация, к сожалению, распространенная
  • 0
    Хмм… не могу сказать что у меня такой уж громадный опыт работы в программистских коллективах, но ни разу с такой проблемой не сталкивался, вроде все нормальные люди понимают, что если тестер нашел где то баг, то это ТВОЯ ошибка и нужно её исправлять…
  • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    По делу статья написана. Главное в создании ПО — действительно командная работа. И вся ответственность по организации этого лежит на менеджере проекта. Именно он задает ориентировки, согласует условия проекта с заказчиком и т.п. А если мы наткнулись на клинический случай, и специалист по-прежнему упрямо твердит: «Это не баг» или «Я ошибку нашел, дальше — не моя проблема», с таким специалистом, увы, нужно прощаться.
    • +1
      +100500
  • 0
    Это все от незнания, а может быть и от нежелания знать, того что должно быть получено в итоге.
  • +1
    Хорошая эмоциональная статья, спасибо!
    Видать наболело у автора и, таким образом, решил излить душу… :-)
    • +1
      наболело то, что многие спрашивают, как быть в такой ситуации ( я часто по конференциям езжу, со многими общаюсь), а как помочь им не знаю, потому что мы всегда такие вещи предотвращали набором правильных людей и созданием правильной атмосферы, я вон выше писала.

  • 0
    Проблема известная, у нас тоже есть.
    Мы пытались разобраться в причинах и поняли, что беды две: личные качества и коммуникации.
    С первым ничего кардинального не сделаешь (не пороть же!). Можно только лучше думать, когда берешь людей на работу. И общаться с теми, кто есть, не замалчивать проблемы.
    А про коммуникации подумать стоит. Мы, например, у себя просто посадили тестировщиков вместе с программистами. Стало лучше.
    • +2
      У нас сейчас в требованиях к кандидату (по вакансии QA-инженера) написано:

      * Сильные коммуникационные навыки (как вербальные, так и письменные), умение предотвращать и решать конфликтные ситуации.

      Это требуется не из-за того, что у нас постоянно конфликты возникают, а для того, что бы они как раз не возникали :-)
      • 0
        А как на собеседовании выявить эти качества? Из области фантастики.
        Все стараются не афишировать свои плохие стороны.
        Не была ни разу на собеседовании, посвятите.
        • 0
          Ну, к примеру, можно пообщаться о том, какие ситуации возникали у человека на предыдущем месте работы. Узнать, какие ситуации кандидат вообще считает сложными, пообщаться на эту тему. Услышать то, как он их решал. Узнать то, что ему нравится/не нравится в коллективе или в процессе разработки, и то, как он пытался изменить это.

          Кроме того собеседование проводят живые люди — и их жизненный опыт является очень важным оценочным инструментом. А стабильность рабочего коллектива и хорошие профессиональные успехи отдела подтверждают их право делать выводы.
          • 0
            Здраво, спасибо.
    • +1
      ещё дело в атмосфере
      вы можете брать отличных людей, которые друг с другом хорошо общаются, но если в проекте атмосфера «сделать продукт, чтоб менеджер (заказчик) отвязался», ни к чему хорошему не приведет.
      Кстати, такая больная атмосфера, в большинстве случаев, исходит от менеджера, который не дает команде понимания, что их работа значима, полезна и ценима
  • +1
    Очень интересная и правдивая статья, спс :)
  • 0
    Из опыта: пока тестировщики и программеры не увидят свой продукт как целое, да еще со стороны пользователя, дела не пойдут. Или пойдут, но плохо, долго и возможно не туда :) Хорошая статья, такие проблемы известны
  • –3
    В идеале тестировщики и программисты не должны пересекаться. При тестировании модуля тестировщик не должен знать, кто этот модуль разработал. Соответственно, и программист не должен знать, кто именно из тестировщиков нашел ошибку в его коде. Именно так работают многие крупные софтверные компании.
    • +2
      Минимизируя взаимодействие между командами, мы уменьшаем общую эффективность.
      Например, при тест дизайне или составлении стратегии, взаимодействие с программистами очень важно, например: Для того что-бы актуально оценить риски, сама оценка должна проходить коллегиально.
      Нужно работать именно над проектом и плотно взаимодействовать между командами, на достижение (Как уже тут многократно говорилось) общей цели.
      Описанный Вами идиальный случай напротив, исключает общую цель и создает много локальных, которые, как-раз могут нанести вреда чем пользы (в рамках всего проекта)

      К сожалению, я не знаю о каких крупных софтверных компаниях Вы говорите, можно пример?
      • +1
        Reuters, например.
    • 0
      Flex25, в крупных компаниях действительно данный метод используется. Но его имеет смысл использовать как дополнительный. Тестировщики, которые общаются с программистом нужны в любом случае. Именно при налаженном взаимодействии есть возможность быстро протестировать продукт на основные баги, на наиболее вероятные баги, в срочном порядке что-то быстренько подправить и т.п. А необходимость таких срочных действий в процессе работы возникает постоянно. Да и глубоко лежащие ошибки порой легче отловить, зная, с кем имеешь дело :-)=
  • +1
    1: а я профессию сменил. теперь девелопером
    2: а раньше кем был?
    1: тестером
    2: и в чем разница?
    1: раньше а кричал на программу «Падай, сука!», а теперь — «Работай, сука!».
    © BOR
    • 0
      Далеко за примером ходить не пришлось. (:
  • 0
    ага, это не баг — это фича :)
    только все вышесказанное можно отнести к любому проекту и обобщить для любой профессии.
  • 0
    Плох тот программист, который не любит тестировщика.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.