Показаны сообщения с ярлыком QA Club Минск. Показать все сообщения
Показаны сообщения с ярлыком QA Club Минск. Показать все сообщения

четверг, 6 июня 2013 г.

Встреча QA Club Minsk. Как тестировать, когда нет времени и людей?

Лето, пора отпусков... Каникулы у тестировщиков, и не только. Но, с другой стороны, если зимой хорошо "накачивать" мышцы, то летом  нужно хотя бы поддерживать то, чего достиг за осень и зиму. И в то же время, "не перекачаться". Поэтому встреча минского QA Club'а, как раз "золотая середина".

Вечером в среду после обеда сон для усталых Игорь Бондаренко нам рассказывал "Как тестировать, когда нет времени и людей". Я хорошо знаю Игоря, мы оба работаем в Intetics, знаю его команду и коллег, и хочу просто выразить респект за то, что Игорь сделал и о чем нам рассказал. Проще всего сказать "у меня нет времени", "мой рабочий день с 9 до 6 и ни минутой больше" и изобразить страуса перьями кверху, потому что раз всех все устраивает, то и мне, QA, больше всех надо что ли? А можно просто нести ответственность, как, например, описано у Натальи Руколь. А как нести ответственность, когда недостаточно ресурсов, Игорь нам и рассказал.
традиционный "кирпич" от Игоря. Фото - QA Club Minsk
Итак, принимаем проект. Есть стартовые проблемы (как же все знакомо) :

  • отсутствие проектной документации
  • полное отсутствие тестовой документации
  • большой объем регрессионной тестирования (20 человеко-часов, это при одном QA на проекте)
  • нет автоматизированных тестов
  • нефункциональные требования не проверяются
Игорь предложил довольно простые решения каждой из описанной проблем, рассказал о том, как проходил процесс внедрения улучшений на его проекте, сколько времени уходило на каждое улучшение, поделился маленькими "хитростями", как увлечь процессом контроля качества разработчиков, менеджера и заказчик, ответил на вопросы. 
смотрим телевизор вместе, фото - QA Club Minsk
Не буду раскрывать карту памяти, оставлю всем возможность послушать этот доклад и на конференциях. Поэтому, если есть вопросы, не ждите конференции, спрашивайте у Игоря: он вам подскажет и с удовольствием выслушает, как получается у вас, и возможно ваш опыт расширит и обогатит его доклад.

Большое спасибо Игорю Бондаренко за доклад, Наташе Савастюк и Алене Дрозд - за организацию, Сергею Минюку - за пригодившийся ноутбук, остальным участникам - за вопросы и обмен опытом. 

Всем лета!





суббота, 30 марта 2013 г.

Встреча минского QA Club. Риск-менеджмент, или кто не пьет шампанского.

23го марта состоялась очередная встреча минского QA Club'а. За 2 недели до встречи участники получили анкеты, в которых могли оставить все волнующие их вопросы касательно темы - "Управление рисками" от Елены Асташкевич.

Так как я был первый раз на встрече клуба, поэтому сразу расскажу про специфику и плюсы клубных встреч.
  •  выбирается одна тема на 2-3 часа, разбирается довольно подробно и обстоятельно. Это не обзорный доклад на конференции на 20-40 минут, где ты ухватываешь идею + пару тезисов. Подходит и для тех, кто "не в теме", и для более опытных и готовых поделиться.
  • каждый желающий может во время доклада задавать вопросы по теме и комментировать. Таким образом, доклад обогащается взглядом и опытом другого участника. Так как тема большая, это еще и возможность "передышки" докладчику - довольно сложно рассказывать непрерывно 2 часа :)
  • докладчик имеет большой практический опыт в теме, которую он рассказывает. Не все спикеры на конференциях именно практики.
  • после доклада все участники могут принять участие в обсуждении темы. Так называемый "круглый стол", обмен мнениями. Имхо. В отличие от конференций, более ровный состав "клубовцев", и дискуссия получается довольно интересной.
Встреча получилась интересной и продуктивной, за что большое спасибо организатору и руководителю QA Club'a в Минске Наташе Савастюк, Лене Асташкевич - как докладчику, за интересный, подробный доклад и за практические советы из собственного опыта, а также остальным участникам за живую дискуссию, и особенно наиболее активным - Сергею, Антону, Екатерине. Очень рекомендую встречи клуба, обязательно по возможности и сам постараюсь бывать.

А чуть ниже - конспект встречи.

Риски неизбежны (c), и особенно следует отметить риски на fixed-price проектах.

"Основная проблема разработки ПО - это риск." Кент Бэк

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

И в каких случаях нужно управление рисками:
  • большие объемные системы
  • изменяющиеся и неясные требования
  • новые технологии в проекте
  • сложность системы
  • неправильная оценка проекта
  • высокая зависимость от определенных людей
  • "новый опыт" для организации

Риск - неопределенное событие, которое при наступлении влияет минимум на 1 цель проекта: содержание, сроки, стоимость, качество.

Затем Лена рассказала про основные фазы управления рисками и специфику УР в Agile-проектах.

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

Категории рисков - см. PMBOK

Как оценивать риски:
- Перемножение трех атрибутов:
Случай * Вероятность * Воздействие = Важность
- Шкала оценки рисков (от 0 до 100 процентов, можно разделить на интервалы, каждому интервалу дать название: например, от "крайне маловероятно" до "очень вероятно")
- Оценка последствий, измерять в том, что важно: деньги, сроки, качество
- Матрица учета последствий риска - например:
Может использоваться и более точная матрица 3x3 (в Скраме) до много * много :) (PMBOK) - пример
- Матрица "угрозы - возможности"

2. Идентификация рисков.

Для идентификации рисков можно использовать следующие мероприятия:
- Мозговой штурм
- Метод Дельфи
- SWOT-анализ
- выявление рисков через катастрофы
Отличный результат может давать ретроспектива.

3. Качественный анализ рисков.

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

Величина затрат = Вероятность риска * оценка стоимости риска
 Для учета рисков при оценке проектов, используем 4 стоимости, которые нам позволяют предположить ту, которая нас ждет:
- оптимистичная стоимость проекта
- стоимость проекта, ожидаемая управлением
- наиболее вероятная стоимость
- наихудший вариант  

4. Планирование реагирования на риски.

Стратегии реагирования:
- Уклонение
- Передача
- Снижение
- Принятие
- Использование
- Улучшение

5. Мониторинг и управление рисками.

Рекомендуемая литература от автора доклада:
- Тони Демарко "Вальсируя с медведями"
- PMI
- PMBOK
- ISTQB Advanced Level Syllabus, Chapter "Risk Management"

Update от 1.06.2013 - презентация от Елены: