Тест сессия что это

Портал TMGuru:

Поиск

SBTM (сессионное тестирование)

Сессионное тестирование (SBTM) — метод управления исследовательским тестированием, при котором процесс тестирования разбивается на сессии определенной длины (авторы метода, Джеймс Бах и Джон Бах, рекомендуют длительность около 90 минут).

Миссия сессии

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

Тестирование во время сессии

Как только тестировщики приступают к работе, они отмечают время старта сессии. Точная длительность не так важна, но у команды тестирования должны быть представления о том, сколько примерно сессия заняла. В различных ситуациях она может длиться от 30 минут до двух часов. Если сессия продлилась меньше — миссия была чересчур конкретизирована, больше — слишком расплывчата.

Метрики

Завершив сессию, тестировщик предоставляет отчет о времени, потраченном на следующие задачи:

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

К другим метрикам SBTM относятся:

Структура отчета

Обсуждение отчета

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

Источник

среда, 9 января 2013 г.

Я уже давно, в принципе, пообещала попробовать внедрить сессионное тестирование и рассказать, что из этого получилось. Или не получилось.

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

Так вот, удивительно, но многие используют сессионное тестирование именно как подмогу в отчетности. Хотя я, когда читала статью, увидела так абсолюьно другие плюшки.

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

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

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

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

Источник

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

Содержание

Элементы сессионного тестирования

Миссия

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

Устав

Сессия

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

Отчет о сеансе

Отчет о сеансе записывает тестовый сеанс. Обычно сюда входят:

Подведение итогов

Результаты анализа

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

Планирование

Тестировщики, использующие тестирование на основе сеансов, могут ежедневно корректировать свое тестирование в соответствии с потребностями проекта. Уставы могут быть добавлены или удалены с течением времени по мере выполнения тестов и / или изменения требований.

Источник

Kontur Mobile Test Session: 446 багов за 5 часов

В декабре Контур принимал ежегодную городскую тест-сессию Екатеринбурга. На этот раз 38 тестировщиков 5 часов искали баги в новом мобильном приложении. Игорь Борисихин, специалист по тестированию и организатор мероприятия, поделился опытом, рассказал что нового для тест-сессии придумал Контур и как попасть на мероприятие в этом году.

Что такое тест-сессия

Тест-сессия — это соревнование для начинающих и продвинутых тестировщиков и людей неравнодушных к тестированию, аналог мастер-класса или воркшопа у разработчиков. На тест-сессии можно познакомиться с коллегами из других компаний, проверить на «прочность» новый для себя продукт, выяснить, кто лучше умеет находить баги. Сессии тестирования — традиционное мероприятие для Екатеринбурга. Какой была прошлая четвертая общегородская тест-сессии можно узнать в сообществе тестировщиков Екатеринбурга — UTC.

О формате

Классический формат тест-сессии предполагает тестирование веб-сервиса. У участника есть аналитика по продукту. Есть N часов на поиск багов. В конце жюри считают, кто сколько багов нашел. Лучшим — призы. К классическому формату тест-сессии Контур добавил:

Мобильное приложение.
Продуктом для тестирования было мобильное приложение Контур.Конференция для проведения внешних и внутренних конференций. Подробнее о приложении Контур.Конференция можно почитать в маркетах: Google Play, App Store. Вот как оно работает:

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

Обучение.
По формату тест-сессии в процессе поиска багов участники изучали новые методики и техники тестирования мобильных приложений. Подробнее о пунктах 2 и 3 чуть дальше.

Об участниках

На тест-сессию собрались 38 тестировщиков из разных компаний Екатеринбурга: iRidium mobile, Ridero, Motorsport.com, Уральские Авиалинии, Точка, Адванта, Мерката, Экстрим про, Студия Флаг, BD Cube, ITM Холдинг, Digital Spectr, SkyDNS, Naumen и Контур.

Тестирование на основе опыта

Вместо того чтобы грузить тестировщиков аналитикой, мы предложили другой способ знакомства с приложением — тестирование на основе опыта.

Тестирование на основе опыта — эвристический эксплоринг в открытом многомерном пространстве. Если проще — исследуй приложение и делай выводы правильно или нет оно работает. Каждый участник тест-сессии уже бывал на конференциях, поэтому предметная область приложения ему знакома.

В основе тестирования на основе опыта лежат три методики:

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

Эвристики мобильного тестирования — это совокупность исследовательских методов, способствующих открытию ранее неизвестного.

О парном тестировании

На сессии участники тестировали в парах. Было составлено 19 команд. Объединяли команды и балансировали их по следующим критериям:

Опыт в тестировании.
Новичкам комфортнее с новичками. Опытному с опытным. Если новичок работает в паре с очень опытным и матерым тестером, в большинстве случаев, опытный доминирует и не дает раскрыться идеям начинающего коллеги. Если стаж участников более 4 лет, например, 5 и 10 лет, то можно смело объединять их в 1 команду.

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

Девайсы.
На тест-сессию люди приходили со своими гаджетами. Старались, чтобы устройства в команде были и iOS и Android.

Разнообразие общения.
Мы за общение! Коллеги из одной компании не могут быть в одной команде.

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

О багтрекере

Системой для багтрекинга был традиционный для Контура Youtrack. Многие тестировщики первый раз работали с Youtrack, поэтому мы подготовили короткую видеоинструкцию о том, как работать с системой и как заводить баги.

О системе оценки багов

По плану побеждали 5 команд, набравшие большее количество баллов. Приведем пример системы оценки.

В багтрекере можно было создать две сущности.
Task — предложения по улучшению работы системы. Таски оценивались в 1 балл.
Bug — дефект в продукте. У багов был разный приоритет: crash, major, minor.

К багам с приоритетом crash относились бесконечная загрузка, зависание, потеря данных (не сохраняются введенные или отредактированные данные), блокирование основных функций девайса. Такие баги оценивались в 20 баллов.

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

К minor относились опечатки, съехавшая верстка (не мешающая работе), некорректная анимация, не информативные подсказки, нестабильно воспроизводящаяся проблема. Такие баги оценивались в 5 баллов.

О сленге

Участники получили особенности сленга для грамотных багрепортов в мобильных приложениях. Небольшой пример:

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

Теперь вы тоже вспомнили, чем тап отличается от свайпа, тогл от тоста, а тайтл от стейта.

О призах

По итогам тест-сессии мы выбирали 5 команд победителей, набравших наибольшее количество баллов. Контур часто проводит соревнования по спортивному программированию, поэтому мы выбрали проверенную схему и вручать призы как на ACM ICPC. На общем столе с призами команда, набравшая большее количество баллов, первая выбирает призы, вторая по баллам команда — выбирает вторая и т.д.

Кто лучше всех тестирует

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

Всего участники сделали 446 репортов, из которых 349 с типом bug и 97 — task.

Жюри приняло 278 и отклонило 140 репортов. Отклоняли непонятно описанные, невоспроизводимые или повторяющиеся в рамках одной команды баги.

Из принятых репортов 215 оказались багами. Из них 118 багов имеют приоритет minor, 80 — major и 17 — crash.

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

Все фото с тест-сессии можно посмотреть здесь.

TestHackathonChallenge

Мы попробовали новую для себя тему. И сделали тест-сессию по мобильным приложениям. Ребятам понравилось, значит продолжим и в 2018 году, но добавим новизны. Следующая тест-сессия пройдет в конце года, анонс появится в нашем блоге — не пропустите!

Источник

В поисках самого лучшего способа тестирования системы

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

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

Почему существуют разные подходы к тестированию?

Я хотел бы начать с Линды Фишер. Вы ее не знаете, но более 19 лет назад я у нее проходил курсы по тестированию. Она говорила о том, что тестирование нужно делать вот так: сначала это, потом то (интерфейсы, проектирование и т.д.).

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

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

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

Основные подходы к тестированию

Существует два основных вида тестирования – сценарное (scripted) и исследовательское (exploratory).

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

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

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

Промежуточные подходы к тестированию

Однако эти два подхода к тестированию – не единственные. Кроме них существуют другие подходы, которые находятся где-то между ними.

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

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

Подробное сценарное и общее сценарное тестирование (Detailed Scripting & Global scripting)

В чем отличия между подробным сценарным и общим сценарным тестированием? Объясню на примере.

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

Сессионное тестирование и поиск багов (Session Based Testing & Bug Hunts)

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

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

Сессионное тестирование предусматривает наличие:

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

Исследовательское тестирование и туры (Exploratory Testing & Test Tours)

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

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

При проведении исследовательского тестирования акцент делается на личной свободе и ответственности тестировщика. Оно предполагает постоянный поиск ответов на вопросы: «как сделать лучше?», «какие тесты сейчас наиболее важны?». Вы не просто делаете то, что написано в сценарии, вы постоянно думаете. Кроме этого, все этапы тестирования (проектирование, выполнение, интерпретация результатов и пр.) проходят не последовательно, а параллельно на протяжении всего проекта.

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

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

В книге «Исследовательское тестирование ПО» Джеймс Уиттакер пишет о самых разных исследовательских турах. Вот некоторые из них:

Основные различия методов тестирования и сравнение их эффективности

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

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

Как решить, какой метод тестирования подходит лучше

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

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

Вместо заключения

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

Если ваша профессиональная деятельность связана с тестированием, наверняка вас заинтересуют вот эти доклады на нашей двухдневной декабрьской конференции Heisenbug 2017 Moscow:

Источник