четверг, 30 августа 2012 г.

Lesson 161

А давайте поиграем в игру «Из чьего окна видно больше кранов»?

Из моего — девять.
Шесть справа
Альбом: office


и три слева
Альбом: office



А еще сегодня мы выпустили очередной релиз, лейтмотивом которого была фраза от руководителя проекта:

«Всю эту итерацию мы работали почти полностью на вас .
Так что в этот раз только ошибки, которые и так собирались чинить».

Зачотная у нас группа, чо.

Кстати, да. эксплуатация детского труда идет полным ходом, за две недели стажер написал с десяток тестов (норма, прим. руководителя группы АТ) и зафигачил яростный рефакторинг, который грозит сэкономить нам до 12 минут на каждый час тестирования (а это вообще офигенно, еще одно мое примечание). Жаль, скоро он будет работать гораздо меньше — все таки первое сентября на носу, выпускной класс...


Слово Канеру

Все проекты развиваются. Нужно запускать проекты развивающиеся правильно.

На протяжении любого проекта вы должны ожидать (это нормальное положение вещей) крупных и мелких уточнений и исправлений общего плана.

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

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

Продажи телефона пост

Продам HTC Wildfire A3333 за три тысячи рублей, самовывозом из Екатеринбурга.
Зарядка, коробка, истекшая гарантия, пара царапин, полностью работоспособен.

Или обменяю на что-нибудь полезное. Например на набор для вышивания крестиком или литр абсента.
В общем, торг уместен.

HTC Wildfire

Lesson 160

Слово Канеру

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

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

Иногда руководитель проекта совершает ошибки, иногда пользуются вашим советом. Предлагать их нужно, безусловно. Пораскиньте мозгами. Но окончательное решение о запуске проекта принимает лишь руководитель проекта. Если он не послушал ваших советов, то так тому и быть.

Мы не пишем в этой главе много о вопросах, связанных с управлением людьми в условиях стресса. Больше об этом мы расскажем в главе 9 «Управление группой тестирования». Сейчас мы отмечаем, что когда руководители проектов принимают плохие решения, они оскорбляют тестировщиков, заставляют работать сверхурочно, ставят под угрозу их работу. Это не в рамках ответственности руководителя проекта. Важной частью вашей работы в качестве тест-менеджера является защита сотрудников от жестокого обращения.

вторник, 28 августа 2012 г.

Lesson 159

С подачи Green FiLin: рекламный ролик компании, занимающейся работой с IT-персоналом



Слово Канеру

Develop the power of the king's ear

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

В идеале, у вас есть возможность указать на проблему, от которой страдает компания. Неисправленная проблема будет стоить группу определенную сумму денег. Если проблема достаточно серьезна, ее будут исправлять. Если нет — то она может так и не решиться, не все проблемы будут исправлены.


Некоторые компании (несколько, из нашего опыта) принимают как данность тот факт, что тестировщики будут показывать свои доклады и сообщать об ошибках тем, кто будет их слушать. Project managers get annoyed, complain, and are told by their peers and managers to stop whining: тестировщики останутся тестировщиками.

Другие компании имеют более строгую иерархию. В их культуре неуместно для тестировщика неуместно посещение маркетолога или менеджера технической поддержки, для того, чтоб обсудить проблему с продуктом на стадии разработки.

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

Lesson 158

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

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


Слово Канеру

Не пытайся создать культуру контроля

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


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

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

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

Мы не говорим что вы (человек, занимающийся тестированием сегодня) должны знать свое место и оставаться на нем. Мы рекомендуем вам расширить свою роль и влияние в компании. Если вам нужна компетенция менеджера проекта — получите ее. Но делайте эту работу в роли менеджера проекта. Это не роль менеджера тестирования.

пятница, 24 августа 2012 г.

Lesson 157

Слово Канеру

Создайте культуру сервиса

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

Тестировщики предоставляют услугу для проекта в целом. Типичный сервис — поиск и отчетность по ошибкам. Другие сервисы зависят от миссии вашей группы (см. Глава 1, «Роль тестировщика»).

Одним из фундаментальных вопросов, проходящих через литературу по тестированию является определение роли тестирования — сервис или контроль:

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

- Поставщик услуг не контролирует качество конечного продукта, не контролирует процессы, используемые другими поставщиками услуг (программисты, техписатели, маркетологи) и не принимает решения о выпуске или не выпуске продукта. Поставщик услуг не является менеджером проекта, поставщик предоставляем менеджеру услуги.

Глава 8

Слово Канеру

Управление проектом тестирования

Управление проектом тестирования такое же, как и управление любым другим проектом — в некотором отношении. Но есть по крайнем мере одна особенность проекта тестирования — он зависит от проекта разработки. То, что вы делаете, это реакция на то, что делают они. Вот почему использование инструмента подобного Microsoft Project для построения задач по тестированию довольно сложно. Вам нужно прищуриться, чтоб подогнать работу своей команды к этим мелким диаграммам Ганта. В этой главе мы рассмотрим уроки о динамике процесса тестирования и о его контроле.

Lesson 156

Слово Канеру

Программисты рады помочь с тестируемостью приложения.

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

Для тестировщика тестируемость это то, что делает проще тестирование приложения. Для разговора с программистами, более точное определение тестируемости — прозрачность и контрол (Lesson 137). Это определение показывает природу функций, которые могут помочь. Зная это они могут предложить такие фичи, о которых вы бы и не подумали (или не попросили), но которые моги быть полезными. Какие фичи вы должны попросить? См. Lesson 137, там есть ряд примеров.

Многие тестировщики были разочарованы в попытках заполучить фичи для тестируемости от программистов. Мы считаем, что есть три ключевых момента, благодаря которым эти попытки могут достичь успеха.

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

Просите заранее См. Lesson 138 Заранее начинайте автоматизацию.

Будьте реалистом Некоторые запросы тестируемости достаточно малы, чтобы быть запланированными вместе с другими задачами по разработке. Другие представляют собой новые фичи и должны быть запланированы в бюджете так же, как и любые другие. You'll have to champion these to management as well.

Большинство программистов любят программировать. Если ваши просьбы будут точными и разумными, у них есть шанс магически выполниться. Что программистам не нравится, так это пытаться читать мысли людей. Они не приветствуют неоднозначные просьбы.

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

Мы видели много фич тестируемости, которые были очень выгодны для тестируемости продукта. Некоторые были созданы по просьбе одного из нас. Другие предложены командами тестировщиков и программистов. Они были сложны для создания, но стоили того. Мы призываем вас быть настойчивыми.

среда, 22 августа 2012 г.

Lesson 155

Ну, или как-то так - шесть правил Глеба Жеглова:


Слово Канеру

Программисты любят говорить о своей работе. Задавайте им вопросы.

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


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

Вы могли бы найти их диаграммы на доске. Одним из методов является указание на случайную стрелку и вопрос: «Что случится, если это не сработает?». Это может выявить отсутствие обработки ошибок и наличие необоснованных предположений. Вопросы, подобные этому, заданные двум или большему количеству программистов, могут выявить интересные различия.
Почему нужно задавать эти вопросы? Чтоб узнать больше о создаваемой системе, чтоб знать, каким образом она может ломаться, чтоб узнать предположения людей, создающих эту систему. Не будьте для них проверяющим или надсмотрщиком, если они узнают, что это так, то перестанут сотрудничать.

Когда вы получите ответы, напишите заметки и поделитесь ими с программистами или другими тестировщиками. Программисты не любят отвечать на одни и те же вопросы от разных тестировщиков.
Знание языка программирования поможет вам. Если они программируют на C++ или Java вы должны иметь о нх представление. Если ваше ПО многопоточное, вы должны иметь представление о потоках.

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

Ваша работа как тестировщика думать о том, как именно продукт может не работать. Но как член команды вы должны понимать, что продукт только создается. Пусть программисты знают, что вы понимаете ценность их работы.

Не говорите программистам, что они должны предоставить определенную документацию, прежде чем вы сделаете свою работу. Если она у них есть, спросите. Если вам все же нужна информация — спросите самого программиста. Объясните, почему вам это нужно и как поможет вашей работе. Они не могут читать ваши мысли. (См. Gause и Weinberg 1989, Chapter 6; Michalko 1991, Chapter 14).

вторник, 21 августа 2012 г.

Есть вопросы

Хорошая задачка от Александра Селяева

Бывает ли автоматизированное регрессионное функциональное тестирование черного ящика?

Lesson 154

Вы, ваши сервисники проводите учения - кто и что делает, если навернутся все сервера?

Или все и без учений ясно, интуитивно?

Слово Канеру

Фокусируйся на работе, а не на человеке

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

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

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

Не стоит недооценивать способность руководства замечать проблемы. Проблемы с людьми проще заметить, чем исправить. Remember that you are not the manager of the manager who is (seemingly and maybe actually) ignoring a problem employee. Обращая внимание на возможную некомпетентность программиста, вы ограничиваете свою способность справиться с проблемой. Или вы могли бы заставить менеджеров столкнуться с некомпетентностью программиста, которую они пытались не замечать. По прежнему плохая игра.

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

Если вы видите полную картину проблемы, которая, как вы боитесь, не решается, в частном порядке предоставьте доказательства менеджеру, пусть он с этим справляется. Вы сделали свою работу (Pettichord 2001c).

суббота, 18 августа 2012 г.

Lesson 153

Таки ура. Благодаря hetzner, группе поддержки внутренней инфраструктуры, неведомой магии и такой то матери мы переехали в германию. Знаете, как у орков из вахи, техника работает потому, что орки верят, что она должна работать.

Теперь фуллтест проходит за 80 минут, супротив 120-210 на других серверах, люди, бившиеся за минуты поймут.

Слово Канеру

Ваша честность и компетентность потребуют уважения

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

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


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

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

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

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

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

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

пятница, 17 августа 2012 г.

Lesson 152

Слово Канеру

Предоставляйте сервис

Напрямую предложите программистам помощь. Это создаст доверие и докажет, что вы тот, с кем можно сотрудничать. Вот некоторые услуги, которые вы могли бы предложить:

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

- Тестируйте из личные билды и прототипы

- Настройте тестовую среду для программистов, чтоб использовать ее в своих тестах.

Просматривайте требования на предмет их тестируемости. Программисты имеют дело с неоднозначными требованиями. Они могут быть рады вашему участию.

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

Lesson 151

Диалоги. О рыбалке.

- Я бы тоже хотел заниматься всякими сложными и интересными штуками и получать за это деньги.
- Занимайся. Для этого надо уметь %технология% . прочитать %книга% и сделать %задача%.
- Я не умею %технология%, я не понимаю, что делать с %книга%.
- Давай научу. Когда?
- Мне некогда.

Альбом: randompics4lj


«А вот в компании %местный_бренд%» зарплаты на десять тыщ больше.
Так они и вьебывают яростно и с энтузиазмом. Творят всякое. Время, что характерно, находят.

Я к чему это. Эффективные способы научиться — это учить и запилить реальный проект. Я в последнее время сильно дофига всего не умею и не понимаю. И у меня есть проектик за тестирование. Екб, нау может кому интересно?

Слово Канеру

Работай на доверие программистов

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

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

Если вы не согласны и считаете, что что-то приведет к проблемам, выскажете свое мнение, но не будьте занудой. Правы вы или нет, будет ясно позже.

Lesson 150

Эпиграф:
- Нам с тобой не о чем говорить. Вот ты достоевского читал?
- Да.
- А я нет. И о чем нам говорить?


Из последнего прочитанного:
Дайте им умереть. Олди. Самая слабая книга серии кабирского цикла.
Альбом: home


Последний герой. Пратчетт. Норм.
Альбом: home


Ключевые процессы тестирования. Рекс Блэк. Незачот, хотя сканает.
Альбом: home


На очереди
Snuff Пратчетта, жду эпика.
Альбом: home


Теория ограничений Голдратта, Максим cartmendum о ней столько говорил
Альбом: home


Dexter by Design Линдсей, ня.
Альбом: home


А еще мы заказали пару неплохих книжек, жаль, на мунспике, ну, буду переводить, чо. Или падаванов попрошу.

How to Break Web Software: Functional and Security Testing of Web Applications and Web Services. Виттакера
Альбом: home



A Practitioner's Guide to Software Test Design
Альбом: home


Слово Канеру

Поймите, как думают программисты

Все трое из нас начинали свою работу как программисты перед специализацией в тестировании. Мы по-прежнему пишем код. Наш опыт помогает понимать программистов, когда мы работаем в качестве тестировщиков — мы работаем с программистами.

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

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

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

Большинство программистов специализируются. Программисты часто фокусируются на какой-то подсистеме или модуле, depending on often-sketchy information about the other system elements that their code must interact with. С другой стороны, вы часто знаете систему в целом. Чтоб тестировать, вы должны понимать, как система работает целиком. Вы могли бы предоставить информацию о всей системе программистам, с которыми работаете.

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

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

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

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


Для дальнейшего обсуждения см. статью Pettichord's (2000b) "Testers and Developers Think Differently."

четверг, 16 августа 2012 г.

Lesson 149

Наша молодая, динамично развивающая компания Я ищу тестировщика в группу.

Ты ответственный, коммуникабельный, дружелюбный, креативный, аккуратный, внимательный и клиентоориентированный? Вон отсюда.

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

Официальная часть такая официальная: http://www.rabota66.ru/vacancy/169772


Слово Канеру

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

Вот два очень разных резюме:
- Наша документация тестирования будет в первую очередь помогать нам искать ошибки, делегировать работу и отслеживать статус продукта.
- Наша документация тестирования будет в первую очередь помогать нам поддерживать стабильность продукта на протяжении 10 лет, предоставит материалы для обучения новых тестировщиков и создаст архивы для аудита или судебного использования.


Эти резюме предполагают разный набор документации. Просмотрите итоговую миссию вашей документации с каждой из заинтересованных сторон.

lesson 148 Часть 2

Слово Канеру



Если документация оговаривает только часть проекта тестирования, должна ли она контролировать ранние или поздние этапы проекта? Тестирование должно проходить со ссылкой на документацию? Это верно для всего времени жизни проекта или на ранних этапах тестирование было скорее исследовательским? Или исследования проводились ближе к завершению проекта?

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

Какие документы (требования или сппецификации) вы отслеживаете и кто это контролирует?


До какой степени документация тестирования должна отслеживать статус продукта, процесс и прогресс тестирования? Вы хотите создать систему, которая позволяет подсчитать количество задокументированных тестов, количество тестов в плане, число успешных, провалившихся тестов, число найденных ошибок? Будет ли документация тестирования играть важную роль в такой системе? К примеру, должны ли тестировщики, работая с документацией, отмечать, какие тесты они проводили? Должны ли они только отмечать пройденные тесты галочками или собирать отчет по статусу продукта?

Насколько хорошо должна документация поддерживать передачу работы новым тестировщикам? Чтоб эффективно делегировать работу, вы должны достаточно подробно объяснить, что нужно делать. Эффективное делегирование не обязательно подразумевает пошаговые инструкции. Мы предпочитаем обучать новых тестировщиков ряду навыков, дать им несколько вступительных задач, ознакомить с документацией (например с руководством пользователя), а затем давать им инструкции, предполагающие, что они уже имеют нужные навыки и справочные материалы. Вместо того, чтоб замедлиться (и усложнить документацию) ради тестировщиков, которые не могут развить свои навыки, мы заменяем их на тех, кто может. Если вы считаете, что детальные инструкции необходимы, то мы предупреждаем вас, что их создание требует много времени и навыков, для того чтоб сделать их эффективными. По этим вопросам читайте Wurman (1991). Другим аспектом делегирования является ваша способность определить что именно должно быть сделано и насколько качественно оно сделано. Если у вас есть кто-то для работы над коротким документом (например одна из матриц из приложения к главе 3, методы тестирования), то вы оцените результат верно с большей вероятностью, чем если бы у вас были несколько десятков или сотен страниц сценариев тестирования.

Каковы ваши предпочтения относительно навыков и знаний новых тестировщиков? Опубликуйте их. Чем больше людей знают о ваших требованиях, тем меньше вам придется проговаривать их.


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

Тестовый набор должен обеспечить профилактику, выявление или прогнозирование? Что является более важным для проекта? Если вы создаете тест достаточно рано и рассматриваете его вместе с программистами, то они могут разработать программу с гарантией, что она пройдет тест. Так как они думали о тесте в процессе разработки, они просто не могли допустить ошибку. Просто проходя через этапы разработки и задавая вопросы программистам можно выделить риски и слабые места в их подходах. Это примеры преимущества профилактических тестов. Затем вы получите код. Если вы спроектировали тесты эффективно, то они помогут вам обнаружить большинство ошибок. Это преимущество тестов, направленных на выявление. Наконец, результаты тестирования помогут вам спланировать остальную часть проекта или будущие проекты. Они помогут выделить проблемные области, общие типы ошибок и улучшить стратегию. Также они позволят получить статистические данные, которые можно будет использовать для прогнозирования сроков выполнения задач и, возможно, для оценки оставшегося объема работ по проекту. Планирование тестирования принесет много пользы. Среди этих трех подходов вы могли бы сосредоточиться на одном, какой это будет подход? У каждой группы свой ответ на этот вопрос.

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

Будет ли документация помогать определить изменения рисков программы? Эвристика говорит нам, что больше всего ошибок в ой области программы, где они были раньше. Таким образом ее надо больше тестировать. Но в определенный момент все ошибки в этой области будут очищены и другие части продукта, ранее бывшие стабильными, перестанут таковыми быть. Будете ли вы создавать документы, помогающие определить изменения стабильности областей продукта с течением времени?

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

четверг, 9 августа 2012 г.

lesson 148 Часть первая

Как считаете, из примерно 25 человек сколько откликнутся на призыв:

Кто хочет потратить уйму свободного времени и энтузиазма на самообучение, слишком похожее на неоплачиваемый рабочий день?


Слово Канеру

Чтоб проанализировать требования к документации тестирования, задайте вопросы из этого списка.

Мы рекомендуем Gause и Weinberg (1989) для введения в анализ требований и в качестве великолепного списка свободных от контекста вопросов, являющихся полезными для анализа любых требований. Michalko (1991, 138) предоставил дополнительный набор независимых от контекста вопросов (вопросы CIA Phoenix). В добавление к этому мы собрали ряд вопросов, выявляющих более конкретные требования к документации тестирования.

Какова миссия вашей группы, какие у вас цели в тестировании продукта? Документация тестирования (как и любая другая работа в продукте, что вы делаете) не имеет ценности, если она не выполняет определенную миссию и не помогает достичь целей.

Документация тестирования это продукт или инструмент? Продукт это то, что вы отдаете кому-либо еще для использования. Они за это платят. Вы выполняете все, что от вас требуют в соответствии со стандартами и готовностью платить за них. Напротив, если документация является внутренним инструментом, она не должна быть более организованной, более полной, более аккуратной, чем это минимально необходимо для того, чтоб помочь в достижении целей.

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

Насколько быстро меняется дизайн? Если дизайн меняется часто, не создавайте детальных тестов; информация будет устаревать слишком быстро. Не тратьте много страниц на тесты, тесты будут пересмотрены или отброшены слишком быстро для того, чтоб оправдать инвестиции.

Насколько быстра меняется спецификация после изменения в архитектуре? You cannot do specification-driven testing if the specification is chronically incomplete and out of date, nor would you want to tie your test documentation to the contents of such a specification. Примечание: не пытайтесь вилять собакой. Если проект был запущен без актуальных спецификаций, проект может в них и не нуждаться. Неудобство группы тестирования не является весомым аргументом для изменения политики ведения спецификаций. Если у вас их нет, запланируйте адаптацию стратегии тестирования, а не изменение политики проекта. Если вы планируете бороться за качественные спецификации, делайте это на основе расходов и рисков других заинтересованных сторон, особенно тех, кто имеет более заметное влияние на прибыли и убытки компании.

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

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

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

Should the documentation ever control the testing project? Do you want testers to look in the documentation for operations information (such as scheduling info that lays out what to do next)?

вторник, 7 августа 2012 г.

А музыка звучит

Если повезет, на днях займусь эксплуатацией детского труда в IT сфере, бгг, всю жизнь мечтал.


Настроение этой недели:


Безотносительно текста песни, чисто на припеве.

Lesson 147



Откуда-то помню, что именно эту песню надо орать в кабаках пьяными голосами.

Слово Канеру

Анализируйте требования перед тем как решить, какой продукт создавать. Это относится как к продукту, так и к его документации.


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

Мы не понимаем менталитет тех, кто настаивает, что код не может быть написан без детального анализа требований, но принимаем тех, кто хочет написать большой объем документации без анализа требований к ней.
Пожалуйста, поймите это правильно. Мы не говорим, что стандарт IEEE 829 не подходит для вашего продукта. Он может быть прекрасной вещью. Так же как COBOL может быть идеальным языком для вашего проекта. Все что мы говорим: подумайте о том, что вы собираетесь создать прежде, чем вы выберете язык программирования и другие основные инструменты.

Lesson 146

Забавная история. Найдено тут.


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

История эта произошла в 1994 году. Страны Карибского региона проводили международный футбольный турнир, который называется Кубок Карибского Моря (Shell Caribbean Cup). В одной отборочной группе собрались сборные Барбадоса, Гренады и Пуэрто Рико. По регламенту только одна команда выходила из группы в следующий раунд финальной фазы. Команда Гренады в первом туре победила Пуэрто Рико со счетом 2:0, в то время как Барбадос свою встречу пуэрториканцам проиграл с минимальным счетом 0:1.

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

Для того, чтобы первое место досталось в итоге Барбадосу, а не Гренаде, ему нужно было побеждать в очной встрече сборную Гренады с разницей в 2 мяча. Один мяч уже ничем не помогал.

Все бы ничего, если бы не страннейшее правило турнира: золотой гол в добавленное время приравнивался двум голам.

Забив быстрые два гола, Барбадос повел в матче со счетом 2:0. Этот счет, устраивающий барбадосцев, держался вплоть до 83-й минуты. Однако, к великому сожалению барбадосцев, они сами же себе случайно забили автогол и свели свои усилия насмарку. Счет на табло стал 2:1.

Матч (точнее, его оставшиеся семь минут) стремительно близился к завершению. Гренада стала плотно обороняться, поскольку очень боялась счета 3:1. Забивать голы сопернику всегда тяжелее, чем себе. Видя это, игрок сборной Барбадоса (как мы помним, этой сборной нужно победить с разницей именно в два мяча) защитник Сиели, не будь дураком, взял да и умышленно забил гол в свои ворота. Ведь он изменил счет на 2:2 и мог вот-вот перевести игру в овертайм (целых 30 минут), в течение которого Барбадосу можно было забить один "золотой гол" и выиграть у гренадцев как раз 4:2 (а не 3-2) и стать лидером группы.

Игроки сборной Гренады и все зрители от этих событий, мягко говоря, обалдели. Всё сошло с ума: сборной Гренады нужно было собраться и забить один мяч (они не хотели рисковать в овертайме). Разницы, в какие ворота им бить, не было никакой. Проиграй Гренада 3:2 - вышла бы дальше. Выиграй Гренада 3:2 - тоже вышла бы дальше.

Естественно, Гренада всем скопом радостно кинулась атаковать свои же ворота. Барбадосцы бросились к воротам соперника и …начали защищать владения Гренады от её же автогола. Позади вратаря гренадцев встал защитник Барбадоса Сиели (тот самый) – он должен был отбивать мячи Гренады . Тогда Гренада побежала забивать гол Барбадосу , и барбадосцы кинулись защищать уже свои владения.

На поле и на трибунах царил такой дурдом! В последние две минуты основного времени и четыре минуты добавленного гренадцы старались забить гол – без разбору - в любые ворота, а барбадосцы обороняли от губительного для них гола ВСЕ ворота на поле. Барбадос выстоял. Гренаде не удалось забить ни гол, ни автогол - 2:2.

В добавленное время гениальный план Барбадоса сработал. Игрок Барбадоса Торн забил «золотой гол», который автоматически прекратил игру и сделал счет 4:2 в пользу Барбадоса .

Слово Канеру

Не используйте стандарт IEEE 829

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

Это похоже на аргумент «Не оружие убивает людей, а люди». Иногда это верно, но иногда и нет.
Что касается IEEE 829 мы видели проблемы достаточное количество раз, у людей, которых мы уважаем, в компаниях, которые использовали шаблоны основанные на 829 в нескольких проектах, так что мы считаем, что эти проблемы отражают слабость стандарта и не могут быть отклонены со ссылкой на некомпетентность людей, этот стандарт использующих.

Аргумент «оружие не убивает людей» читается в этом случае иначе: если бы спусковой крючок пистолета был бы ворсинкой и это небезопасное оружие оставляли бы в общественных местах, заявляя «используйте это оружие во всех проектах».

Вот некоторые из вопросов, возникающих при использовании стандарта на практике:

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

- Массивная документация создает определенный менталитет — делать то, что предписывает план. Это в корне отличается от менталитета настороженного, критического тестировщика, обращающего внимание на любые детали и следящего за перспективными возможностями.

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

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

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

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

- Расходы на обслуживание документов огромны. Когда ПО меняется, вы не просто должны изменить часть документации, связанные с определенным аспектом программы. Вы должны найти все остальное, чтоб выяснить, что именно должно измениться. Это усилия по поиску и изменению неактуальных файлов. Если документация не соответствует коду 1 к 1, то это принесет массу затрат времени позже.

- Документирование каждого теста серьезно мешает автоматизации тестирования. Если документирование теста занимает 1 час (это заниженная оценка) и вы хотите 10 000 тестов в вашем проекте (это, безусловно, не завышенная оценка числа тестов) то придется потратить 10 000 тестер-часов на документирование. Также вы оплатите стоимость работы по приведению в соответствие тестов и документации. Когда тесты изменятся, например из за особенностей обслуживания тестируемого ПО, то придется менять и документацию, это приведет к затратам еще большего количества тестер-часов. Это огромный налог на автоматизацию. Компании, которые его платят могут отказаться от написания большого количества тестов вместо того, чтоб отказаться от затрат, связанных с их документированием. По нашему опыту, компании чаще всего просто отказываются от любой документации, в конечном итоге бесполезными становятся любые документы, созданные до этого (так как они становятся неактуальными).

- Парадигма автоматизированного тестирования, включающая миллионы тестов, сгенерированных или использующих случайные данные или последовательности, кажется совершенно чуждой данному стандарту. We can imagine shoe-horning the software documentation and the associated software models into the Standard's categories, but we don't see that done in practice. Instead, we see that these efforts (models, code, oracles, and so on) are documented elsewhere or not at all.

- Мы уже упоминали наш опыт судебных процессов. Закончив этот перечень, упомянув другой опыт. Некоторые компании начинают с соглашения о том, что процесс тестирования будет задокументирован в определенной степени, что стандарт 829 будет исполняться, что стратегия тестирования будет то-то и то-то. Затем они проходят часть пути проекта и отказываются от своего заявления в пользу того, как они видят положение сейчас, ради выполнения реальных задач по реальному графику. Они могли бы сразу принять правильное решение, но думали о том, как это будет выглядеть в суде. Они начали с тщательного планирования и следования стандартам индустрии, не выдержали их и выпустили дефектный продукт. Это выглядит очень плохо. Если вы не собираетесь следовать амбициозным планам и у вашей компании есть риск судебного преследования, не начинайте проект с заявления, что вы собираетесь следовать этому плану. Чрезмерно амбициозный план может принести больше вреда, чем пользы.


Перечислив все эти затраты, вернемся к вопросу бонусов. If we spend all this money, add all this inertia to our projects, and encourage our staff to run their brains at a lower setting when they do (as opposed to write about) testing, what do we get back in return?
Многие компании исползуют существенно меньше бумаги. Они отслеживают статус продукта с помощью набора коротких таблиц, отчетов о состоянии, а также регулярных встреч команды. Они отслеживают проблемы с помощью хорошо написанных багрепортов, хранящихся в хорошем багтрекере. Какие преимущества получат эти компании от стандарта 829? А какие выгоды будут решающими в ваших обстоятельствах?

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

воскресенье, 5 августа 2012 г.

пятница, 3 августа 2012 г.

Lesson 145

Девушки-тестировщицы такие девушки...


я: Ты б заходила к нам в кабинет. И новенькую брала. Надо ж знакомиться.
Коллега: ой, Максимка, как новенькую увидел - дак сахарный весь прям.. эх, мужики, козлина ты, я ревную
я: да я ж это, в смысле что за человек и так далее. Может ей интересно и можно из нее "звезду вырастить", как шеф говорил
Коллега: только ты будешь из нее растить зведу, а меня кинешь, а я мож тоже хочу быть молодцом
Коллега: И не говори: хочешь - будь =)



Слово Канеру

Используйте стандарт IEEE 829 для документирования тестирования.

Стандарт IEEE 829 это проект, во главе которого находится David Gelperin. Он умный вдумчивый, внимательный, открытый человек, который способствовал разнообразию, творчеству, развитию и применению навыков в области тестирования ПО. Его компания Software Quality Engineering (SQE) организатор STAR Conference (Software Testing Analysis & Review), конференции, являющейся одной из лучших и успешных конференций в этой области. Мы регулярно выступаем на SQE конференциях. SQE также предлагает курсы по тестированию. Наша критика стандарта 829 не является критикой ни David'а, которого мы считаем своим другом, ни многих общественных движений, которые, при условии, что они совершаются за свой счет, способствуют развитию сообщества тестировщиков.

Многие атрибуты стандарта 829 отражают сильные стороны David'а. Но ни одна из многих категорий информации в стандарте не является лишней. Когда мы читаем стандарт, мы имеем возможность понять, почему кто-то хотел знать каждую частицу информации из тех, что требует стандарт.

Ничто в стандарте не является обязательным. Если вы хотите создать процедуру тестирования по сценариям, стандарт 829 расскажет вам, как их назвать и где разместить в документации. Если вы не пишете такие тесты, то вы не должны создавать этот тип документации просто, чтоб следовать стандарту. Этот стандарт дает основу, структуру и набор терминов, а не набор обязательных секций.
Стандарт был изучен и обсужден. Люди в нашей сфере знают об этом. Стандарт является основой для многих (возможно, большинства) шаблонов документации по тестированию, циркулирующих между компаниями. Он стал основой для разговора о планировании улучшения и проверки документации (к лучшему или к худешму) во многих компаниях.

Двое из нас, Bach и Kaner. Были консультантами в суде в делах, связанных с дефектной продукцией, а наши коллеги также были в подобных ситуациях, что дало нам подробные описания подобных инцидентов. Мы наблюдали случаи, когда плохая документация была основой проблемы, приведшей к судебному разбирательству. Даже если документация не была ключевой проблемой, многим из компаний, чья продукция была якобы неисправна и которые были обвинены в мошенничестве, было бы лучше, если их документация тестирования была яснее и лучше организована. Беспорядок ослабил их оборону. Стандарт IEEE 829 мог бы спасти этим компаниям много денег и, возможно, помог бы сохранить деньги их клиентам.

Lesson 144

Рекомендую:
http://hvorostovoz.blogspot.com/2012/08/bdd-bug-driven-development.html


Слово Канеру

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

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