Как работать «инженером QA» в проекте, а не в «группе разработчиков, управляемой тестами»?

Question

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

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

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

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

У меня трудности с выполнением второй части запроса.Написание автоматических тестов затруднительно, если код не предназначен для тестирования.

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

Какие методы я могу использовать, чтобы стать более эффективными в моей роли QA, когда другие разработчики еще не пишут о создании тестируемого кода?

Answer 1

Проблема с именами Разработка через тестирование и модульное тестирование заключается в том, что они подразумевают, что они предназначены для тестирования программного обеспечения.Они не .TDD и модульное тестирование - это примерно дизайн , и они по сути являются обязанностью разработчиков.

Роль QA Analyst по-прежнему имеет первостепенное значение для любой команды, практикующей TDD, и она будет долгое, долгое время, прежде чем вы окажетесь без работы в качестве добросовестного QA!

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

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

Answer 2

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

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

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

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

Answer 3

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

До этого момента, когда вы работаете с унаследованным кодом, книга Майкла Фезера Эффективная работа с унаследованным кодом содержит много полезных советов по тестированию такого кода.

Вы, наверное, уже знаете это, но также ознакомьтесь с Behavior Driven Development (BDD), которая включает в себя много вопросов о создании автоматических интеграционных тестов, которые, я думаю, будут вам интересны.

Answer 4

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

Вы можете погрузиться в написание тестов самостоятельно:

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

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

Answer 5

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

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