https://wodolei.ru/catalog/uglovye_vanny/malenkie/
Наблюдение за количеством изменений информации об ошибках поможет определить те, что требуют внимания со стороны ведущих специалистов и менеджера проекта.
Счётчик неудачных исправлений
Ещё один хороший способ оценки нестабильности проекта — счётчик неудачных исправлений для всех ошибок, которые считались исправленными, но на самом деле исправлены не были. При устранении неполадки от команды тестировщиков требуется подтверждение того, что ошибка действительно исправлена. Если проблема всё ещё существует или исправление не принято, ей возвращается статус открытой, а значение поля «Исправлено неудачно» устанавливается в 1. Если тестировщики снова не могут подтвердить устранения неполадки, значение счётчика увеличивается до 2 или 3. Это сигнализирует о серьёзности проблемы и говорит о необходимости вмешательства ведущих специалистов или менеджера проекта.
Дополнительные средства
Хотя средства управления исходным кодом и устранения проблем были стержнем процесса разработки в NuMega, мы регулярно использовали и другие инструменты.
Отладчики
Одним из наиболее важных инструментов для наших разработчиков был разработанный NuMega Technologies невероятно мощный отладчик для Windows — SoftICE. Он загружается при запуске системы как драйвер устройства на уровне ядра и предоставляет беспрецедентные возможности управления и наблюдения за внутренними процессами приложения и операционной системы. Команда разработчиков часто использовала SoftICE для разрешения наиболее сложных проблем при отладке.
Средства анализа производительности и полноты
Мы часто использовали средства анализа производительности, в том числе наши собственные продукты TrueTime и TrueCoverage, для настройки производительности собираемых приложений. Мы поняли, что эти инструменты нужно использовать регулярно в течение цикла разработки, а не в самом конце, когда времени на оптимизацию или устранение проблем не хватает. Анализ производительности проекта по завершении определённого этапа или при выпуске бета-версии предупреждает проблемы и часто раскрывает ошибки, которые могут не проявляться в коде до самого выпуска. Не ждите, пока вы столкнётесь с проблемами производительности, а начинайте сразу применять средства анализа производительности.
Мы также поняли, что эти средства работают наиболее эффективно, если проект специально разрабатывается с учётом анализа производительности и полноты. Собирая такие приложения, мы интегрируем их с нашими тестовыми заданиями для раннего обнаружения проблем с производительностью или для лучшей оценки полноты наших тестовых заданий.
Средства написания сценариев и автоматизации тестирования
Так как наши планы тестирования требовали максимально возможной автоматизации, мы всегда интересовались инструментами, способными нам в этом помочь. Наиболее важными были средства написания сценариев (Perl, командные файлы DOS и т.п.) и средства автоматизации тестирования. В то время Visual Test был доступен по разумной цене и предлагался взыскательным тестировщикам и разработчикам. С его помощью мы тестировали пользовательский интерфейс, но в подавляющем большинстве мероприятий по автоматизации полагались на средства написания сценариев.
Из собственного опыта
Когда мы создавали группу разработки ПО, проверяющего исправность кода, члены команды не были до конца уверены в его значимости. Но с продвижением проекта, когда команда начала применять собственный продукт на собственном коде, стало ясно, что если разработчики блочно тестировали свой код с полнотой 80%, то качество продукта заметно повышалось.
Типичные проблемы и их решение
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Проблемы с инструментами
• Отбор нужных инструментов
Одна из главных ошибок которую допускают команды разработчиков, — игнорирование нужных инструментов. Я убеждён в том, что система управления исходным кодом и система устранения проблем и неисправностей необходимы. В равной степени для команды разработчиков важны средства отладки, поиска ошибок, оптимизации производительности и проверки полноты. Они помогут решить многие уникальные проблемы, всплывающие на поверхность в процессе разработки.
Всё, что может ускорить и автоматизировать цикл разработки, критично для вашего графика. Слишком часто графики сбиваются, так как сложные ошибки или проблемы с производительностью вносятся в процессе разработки, но не выявляются на раннем этапе. Когда они обнаружены, людям без посторонней помощи устранить их практически невозможно. Времени искать нужные инструменты в Интернете просто не будет. Убедитесь, что определились с инструментами, которые вам понадобятся, интегрировали их в процесс разработки и обучили персонал работе с ними.
• Смена инструментов на средине пути
Одно из главных искушений в процессе разработки — замена того, что вы используете сейчас, новой версией или инструментом от другого производителя. Последствия такого решения обычно не просчитывают. Я не могу представить себе смены систем управления исходным кодом или устранения проблем и неисправностей без значительного сдвига графиков. Обычно лучше дойти до конечного выпуска с тем, что у вас имеется, нежели менять это на полпути.
Проблемы управления исходным кодом
• Структура проекта
С ростом проекта структура системы управления исходным кодом становится очень важной. Хотя здесь я предлагаю стандартный способ работы, не забудьте спланировать систему в соответствии с нуждами вашего проекта. Вы должны принять во внимание фактор одновременного выпуска нескольких версий (пакеты обновлений, сокращённые и полные выпуски), а также потребности разработчиков, тестировщиков, фактор обучения пользователей, человеческий фактор и технологические потребности.
• Содержание
Не обманывайте себя, думая, что исходный код — это всего лишь набор файлов, требующий контроля над изменениями. Как было отмечено ранее, управления требует великое множество файлов и документов — не ограничивайтесь преимуществами контроля над изменениями только для исходного кода. Даже если придётся переучивать людей, отвечающих за контроль качества или обучение пользователей, время будет потрачено не зря.
• Конфликты ключевых файлов
Типичный случай: разработчику X был выдан файл, и поэтому разработчик Y не может его взять для внесения важных изменений. Такие конфликты из-за файлов способны замедлить работу над проектом. Предусмотрите способ быстрого внесения критичных исправлений или изменений.
Лучший способ решить эту проблему — предотвратить её появление. Подумайте, можете ли вы разделить наиболее востребованную информацию на несколько файлов, основываясь на логических подсистемах, компонентах и классах. Разбивка содержимого файлов уменьшает вероятность конфликтов.
Когда разделить содержимое файлов невозможно, например из-за жёсткой связи между блоками, следует разработать политику, предусматривающую возврат файлов в течение определённого количества часов после выдачи. Также в случае недоступности файлов программисты могут работать над их копиями, а не над оригиналами. Ставший доступным файл можно взять на короткий срок, быстро обновить и возвратить на место.
В большинстве систем управления исходным кодом поддерживается слияние файлов. Это позволяет совместить изменения в файлах. Хотя обычно эта функция работает правильно, не позволяйте операцию слияния проводить автоматически. Вы должны убедиться, что проверили все изменения, сделанные в файле. Если в нашей системе управления исходным кодом поддержка слияния реализована плохо, можете воспользоваться такими редакторами кода, как Visual Slick Edit и Code Write. Они помогут выявить различия визуально и проверить результат слияния перед его реальным осуществлением.
• Маркировка
Одно из главных достоинств системы управления исходным кодом — возможность маркировки набора файлов, включённых в выпуск. Не забывайте проделывать этот важный этап работы для каждого выпуска, в том числе на основных уровнях, по завершении этапов работы, при выпуске бета-версий и т.д.
Метки должны устанавливаться не только для файлов с исходным кодом. Помечайте файлы-сборки, установочные файлы, файлы документации, файлы контроля качества — словом, все файлы, включённые в выпуск. Метка должна быть информативной и следовать соглашениям об именах, принятым для проекта.
Из собственного опыта
Однажды у нас работала команда, которая оценивала свою систему поиска ошибок во время разработки. Спустя некоторое время они пришли к выводу, что им следует переключиться на использование нового продукта, так как в нём были реализованы новые возможности. Они запустили конвертор и загрузили ПО. К сожалению, через две недели работы с продуктом они обнаружили, что там нет поддержки некоторых отчётов, а производительность программы ужасна. Им нужно было вернуться к предыдущей системе, но так как в новой версии не было предусмотрено процедуры автоматического обратного перехода, им пришлось вручную водить все записи об ошибках и неполадках, внесённые с момента перехода.
Проблемы поиска ошибок и неисправностей
• Целостность данных
Обеспечение целостности данных в системе должно быть приоритетной задачей. Если вы не будете доверять информации в системе, то не станете её использовать, и она потеряет свою значимость. Очень важно определить правила обеспечения целостности данных, в большинстве основанных на внутреннем процессе разработки. Так, вы никогда не должны сталкиваться с ошибками, которые реально «закрыты», но для них установлен статус «исследуется». Чтобы отображать работу над ошибками, нужно со временем изменять статус ошибок. Также убедитесь, что вы вводите правильные значения в поля (информацию об этапе, информацию о выпуске и т.д.). Какими бы ни были у вас внутренние методы проверки целостности, не допускайте хранения недостоверных или устаревших данных, иначе команда разработчиков будет присваивать данным любые значения, а вся система перестанет внушать доверие и станет бесполезной.
Лучший способ избежать проблем с целостностью данных — это убедиться в том, что команда осознает важность этих данных и может обнаруживать и решать проблемы самостоятельно. Собственная мотивация заработает хорошо, если вы продемонстрируете реальную значимость этих данных для команды. Не забудьте также периодически пересматривать данные и обсуждать результаты с командой.
Я показал некоторые способы моделирования ключевых элементов цикла разработки с применением средств устранения проблем и неисправностей. Однако не стоит увлекаться и использовать всё, что только может подойти для вашей команды. Вместо этого определите ключевые потребности для процесса разработки и выберите простые средства для их реализации.
Глава 6
Основы системы контроля качества
Проблемы с контролем качества могут разрушить проект: сорвать сроки или испортить продукт так, что потребители не смогут им пользоваться. Какой бы ни была ваша компания — начинающей или транснациональной корпорацией, вы должны эффективно балансировать между качеством продукта и временем его представления на рынке. Успех или неудача зависят именно от этого.
В этой главе мы рассмотрим основы системы контроля качества в динамичной среде с ограниченными ресурсами, обычной для современных проектов по разработке ПО. Мы остановим своё внимание на том, что, когда, как и кто должен тестировать. Затем я продемонстрирую общее решение и расскажу о некоторых простых и эффективных приёмах управления тестированием.
Основные принципы
Начнём с принципов работы системы контроля качества. Лейтмотив — обеспечение качества непосредственно в процессе разработки. Продукту нельзя придать качество позже без значительных затрат денег, сил и времени. Создание качественного продукта основывается на четырёх простых принципах:
• тестирование продукта осуществляется параллельно с процессом его разработки;
• качество продукта улучшается регулярно при завершении каждого планового этапа разработки;
• тестирование необходимо максимально автоматизировать;
• качество является частью культуры и технологии.
Параллельное тестирование
В среде с ограниченным временем поиск и устранение проблем в кратчайшие сроки с момента их появления — условие необходимое. Раньше узнаешь о проблеме — раньше решишь. Ваша задача — тестировать функции программы сразу после их окончательного создания. Это и называется параллельным тестированием. Чтобы его правильно осуществлять, вы должны иметь средства автоматизированного тестирования или ресурсы для проведения ручных тестов, доступные в момент реализации новых функций. Если реализация функции запланирована на конец пятой недели, то команда испытателей должна быть готова протестировать её на шестой. Это правило следует применять ко всем основным функциям. Хотя автоматизированное тестирование предпочтительнее, к запланированному моменту должны быть готовы и ресурсы для ручного проведения этой операции.
Ниже представлен идеальный график параллельного тестирования набора функций программы (табл. 6-1). Заметьте, что разработка и тестирование идут максимально плотно друг за другом. Реализация функции завершается в конце недели, команда испытателей готова приступить к тестированию в начале следующей. Хотя разработчики ответственны и за создание кода, и за его базовое тестирование, команда тестировщиков в заданный период проверяет функцию по максимуму. Так как разработчики и тестировщики должны работать над функцией вместе, их называют «оперативной командой».
Табл. 6-1. График работы оперативной команды над функциями А, В и С.
Разработчики и тестировщики несут обоюдную ответственность за своевременное обеспечение качества.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
Счётчик неудачных исправлений
Ещё один хороший способ оценки нестабильности проекта — счётчик неудачных исправлений для всех ошибок, которые считались исправленными, но на самом деле исправлены не были. При устранении неполадки от команды тестировщиков требуется подтверждение того, что ошибка действительно исправлена. Если проблема всё ещё существует или исправление не принято, ей возвращается статус открытой, а значение поля «Исправлено неудачно» устанавливается в 1. Если тестировщики снова не могут подтвердить устранения неполадки, значение счётчика увеличивается до 2 или 3. Это сигнализирует о серьёзности проблемы и говорит о необходимости вмешательства ведущих специалистов или менеджера проекта.
Дополнительные средства
Хотя средства управления исходным кодом и устранения проблем были стержнем процесса разработки в NuMega, мы регулярно использовали и другие инструменты.
Отладчики
Одним из наиболее важных инструментов для наших разработчиков был разработанный NuMega Technologies невероятно мощный отладчик для Windows — SoftICE. Он загружается при запуске системы как драйвер устройства на уровне ядра и предоставляет беспрецедентные возможности управления и наблюдения за внутренними процессами приложения и операционной системы. Команда разработчиков часто использовала SoftICE для разрешения наиболее сложных проблем при отладке.
Средства анализа производительности и полноты
Мы часто использовали средства анализа производительности, в том числе наши собственные продукты TrueTime и TrueCoverage, для настройки производительности собираемых приложений. Мы поняли, что эти инструменты нужно использовать регулярно в течение цикла разработки, а не в самом конце, когда времени на оптимизацию или устранение проблем не хватает. Анализ производительности проекта по завершении определённого этапа или при выпуске бета-версии предупреждает проблемы и часто раскрывает ошибки, которые могут не проявляться в коде до самого выпуска. Не ждите, пока вы столкнётесь с проблемами производительности, а начинайте сразу применять средства анализа производительности.
Мы также поняли, что эти средства работают наиболее эффективно, если проект специально разрабатывается с учётом анализа производительности и полноты. Собирая такие приложения, мы интегрируем их с нашими тестовыми заданиями для раннего обнаружения проблем с производительностью или для лучшей оценки полноты наших тестовых заданий.
Средства написания сценариев и автоматизации тестирования
Так как наши планы тестирования требовали максимально возможной автоматизации, мы всегда интересовались инструментами, способными нам в этом помочь. Наиболее важными были средства написания сценариев (Perl, командные файлы DOS и т.п.) и средства автоматизации тестирования. В то время Visual Test был доступен по разумной цене и предлагался взыскательным тестировщикам и разработчикам. С его помощью мы тестировали пользовательский интерфейс, но в подавляющем большинстве мероприятий по автоматизации полагались на средства написания сценариев.
Из собственного опыта
Когда мы создавали группу разработки ПО, проверяющего исправность кода, члены команды не были до конца уверены в его значимости. Но с продвижением проекта, когда команда начала применять собственный продукт на собственном коде, стало ясно, что если разработчики блочно тестировали свой код с полнотой 80%, то качество продукта заметно повышалось.
Типичные проблемы и их решение
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Проблемы с инструментами
• Отбор нужных инструментов
Одна из главных ошибок которую допускают команды разработчиков, — игнорирование нужных инструментов. Я убеждён в том, что система управления исходным кодом и система устранения проблем и неисправностей необходимы. В равной степени для команды разработчиков важны средства отладки, поиска ошибок, оптимизации производительности и проверки полноты. Они помогут решить многие уникальные проблемы, всплывающие на поверхность в процессе разработки.
Всё, что может ускорить и автоматизировать цикл разработки, критично для вашего графика. Слишком часто графики сбиваются, так как сложные ошибки или проблемы с производительностью вносятся в процессе разработки, но не выявляются на раннем этапе. Когда они обнаружены, людям без посторонней помощи устранить их практически невозможно. Времени искать нужные инструменты в Интернете просто не будет. Убедитесь, что определились с инструментами, которые вам понадобятся, интегрировали их в процесс разработки и обучили персонал работе с ними.
• Смена инструментов на средине пути
Одно из главных искушений в процессе разработки — замена того, что вы используете сейчас, новой версией или инструментом от другого производителя. Последствия такого решения обычно не просчитывают. Я не могу представить себе смены систем управления исходным кодом или устранения проблем и неисправностей без значительного сдвига графиков. Обычно лучше дойти до конечного выпуска с тем, что у вас имеется, нежели менять это на полпути.
Проблемы управления исходным кодом
• Структура проекта
С ростом проекта структура системы управления исходным кодом становится очень важной. Хотя здесь я предлагаю стандартный способ работы, не забудьте спланировать систему в соответствии с нуждами вашего проекта. Вы должны принять во внимание фактор одновременного выпуска нескольких версий (пакеты обновлений, сокращённые и полные выпуски), а также потребности разработчиков, тестировщиков, фактор обучения пользователей, человеческий фактор и технологические потребности.
• Содержание
Не обманывайте себя, думая, что исходный код — это всего лишь набор файлов, требующий контроля над изменениями. Как было отмечено ранее, управления требует великое множество файлов и документов — не ограничивайтесь преимуществами контроля над изменениями только для исходного кода. Даже если придётся переучивать людей, отвечающих за контроль качества или обучение пользователей, время будет потрачено не зря.
• Конфликты ключевых файлов
Типичный случай: разработчику X был выдан файл, и поэтому разработчик Y не может его взять для внесения важных изменений. Такие конфликты из-за файлов способны замедлить работу над проектом. Предусмотрите способ быстрого внесения критичных исправлений или изменений.
Лучший способ решить эту проблему — предотвратить её появление. Подумайте, можете ли вы разделить наиболее востребованную информацию на несколько файлов, основываясь на логических подсистемах, компонентах и классах. Разбивка содержимого файлов уменьшает вероятность конфликтов.
Когда разделить содержимое файлов невозможно, например из-за жёсткой связи между блоками, следует разработать политику, предусматривающую возврат файлов в течение определённого количества часов после выдачи. Также в случае недоступности файлов программисты могут работать над их копиями, а не над оригиналами. Ставший доступным файл можно взять на короткий срок, быстро обновить и возвратить на место.
В большинстве систем управления исходным кодом поддерживается слияние файлов. Это позволяет совместить изменения в файлах. Хотя обычно эта функция работает правильно, не позволяйте операцию слияния проводить автоматически. Вы должны убедиться, что проверили все изменения, сделанные в файле. Если в нашей системе управления исходным кодом поддержка слияния реализована плохо, можете воспользоваться такими редакторами кода, как Visual Slick Edit и Code Write. Они помогут выявить различия визуально и проверить результат слияния перед его реальным осуществлением.
• Маркировка
Одно из главных достоинств системы управления исходным кодом — возможность маркировки набора файлов, включённых в выпуск. Не забывайте проделывать этот важный этап работы для каждого выпуска, в том числе на основных уровнях, по завершении этапов работы, при выпуске бета-версий и т.д.
Метки должны устанавливаться не только для файлов с исходным кодом. Помечайте файлы-сборки, установочные файлы, файлы документации, файлы контроля качества — словом, все файлы, включённые в выпуск. Метка должна быть информативной и следовать соглашениям об именах, принятым для проекта.
Из собственного опыта
Однажды у нас работала команда, которая оценивала свою систему поиска ошибок во время разработки. Спустя некоторое время они пришли к выводу, что им следует переключиться на использование нового продукта, так как в нём были реализованы новые возможности. Они запустили конвертор и загрузили ПО. К сожалению, через две недели работы с продуктом они обнаружили, что там нет поддержки некоторых отчётов, а производительность программы ужасна. Им нужно было вернуться к предыдущей системе, но так как в новой версии не было предусмотрено процедуры автоматического обратного перехода, им пришлось вручную водить все записи об ошибках и неполадках, внесённые с момента перехода.
Проблемы поиска ошибок и неисправностей
• Целостность данных
Обеспечение целостности данных в системе должно быть приоритетной задачей. Если вы не будете доверять информации в системе, то не станете её использовать, и она потеряет свою значимость. Очень важно определить правила обеспечения целостности данных, в большинстве основанных на внутреннем процессе разработки. Так, вы никогда не должны сталкиваться с ошибками, которые реально «закрыты», но для них установлен статус «исследуется». Чтобы отображать работу над ошибками, нужно со временем изменять статус ошибок. Также убедитесь, что вы вводите правильные значения в поля (информацию об этапе, информацию о выпуске и т.д.). Какими бы ни были у вас внутренние методы проверки целостности, не допускайте хранения недостоверных или устаревших данных, иначе команда разработчиков будет присваивать данным любые значения, а вся система перестанет внушать доверие и станет бесполезной.
Лучший способ избежать проблем с целостностью данных — это убедиться в том, что команда осознает важность этих данных и может обнаруживать и решать проблемы самостоятельно. Собственная мотивация заработает хорошо, если вы продемонстрируете реальную значимость этих данных для команды. Не забудьте также периодически пересматривать данные и обсуждать результаты с командой.
Я показал некоторые способы моделирования ключевых элементов цикла разработки с применением средств устранения проблем и неисправностей. Однако не стоит увлекаться и использовать всё, что только может подойти для вашей команды. Вместо этого определите ключевые потребности для процесса разработки и выберите простые средства для их реализации.
Глава 6
Основы системы контроля качества
Проблемы с контролем качества могут разрушить проект: сорвать сроки или испортить продукт так, что потребители не смогут им пользоваться. Какой бы ни была ваша компания — начинающей или транснациональной корпорацией, вы должны эффективно балансировать между качеством продукта и временем его представления на рынке. Успех или неудача зависят именно от этого.
В этой главе мы рассмотрим основы системы контроля качества в динамичной среде с ограниченными ресурсами, обычной для современных проектов по разработке ПО. Мы остановим своё внимание на том, что, когда, как и кто должен тестировать. Затем я продемонстрирую общее решение и расскажу о некоторых простых и эффективных приёмах управления тестированием.
Основные принципы
Начнём с принципов работы системы контроля качества. Лейтмотив — обеспечение качества непосредственно в процессе разработки. Продукту нельзя придать качество позже без значительных затрат денег, сил и времени. Создание качественного продукта основывается на четырёх простых принципах:
• тестирование продукта осуществляется параллельно с процессом его разработки;
• качество продукта улучшается регулярно при завершении каждого планового этапа разработки;
• тестирование необходимо максимально автоматизировать;
• качество является частью культуры и технологии.
Параллельное тестирование
В среде с ограниченным временем поиск и устранение проблем в кратчайшие сроки с момента их появления — условие необходимое. Раньше узнаешь о проблеме — раньше решишь. Ваша задача — тестировать функции программы сразу после их окончательного создания. Это и называется параллельным тестированием. Чтобы его правильно осуществлять, вы должны иметь средства автоматизированного тестирования или ресурсы для проведения ручных тестов, доступные в момент реализации новых функций. Если реализация функции запланирована на конец пятой недели, то команда испытателей должна быть готова протестировать её на шестой. Это правило следует применять ко всем основным функциям. Хотя автоматизированное тестирование предпочтительнее, к запланированному моменту должны быть готовы и ресурсы для ручного проведения этой операции.
Ниже представлен идеальный график параллельного тестирования набора функций программы (табл. 6-1). Заметьте, что разработка и тестирование идут максимально плотно друг за другом. Реализация функции завершается в конце недели, команда испытателей готова приступить к тестированию в начале следующей. Хотя разработчики ответственны и за создание кода, и за его базовое тестирование, команда тестировщиков в заданный период проверяет функцию по максимуму. Так как разработчики и тестировщики должны работать над функцией вместе, их называют «оперативной командой».
Табл. 6-1. График работы оперативной команды над функциями А, В и С.
Разработчики и тестировщики несут обоюдную ответственность за своевременное обеспечение качества.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36