Встреча минского 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 - презентация от Елены:

Елена Асташкевич "Управление рисками" from QA Club Minsk

IT Spring в Минске 16-17 марта. День второй

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

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

А теперь к самим докладам. Первыми на сцене А ожидаемо отжигали Орлов и Панкратов с докладом про стартап Стратоплан. Слов и времени ребята не жалели, благо времени у них было полтора часа. И на идеи, и на рекламу хватило :)

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

- У кого на картинке есть деньги?
- У кого видно, откуда они приходят?
- У кого видно, за что они приходят?

Затем докладчики рассказали про свой бизнес: за 2011-2012 год было организовано 24 различных клуба: фриланс, переговоры, лидерство, agile, проектное управление, практическое программирование, практическое тестирование, проектирование....  Но не все клубы были одинаково успешны. На данный момент, О&П сфокусировались на восьми наиболее успешных клубах.

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

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

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

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

Вторым выступал Джон Эйсон (John Ason), компания "Angel Investor". Как несложно догадаться, Джон занимается инвестированием в стартапы, и в своем докладе он рассказал как про свои работающие проекты, так и про требования к потенциальным кандидатам-стартапам.

Что основное можно рассказать по докладу:
- Компания Джона не занимается покупкой существующего бизнеса. Только инвестиции (funding)
- Управление командой - не прямое или совмещенное, а консультации по менеджменту (mentoring)
- Angels оставляет за собой право выйти из бизнеса в любой момент

Что Angels требуют от стартапа:
- короткий сфокусированный бизнес-план на 1 страницу
- управление качеством
- разумные оценки (разброс не более 20-30%)
- оценку рынка
- графическая презентация ценится больше, чем слова

Культурные ценности Angels (напишу на английском, дабы не исказить смысл) :
- speed, speed, speed
- outsorce everything
- leverage / margins
- compete / cooperate
- open non-secretive

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

Вобщем, если у вас есть хороший бизнес-план, и вы готовы с головой взяться за его реализацию - можете попробовать обратиться в Angels Investors. Более подробную информацию вы найдете на сайте - http://www.johnason.com

Следом за Джоном выступал Алексей Минкевич c докладом про трансформацию разработчик -> руководитель. За неполный час Алексей рассказал очень многое в простой ненавязчивой форме, только успевай конспектировать :) При этом, доклад получился очень живым и увлекательным, а ответы на вопросы только усилили и без того очень хорошее впечатление о докладе. С нетерпением буду ждать записи выступления.

А пока нет записи, поделюсь своим конспектом :)

Чем занимается руководитель:
- 90% рабочего времени - решение проблем других людей
- совещания: их много, нужна максимальная эффективность от них, не нужно ходить на те, которые не нужны
- нет больше технологий (как было у девелопера)
- растаскивание по мелочам
- ненормированный рабочий день
- много проектов (всего в подчинении порядка 20 человек)
- завоевать уважение на новом месте или в новом проекте
- одиночество
- кабинет, чтобы "уединиться и поплакать, когда никто не видит"

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

Чему нужно будет научиться при работе ПМом:
- мыслить стратегически
- делегировать
- уметь говорить "нет"
- не бояться давать людям расти

Как научиться быть руководителем:
- найти себе наставника
- общение с тусовкой
- тренинги
- бизнес-книги (личная рекомендация Алексея - "Deadline" Тони Демарко)
- конференции
- сертификация

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

После Алексея был часовой перерыв на обед, во время которого можно было не только отведать масленичные блины от IBA, но и пообщаться в неформальной обстановке с коллегами и докладчиками.

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

Стив разделил эволюцию покупателя на 7 этапов (первые три относятся к маркетингу, другие 4 - непосредственно к продаже). Опять же, дам их перечисление на английском, не искажая авторский оригинал:
1. Status Quo
2. Priority Shift
3. Research
4. Identify options
5. Step back
6. Validation & Beliefs
7. Choice & Commitment

Соответственно как аутсорсер, на различных этапах эволюции покупателя вы должны использовать различные приемы и стратегии, о которых вкратце, в рамках выделенного ему времени, и рассказал Стив. Также докладчик представил свою книгу, посвяшенную этой теме, -  "Software without Borders". Два экземпляра книги были разыграны, награда вместе с автографом Стива Мезака нашла своих героев. Тем, кому не так повезло, можно посетить сайт www.accelerance.com и бесплатно скачать электронный вариант книги.

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

Затем я переместился в секцию Б на доклад Тима Евграшина (мне нравится его подача и доклады на www.tim.com.ua) о "Продукте: вам нарезать или целым куском?" Лектор поговорил в целом про аджайл и про то, как решаются проблемы в нем. Доклад был обзорный, без углубления в детали. Что мне нравится у Тима - это яркие и умело подобранные слайды, которые очень "в тему" и к месту. После доклада было как-то маловато вопросов, но кто хотел - мог задать вопросы и после :) Тим очень внимательно слушал и обстоятельно отвечал, несмотря на то, что доклад был последний в этой секции, и лекционное время уже истекло :)

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

Ищете учителя? Задайте ему всего один вопрос....

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

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

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

Итак:

1. Стратоплан, "Курс практического тестирования". 550$

2. Экзамен ISTQB Advanced Level Test Analyst, готовился самостоятельно, сдал со 2-го раза. 2 * 150 евро = 300 евро или  почти 400 долларов

3. Дистанционное обучение Mini-MBA + годовая подписка на онлайн-семинары MBA. 450$ по скидке. 

4. Тренинг Стратоплана "Продуктивные коммуникации в команде" - 100 долларов

5. Confet&QA - выиграл бесплатное участие в конкурсе - 100 долларов за осеннюю программу
6. SQA Days-12 - бесплатное участие как докладчик конференции - 350 долларов за участие в конференции.

Итого 1950 долларов за год. Из них - 300 долларов оплатила компания, 450 долларов я выиграл в конкурсе или как участник конференции. Получается 1200 долларов только за тренинги я заплатил самостоятельно. Или 100 долларов в месяц.

Кроме того:
- приобретение наиболее ценных для меня бумажных книг в интернет-магазине. Приблизительно 2 книги или около 20-25 долларов ежемесячно.
- чтение литературы и блогов по тестированию - это бесплатно
- просмотр видео, участие в бесплатных видеоконференциях по тестированию (Рекс Блэк, Михаил Поляруш, Майкл Болтон, Джеймс Бах, SQA Days 11, Selenium Camp...)

В марте мой друг посоветовал меня в УЦ "Белхард", и с мая я преподаю курсы "Тестирование ПО" и "Тестирование веб-ориентированных приложений". Продолжительность курса  - 56 академических часов. С мая по декабрь я выпустил 4 группы (в сумме 40 человек). Подробнее про занятия буду освещать в этом блоге.

Но 2012 год уже история, а впереди очень много интересных событий: Стратосфера Grand Conference, сертификат ISTQB AL TM, SQA Days-13, новая Confet&QA, окончание Mini MBA, запланированные тренинги, продолжение преподавания в УЦ... Отличный должен получиться год! Обо всем этом я буду рассказывать в своем блоге.

До связи!

Курсы по тестированию ПО. 7 советов по улучшению.

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

1. Помните, что обучение - это передача не только знаний, но и энергии. 

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

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

2. Организуйте себя и учите личным примером.

Начинается новое занятие. Все в сборе, а преподаватель опаздывает? "Ждем 15 минут и уходим" - в университете так и было, здесь люди "ждут, берут деньги и уходят.... к другому преподавателю".

Не открою вам Америки про личное "неопаздывание". Я лично прихожу за 5-10 минут, не больше. Этого достаточно, чтобы самому подготовиться, раздать всем материал и начать занятие вовремя. Чисто субъективно, не очень буду доволен, если преподаватель пришел и сидит и серфит в интернете, или как в метро что-то кликает на мобилке, или с отсутствующим видом смотрит в окно. Это - не энергия, снова возвращаемся в первый пункт. Занятие - по максимуму, пришли - и сразу включились в работу. Это и настраивает на рабочий лад учеников.

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

Для себя решил - берись за группу, если уверен на 99.99%, что будешь вести ее до конца. Иначе пострадают студенты, сложно привыкать к новому преподавателю. Если не уверены, что сможете, - предупредите заранее. И, конечно, никаких перерывов в занятиях, регулярность - залог успешного обучения. Лучше заниматься 3 раза в неделю по 2 часа, чем один раз в неделю 6 часов.

И да, если вы опаздываете более чем на 5 минут (даже если у вас форс-мажор, никто не застрахован), то студенты должны иметь возможность связаться с вами, или вы с ними.

3. Делайте ритмичные перерывы, не перегружайте.

Универсального, всем подходящего, графика нет, тут важен ваш пример. Работаете, например по Pomodoro: 25 минут работы + 5 минут отдыха, - отлично, научите свою группу так работать и понаблюдайте, чтобы группа "приняла" ваш режим.

Мой режим: 55 минут работы + 5 минут перерыва. Стараюсь планировать свои тематические блоки именно таким образом. И да, эти 55 минут тоже не монотонные - см. кривую внимания.

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

4. Создайте и поддерживайте в актуальном состоянии дополнительные материалы.

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

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

Обязательно: регулярно обновлять материал, добавлять что-то новое. Вы тоже продолжаете учиться и узнавать что-то новое, не так ли?

5. Внедряйте больше практики!

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

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

Практики мало не бывает: скриншоты с ошибками, командные игры по нахождению багов, рецензирование и оценка коллег (peer review)... И геймификация вам тоже в помощь. Testing could be fun!

6. Используйте все каналы связи со студентами: онлайн-связь и онлайн-сообщества.

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

7. Признавайте свои ошибки и учитесь, не "бронзовейте".

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

Если допустили ошибку - поправьтесь и продолжайте дальше. Только один человек был совершенен, он жил более 2 тысяч лет тому назад. " А мы не ангелы, парень" (c)

8. "Будьте собой, все остальные места уже заняты".

Перенимая "передовые методики", оставайтесь собой. Люди не верят тем, кто говорит, что он лучший. Будьте собой и ищите свой стиль, предлагайте свой продукт, и тогда к вам пойдут люди учиться.

Обзор 1. Размышления о регрессионном тестировании от Майкла Болтона, или "все могло быть гораздо хуже".

Открываю серию постов-обзоров, постов-конспектов по очень полезным материалам по тестированию, которые, на мой взгляд, просто НУЖНО просмотреть-прочитать-прочувствовать и много других "про-" начинающему и не очень тестировщику.

Начну с темы, которая сейчас наиболее для меня актуальна - регрессионное тестирование. Автор - Майкл Болтон. Лекция "Things Could Get Worse: Ideas About Regression Testing" и презентация.

Почему регрессионное тестирование важно? 

С ростом проекта мы получаем рост сложности, функционала, числа тест-кейсов, которые нам необходимо будет запускать каждый раз. Растет объем регрессионного тестирования, проверок и тестирования, которые нам будет необходимо выполнять (в чем разница между тестированием и проверкой - "testing vs checking" - здесь). Времени на регрессионное тестирование не увеличивается, а если и увеличивается, то незначительно, недостаточно, чтобы выполнить его в том всевозрастающем с каждой итерацией объеме, котором нам нужно. А ошибки в регрессионном тестировании и обходятся "дороже", и иногда не настолько очевидны из-за сложности продукта.

Что же делать, как правильно распределить усилия на этом этапе?
Давайте посмотрим, что нам советует Майкл Болтон (далее ниже синим шрифтом - выдержки из лекции Майкла Болтона, черным стандартным - мои комментарии).

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

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

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

Тестирование против проверки (Проверка - процесс подтверждения, верификации и валидации. Тестирование - процесс поиска новой информации, это исследование, открытие, изучение).

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

Вместо того, чтобы думать, прошел тест или нет (Pass или Fail), опытные тестировщики задают вопрос "Есть ли здесь (в этом функционале) проблема?"

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

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

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

"Тестирование важнее проверок" (дословно - "Testing Dominates checking") (c) Майкл Болтон

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

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

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

Риск регрессионной зависимости - самый большой проектный риск? Нет, только в 6-15% случаях (опрос тест менеджеров).
Риск регрессионной зависимости - эмоциональный страх.

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

Способы снижения риска регрессионной зависимости в Agile:  разработка через тесты (Test Driven Development), модульные тесты (Unit Tests), парное тестирование, непрерывная интеграция (Continious Integration), контроль сборок и версий (Version and Build Control).

Оставим эту тему для отдельного озбора, вместе с ролью QA в Aglie-команде.

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

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

Как выбрать то, что нужно протестировать в регрессионном тестировании. Карен Джонсон, эвристика RCRCRC + автоматизированные проверки в регрессионном тестировании, Майкл Келли.

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

Стратегические идеи во время регрессионного тестирования (по клику начинается просмотр видео со слайда презентации).

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

На этом все. Спасибо за внимание, и успехов вам в регрессионном тетсировании!

Short intro

Всем привет!

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

А в своем уютном блоге я буду рассказывать вот о чем:

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

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

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

So, let's begin our journey!