Home

Доклад одного из наших тренеров Натальи Руколь (автор и ведущий тренингов Школа тест-менеджеров и Школа тест-аналитиков) на конференции SQA Days 17.

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

На конференциях принято рассказывать: мы сделали такую крутую штуку! Мы внедрили опупенный инструмент! Посмотрите, как мы справились с этими техниками… Такие рассказы слушать приятно, и есть, чему поучиться. Но наши рабочие дни обычно состоят не из геройских подвигов! Мы сталкиваемся с проблемами и трудностями:

• пропустили критичный дефект
• не успели провести тестирование вовремя
• автотесты не окупаются и требуют слишком много времени
• нет сил актуализировать тесты и планы

Что делать при возникновении таких проблем? Я знаю отличное решение:

расплакаться! Но на докладе расскажу о другой реакции: как извлекать полезный опыт из каждой допущенной ошибки.

На этом докладе вас ждут:

• мои самые позорные грабли в карьере тестировщика
• извлечённый опыт и найденные решения
• самоуспокоительные мантры тестировщиков.

Обсуждение, организованной Татьяной Писчасовой, о Мире без тестировщиков на конференции CodeFest 2015.

В черном-черном городе.. на черной-черной горе.. в черном-черном офисе.. черные-черные разработчики.. писали черные-черные программы...
И САМИ ИХ ТЕСТИРОВАЛИ!!!!

Каждый тестировщик будучи junior-ом слышал такую страшилку от старших товарищей.

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

Приглашаю коллег обсудить этот тренд. Чем грозит (и грозит ли) тестирование продукта без выделенного специалиста.
В чем плюсы, в чем минусы такого подхода.
На каких проектах он применим, на каких - нет.
Как обеспечить качество продукта без специалистов по качеству.

И как жить тестировщикам, которых "оставили без работы".

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

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

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

Для просветлённых тест-менеджеров, готовых отказаться от таких абстрактных правил, предлагаем вниманию 1-й вводный вебинар нового онлайн-тренинга Натальи Руколь Школа Тест-Менеджеров v 2.0.

На нём мы рассмотрим:

• Кто является внутренним заказчиком (пользователем) тестирования?
• Что от нас хотят?
• Как понять ожидания, когда их не могут сформулировать?
• Как сделать тестирование более полезным и подходящим вашему проекту?

Вебинар будет полезен тест-менеджерам и тестировщикам-оркестрам, самостоятельно определяющим "как будет проводиться тестирование на проекте".

Доклад Дмитрия Химиона, Performance Lab на конференции CodeFest 2015.

Вы — участник проекта, где релиз дополняется 20-ю патчами?
Вы — QA-менеджер и чувствуете, что разработчики «лукавят», говоря что «у них всё работает»?
Вы — тестировщик и думаете, куда бы развиваться и как еще можно повлиять на качество проекта?
Тогда этот доклад будет вам интересен и, возможно, полезен в работе. Я расскажу о работе с проблемой технического долга со стороны команды тестирования, что qa-team может в этой области, и как оно может выглядеть. Рассмотрим связь между ISO, зрелостью процессов, командой тестирования и проявлением технического долга.

Доклад Андрея Солнцева, разработчика в таллинской компании Codeborne, на конференции CodeFest 2015.

Есть большие отделы QA, поделённые на касты «мануальщиков», «автоматизаторов», «тест-менеджеров» и «тест-лидов». Есть армия тестировщиков, колбасящая селениум изо дня в день. Есть гриды и облака для параллельного запуска тестов в тысячу потоков по ночам.

А мы разрабатываем интернет-банк всего лишь вчетвером. Вместе с автотестами. Никаких аналитиков. Никаких тестировщиков. Никаких тест-менеджеров. И тесты наши пробегают всего лишь за 5 минут. Как нам это удаётся?

Смотрите запись доклада

Выступление Максима Цепкова на AgileDays-2015.

Страница данного доклада с кратким текстовым содержанием и презентацией

Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей. Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР. Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки. А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering).

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

За время доклада мы рассмотрим основные вехи развития подходов к управлению ИТ-проектами и эволюцию критериев качества ПО в мире и в России, которая в 90-х годах шла своим путем, но за последнее время приблизилась к общим трендам.

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

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

Первая статья

Сегодня я хотел бы рассказать о создании стратегии для тестирования одного крупного сайта (http://lingualeo.com). Коротко: это онлайн-платформа для желающих изучить английский язык.

Цель у меня такая: не показать результат, а в первую очередь рассказать о самом процессе составления стратегии. Мне было интересно проследить, как и что я делаю. Это напоминает работу над ошибками и самопроверку. Кроме того, это попытка объяснить свою работу. Не всегда это просто сделать, потому что часто мы работаем интуитивно. Для меня умение объяснить свою работу означает способность понять свои ошибки (что я делаю неправильно) и свои достижения (что я делаю правильно).   
Итак, я расскажу о процессе составления стратегии и постараюсь сделать это в структурированной форме, по порядку. Как вы понимаете, не каждый процесс структурирован сам по себе. Поэтому не факт, что у меня получится разложить все по полочкам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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