Я уже давно, в принципе, пообещала попробовать внедрить сессионное тестирование и рассказать, что из этого получилось. Или не получилось.
Для начала немного теории. Начинать, думаю, стоит со статьи Jonatan Bach - "Session-Based Test Management". Я думаю, каждый из нее может почерпнуть что-то свое.
В статье описывается, что такой вид движения, как сессионное, был придуман из-за стремления сделать мир лучше, а тестирование ПО гибче и проще. В том числе и в плане отчетности. Отчетность делать мало кто любит, но, с другой стороны, она очень нужна - ведь Заказчик хочет в любой момент зайти к вам на сайт и понять, в каком статусе находится тестирование его проекта.
Поэтому - проводится сессия тестирования. У которой есть определенная миссия. Миссия в глобальном плане - не то, как ты собираешься тестировать, а то, что ты собираешься тестировать. Длительность у сессий так же бывает разная, но в среднем это - 90 минут.
Провел сессию, написал отчет - сколько времени потратил на подготовку к тестированию, что протестировал, какие баги нашел... А потом происходит главная часть - обсуждение. Это когда коллеги собираются вместе и обсуждают проведенные за день сессии. Кто что протестировал. Один человек отчитался и вместе решили, стоит ли проводить дополнительную сессию, продолжая тестировать функционал или хватит уже. Так же высказывают идеи, что можно было протестировать, если не услышали этого от докладчика.
Чем хороша сессия? Тем, что избавляет тебя от чувства неудовлетворенности, когда вроде и тестируешь, и багов нет, а кажется, что есть, просто не докопался... Такое тестирование может поглотить, а в итоге ты потратишь очень много времени впустую. А так хорошо - сам потестировал, а потом на мозговом штурме пожаловался - так и так, протестил то-то и то-то, и даже то-то и то-то, нет багов! Что делать?
И вместе уже решаете, а стоит ли вообще еще что-то делать, или стоит заняться более важными вещами. Или, наоборот, коллеги подкидывают тебе новых идей, а что же можно еще протестировать.
Так вот, удивительно, но многие используют сессионное тестирование именно как подмогу в отчетности. Хотя я, когда читала статью, увидела так абсолюьно другие плюшки.
А именно - общение. Коротенький устный отчет на 5 минут о том, что ты уже проверил, для того, чтобы тебе накидали идей. Мне кажется, отличная подмога для ревью тестов, только еще до их проверки. Мы, кстати, иногда так и делали, особенно, когда ребята писали тесты впервые или когда писали тесты по незнакомой им части системы - они идей накидают и идут ко мне, посмотри, мол, что я забыл? И не надо задачу потом переоткрывать, вот, мол, пропустил. Если заранее понял, что нужен будет такой тест - сразу и скажи, не тяни.
Это помогает хотя бы тем, что часто тесты пишутся не час и не два (автотесты) и ты в итоге просто перестаешь соображать, не можешь сам сказать, что ничего не упустил, хочется услышать мнение со стороны.
Так и получается, что сессии и так есть, даже некоторая отчетность по ним есть (спасибо удобным инструментам типа JIRA), а вот общение можно и добавить
Но, тесты тестами, а еще я, поразмыслив, решила, что сессии - это потрясающая идея для регрессионного exploratory. То есть основной функционал покрыт автотестами, smoke ты провел, вручную новые фишки проверил и есть время помедитировать и поизучать продукт.
О-о-о, думаю, вот где мы развернемся. Будем устраивать сессии, а потом встречаться и обсуждать. Ага. Подходит время регрессии, полотдела тестирования сваливается с температурой. Ну и ладно, еще лучше! Сейчас мы на пару с коллегой с помощью сессий мало того, что проверим все, да еще и качественно, так как - не пересекаясь.
Провели несколько сессий, обсудили, я даже подкинула коллеге пару идей, который он побежал проверять, так как не смог сходу сказать, как система отреагирует на такое воздействие. Ну вот, уже обучение и углубление внутрь! А потом еще и другие коллеги выздровели, казалось бы, вообще здорово.
Но, увы. Знаете, какая самая главная проблема внедрения? Правильно, никому нововведение особо не надо, пока они не прочувствуют, чем оно помогает, пока оно не поставлено на поток.
А знаете, какая главная проблема сессий, даже более-менее поставленных на поток? Правильно, тест-менеджеру, который должен проводить встречи-обсуждения, не хватает времени на это все.
И я на собственной шкуре почувствовала, каково это, когда действительно нет времени и сил на проведение пусть и коротких, но обсуждений. На меня упала крайне важная и срочная задача, пришлось заняться ей, а, так как до нового года оставалось всего ничего, то и времени отвлекаться у меня не было, вообще от слова "совсем".
И вы знаете, теперь я даже понимаю этих самых менеджеров Это нам с вами хочется получить консультацию и кажется, что уж 5-10 минут то можно выделить, можно найти. Можно. Но только если человек сам к тебе подойдет. Ходить и что-то внедрять, когда есть задачи важнее, попросту глупо. Ведь все внедрения направлены на улучшение системы. Но при этом они не должны мешать. Да, нужно время на то, чтобы привыкнуть. Но это должно быть более-менее сводобное время, а не время напряженной работы.
Но, с другой стороны, первые шажки сделаны и потенциал в таком подходе я вижу. Даже знаю, что можно улучшить, вот надеюсь, что мне хватит времени в новогодние праздники сделать то, что задумано
А дальше будем снова смотреть по ситуации и применять и внедрять этот подход там, где он может "взлететь" - ведь в этом и фишка всех улучшений в гибких методологиях - ты не тупо копируешь известный подход, даже если он тебе вообще не нужен, "зато у других работает!". Ты думаешь, как его можно подстроить лично в твоей команде - и делаешь осмысленный выбор!
Для начала немного теории. Начинать, думаю, стоит со статьи Jonatan Bach - "Session-Based Test Management". Я думаю, каждый из нее может почерпнуть что-то свое.
В статье описывается, что такой вид движения, как сессионное, был придуман из-за стремления сделать мир лучше, а тестирование ПО гибче и проще. В том числе и в плане отчетности. Отчетность делать мало кто любит, но, с другой стороны, она очень нужна - ведь Заказчик хочет в любой момент зайти к вам на сайт и понять, в каком статусе находится тестирование его проекта.
Поэтому - проводится сессия тестирования. У которой есть определенная миссия. Миссия в глобальном плане - не то, как ты собираешься тестировать, а то, что ты собираешься тестировать. Длительность у сессий так же бывает разная, но в среднем это - 90 минут.
Провел сессию, написал отчет - сколько времени потратил на подготовку к тестированию, что протестировал, какие баги нашел... А потом происходит главная часть - обсуждение. Это когда коллеги собираются вместе и обсуждают проведенные за день сессии. Кто что протестировал. Один человек отчитался и вместе решили, стоит ли проводить дополнительную сессию, продолжая тестировать функционал или хватит уже. Так же высказывают идеи, что можно было протестировать, если не услышали этого от докладчика.
Чем хороша сессия? Тем, что избавляет тебя от чувства неудовлетворенности, когда вроде и тестируешь, и багов нет, а кажется, что есть, просто не докопался... Такое тестирование может поглотить, а в итоге ты потратишь очень много времени впустую. А так хорошо - сам потестировал, а потом на мозговом штурме пожаловался - так и так, протестил то-то и то-то, и даже то-то и то-то, нет багов! Что делать?
И вместе уже решаете, а стоит ли вообще еще что-то делать, или стоит заняться более важными вещами. Или, наоборот, коллеги подкидывают тебе новых идей, а что же можно еще протестировать.
Так вот, удивительно, но многие используют сессионное тестирование именно как подмогу в отчетности. Хотя я, когда читала статью, увидела так абсолюьно другие плюшки.
А именно - общение. Коротенький устный отчет на 5 минут о том, что ты уже проверил, для того, чтобы тебе накидали идей. Мне кажется, отличная подмога для ревью тестов, только еще до их проверки. Мы, кстати, иногда так и делали, особенно, когда ребята писали тесты впервые или когда писали тесты по незнакомой им части системы - они идей накидают и идут ко мне, посмотри, мол, что я забыл? И не надо задачу потом переоткрывать, вот, мол, пропустил. Если заранее понял, что нужен будет такой тест - сразу и скажи, не тяни.
Это помогает хотя бы тем, что часто тесты пишутся не час и не два (автотесты) и ты в итоге просто перестаешь соображать, не можешь сам сказать, что ничего не упустил, хочется услышать мнение со стороны.
Так и получается, что сессии и так есть, даже некоторая отчетность по ним есть (спасибо удобным инструментам типа JIRA), а вот общение можно и добавить
Но, тесты тестами, а еще я, поразмыслив, решила, что сессии - это потрясающая идея для регрессионного exploratory. То есть основной функционал покрыт автотестами, smoke ты провел, вручную новые фишки проверил и есть время помедитировать и поизучать продукт.
О-о-о, думаю, вот где мы развернемся. Будем устраивать сессии, а потом встречаться и обсуждать. Ага. Подходит время регрессии, полотдела тестирования сваливается с температурой. Ну и ладно, еще лучше! Сейчас мы на пару с коллегой с помощью сессий мало того, что проверим все, да еще и качественно, так как - не пересекаясь.
Провели несколько сессий, обсудили, я даже подкинула коллеге пару идей, который он побежал проверять, так как не смог сходу сказать, как система отреагирует на такое воздействие. Ну вот, уже обучение и углубление внутрь! А потом еще и другие коллеги выздровели, казалось бы, вообще здорово.
Но, увы. Знаете, какая самая главная проблема внедрения? Правильно, никому нововведение особо не надо, пока они не прочувствуют, чем оно помогает, пока оно не поставлено на поток.
А знаете, какая главная проблема сессий, даже более-менее поставленных на поток? Правильно, тест-менеджеру, который должен проводить встречи-обсуждения, не хватает времени на это все.
И я на собственной шкуре почувствовала, каково это, когда действительно нет времени и сил на проведение пусть и коротких, но обсуждений. На меня упала крайне важная и срочная задача, пришлось заняться ей, а, так как до нового года оставалось всего ничего, то и времени отвлекаться у меня не было, вообще от слова "совсем".
И вы знаете, теперь я даже понимаю этих самых менеджеров Это нам с вами хочется получить консультацию и кажется, что уж 5-10 минут то можно выделить, можно найти. Можно. Но только если человек сам к тебе подойдет. Ходить и что-то внедрять, когда есть задачи важнее, попросту глупо. Ведь все внедрения направлены на улучшение системы. Но при этом они не должны мешать. Да, нужно время на то, чтобы привыкнуть. Но это должно быть более-менее сводобное время, а не время напряженной работы.
Но, с другой стороны, первые шажки сделаны и потенциал в таком подходе я вижу. Даже знаю, что можно улучшить, вот надеюсь, что мне хватит времени в новогодние праздники сделать то, что задумано
А дальше будем снова смотреть по ситуации и применять и внедрять этот подход там, где он может "взлететь" - ведь в этом и фишка всех улучшений в гибких методологиях - ты не тупо копируешь известный подход, даже если он тебе вообще не нужен, "зато у других работает!". Ты думаешь, как его можно подстроить лично в твоей команде - и делаешь осмысленный выбор!
Привет Оля,
ОтветитьУдалитьА какие инструменты ты для SBTM используешь?
Я сейчас на проекте – единственный тестировщик. Для меня, в принципе, XMind вполне хватает:
Есть отдельная карта для новых чартеров (миссий), есть отдельная карта на сессию. Есть еще кучка майнд-мапов со структурой приложения, которые я обновляю по мере пополнения знаний.
Для одного человека – очень удобно. Вот как, правда, что будет если нужно будет работать в режиме совместной работы – не знаю, но, в принципе выход думаю есть.
Знаешь, Дим, как я сказала, я пока не вижу потенциала заставлять кого-то (да даже себя :) ) делать письменную работу, я просто хочу свести к 10-15 минутным обсуждениям проведенных сессий, а уж где ребята запишут, что тестили - да хоть на коленке!
УдалитьХотя, идея с XMind мне нравится. Именно этот инструмент я и хочу заюзать, чтобы нарисовать "помощников" для будущего сессионного тестирования... Но почему бы еще и результаты сессий там не записывать :)
На счет не нужной письменной работы – поддерживаю. Когда не видишь, что то, что ты написал действительно приносит пользу или хоть когда-либо будет использовано – просто клавиша не поднимается написать полный тест-кейс "для человека, который придет с улицы", вместо того, чтобы сделать коротенькую пояснительную запись, или добавить пункт в майндмапу или одностраничный вордовский документ, который описывает недостающие знания о системе. Ну, и конечно же, живое общение, обсуждение – это лучше, по моему мнению, бумажной работы.
УдалитьНо, иногда дело доходит до того, что надо написать n-штук тест-кейсов. Недавно научился их генерировать из данных: т.е. 3 параметра из строки данных превращаться в валидный тест-кейс, с правильным текстом и 20-тью шагами. И – все довольны :)
Да, действительно, умение кратенько записать n-штук кейсов очень важно!
УдалитьЯ говорила про документацию сессионного тестирования. Хотя и советуют вначале делать прям как автор указал, но у нас эту информацию и так можно найти, зачем писать лишние отчеты? Поэтому в плане сессий документации нет и я пока не вижу в ней смысла.
А по тест-кейсам, конечно же, есть. А то упадут тесты, ответственного нет (отпуск / отгул / прочее), ты чинишь - а как понять, что тест делает? Конечно, краткое описание очень нужно, я считаю)