Почему тестеры и программисты не любят друг друга? [закрыто]

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

Это правильное решение, принятое мной, почему, и что мы можем сделать, чтобы избежать подобных проблем?

Я думаю, что это грубое обобщение и упрощение.

В настоящее время я тестировщик, я пишу почти столько же кода, сколько написал dev (зависит от фазы тестирования), а мой лучший друг в компании - dev, и мы все ладим.

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

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

редактировать

Также обратите внимание, что я думаю, что ответственность за связь между ними лежит на тестере больше, чем на разработчике.

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

Я ЛЮБЛЮ своих тестеров - они помогают мне устранять неполадки и выявляют вещи, которые я не считаю проблемой, но наши клиенты будут. И самое главное для меня, они помогают мне убедиться, что я не убью кого-нибудь с плохим кодом.

Почему возникают проблемы?

• Вы постоянно судить друг друга работу, и некоторые люди не могут принимать какие - либо critism
• Плохая работа тратит впустую время вашего противника
• Вы оба испытываете давление в одно и то же время, и никто не хочет быть тем, кто держит вещи

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

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

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

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

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

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

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

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

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

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

Ни dev, ни test не пройдут без другого. Если вы работаете как две половины одной машины и уважаете другую сторону так же, как уважаете своих более непосредственных членов команды, все будет хорошо. Веди себя как две отдельные машины и считай, что твоя машина лучше, все будет ужасно.

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

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

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

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

Другая проблема заключается в том, что многие компании часто думают о QA. Много раз говорят о проектах в последнюю минуту и ​​сильно недоукомплектованы по сравнению с командой разработчиков. В некоторых местах путь к разработчику - это техническая поддержка, QA, а затем разработчик. Поэтому иногда в нем работают люди, которые хотят, чтобы они были разработчиками ... А потом, когда они обнаруживают дефект, их отношение заключается в том, как этот человек может быть разработчиком, а не я, я бы никогда не допустил такой ошибки и т. Д ...

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

Кроме того, многим командам QA приходится делать вещи вручную, и в этом случае это ДЕЙСТВИТЕЛЬНО скучная работа. В некоторых местах QA пишет сценарии и использует программы автоматизации, которые даже позволяют создавать сценарии с графическим интерфейсом (через какое-то распознавание изображений на экране для кнопок и т. Д.). Тогда все еще сложно, когда сначала происходят серьезные изменения, но потом все автоматизировано, и это кажется более увлекательным ...

Также некоторые разработчики смотрят свысока на QA. Тем не менее, я бы предпочел QA найти дефект, чем клиент ....

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

Главное - относиться ко всем профессионалам с вежливостью и уважать, делают ли они то, что вы делаете или нет. Как только вы начинаете думать, что ваша работа лучше или важнее их, вы теряете.

Основываясь на этом вопросе: Методы тестирования программного обеспечения или категории Я подозреваю, что вам нужно изменить отношение к тестерам и тестированию в целом.

Как разработчик, я испытал свою долю напряжения с тестерами.

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

Тем не менее, хорошие тестеры на вес золота - я бы обменял паршивого разработчика на хорошего тестера в одно мгновение. Хороший тестер - партнер в предоставлении качественного продукта.

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

Как избежать этих проблем? Как насчет того, чтобы быть милыми друг с другом? Один нужен другому, чтобы получить качественное программное приложение, так почему бы не уважать то, что нужно сделать каждой стороне для достижения этой цели? Узнайте, что делает каждая из сторон, и вы действительно сможете оценить проделанную работу.

Упрямство с обеих сторон от правильного толкования требования может привести к конфликту между разработчиками и тестерами в целом. Хотя может показаться снобизм или высокомерие, просто каждая сторона придерживается своего оружия и хочет быть правым.

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

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

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

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

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

Плохой юджу

Это часто возникает из-за трех факторов -

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

Мне нравятся тестеры, но в двух случаях я обнаружил конфликт.

1. При управлении играют тестировщики и разрабатывают друг друга.

2. Когда проблемы постоянно представляются, в которых отсутствует детализация, например, «Экран х не работает».

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

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