Home

Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.

Сегодня мы опубликуем в открытом доступе доклад ПБО: ПротивоБаговая Оборона, Наталья Руколь (Россия), который с внушительным отрывом занял первое место на прошедшей онлайн-конференции для тест-менеджеров и тест-лидов Chief ConfeT&QA.

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

Аналогично, в тестировании нам требуется заранее подготовленная, тщательно продуманная ПБО. Из чего состоит комплекс ПБО?

• Анализ тестируемых продуктов и документирование тестов в удобном формате 
• Тестовые комплекты на любой случай: BVT (приёмка сборки, борьба с наиболее опасными и крупными багами), UAT (приёмочное пользовательское тестирование), FTP (полное регрессионное тестирование – «враг не пройдёт!» 
• Оперативное планирование тестирования: как реагировать на «релиз сегодня», «недельную итерацию» и «выпуск в III квартале следущего года»? 
• Стратегия принятия решений в различных боевых ситуациях 
• Тестовые заплатки: что делать после высадки десантников (пропущенных багов)?

На доклад приглашаются бойцы ПБО, которые хотят быть готовыми к любой неприятельской атаке. No pasaran!

Продолжаем публикацию лучших докладов SQA Days 13. Сегодня представляем доклад Игоря Любина (http://auto-testing.ru/) и Анны Скуминой "Риски. Философия и практические рекомендации".

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

Какую ценность представляют результаты тестировщика и для кого? 
На простом «бытовом уровне» цель деятельности QC/QA можно усмотреть в проектировании и прохождении тестов, своевременном репортированнии багов и статуса продукта. 
Мы предлагаем подняться на уровень выше и рассмотреть вопрос о снижении рисков проекта как на основную цель отдела тестирования. 
Несмотря на это философское вступление, мы поговорим о вполне конкретных вещах. О том, как силами Тестировщиков минимизировать риски:

• Невыявленых требований
• Недооценки трудозатрат на разработку и тестирование
• Недостаточного покрытия функциональности тестовыми наборами.
• Потери "ключевых" сотрудников
• Непопадания всей команды в запланированное расписание
• Непрохождения продукта "приемки"

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

И конечно поделимся практическими советами и наработками из личного опыта.

Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.

На конференции Chief ConfeT&QA первое место поделили Анастасия Мусина с докладом “Тестировщики не винтики!” или “Не закручивайте гайки!” и Андрей Мясников с докладом “Что нам стоит дом построить”.

Доклад Анастасии мы уже опубликовали. А сегодня представляем доклад второго победителя Андрея Мясникова “Что нам стоит дом построить”.

Директор: «Ну вот, мы решили расширяться. Теперь ты не тестировщик-одиночка. Теперь ты руководишь отделом! Набирай людей и делай нам хорошее тестирование: не хуже, чем в «Пупкин Inc.»

Тебе дают полномочия, права и ресурсы. Но что с ними делать?

До этого ты тестировал один и писал баги в гугл-док, который показывал программистам. Но с командой так работать не получится! Что делать в такой ситуации? Как не ошибиться?

Мой доклад поможет вам составить список первоочередных задач в ситуации, когда вы становитесь тим-лидом или тест-менеджером. С чего начать? Как выбрать необходимые вам решения? Как распределить своё время?

В конечном счёте, всё в ваших руках. Но я помогу вам выжить первое время.

Представляем доклад Сергей Нужненко, который он делал на Летнем Аналитическом Фестивале в 2012 году. По отзывам посетителей это один из лучших докладов ЛАФ-2012.

В этом году на ЛАФ-2013 Сергей прочтет доклад с интригующей темой: “Внедрение системы управления требованиями: (анти?)утопия”.

Программа первого дня фестиваля сформирована: http://conf.uml2.ru/program2013/

А до самого фестиваля осталось совсем немного.

Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.

Сегодня мы опубликуем в открытом доступе доклад Анастасии Мусиной “Тестировщики не винтики!” или “Не закручивайте гайки!”, который разделил первое место с докладом Андрея Мясникова “Что нам стоит дом построить” на прошедшей онлайн-конференции для тест-менеджеров и тест-лидов Chief ConfeT&QA.

Когда в вашей группе по тестированию много проектов, продуктов и различных задач, неизбежно наступают проблемы:

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

2. Тестировщики недовольны распределением задач, а если выбирают их сами — не успевают все в срок;

3. Тестировщики достаточно хорошо знают все продукты, чтобы подхватить тестирование соседней задачи, но на каверзные вопросы «вглубь» ответить не могут;

4. «Море работы, горы работы», и никакого просвета;

5. Вася собрался на футбол, а Маша на свидание? Да бросьте! у нас сегодня релиз, так что на ужин пицца и ночуем на работе!

Знакомо?

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

Автор: Наталья Руколь, ведущая Школы Тест-Менеджеров, очередной запуск которой начнется 20 мая.

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

Как это произошло? Как избежать подобных ситуаций в будущем? Как реабилитировать своё доброе имя перед коллегами?

Я уже рассказывала о пропуске ошибок глазами тестировщика. А в этой статье давайте разберёмся с позиции тест-менеджера: какие возможные проблемы приводят к пропускам, и каковы способы их решения.

Причины пропуска проблем

Представьте себе, что у вас что-то болит, и вы записываетесь к доктору. На приеме он даже не пытается выслушать симптомы, а сразу назначает лекарство. Что вы сделаете? Скорее всего, сбежите от него. И правильно сделаете! Лечение невозможно без диагностики, и, только точно зная источник проблемы, её можно решить.

В тестировании и разработке ПО всё то же самое. Хотите что-то улучшить? Значит, вы хотите вылечить проблему. Найдите её!

Давайте посмотрим на стандартные причины пропуска ошибок, и для удобства восприятия поделим их на 2 категории: проблемы в процессе и человеческий фактор.

Сергей Высоцкий, cпециалист по тестированию высоконагруженных сервисов 2ГИС

Представляем вашему вниманию запись выступления, которое состоялось в рамках DevDay , организованном компанией 2ГИС в Новосибирске.

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

По старой традиции мы публикуем лучший доклад онлайн-конференции Chief ConfeT&QA. По результатам голосования участников конференции, лучшим признан доклад Николая Алименкова "Почему тестирование занимает так много времени".

Многие сейчас работают по итеративным подходам и регрессионное тестирование происходит на каждой итерации (я надеюсь). И часто происходит следующее: в одной итерации оно успело закончиться в срок, а в следующей не завершилось даже на 50%. Как же так? Ведь количество функциональности изменилось очень незначительно! И тут менеджеры начинают подозревать тестировщиков в недостаточной эффективности и берутся за анализ. В ход идут метрики и статистика… Возможно, кого-то увольняют… Но ситуация повторяется снова и снова. В докладе я подробно рассмотрю, что в действительности тормозит тестирование и как можно с этим бороться.

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Testing Problems Are Test Results
Перевод: Сергей Высоцкий и RA

Часто во время курса "Быстрое Тестирование ПО", я провожу упражнение, в ходе которого прошу людей записать те вещи, которые, по их мнению, замедляют тестирование и делают его сложней. Эти списки отлично ложатся на шаблон, который я снова и снова слышу от тестировщиков (вы можете посмотреть пример такого шаблона в этой беседе на Stack Exchange). Обычные пункты в этих списках выглядят так:

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

В добавок к этому:

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

Ах да, вот еще:

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

Как мы можем принять во внимание все эти наблюдения?

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

С разрешения Санкт-Петербургского сообщества тестировщиков мы публикуем слайдкаст с выступления Олега Ладыгина «Опыт создания системы управления сборкой и тестированием».