среда, 27 августа 2008 г.

Рекс Блэк "Ключевые процессы тестирования"


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

суббота, 23 августа 2008 г.

Роман Савин "Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах"

Tестирование dot com или пособие по жесткому обращению с багами в интернет-стартапах. Так называется книга Романа Савина. Хочется сразу сказать, что "жесткого обращение с багами" в книге я не увидела. Минусом считаю определение тестирования, данное в книге. Слишком много печатного места посвящено описанию занесения багов в bug tracking систему.

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

А вот "послесловие" советую прочитать всем! Праввильно написано, ППКС, как говорится :)

вторник, 19 августа 2008 г.

Воители обеспечения качества: часть1 – боевые стратегии для высоко-производительных тестировщиков

Автор: Лаура Роуз, руководитель программ Design Partner, IBM Rational Software Group

Перевод: Галина Галкина (выражаю особую благодарность Артему Бабамуратову за помощь и критику)

Лаура Роуз является экспертом в области обеспечения качества, отвечает за инструменты обеспечения качества в IBM Rational. Лаура обладает 13-ти летним опытом программирования и 10-ти летним опытом руководства тестированием. Она была членом Американского Общества Качества (American Society for Quality), Трехстороннего совета по качеству (Triangle Quality Council) и Трехсторонней ассоциации по обеспечению качества информационных систем (Triangle Information Systems Quality Association), имеет публикации, участвовует в различных конференциях по качеству и тестированию. Вы можете связаться с Лаурой по электронной почте: llrose@us.ibm.com.

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

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

1. Краткое введение в искусство войны

Сунь Цзы (Sun Tsu) был философом-практиком, один из его трудов - «Искусство войны» создан примерно в 500 году до н. э. Веками «Искусством войны» пользовались китайские и японские военные, и политические стратеги. В 2001 году Джеральд Михаэльсон (Gerald Michaelson) изложил «Искусство войны» применительно к бизнесу в своей книге «Искусство войны для менеджеров».

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

Михаэльсон преобразовал стратегии Сунь Цзы в 13 глав книги для бизнесменов. Заимствуя его идеи, я перевела эту работу для инженеров тестирования программного обеспечения. Категории Михаэльсона мне кажутся удачными, и я структурировала свой рассказ в том же ключе:

- Построение планов

- Оценка условий

- Сравнение свойств

- Поиск стратегических решений

- Ведение войны

- Использование разумного количества ресурсов

- Сделайте время союзником

- Каждый должен получить выгоду от победы

- Знайте ваши сильные стороны

- Атака с использование военной хитрости

- Победа без боя

- Сила против слабости – всегда

- Обходите стороной глупцов

- Следуйте фундаментальным принципам

На этом закончится часть 1. Последующие части покроют оставшиеся темы:

- Дислокация военных сил

- Использование энергии

- Слабость и сила

- Маневрирование

- Разновидности тактик

- Марш

- Местность

- 9 переменных расположения

- Атакуем огнем

- Нанимаем секретных агентов

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

2. Построение планов

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

- Детальная оценка условий

- Сравнение свойств

- Поиск стратегических решений

2.1. Оценка условий

«Хорошая оценка – фундамент успешной операции»1

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

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

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

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

Кроме того, высокопроизводительный тестировщик отслеживает сообщения от заказчика, чтобы проверить, не пропущена ли какая-нибудь тестовая область. Он рассматривает «ошибку пилота» (см. http://en.wikipedia.org/wiki/Pilot_error) или «ошибку заказчика» как что-то двусмысленное и неопределенное в продукте. Он уменьшает стоимость и скорость обучения клиента с помощью публикаций документации, FAQов и статей. Он избегает будущих проблем, оформляя свои знания о продукте в базу знаний в виде статей, презентаций, аудио и видео файлов.

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

2.2. Сравнение свойств

«Сравните свои сильные и слабые стороны с конкурентами»

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

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

2.3. Поиск стратегических решений

«Разрабатывайте стратегии, идущие впереди традиционных правил».

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

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

2.4. Применение знаний

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

Вот некоторые способы:

- Пишите статьи, создавайте презентации и FAQ’и, основанные на опыте тестирования и использования продукта;

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

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

- Проходите сертификацию.

3. Ведение войны

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

3.1. Использование разумного количества ресурсов

«Инвестируйте только столько ресурсов, сколько необходимо для поддержания активности»

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

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

Учитывая написанное выше - что более соответствует развитию вашей карьеры: подготовка к использованию новой технологии или реализации далеко идущих идей?

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

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

Лучший исполнитель также контролирует время. Он мастер в управлении временем. Мы подошли к следующему пункту.

3.2. Сделайте время союзником

«Ключ в том, чтобы быстро стать эффективным и продуктивным»

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

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

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

3.3. Каждый должен получить выгоду от победы

«Усиливайте человеческие и материальные ресурсы с каждой победой»

В войне успешная команда – это команда, в которой каждый выигрывает. Когда нанесено поражение врагу, вы получаете трофеи; вы комбинируете свои и чужие ресурсы, вы добры к пленникам, вы добавляете их к своим силам.

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

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

Ниже приведена пара примеров.

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

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

3.4. Знайте ваши сильные стороны

«Изучайте то, что необходимо для победы»

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

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

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

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

3.5. Применение знания

В этом разделе приведены идеи ведения войны Лао Цзы и адаптированы к реальности тестирования программного обеспечения. Вот несколько практических применения этих идей:

- Найдите «гуру» в области и следуйте за ним;

- Записывайтесь докладчиком на конференции по малознакомым вам темам, это создаст сильнейший стимул для изучения;

- Объединяйтесь с коллегами для подготовки к сертификации;

- Стройте и поддерживайте взаимовыгодные отношения;

- Контролируйте ваше время, занимайтесь тем, что помогает достижению ваших целей.

4. Атака с использованием военной хитрости

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

4.1. Победа без боя

«Безоговорочная победа – это победа без конфликта»

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

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

4.2. Сила против слабости – всегда

«Битвы выигрываются концентрацией силы»

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

Ниже несколько примеров:

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

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

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

4.3. Обходите стороной глупцов

«Прежде чем действовать, узнайте все о ситуации»

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

Лучший исполнитель фокусируется на целях компании, чтобы избежать ошибок. Рассмотрим примеры.

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

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

10% изменений влекут за собой новые ошибки.7 Проведение повторного тестирования к определенной дате позволяет обнаружить и исправить эти «добавленные» ошибки. Закрытие ошибок без проверки совсем не соответствует целям качества.

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

4.4. Следуйте фундаментальным принципам

«Шансы на провал будут высоки, если не следовать правилам, обеспечивающим победу»

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

4.5. Применение знаний

В этом разделе описаны основные концепции стратегии. Практическое применение:

- Понимайте цель метрик и процедур;

- Предпочитайте личное общение почте;

- Оценивайте необходимость собраний и задач, посещайте и делайте только то, что принесет пользу;

- Взаимодействуйте с другими командами;

- Проводите анализ возможности ротации для временного увеличения количества ресурсов;

- Цените своё время, используйте его в соответствии с вашими целями.

5. Заключение

Это статья будет продолжена. В части 1 приводятся несколько практических советов, как увеличить производительность тестирования. Как я упоминала во введении, следующие части будут посвящены остальным стратегиям трактата Сунь Цзы применимым к области тестирования. Оставайтесь на связи!

Ссылки

1 Цитаты приведены из книги «Сунь Цзы: Искусство войны для менеджеров» Джеральда Михаэльсона

2 Один из примеров, проверка системы на ошибку «нет свободного места на диске».

3 «Переговоры без поражений. Гарвардский метод» Роджер Фишер, Вилльям Ури.

4 «7 привычек высокоэффективных людей» Стивен Ковей

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

6 «Искусство войны для менеджеров» Джеральд Михаэльсон

7 Статистика показывает, что если необходимо проверить 100 исправленных ошибок, вы найдете как минимум 10 новых.

Список использованной литературы

The Effective Executive: The Definitive Guide to Getting the Right Things Done (Harperbusiness Essentials) by Peter F. Drucker, HarperCollins Publishers Inc, 2002

Sun Tzu: The Art of War for Managers; 50 Strategic Rules by Sun-tzu and Gerald A. Michaelson, Adams Media Corporation 2001The Top Ten Mistakes Leaders Make by Hans Finzel, Davide C cook Distribution Canada, 2007

A Whack on the Side of the Head: How you can be More Creative by Roger Von Oech, 3rd Edition, Warner, 1998Bookis INc

Smart Moves for People in Charge: 130 Checklists to Help You Be a Better Leader by Sam Deep and Lyle Sussman, Perseus Book Group, 1998

The One Minute Manager Meets the Monkey by Kenneth Bnanchard, Blanchard Family Partnership, 1989

The Seven Spiritual Laws of Success A Practical Guide to the Fulfillment of Your Dreams by Deepak Chopra, Pgw, 1995

The Tao of Leadership by John Heider, Lightning Source Inc, 1984

The 7 Habits of Highly Effective People by Stephen R. Covey, Free Press, 2004

The 100 Simple Secrets of Successful People by David Niven, PH. D, HarperCollins Publications, 2006

Getting to Yes: Negotiating Agreement Without Giving In by Roger Fisher and William Ury, Penguin Group USA, 1991

Managing Your Mouth by Robert L. Genua, Amacom Books, 1993

суббота, 16 августа 2008 г.

Правила тестирования

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

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

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

Третье правило: покрывайте требования тестами в зависимости от приоритетов. Написание тестовых сценариев вещь полезная, однако, весьма трудоемкая. Покрывайте тестами только то, что будете тестировать.

Четвертое правило: внимательно читайте требования. Если есть хотя бы малейшая неоднозначность, не стесняйтесь лишний раз спросить. Цена неточности возникшей в начале цикла разработки, с каждым шагом, этапом, раундом - повышается. Лучше задать глупый вопрос и быть уверенным в ожидаемом результате, чем на последних раундах жизненного цикла проекта/релиза судорожно выяснять, как же должна работать программа. Следите, чтобы требования и test case’ы были в актуальном состоянии.

Пятое правило: проводите раунды тестирования «в свободном полете». Другое название – exploratory testing. Штука весьма и весьма полезная. Протестировать все по test case’ам конечно хорошо. Но пользователи не роботы, а живые люди и они могут сделать что-то не так, не по сценарию. Отсюда следует, что иногда полезно пройтись по приложению в отрыве от test case’ов и «копать» в наиболее часто используемых пользователями местах.

Шестое правило: ведите тест-логи (test logs) аккуратно. Тест-лог – это официальный документ. Он подтвердит результаты проверки, и как следствие – общее качество разработанного продукта. Лог должен вестись добросовестно. Самая неприятная ситуация, когда тест помечен как успешно пройденный, а на деле получается, что этот кусок функциональности не работает совсем, и работать ранее не мог. Прививайте культуру ведения тест-логов в вашей команде.

Седьмое правило: все ошибки должны быть зарегистрированы (записаны, занесены в систему управления дефектами). Прививайте культуру фиксации дефекта сразу после его обнаружения. Ошибки должны исправляться, но откладывание занесения ошибки, а, следовательно, её «обнародования» сдвинет момент исправления. В результате риск сорвать сроки увеличивается.

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

среда, 13 августа 2008 г.

И я туда же...

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