Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как?

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

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

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

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

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

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

Выступление Николая Юденко, Днепропетровск (Украина) на онлайн-конференции для тестировщиков ConfeT&QA, 2011 год. 

Какое покрытие требований считается хорошим? 80%, 90%, 100%? От чего это зависит? А как добиться того, чтобы покрытие было 110% или 120%? Как научиться «читать между строк» и находить скрытые требования, которые являются потенциальными источниками ошибок. Как неявные требования могут повлиять на развитие проекта или даже его архитектуру?На примерах я попытаюсь показать, как повысить эффективность тестирования анализируя «явные требования» и находя в них «неявные».

Доклад Натальи Руколь с конференции SECR.

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

В октябре прошлого года Андрей Ладутько выступал на Chief ConfeT&QA c докладом про Организацию времени в тестировании и получил третий приз за доклад.

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

* Тайм-менеджмент: что правда, а что вымысел?
* Самодиагностика: начнем с хронометража
* ТМ-инструменты для планирования и работы с целями
* Фиксируем, записываем, улучшаем рабочий процесс

Когда тратишь время на планирование – времени становится больше. Обязательно приходите на доклад, выделите 30 минут, чтобы стать эффективным хозяином своего «временного бюджета» в тестировании и не только. До встречи на докладе!

Сегодня Андрей делится с нашими читателями записью своего выступления.