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

Итак приступим.

Для создания загрузочной флешки нам понадобится:

• компьютер с Windows XP или старше
• флешка или SD-карта размером больше 2.5 гб (так как объема в 3Гб у носителей я не видел, минимально-подходящая – 4 Гб)
• Дистрибутив Windows 7 в виде ISO-образа на диске или уже записанный DVD с W7

Внимание: все данные на съемном носителе будут уничтожены!!!

Шаг 1 – Diskpart
Вставляем флешку (или SD) в соответствующее устройство на компьютере.
вызываем командную оболочку (Win + R или Пуск-Выполнить-cmd) и запускаем diskpart
В командной строке DiskPart’а выполняем следующие команды:
list disk – отобразит нам список дисков представленных на компьютере, среди которых должна быть наша флешка (или SD). Если в списке отображенных дисков Вашей флешки или SD-карты нет, попробуйте сделать list volume.
выбираем свой сменный накопитель командой select disk #, где # – номер нашего диска в списке, выведенном предыдущей командой. (если на предыдущем шаге Вы пользовались list volume, то и сейчас надо будет select volume #)
удаляем все партиции на флешке командой clean
создаем первичную командой create partition primary
выбираем ее select partition 1
делаем активной active
форматируем format fs=fat32
назначаем ей букву в системе assign (если вдруг не сработает попробуйте указать букву напрямую, например assign letter=Q – у вас появится новый диск
выходим из дискпарта exit

Шаг второй – переносим контент
Если у Вас ISO-образ W7, его можно просто распаковать на винчестер, в любую директорию, любым архиватором, работающим с этим форматом, а затем скопировать на флешку.
Если у Вас DVD – выполняем в командной строке следующую команду xcopy x:*.* /s/e/f y: где x – имя вашего DVD-привода со вставленным диском W7, а y-имя Вашего USB-привода (SD-карты)
через некоторое время контент будет успешно скопирован

Шаг третий – делаем привод загрузочным
Идем в директорию boot нашего распакованного образа (или на DVD-диске) и выполняем там команду bootsect.exe /nt60 Y:, где Y – имя вашего USB-привода (или SD).

Вуаля!

Давайте в первую очередь разграничим Контроль качества (QC) и Обеспечение качества (QA).

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

Качество это параметр конечного продукта. Продуктом может быть что угодно – выработанные требования, сгенерированные тестовые данные, написанный исходный код, и так далее. Сервис тоже является продуктом — таким образом встречи с клиентом, работа службы поддержки,обучение персонала — все это попадает под определение «продукт» и, как результат, имеет тот же набор параметров — качество в том числе. Каждый продукт является результатом какого-либо процесса, а смысл процесса – производить один и тот же продукт снова и снова с теми же характеристиками. Это применимо ко всем областям разработки ПО. Обеспечение качества (QA) прежде всего интегрируется с процессом разработки, и, будучи интегрированным в процесс разработки, может, при соблюдении всех его составляющих, на постоянной основе гарантировать соответствующий уровень конечного продукта.

Контроль качества (QC)

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

Обеспечение качества (QA)

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

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

Давайте подытожим и окончательно разграничим контроль качества и обеспечение качества

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

Именно QA, Будучи внедренным в существующий процесс, выявит его слабые места и позволит избавиться от них, повышая качество разработки.

Контроль качества возможен в любой среде — даже с отсутствующим QA. И наоборот.

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

Контроль качества занимается проверкой выполнения (или не выполнения) конкретных условий в заданном продукте (или сервисе). Основная цель контроля качества — выявить существующие недостатки в продукте для их последующего устранения, а обеспечение качества занимается выстраиванием процесса -указывает на слабые места и помогает устранить их. Иногда QA даже называют «контролем за контролем качества». Тем не менее, QA-специалисты не выполняют задания по контролю качества, за исключением случаев, когда им необходимо проверить что они корректны и выполняют свою функцию.

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

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

1. Немного этимологии и энтомологии

Давайте посмотрим попристальней на такое знакомое и (до боли?) родное слово БАГ. Происходит оно от английского слова Bug, означающего «насекомое». Есть еще много сторонних значений, в частности английское выражение «to go bugs» – сойти с ума, что легко кореллируется со вполне русским «тараканы в голове завелись». Также вспоминаются и «жучки на линии» (тоже, кстати, по-английски – bugs). И опять мы пришли к насекомым.

Еще в 1878 году, Томас Альва Эдисон (да-да, тот самый!) в письмах к своему соратнику Пускасу писал: «It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and [it is] then that ‘Bugs’ — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached». Тем же словом, инженеры называли и сбои радарной электроники во время второй Мировой Войны. Конечно, более распространена история о том, что в 1946 году разработка компьютера Марк-2 (Mark-II) были приостановлена из-за сбоя его функционирования, вызванного попаданием мотылька между контактов. Трупик мотылька был извлечен и приклеен к отчету липкой лентой с комментарием «First actual case of bug being found.» («Первый случай нахождения настоящего жучка»). Как нетрудно догадаться, примерно оттуда же «растут уши» и слова «дебаггер» (debugger) – буквально «избавитель от жучков».

2. Виды багов.

Простейший (не как инфузория-туфелька, а самый простой для понимания, можно сказать «классический») баг – это несоответствие между ожидаемым результатом (ОР) и фактическим результатом (ФР). Разберем это на примере:

(это, кстати, реальный баг старого Microsoft Excel – он не учитывал приоритета математических операций, по которому умножение имеет высший приоритет по сравнению со сложением)

Все просто. Ждем одно – получаем другое. Баг.

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

2.1. Гейзенбаг (Heisenbug)

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

2.2. Борбаг (Bohrbug)

Тип бага, названный так в честь атомной модели Бора. В противоположность Гейзенбагу, он проявляется постоянно при одном и том же стечении обстоятельств. Вопрос в том, что весь набор обстоятельств бывет невозможно (или очень трудно) отследить.

2.3. Мандельбаг (Mandelbug)

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

2.4. Шрединбаг (Schroedinbug)

Шрединбаг назван в честь известного парадокса с кошкой Шредингера (или эта несчастная животина – кот?). Он заключается в том, что кто-нибудь читает код программы (работающей уже некоторое время) и восклицает «Да этого не может быть! Она просто не может функционировать!», после чего программа прекращает свое функционирование пока данная ошибка не будет исправлена. Будучи, казалось бы, абсолютно фантастической, данная ошибка попадается в реальности – спросите знакомых ветеранов- разработчиков, они подтвердят. Хотя, конечно, последующий анализ, как правило, позволяет отнести ошибку к разделам 2.1, 2.2 или 2.3, это удается не всегда.

2.5. Фазы луны

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

2.6. Статистический (более известный как количественный) баг

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

2.7. Демонстрационный эффект.

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

На этом я закончу краткий обзор багов, буду рад Вашим замечаниям и предложениям.

Автор,
Мартынкин Денис