Обеспечение качества в небольших командах разработчиков

Question

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

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

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

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

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

Answer 1

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

Мы используем Scrum. Это хороший способ сделать наши команды эффективными, но это также хороший способ введения правил в разработку программного обеспечения. Как и вы - я часть небольшой команды. К сожалению, мы не наделены отделом QA или любыми людьми QA. Работа, выполненная во время Спринта, потенциально может быть отправлена, поэтому разработчики в команде должны справиться с заданием QA.

В Scrum и, например, Kanban Вы используете Панель задач для отслеживания текущего Sprint, и на этих досках часто есть столбец для задач, ожидающих одобрения QA. Что мы делаем, так это то, что когда задача выполнена, мы перемещаем ее в «Готовность к проверке». А затем другой разработчик в команде выполняет работу по обеспечению качества. Он будет:

• Убедитесь, что новая функциональность делает то, что от нее ожидают / исправлены ошибки / etc.
• Убедитесь, что есть достаточные юнит-тесты
• Сделайте быстрый просмотр кода , чтобы убедиться, что код выглядит чистым и понятным

Если в обзоре есть что-то неудовлетворительное, он вернет задачу к началу, и ее необходимо исправить, прежде чем она сможет войти в другой сеанс QA.

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

Answer 2

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

Последние три года я работал в командах разработчиков из 2-4 человек без какого-либо официального контроля качества. У нас очень довольные клиенты и низкий уровень ошибок.

Это работает для нас, потому что:

• Приоритетом каждого является качественное программное обеспечение. Мы не передаем роль QA, но все делают это постоянно. Мы хотим, чтобы наш код выглядел хорошо. И все разработчики стремятся написать как модульные, так и интеграционные тесты, и команда должна убедиться, что тесты есть.
• Мы проводим обширную программу. Эти небольшие накладные расходы значительно улучшают качество и обладают всевозможными преимуществами. Вы развиваете общее понимание того, что означает «качество», и сами отвечаете на вопросы.
• У нас есть регулярные «ретроспективы», где мы спрашиваем, что мы можем улучшить. В связи с этим, если у нас возникают проблемы с качеством, команда выясняет, что нужно изменить, чтобы решить эту проблему ( 5 Почему анализ ). Мы разработали такие правила, как «два глаза на любую регистрацию» для решения проблем.

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

Answer 3

Для начала, если вы еще этого не сделали, я настоятельно рекомендую настроить автоматическую сборку, которая также запускает модульные тесты, предпочтительно с покрытием кода, чтобы проверить, есть ли области, которые требуют большего охвата модульных тестов. Я не большой поклонник требования 100% покрытия кода, но все, что имеет только около 60% -80%, вероятно, нужно изучить.

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

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

Answer 4

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

Я обнаружил, что все следующее полезно для поддержания качества, когда кто-либо играет официальную роль QA или нет:

• Автоматизированные модульные тесты
• Автоматизированные сборки - так часто, как вы можете управлять
• Измерение покрытия испытаний
• Рецензии на коды проверок
• Принятые нормы и стандарты кодирования
• Личные ветки
• Частые слияния
• Ешь свою собачью еду!

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

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

Answer 5

В небольших или больших командах функция QA (включая тестирование) должна быть независимой от функции разработки. Если менеджер по разработке имеет контроль над QA, тогда возникнет конфликт интересов, так как менеджер по разработке обычно хочет выпустить продукт для достижения своих целей (которые обычно связаны со временем). В организационной структуре, где QA \ QC отчитывается перед менеджером по разработке, мы называем этот QA \ QC «инженерными услугами» (тестирование, документация), а не независимой проверкой \ проверкой (IV & V) поставляемого программного обеспечения.

Answer 6

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

• Групповой обзор критического кода. Часто код предоставляется кем-то другим , чем его автор.

• Индивидуальный просмотр чужого кода в автономном режиме.

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

• Парное программирование.

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

Answer 7

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

После того, как часть кода / функциональности будет завершена, организуйте проверку кода между разработчиком и назначенным еженедельно разработчиком QA или другим разработчиком. Они могут сесть и посмотреть на код, разработчик может рассказать о том, что он сделал, почему он так сделал и т. Д. Таким образом, рецензент может смотреть на код и не тратить время на попытки понять, «почему они сделали это таким образом? Таким образом, рецензент может также предложить другие, более эффективные способы выполнения определенной процедуры или научить разработчика определенной функции в используемой среде, о которой он, возможно, не знал.

Все дело в обучении и передаче информации; это помогает улучшить код.

Надеюсь, это поможет.

Answer 8

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

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

1. Регулярные проверки кода / проверка на наличие новых кодов перед проверкой.
2. Запуск инструментов статического анализа, таких как lint.
3. Оставляя эго у двери.
4. Обеспечение соблюдения стандартов кодирования.
5. Проверка в тестовом коде, используемом для разработки функции / исправления. Команда тестирования использует это как ЧАСТЬ своих регрессионных тестов.

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

Надеюсь, это поможет. Надеюсь, это поможет.

Answer 9

Целью отдела обеспечения качества является идентификация и:

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

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

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

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

Answer 10

Вы можете настроить сервер, который выполняет статический анализ кода, например Sonar . Он может быть настроен на извлечение и сборку вашего кода один раз в день, а также на выполнение синтаксических и семантических проверок, предоставляемых различными плагинами (Checkstyle, Findbugs и т. Д.) Над вашим кодом, и обеспечивает хороший вывод HTML, так что каждый в команде может посмотреть на обнаруженные потенциальные проблемы в коде.

Имейте в виду, что возможны ложные срабатывания.