Как создать отдел QA? [закрытый]
2 ответа
Вы указываете, что хотите получить группу/отдел контроля качества, но не говорите, почему. Есть много предположений о том, что делает группа контроля качества.
Базовая природа QA заключается в том, чтобы гарантировать, что правильный продукт построен правильно, с первого раза. Обеспечение качества программного обеспечения обычно фокусируется на процессе разработки кода.
Или вы просто ищете кого-то другого, чтобы проверить ваш код для вас?
Если вы сосредоточены на тестировании аспектов контроля качества, я бы как можно больше продвинулся в часть разработки вашей группы. Автоматизированные тесты будут иметь большое значение, чтобы помочь улучшить шансы сделать это правильно с первого раза. Кроме того, тесты значительно снижают риск изменений внутри продукта. И не отвлекайте большую часть написания теста на подмножество команды. Вы хотите сделать тестируемость ключевым аспектом вашего дизайна, а разработчики, которые не пишут достаточно тестов, не взвешивают ее в своих проектах. Рассчитывать на то, что человек или группа людей проедуют кучу тестов, означает, что вы не можете запускать их очень часто, и вы будете склонны недооценивать старые регрессионные тесты.
Если вы сосредоточены на QA, а не только на тестировании,Стоит назначить кого-то, чья основная роль заключается в том, чтобы посмотреть на продукт, его сложность, метрики и охват тестирования, чтобы определить, достаточно ли тестов в нужных местах в кодовой базе. Эта роль ничем не отличается от роли архитектора, контроливщего общий дизайн, или кого-то, специализирующегося на юзабилити и / или дизайне, направляющего разработку пользовательского интерфейса. Роль должна заключаться в том, чтобы отстаивать правильную работу, а не обязательно выполнять ее.
Единственное исключение, которое у меня лично есть со всем вышеперечисленным, - это необходимость хотя бы одного человека с правильным мышлением для выполнения исследовательского тестирования . Исследовательское тестирование должно быть подмножеством всего тестирования, описанного выше. И, по мере того, как проблемы обнаружены, должны использоваться для обратной связи в автоматизированном тестировании (например, если ошибка найдена, частью акта исправления должно быть написание теста, который демонстрирует ошибку и исправление. И, если тестовое покрытие низкое для сложности кода,напишите несколько других тестов, чтобы убедиться, что нет дополнительных ошибок). В частности, В частности, В исследовательском тестировании нуждаются в исследовательском тестировании. Перестановки пригодных для использования способов выполнения задачи, а также сложность автоматизации тестов в старых фреймворках пользовательского интерфейса часто хорошо обслуживаются исследовательским тестированием.
Обновление: Возможно, вы захотите проверить Эпизод 164: Гибкое тестирование с Лизой Криспин
Если вы используете Scrum, Я полагаю, вы имеете в виду гибкий подход. Разве планы тестирования, отчеты об ошибках и тому подобное не будут лишними?
Что касается инструментов, которые я бы предложил добавить вики или jira в качестве места для хранения задач, связанных пользовательских историй, и связанные с ними ошибки.
Что касается создания отдела QA (один человек в качестве отдела Oo), я бы предложил убрать ярлык «QA dept.», просто нанять еще одного члена команды, который сосредоточится на тестировании. Возможно, вам понадобится человек, который работал в Agile и имел опыт тестирования. Было бы хорошо, если бы этот человек знал исследовательское тестирование (инструменты и методы).
Если вы думаете об автоматизации тестирования (поскольку у вас уже есть Hudson), тестировщику потребуется иметь некоторые навыки программирования. С другой стороны, вы можете оставить автоматизацию разработчикам и сосредоточиться на том, чтобы получить хорошего тестировщика, а не среднего тестировщика, который может делать какой-то код. В любом случае я бы реализовал немного автоматизации тестирования, некоторый регресс.
Во-первых, не впадайте в сложную документацию / процессы / планы тестирования / подробные ручные скрипты / вещи, ориентированные на процессы. Держите все гибко, иначе скоро вы заметите, что это действительно не работает.
================= отредактируйте в соответствии с комментарием Джеко ========================= ===
Итак, я предполагаю, что не намерены вносить свой вклад в этот проект с открытым исходным кодом, а скорее сделаю несколько плагинов, которые будут использовать его код, но также расширят его функциональность, чтобы он соответствовал вашим потребностям в вашем собственном проекте? Прохладный.
Итак, у вас есть:
1) Проект с открытым исходным кодом, разработанный другой стороной, с собственным графиком, планом проекта и т. Д.
2) Разрабатываемые вами расширения / плагины, которые делают этот проект полезным для вас
3) Ваш собственный проект, некоторые функции которого делегированы через плагины проекту с открытым исходным кодом.
Я полагаю, что все это интегрируется на уровне кода через какой-то механизм обмена сообщениями. В этом случае я бы сказал, что вам нужен кто-то, кто умеет кодировать, независимо от его опыта (хотя разработчика будет легче найти, но будет ли он заинтересован в написании тестов автоматизации?).
В любом случае вам нужны тесты автоматизации для:
A) Очевидно, ваш проект - напишите модульные тесты, как вы делаете сейчас, или, может быть, немного больше.
Б) Модульные тесты, которые гарантируют, что любые изменения в вашем основном проекте не нарушают его взаимодействие с плагинами / расширениями (для проекта с открытым исходным кодом)
C) модульные тесты плагинов / расширений - это код, который вы пишете, поэтому вам нужны модульные тесты, так как вам нужен A для вашего проекта
D) (не столь очевидная часть) вам нужны тесты, чтобы увидеть, влияют ли изменения в проекте с открытым исходным кодом на ваши плагины.
Конечно, A и B как C и D как-то пересекаются, но формально это то, о чем вам нужно знать.
Итак, возвращаясь к исходному вопросу, я не думаю, что вам нужен отдел контроля качества (кстати, разве скрам не говорит, что нужно отказаться от ярлыков отдела и создать одну команду?) В традиционном понимании. Найдите парня, который умеет (и любит) создавать автоматические тесты, возможно, на уровне Unit Test. Используйте Scrum. Создайте одну команду. Пропустите исчерпывающую документацию, формальный процесс, стандарты ISO / IEEE для тестирования. Создавайте легкую документацию, чтобы иметь возможность ссылаться на основные / общие цели / подходы / предположения.
... и если это не сработает, обсудите это ретроспективно, попробуйте что-то подправить, попробовать что-то новое. Постоянное улучшение!