Гарантия качества в малочисленных командах разработчика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Самый большой прирост качества, который я когда-либо делал, произошел после случайной отправки нефункциональной версии клиенту. После того, как мы соскребли яйца с наших лиц, мы придумали формальный контрольный список на шести страницах для создания и проверки выпусков, начиная с разных машин для сборки и тестирования, каждая со свежеустановленной ОС и соответствующими четко определенными инструментами. Было три разные роли (инженер по сборке, тестировщик, релиз-инженер), перекрестная проверка, и каждый индивидуально подписывал каждый шаг, за который он отвечал, по мере его завершения.Если что-то шло не по плану, мы исправляли всю проблему и начинали заново. Для большинства проектов на это уходило около 4-8 часов, и когда что-то не срабатывало, и нам приходилось начинать все сначала, иногда у нас были очень поздние ночи, но мы никогда больше не выпускали нестандартные релизы.

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

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

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

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

Задача отдела обеспечения качества - выявить и:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Похоже, вы делаете много вещей правильно и задаете правильные вопросы.

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

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

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

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