воскресенье, 4 ноября 2012 г.
Канер о наборе тестировщиков
Недавно я натолкнулся на статью Канера о наборе тестировщиков. Она выложена как дополнительный материал для изучения в курсе BBST Foundtation. Думаю статья заинтересует всех, кто занимается набором персонала, особенно набором тестировщиков, менеджеров по управлению командами тестировщиков, да и просто айтишников. Статья будет также полезна тестировщикам, ищущим работу (чтобы понимать, чего от них ждут). Для меня Канер (посмотрите его блог на http://kaner.com) - это безусловный авторитет в мире тестирования, его мысли всегда изложены доступным языком (даже по-английски), его книги и статьи мотивируют на то, чтобы развиваться в своей профессии.
Далее следуют мои заметки из статьи, которые я решил сохранить на будущее.
суббота, 8 сентября 2012 г.
Курс Bug advocacy - часть 2 - Эффективная защита: Как заставить людей захотеть пофиксить баг
Предыдущая часть лекций показалась мне более структурированной, чем часть, которую мы рассмотрим сегодня. В этой части я обнаружил много светлых и хороших идей, но разбросанных безсистемно. Возможно дело во мне и я просто не смог увидеть структуру. В любом случае, думаю полезно будет обсудить основные тезисы второй части. Напоминаю, что все материалы курса BBST можно найти по ссылке http://www.testingeducation.org/BBST/bugadvocacy/.
В предыдущей части мы рассматривали случаи, в которых должен быть заведен баг репорт. Основные заключения:
Представим себе ситуацию, когда в одной компании возникает уйма жалоб от пользователей: продукт не работает. Начинается разбирательство и выясняется, что баги были заведены, но программисты не поняли баг репорты и не пофиксили их. Проблема заключалась в том, что тестеры были более сосредоточены на том, чтобы завести воспроизводимые баги, а не на качестве предоставляемой в баг репорте информации. Конечно, воспроизводимость бага имеет большое значение, но иногда одной воспроизводимости недостаточно.
В предыдущей части мы рассматривали случаи, в которых должен быть заведен баг репорт. Основные заключения:
- Баг - это что либо угрожающее ценности продукта для влиятельного стейкхолдера;
- Баг репорт - это утверждение о том, что продукт может быть лучше, чем он есть;
- Идея "быть лучше" сама по себе субъективна: что лучше для одного, может быть хуже для другого;
- Баг репорт обоснован, если он описывает проблему, которая действительно уменьшает ценность продукта для влиятельного стейкхолдера.
Представим себе ситуацию, когда в одной компании возникает уйма жалоб от пользователей: продукт не работает. Начинается разбирательство и выясняется, что баги были заведены, но программисты не поняли баг репорты и не пофиксили их. Проблема заключалась в том, что тестеры были более сосредоточены на том, чтобы завести воспроизводимые баги, а не на качестве предоставляемой в баг репорте информации. Конечно, воспроизводимость бага имеет большое значение, но иногда одной воспроизводимости недостаточно.
суббота, 18 августа 2012 г.
Курс Bug advocacy - часть 1 - Основные понятия
В первой части рассматриваются основные понятия:
Баг репорт - это главный продукт деятельности тестировщика.
Это то, что люди вне группы тестирования замечают больше всего и помнят больше всего из всей нашей работы. Люди делают выводы об уровне наших исследований, у них складывается определенное впечатление о нас. Баг репорты создают нам репутацию. Даже люди, которых мы ни разу не видели, буду делать выводы о нас на основе баг-репортов. И даже самое тщательное тестирование не будет положительно сказываться на нашей репутации, если наши баг репорты не отражают нашу заинтересованность и наш интеллект.
- зачем нужны качественные баг-репорты;
- что такое error, failure, bug;
- что такое качество.
Зачем нужны эффективные баг репорты?
Баг репорт - это запрос на добавление дополнительной задачи в список задач программиста. Когда релиз уже близко и программист вынужден исправлять много багов, он устал и он будет просто игнорировать те баги, которые кажутся ему слишком сложными или непонятными. И это происходит не потому, что он не заинтересован в качестве, а потому, что он не может сделать абсолютно все.Баг репорт - это главный продукт деятельности тестировщика.
Это то, что люди вне группы тестирования замечают больше всего и помнят больше всего из всей нашей работы. Люди делают выводы об уровне наших исследований, у них складывается определенное впечатление о нас. Баг репорты создают нам репутацию. Даже люди, которых мы ни разу не видели, буду делать выводы о нас на основе баг-репортов. И даже самое тщательное тестирование не будет положительно сказываться на нашей репутации, если наши баг репорты не отражают нашу заинтересованность и наш интеллект.
Курс Black Box Software Testing (BBST) - обзор
Не так давно я нашел онлайн курс BBST (Black Box Software Testing), созданный Сэмом Канером и Джеймсом Бахом. Курс включает в себя основные подкурсы:
- Foundations of Software Testing
- Bug Advocacy: Effective Bug Investigation and Reporting
- Test Design: A Survey of Black Box Software Testing Techniques
вторник, 13 марта 2012 г.
О спешке (цитата из "EAST OF EDEN" Стейнбека)
"In human affairs of danger and delicacy successful
conclusion is sharply limited by hurry. So often men trip
by being in a rush. If one were properly to perform a
difficult and subtle act, he should first inspect the end to
be achieved and then, once he had accepted the end as
desirable, he should forget it completely and concentrate
solely on the means. By this method he would not be
moved to false action by anxiety or hurry or fear. Very few
people learn this".
John Steinbec, "EAST OF EDEN".
conclusion is sharply limited by hurry. So often men trip
by being in a rush. If one were properly to perform a
difficult and subtle act, he should first inspect the end to
be achieved and then, once he had accepted the end as
desirable, he should forget it completely and concentrate
solely on the means. By this method he would not be
moved to false action by anxiety or hurry or fear. Very few
people learn this".
John Steinbec, "EAST OF EDEN".
воскресенье, 26 февраля 2012 г.
Количественный метод анализа интерфейса с помощью модели GOMS (по книге Джефа Раскина)
Сегодня мы познакомимся с количественным методом анализа интерфейса, основанным на модели GOMS. О нем я прочитал в книге Джефа Раскина "The Human interface". Постараюсь объяснить в общих чертах идею метода, а за подробностями можно обратиться к книге.
Модель GOMS (расшифровывается как "the model of goals, objects, methods, and selection rules") позволяет предсказать время, необходимое для выполнения задачи с помощью конкретного интерфейса. Разработчики этой модели обнаружили, что для решения поставленной задачи при работе с компьютером пользователь совершает определенный набор жестов. Таким образом, время выполнения задачи складывается из времени выполнения этих жестов и из промежутков между жестами, которые требуются для обдумывания.
Модель GOMS (расшифровывается как "the model of goals, objects, methods, and selection rules") позволяет предсказать время, необходимое для выполнения задачи с помощью конкретного интерфейса. Разработчики этой модели обнаружили, что для решения поставленной задачи при работе с компьютером пользователь совершает определенный набор жестов. Таким образом, время выполнения задачи складывается из времени выполнения этих жестов и из промежутков между жестами, которые требуются для обдумывания.