Разработка / QA / Производственная среда

Question

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

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

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

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

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

Answer 1

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

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

2. Команда тестирования, работающая над нестабильными версиями
   Нет абсолютно никаких причин, по которым группа тестирования должна тратить время на версию, которая "мертва по прибытии".Непрерывная интеграция - это методология, с помощью которой «взлом кода» обнаруживается как можно скорее.Это требует определенных вложений в такие продукты, как Hudson или собственное решение, чтобы убедиться, что сбои сборки являются уведомлениями по мере их возникновения, и к ним применяется некоторое «Тестирование дыма».

3. Ваш цикл тестированияlong
   Инвестируйте в автоматизированное тестирование.Это не значит, что ваши тестеры должны учиться программировать;скорее, вы должны инвестировать в набор или рост людей с их знаниями и страстью к написанию стабильных автоматических тестов.

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

Опять же, это мои два цента.

Answer 2

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

Answer 3

Вам необходим сервер непрерывной интеграции, способный автоматизировать сборку, тестирование и развертывание. Я бы посмотрел на комбинацию Apache Hudson, JUnit (DBUnit), Selenium и таких инструментов качества кода, как Sonar.

Answer 4

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

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

Вы также можете поговорить с руководителями вашей команды разработчиков (или теми, кто когда-либо ими управляет) и обсудить, где они смотрят QA и что QA может сделать, чтобы помочь им лучше всего.Спросите: есть ли у вашей команды разработчиков время перед выпуском?Вы тестируете каждую строку кода?Есть ли места, на которые вы могли бы потратить слишком много детального времени на тестирование?Не все должно зависеть от QA, QA и dev, которые должны работать вместе, чтобы выпустить продукт.