• Содержание

Не обманывайте себя, думая, что исходный код — это всего лишь набор файлов, требующий контроля над изменениями. Как было отмечено ранее, управления требует великое множество файлов и документов — не ограничивайтесь преимуществами контроля над изменениями только для исходного кода. Даже если придётся переучивать людей, отвечающих за контроль качества или обучение пользователей, время будет потрачено не зря.

• Конфликты ключевых файлов

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

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

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

В большинстве систем управления исходным кодом поддерживается слияние файлов. Это позволяет совместить изменения в файлах. Хотя обычно эта функция работает правильно, не позволяйте операцию слияния проводить автоматически. Вы должны убедиться, что проверили все изменения, сделанные в файле. Если в нашей системе управления исходным кодом поддержка слияния реализована плохо, можете воспользоваться такими редакторами кода, как Visual Slick Edit и Code Write. Они помогут выявить различия визуально и проверить результат слияния перед его реальным осуществлением.

• Маркировка

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

Метки должны устанавливаться не только для файлов с исходным кодом. Помечайте файлы-сборки, установочные файлы, файлы документации, файлы контроля качества — словом, все файлы, включённые в выпуск. Метка должна быть информативной и следовать соглашениям об именах, принятым для проекта.

Из собственного опыта

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

• Целостность данных

Обеспечение целостности данных в системе должно быть приоритетной задачей. Если вы не будете доверять информации в системе, то не станете её использовать, и она потеряет свою значимость. Очень важно определить правила обеспечения целостности данных, в большинстве основанных на внутреннем процессе разработки. Так, вы никогда не должны сталкиваться с ошибками, которые реально «закрыты», но для них установлен статус «исследуется». Чтобы отображать работу над ошибками, нужно со временем изменять статус ошибок. Также убедитесь, что вы вводите правильные значения в поля (информацию об этапе, информацию о выпуске и т.д.). Какими бы ни были у вас внутренние методы проверки целостности, не допускайте хранения недостоверных или устаревших данных, иначе команда разработчиков будет присваивать данным любые значения, а вся система перестанет внушать доверие и станет бесполезной.

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

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

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

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