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

По каким причинам он появился у нас в описании дефекта в таком виде уже и не вспомнишь. Поэтому начали разбираться. Как оказалось, это был компромисс между добавлением/не добавлением поля Severity (а компромисс это зачастую наихудшее решение).

В итоге разобрались и документально зафиксировали следующее:

Severity и Priority – это две отдельные активности.

Severity – это оценка важности дефекта в контексте приложения в целом, и определяется тестировщиком.

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

Слово, напечатанное с ошибкой, может иметь самый низкий уровень severity, но перед выпуском продукта "в свет" эта ошибка может иметь наивысший приоритет и должна быть экстренно исправлена (если вдруг окажется, что на вашем интернет портале имя владельца компании напечатано с ошибкой

Выставляя severity тестировщик оценивает влияние дефекта на работоспособность приложения. Чем выше severity, тем масштабнее негативные последствия данного дефекта.
Priority – это инструмент менеджера по планированию работ. Чем выше priority, тем быстрее нужно исправить дефект.

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

По большому счету, можно ограничиться тремя критериями:

а) юзабилити проблема (надписи в диалоге съехали, комбо-бокс смотрится отвратно);

б) функциональная проблема (участок функционала работает неправильно);

в) блокирующая проблема (определенная функциональность отвалилась).

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

Как резюме можно процитировать одного из участников обсуждения на форуме it4business:

Вопрос не в том, нужно ли использовать priority и severity, толстый клиент или тонкий, а в эффективности работы команды.
Если добавление полей повысит эффективность – добавляйте. Если внесет путаницу – не множьте сущности без необходимости

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

Наиболее часто забываемые активности:

1. Правильная постановка задач
2. Управление рисками
3. Управление изменениями
4. Post-mortem анализ
5. Управление знаниями

Немного о том, что из себя представляют данные активности и почему про них “забывают”.

Правильная постановка задач

Постановка задачи — точная формулировка задачи с описанием входной и выходной информации.
Характеристики правильной постановки задач организации или проекта основаны на английской аббревиатуре S.M.A.R.T. Задачи должны быть: Specific, Measurable, Achievable, Realistic, Time-limited, что означает – Определенными – т.е. они должны указывать на определенный результат или продукт; Измеряемыми – т.е. на каждом шагу должно быть ясно, насколько вы продвинулись в решении задачи; Достижимыми – т.е. их решение должно быть в принципе возможно; Реалистичными – т.е. их решение одинаково возможно как с точки зрения персонала организации, так и с точки зрения ее целевой аудитории; Ограниченными во времени – т.е. их решение должно происходить в обозримый период времени. 
Зачем?
Как ты лодку назовешь – так она и поплывет. От качества постановки задачи напрямую зависит конечный результат.
Почему не делают
По простой причине – на это нужно время и понимание как измерять достижение цели. Как вариант – так можно возложить ответственность за неудачу на инженера.

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

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

Управление конфигурацией (изменениями)

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

Post-mortem анализ

Post Mortem – это процедура, посредством которой команда проекта подводит итоги проекта и анализирует все его позитивные и негативные аспекты. Целью является извлечение уроков из предыдущего опыта для повышения эффективности при выполнении последующих проектов.
Post Mortem – общее собрание по завершении проекта. Это не вечеринка по случаю закрытия проекта, хотя, если проект завершился успешно, встреча может иметь подобную атмосферу.
Зачем?
Это возможность начистоту поговорить о том, что вышло не так, как планировалось, и, самое главное, о том, что усвоено для будущего.  Анализ допущенных ошибок важен для их избежания, а, следовательно, успеха в будущем. Поэтому, если вы столкнулись со множеством проблем, не упускайте возможность обсудить их, когда они еще свежи в памяти. К тому же, команде нужно ощутить завершенность проекта, чтобы с ясной головой приступить к следующему проекту.
Это не разговор о собственных амбициях или попытка «прикрыть свой зад», это открытая дискуссия о допущенных каждым ошибках (все совершают ошибки) или тех сторонах процесса, которые требуют улучшения. 
Почему не делают
Все дружно выступают за проведение такого собрания в том случае, если все сложилось удачно, но тихо спускают на тормозах если было допущено большое количество ошибок или проект вообще провалился.

Управление знаниями

Управление знаниями (англ. knowledge management) — это систематические процессы, благодаря которым распознаются, создаются, сохраняются, распределяются и применяются необходимые для успеха организации знания.
Зачем?
Если коротко, то чтобы постоянно не наступать на одни и те же грабли и не терять компетенцию при изменении группы проекта.
Более подробно я описывал в статье Управление знаниями. С чего начать. 
Почему не делают
Потому что требует времени и ответственного отношения от всех участников процесса, а также потому что не всегда понимают к чему приводит отсутствие данной активности.

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

найти формальное решение там,

где его быть не может

Алексей Никулин

Дано:

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

После некоторого времени работы эти специалисты по тестированию становятся так называемыми гуру в данном проекте/модуле.

Проблемы:

1. Страдает мотивация, человек начинает искать другую работу (да, да, очень мало людей просят перевести куда-нибудь, многие просто тихонько ищут другую работу). Думаю, не нужно объяснять стоимость ухода такого специалиста.
2. Происходит некоторое “замыливание” взгляда: А в прошлом билде это работало, значит и сейчас будет. Ставим Passed на эти тесты и идем дальше.

В итоге:  или теряем специалиста по конкретному проекту/модулю, или теряем в качестве тестирования.

Для более эффективной работы команды тестирования необходимо время от времени перераспределять задачи между инженерами следующим образом:

1. Пишет тестовую документацию один, тестирует – другой.
2. На разных этапах тестирования один и тот же функционал тестируют разные специалисты.

Пример

Есть 6 модулей в продукте. За каждым модулем закреплен свой специалист по тестированию

1 – А, 2 – B, 3 – C, 4 – D, 5 – E, 6 – F

Проект длится не один месяц (по моим оценкам применять данную практику имеет смысл на проектах длиной от полугода).

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

Рассмотрим плюсы и минусы предлагаемого подхода:

Плюсы работникам:

1. Переключение в новую область дает новые знания (Что само по себе плюс, но кроме этого может дать толчок для применения этих знаний о технологии, полученных при тестировании, для тестирования (и не только) другой подсистемы).
2. Порождает некую соревновательность. (Возможность показать, что ты лучше, чем твой коллега Главное, чтобы это не перешло в гонку вооружений).
3. Понимание работником отношения к нему его руководства. (Про тебя помнят и следят за твоими успехами и неудачами).

Плюсы работодателю:

1. Становится меньше (или вообще исчезают) “незаменимые люди”.
2. Облегчается верификация дефектов. В случае, когда тот кто занес дефект, по каким-то причинам не может его проверить, то лучше его верифицировать человеку, кто уже тестировал подсистему/функциональность, чем тому, кто ее первый раз видит.
3. Одна голова хорошо, а две лучше.
4. Если тестовую документацию пишет один человек (тест-кейзы, чек-листы итд), а тестирует по ним другой, то находятся проблемы не только в ПО, но и в тестах.
5. Появляется более сбалансированная команда, где обучение происходит peer-to-peer, просто в процессе работы. Надо меньше тренингов, семинаров и т.д.
6. Есть возможность получить “более хорошего” специалиста по тестированию для той или иной подсистемы не нанимая нового сотрудника.
7. Переключение в новую область зачастую влечет повышение мотивации сотрудника без каких-либо материальных затрат (читай: не надо поднимать зарплату).
8. Опять же, есть возможность принимать на работу не профессионала, а новичка, и,. в дальнейшем, выращивать его до опытного сотрудника будет проще.
9. Если на одном проекте временное затишье, то можно переключить сотрудников на другой проект не теряя время специалистов на изучение проекта/функционала с нуля.

Минусы:

1. Тратится время на изучение новой области – меньшая отдача от сотрудника. (Сиюминутный минус – стратегический плюс).
2. Большие затраты времени на тестирование, При подходе – тестовую документацию пишет один, тестирует другой. (Опять же сиюминутный минус – для качества проекта плюс, да и никто не запрещает заносить баги при написании тестов).
3. Необходимость более тонкого и чуткого распределения задач со стороны руководства. (Ну должны же ведь начальники доказать, что они не зря деньги получают, ага? ).
4. Ну и самое, наверное, сложное, люди в команде должны быть правильными. Как раз чтобы избежать ситуаций, где все знают ничего обо всем, где кто-нибудь кому-нибудь завидует, где никто ничего не хочет. (А собеседования и испытательный срок зачем нужны?).

Когда и для каких людей будет работать данная практика?

Когда:

1. Проект/проекты длиной от полугода или проекты по поддержке/доработке ранее разработанного ПО.
2. Желание руководства возиться с перераспределением задач.
3. Понимание руководством выгод данного подхода в будущем даже с учетом увеличенных затрат по времени сейчас.

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

Для каких людей:

Алексей Никулин вот в этом посте описал ограничение по применимости данной практики к специалистам по тестированию в зависимости от типа

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

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

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

P.S. Данная практика нацелена на повышение квалификации всех специалистов по тестированию, повышение их мотивации и уменьшение рисков ухода сотрудников. Она ни в коем случае не предполагает формальное использование из разряда «делай раз, делай два» (см. цитату в начале статьи) и именно в таком ключе и надо ее воспринимать. Я сам применяю эту практику около 3-х лет и доволен результатами.

Статья написана по мотивам обсуждения на форуме it4business

В статье были использованы посты и замечания Алексея Лянгузова и Алексея Никулина.

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

Итак попробую ответить на вопрос: какие артефакты необходимы для обеспечения процесса тестирования (имеется ввиду разрабатываемые самим тестировщиком).

Я выделяю несколько артефактов:

1. План тестирования (Test plan)
2. Тестовый сценарий (Test-case)
3. Наборы тестовых сценариев (Test script or Test suite)
   • Набор тестовых сценариев для Smoke-test
   • План приёмосдаточных испытаний (ПСИ)
4. Описание дефектов
5. Отчет о тестировании

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

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

Есть как минимум два общепринятых понимания этого документа:

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

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

• Взять книгу Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование
• Взять RUP
• Погуглить
• Дождаться когда я изложу пример в одной из следующих статей

Тестовый сценарий(тест)

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

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

Варианты названий:

• Атомарный тест
• Тестовый вариант
• Вариант тестирования
• Тестовый случай

Наборы тестовых сценариев

Это тестовые сценарии сгруппированные по некоему признаку (например тестируемой функциональности). Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего (Test script)), так и независимыми (Test suite).
Наиболее часто выделяемыми наборами являются: Набор тестовых сценариев для Smoke-test и План приёмо-сдаточных испытаний.

Набор тестовых сценариев для Smoke-test

Если честно, то я не знаю адекватного перевода на русский данного термина. Иногда используется перевод “Дымчатое тестирование”, но он вызывает у меня стойкое отвращение.

Набор тестовых сценариев для Smoke-test – это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test – убедиться в том, что ключевые функции программы работают, не вникая в подробности.
Хорошая практика – прием билда в тестирование на основании прохождения Smoke-test. Также зачастую в качестве такого теста используют ежедневную сборку с обязательным прохождением unit тестов.
Комментарий: Ежедневная сборка без unit тестов не может считаться как Smoke test. Это называется: “Ух ты компилицо”

План приёмо-сдаточных испытаний (ПСИ)

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

В общем случае подмножества тестов выглядят так как на рисунке.

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

Москва не сразу строилась…

(из известной песни)

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

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

Управле́ние зна́ниями (англ. knowledge management) — это систематические процессы, благодаря которым распознаются, создаются, сохраняются, распределяются и применяются необходимые для успеха организации знания. С 1995 года, управление знаниями стало установившейся научной дисциплиной, с преподаванием университетских курсов и посвящёнными данной теме профессиональными и академическими изданиями.

В полном объеме управление знаниями объемная научная дисциплина, но на практике достаточно использовать небольшое подмножество – Базу Знаний.

Сегодня база знаний — один из самых важных активов современной организации. Знания — это информация в контексте, способная произвести побуждающее к действиям понимание.

Для того, чтобы организовать и развивать Базу Знаний есть всего лишь одно условие: необходим “Человек, Которому Больше Всех Надо” (например, в нашей компании таким человеком выступаю лично я). Т.е. у кого-то в компании должно хватить сил взять на себя ответственность продавить и начать такую инициативу, а затем постоянно контролировать и мониторить процесс наполнения.

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

1. Начинайте с малого

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

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

2. Не следует слишком увлекаться информационными технологиями.

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

3. Избегайте излишней формализации

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

4. Будьте избирательны!

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

5. Регулярно оценивайте достижения.

Как далеко вы продвинулись? Не столкнулись ли вы с чем-то неожиданным? Что удалось, а что – нет? Как вы должны скорректировать свою стратегию с учетом знаний, полученных вами в процессе работы?

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

1. Какое ПО использовать для Базы знаний?

Какое вам удобно. Я использую Mediawiki.

2. Кто и в каких случаях вносит записи в Базу Знаний?

“Человек, Которому Больше Всех Надо”, начинает где-то вести заметки, рассказывает об этом коллегам, которые тоже начинают пользоваться и вносить правки. (В моем случае занесение новых статей в Базу Знаний вначале было обязательное условие для сотрудников моего отдела при изучении любого нового материала, где-то через полгода наполнение продолжилось уже без моего участия).

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

Не требуется никакой утвержденной структуры. Есть такое замечательное понятие – самоорганизация, “Человек, Которому Больше Всех Надо”, за всем приглядывает.
Более того, как только в дело вмешиваются Процедуры, Правила, Регламенты и прочее, народ к написанию сразу охладевает. Тем более структура wiki позволяет в любой момент все перетасовать.

4. Кто и как в дальнейшем пользуется этими записями.

Тестировщики, программисты, аналитики, менеджеры – когда что-то забывают или чего-то не знают.

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

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

В процессе подготовки статьи были использованы следующие источники:

Алёна C++. Система контроля версий, багтрак и wiki

С высоты птичьего полета /блог Сергея Орлика/. Средства Web 2.0 внутри предприятия – кому это надо?

Wikipedia. Управление знаниями