Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Тест-менеджмент
Тестовая стратегия
18.03.2015 11:16

Автор: Роман Шейко. Оригинальная публикация в блоге автора

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

Формирование тестовой стратегии - интересный процесс, который часто выполняется нами на уровне интуиции, когда мы сами не до конца осознаем, почему мы решили делать так или иначе. Часто после своего формирования где-то на уровне интуиции стратегия так и продолжает жить там, в области неосознанного. Давайте попробуем достать её оттуда.

Подробнее...
 
Тестировщик среди программистов: жизнь по ту сторону кода
21.11.2014 17:22

Анастасия Коцевич, ЗАО «Технологии качества», бренд A1QA

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

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

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

Подробнее...
 
Регламент по работе с дефектами на проекте
13.11.2014 12:12

Пример регламента по работе с дефектами на проекте для статьи Alien bugs или пришельцы из мира дефектов, Павел Новик, ЗАО «Технологии качества», бренд A1QA

I. Описание полей, принципы заполнения

Заводя дефект, заполняется следующие 8 полей:

  • Приоритет;
  • Тема;
  • Описание;
  • Компоненты;
  • Проявляется в версиях;
  • Окружение;
  • Исправить в версиях;
  • Вложение;

II. Подробнее про заполнение каждого из них:

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

  • Блокирующий – тестирование значительной части функциональности вообще недоступно.
  • Критический – не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround, позволяющий продолжить тестирование.
  • Важный – не работает важная часть одной какой-либо функции, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
  • Желательный – часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определённом устройстве.
  • Незначительный – почти всегда дефекты на GUI -опечатки в тексте, несоответствие шрифта и оттенка и т.п.

Тема – краткое (в пределах 20 слов) описание ошибки, состоит из трех частей: < где найден дефект>: <короткое описание самой ошибки и места проявления><влияние (импакт) на пользователя>

  • <где найден дефект> – обычно описание функциональной части где найден дефект.
  • <короткое описание самой ошибки и места проявления> – отвечает на вопрос "В чем заключается дефект?" - из этой части должно быть четко понятно, что случилось – возникла ошибка, отсутствует кнопка, произошло "зависание" или что-то еще. Кроме того, должно быть указано, где именно встретили ошибку – какая-то форма, поле и т.п.
  • <влияние (импакт) на пользователя> – отвечает на вопрос "На что влияет дефект?" - особенно важно для дефектов с высоким приоритетом.

Описание – самое большое поле, предназначенное для подробного описания проблемы. Состоит из следующих частей:

  • Пользователь – указывается пользователь под которым воспроизводится дефект (опционально, в случае если данный факт не важен, можно не указывать)
  • Шаги воспроизведения – подробное и последовательное описание на русском языке кратчайшего пути для воспроизведения дефекта. Для удобства восприятия шаги нумеруются: 1...2...3... В описании шагов важно найти тонкую грань между избыточностью (описание каждого движения мышкой) и недостаточностью (пропуск важных для воспроизведения шагов или отсутствие описания, где находится то окошко, в котором воспроизвелась ошибка).
  • Результат – описание фактического поведения со всеми необходимым деталями.
  • Ожидаемый результат – описание ожидаемого поведения, обычно вытекает из функциональных требований или является общепринятым и очевидным поведением.

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

Проявляется в версиях – указывается версия билда, в котором был найден дефект.

Окружение – указывается устройство и версия iOS (опционально несколько), на которых воспроизводится дефект.

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

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

III. Общие правила заведения дефектов:

Перед тем, как регистрировать ошибку в баг-трекер, необходимо провести как минимум три основных действия:

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

IV. Описание типичного жизненного цикла дефектов.

Возможные состояния и резолюции описаны в Jira, a также дополнительно приведены на скриншоте ниже.

V. Пример описания дефекта несоответствующего регламенту.

{необходимо привести описание реального дефекта с вашего проекта}

VI. Пример описания дефекта соответствующего регламенту.

{необходимо привести описание реального дефекта с вашего проекта}

 
Как избежать ссор в команде тестировщиков и разрешить имеющиеся
22.09.2014 12:01

Доклад Андрея Мясникова на онлайн-конференции Chief ConfeT&QA, осень 2012 года.

Зачем работать в команде?
Ведь команда – это другие люди.
Другие точки зрения, другое восприятие.
Кто-то не сделает задачу, кто-то сделает не так, как надо.
Словом, трения неизбежны.
Но мы живем во времена корпораций, поэтому работая в компании почти невозможно работать не в команде.

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

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

Ответы на эти и многие другие вопросы вы найдёте в моём докладе.

Подробнее...
 
Гибкое тестирование
15.09.2014 09:13

Запись выступления Натальи Руколь на конференции Agile Days 2014.

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

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

Чаще всего в этом уличаются именно тестировщики, которые вместо содействия проекту выполняют роль Стражей Качества, которые готовы с остальной командой воевать - вместо того, чтобы помогать ей.

На своём докладе я расскажу, как сделать тестирование гибким и помогающим вашему проекту, а не мешающим ему:

  • Что зависит от тестировщиков, а что - нет?
  • Каковы наши общие цели?
  • Какие процессные решения помогают избежать "тёрок"?
  • Каким людям нельзя работать в тестировании?
  • Что могут сделать РМ и РО для развития тест-направления?

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

Подробнее...
 
Метрики в тестировании. Практические советы
21.07.2014 11:59

Запись доклада Николая Юденко на онлайн-конференции Chief ConfeT&QA.

«Ты не можешь контролировать то, что ты не можешь измерить».
Том ДеМарко

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

Как оценить выполненный объем? Или как оценить планируемый объем?
Что сказать прожект менеджеру о состоянии проекта, его качестве?
Как формализовать такие понятия в тестировании как «хорошо», «плохо», «нормально», «еще немного», «никогда»?
Как и главное на основании чего прогнозировать и планировать работу отдела тестирования?
Когда мы закончим тестирование?
Зачем нам столько тестировщиков?
Как нам поможет автоматизация?
Как мы можем влиять на разработку проудкта?

С подобными вопросы периодически сталкивается практически каждый тест менеджер (Test Manager) или ведущий тестировщик (Test Lead).
Я хочу рассказать и показать как мы можем «измерять тестирование» на разных этапах жизненного цикла ПО: от изучения требований до написания автотестов, от тест дизайна до регрессии, от функционального тестирования до внедрения.

Как при помощи «линейки и калькулятора» улучшать процесс тестирования и как следствие весь процесс разработки.

Подробнее...
 
Процессы, процессы, процессы... (обзор тем на форуме)
26.06.2014 10:59

Есть одно высказывание, гласящее, что «Работать может каждый, главное — правильно организовать». Может, именно поэтому тема организации процесса тестирования (да и разработки в целом, к чему скрывать) привлекает столько внимания и настолько популярна. Вот и у нас на форуме она на первых страницах.

Например, тут обсуждают проблему организации процесса тестирования и ведения документации — всё в одном да ещё и на затянувшемся проекте.

А вот тут уже проблема организации процесса на авральном проекте: не хватает времени, не хватает людей — знакомая ситуация, не правда ли?

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

А ещё на процесс влияют всяческие ново- и не очень ново-модные технологии. Тот же Agile манифест был написан больше 10 лет назад, но методологии, построенные на его основе, до сих пор считаются «новыми и перспективными». Вот и здесь, например, обсуждается роль тестировщика в гибких командах, приводится много ссылок наразнообразную литературу и презентации как на русском, так и на английском языках.

И, конечно, как обойтись без любимой многими итерации— как измерить её качество обсуждают тут.

Если Вам есть, что сказать, - присоединяйтесь к дискуссиям!

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

 
Тестовая документация: пациент скорее жив, чем мёртв, или скорее мёртв, чем жив?
23.06.2014 14:12

Автор: Татьяна Зинченко

Как давно вы писали тестовую документацию?
Нет, не так. Как давно Вы - лично Вы - писали тестовую документацию?

Когда-то давно, когда мир был большим, деревья - высокими, а процесс - вотерфолом, документация была жизненно важной штукой. На её создание выделялась тонна времени и не меньшая тонна денег. Сейчас стало модно прикрывать отсутствие документации гибкими нововведениями, а фраза: "У нас нет документации, у нас Agile!" давно стала новым мемом, по популярности не уступающим "Это не баг, это фича!"

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

Подробнее...
 
Читаем багтрекер между строк или тестирование процесса разработки
19.05.2014 18:15

Запись доклада Сергея Вербенко на онлайн-конференции Fun ConfeT&QA, весна 2012.

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

Как?

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

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

Подробнее...
 
Планирование тестирования как ежедневная активность тест-менеджера
17.03.2014 13:28

Запись доклада Натальи Руколь (автор Онлайн-интенсива по планированию тестирования) на онлайн-конференции Chief ConfeT&QA, весна 2012.

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

На этом докладе я рассмотрю следующие вопросы:

  • Что такое планирование тестирования?
  • Зачем нужны тест-планы и стратегия тестирования?
  • Как нивелировать риски, если они не зависят от вас?
  • Какие способы мониторинга проекта всегда доступны?
  • Кто должен участвовать в планировании?
  • Как сделать «всё хорошо, и желательно вчера»?
Подробнее...
 



Страница 4 из 10