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

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

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

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

Edit:

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

Ответ 1

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

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

В Scrum и, например, Kanban вы используете Task Board, чтобы отслеживать текущий Sprint, и эти доски часто имеют столбец для задач, ожидающих утверждения QA. Мы делаем то, что, когда задача выполняется, мы переместим ее в "Готово для проверки". И затем другой разработчик в команде выполняет работу по обеспечению качества. Он будет:

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

Ответ 8

Целью отдела QA является определение и:

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

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

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

Ответ 9

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

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

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

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

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

Ответ 10

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

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

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

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

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

Ответ 11

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

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

Ответ 12

Бесстыдный плагин здесь, но вы можете использовать нас: https://99tests.com/crowd-functional-testing-bugbash. У нас довольно много клиентов, которые полностью полагаются на нас для доставки своих продуктов и новых функций. Сохраняет головную боль управления и получает право QA. Наша толпа тестировщиков сообщает, проверяет и предоставляет подробные воспроизводимые ошибки, которые команда разработчиков может легко понять и исправить.

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