21.10.2013 19:10 |
Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.
Сегодня мы опубликуем в открытом доступе доклад ПБО: ПротивоБаговая Оборона, Наталья Руколь (Россия), который с внушительным отрывом занял первое место на прошедшей онлайн-конференции для тест-менеджеров и тест-лидов Chief ConfeT&QA.
Чтобы защититься от нападений с воздуха, все крупные державы строят сеть ПВО – целый комплекс по поддержанию противовоздушной обороны. При этом, строительство идёт годами, даже в мирное время – чтобы в случае неприятельской атаки быть готовыми ответить сразу же.
Аналогично, в тестировании нам требуется заранее подготовленная, тщательно продуманная ПБО. Из чего состоит комплекс ПБО?
- Анализ тестируемых продуктов и документирование тестов в удобном формате
- Тестовые комплекты на любой случай: BVT (приёмка сборки, борьба с наиболее опасными и крупными багами), UAT (приёмочное пользовательское тестирование), FTP (полное регрессионное тестирование – «враг не пройдёт!»
- Оперативное планирование тестирования: как реагировать на «релиз сегодня», «недельную итерацию» и «выпуск в III квартале следущего года»?
- Стратегия принятия решений в различных боевых ситуациях
- Тестовые заплатки: что делать после высадки десантников (пропущенных багов)?
На доклад приглашаются бойцы ПБО, которые хотят быть готовыми к любой неприятельской атаке. No pasaran!
|
Подробнее...
|
05.07.2013 11:40 |
Продолжаем публикацию лучших докладов SQA Days 13. Сегодня представляем доклад Игоря Любина (http://auto-testing.ru/) и Анны Скуминой "Риски. Философия и практические рекомендации".
Известно, что любая деятельность представляет собой ценность тогда и только тогда, когда у нее есть некий внешний "потребитель", заинтересованный в результатах этой самой деятельности.
Какую ценность представляют результаты тестировщика и для кого? На простом «бытовом уровне» цель деятельности QC/QA можно усмотреть в проектировании и прохождении тестов, своевременном репортированнии багов и статуса продукта. Мы предлагаем подняться на уровень выше и рассмотреть вопрос о снижении рисков проекта как на основную цель отдела тестирования. Несмотря на это философское вступление, мы поговорим о вполне конкретных вещах. О том, как силами Тестировщиков минимизировать риски:
- Невыявленых требований
- Недооценки трудозатрат на разработку и тестирование
- Недостаточного покрытия функциональности тестовыми наборами.
- Потери "ключевых" сотрудников
- Непопадания всей команды в запланированное расписание
- Непрохождения продукта "приемки"
Речь пойдет о знакомых вещах, таких как раннее проектирование тестов или независимость тестирования, но мы предложим вам посмотреть на них под ракурсом снижения рисков.
И конечно поделимся практическими советами и наработками из личного опыта.
|
Подробнее...
|
25.06.2013 00:05 |
Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.
На конференции Chief ConfeT&QA первое место поделили Анастасия Мусина с докладом “Тестировщики не винтики!” или “Не закручивайте гайки!” и Андрей Мясников с докладом “Что нам стоит дом построить”.
Доклад Анастасии мы уже опубликовали. А сегодня представляем доклад второго победителя Андрея Мясникова “Что нам стоит дом построить”.
Директор: «Ну вот, мы решили расширяться. Теперь ты не тестировщик-одиночка. Теперь ты руководишь отделом! Набирай людей и делай нам хорошее тестирование: не хуже, чем в «Пупкин Inc.»
Тебе дают полномочия, права и ресурсы. Но что с ними делать?
До этого ты тестировал один и писал баги в гугл-док, который показывал программистам. Но с командой так работать не получится! Что делать в такой ситуации? Как не ошибиться?
Мой доклад поможет вам составить список первоочередных задач в ситуации, когда вы становитесь тим-лидом или тест-менеджером. С чего начать? Как выбрать необходимые вам решения? Как распределить своё время?
В конечном счёте, всё в ваших руках. Но я помогу вам выжить первое время.
|
Подробнее...
|
18.06.2013 16:09 |
Представляем доклад Сергей Нужненко, который он делал на Летнем Аналитическом Фестивале в 2012 году. По отзывам посетителей это один из лучших докладов ЛАФ-2012.
В этом году на ЛАФ-2013 Сергей прочтет доклад с интригующей темой: “Внедрение системы управления требованиями: (анти?)утопия”.
Программа первого дня фестиваля сформирована: http://conf.uml2.ru/program2013/
А до самого фестиваля осталось совсем немного.
|
Подробнее...
|
21.05.2013 12:27 |
Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.
Сегодня мы опубликуем в открытом доступе доклад Анастасии Мусиной “Тестировщики не винтики!” или “Не закручивайте гайки!”, который разделил первое место с докладом Андрея Мясникова “Что нам стоит дом построить” на прошедшей онлайн-конференции для тест-менеджеров и тест-лидов Chief ConfeT&QA.
Когда в вашей группе по тестированию много проектов, продуктов и различных задач, неизбежно наступают проблемы:
1. Тебя (тимлида) разрывают на части менеджеры разных групп разработки, и не все остаются довольны уделенным им вниманием;
2. Тестировщики недовольны распределением задач, а если выбирают их сами — не успевают все в срок;
3. Тестировщики достаточно хорошо знают все продукты, чтобы подхватить тестирование соседней задачи, но на каверзные вопросы «вглубь» ответить не могут;
4. «Море работы, горы работы», и никакого просвета;
5. Вася собрался на футбол, а Маша на свидание? Да бросьте! у нас сегодня релиз, так что на ужин пицца и ночуем на работе!
Знакомо?
Анастасия расскажет о проверенных на практике методах борьбы со всем этим безобразием. Как не разорваться, сделать тестировщиков счастливыми, и при этом отлично протестировать все продукты?
|
Подробнее...
|
21.03.2013 19:54 |
Автор: Наталья Руколь, ведущая Школы Тест-Менеджеров, очередной запуск которой начнется 20 мая.
Каждый тест-менеджер сталкивался с этой неприятной ситуацией: пользователь обнаруживает ошибку, которую мы своевременно не нашли. И ошибку важную, в основном функционале, который мы многократно и тщательно тестировали!
Как это произошло? Как избежать подобных ситуаций в будущем? Как реабилитировать своё доброе имя перед коллегами?
Я уже рассказывала о пропуске ошибок глазами тестировщика. А в этой статье давайте разберёмся с позиции тест-менеджера: какие возможные проблемы приводят к пропускам, и каковы способы их решения.
Причины пропуска проблем
Представьте себе, что у вас что-то болит, и вы записываетесь к доктору. На приеме он даже не пытается выслушать симптомы, а сразу назначает лекарство. Что вы сделаете? Скорее всего, сбежите от него. И правильно сделаете! Лечение невозможно без диагностики, и, только точно зная источник проблемы, её можно решить.
В тестировании и разработке ПО всё то же самое. Хотите что-то улучшить? Значит, вы хотите вылечить проблему. Найдите её!
Давайте посмотрим на стандартные причины пропуска ошибок, и для удобства восприятия поделим их на 2 категории: проблемы в процессе и человеческий фактор.
|
Подробнее...
|
29.11.2012 12:36 |
Сергей Высоцкий, cпециалист по тестированию высоконагруженных сервисов 2ГИС
Представляем вашему вниманию запись выступления, которое состоялось в рамках DevDay , организованном компанией 2ГИС в Новосибирске.
В разработке программного обеспечения мы работаем со сложными системами. В них не самые тривиальные технологии переплетаются со сложными процессами, и это только начало. Зачастую это означает, что, когда все ломается, не всегда очевидно, почему произошла ошибка, и что можно сделать, чтобы хоть чему-то из этой ошибки научиться. Как проводить пост мортем? Почему происходят ошибки? Как сделать нашу работу надежнее и безопаснее? Чему мы можем научиться из авиакатастроф и аварий на объектах мирного атома?
|
Подробнее...
|
02.10.2012 14:01 |
По старой традиции мы публикуем лучший доклад онлайн-конференции Chief ConfeT&QA. По результатам голосования участников конференции, лучшим признан доклад Николая Алименкова "Почему тестирование занимает так много времени".
Многие сейчас работают по итеративным подходам и регрессионное тестирование происходит на каждой итерации (я надеюсь). И часто происходит следующее: в одной итерации оно успело закончиться в срок, а в следующей не завершилось даже на 50%. Как же так? Ведь количество функциональности изменилось очень незначительно! И тут менеджеры начинают подозревать тестировщиков в недостаточной эффективности и берутся за анализ. В ход идут метрики и статистика… Возможно, кого-то увольняют… Но ситуация повторяется снова и снова. В докладе я подробно рассмотрю, что в действительности тормозит тестирование и как можно с этим бороться.
|
Подробнее...
|
24.10.2011 10:06 |
Автор: Майкл Болтон (Michael Bolton) Оригинальная публикация: Testing Problems Are Test Results Перевод: Сергей Высоцкий и RA
Часто во время курса "Быстрое Тестирование ПО", я провожу упражнение, в ходе которого прошу людей записать те вещи, которые, по их мнению, замедляют тестирование и делают его сложней. Эти списки отлично ложатся на шаблон, который я снова и снова слышу от тестировщиков (вы можете посмотреть пример такого шаблона в этой беседе на Stack Exchange). Обычные пункты в этих списках выглядят так:
- Я - тестировщик, работающий один с несколькими программистами (или несколько тестировщиков работающих с большим числом программистов).
- Мне приходится работать в чудовищных временных рамках. Сборки приходят постоянно и мы работаем в одно- двух-недельных циклах.
- Продукт(ы) который(е) я тестирую очень сложный(е).
- Очень много взаимозависимостей между компонентами продукта или между продуктами.
- Я вижу устоявшийся шаблон ошибок, связанных с этими взаимозависимостями. Даже малейшие изменение может привести к чудовищным последствиям по всему продукту.
- Я думаю, мне нужно прогонять полный цикл регрессионных тестов, чтобы обнаружить как можно больше таких ошибок.
- Я пытаюсь справиться со всем этим при помощи автоматических проверок, но вся эта сложность делает автоматизацию крайне затруднительной, в лучшем случае у меня есть пара способов обойти проблему при помощи нескольких тестовых приемов, а частые изменения делают всю эту конструкцию очень хрупкой.
- На поддержание автоматических тестов уходит столько времени, что почти ничего не остается на другую тестовую активность.
- Я чувствую, что перегружен всем этим, но я пытаюсь справиться.
В добавок к этому:
- Организация на которую я работаю говорит, что она работает по Agile.
- Кроме двухнедельных итераций мы так же активно практикуем две другие вещи, часто ассоциирующиеся с Agile разработкой, обычно это ежедневные скрам митинги или доски Канбан.
Ах да, вот еще:
- Сборки, которые я получаю, очень нестабильные. Система практически всегда валится после нескольких простейших smoke-тестов. Мне приходится тратить много времени на ожидание новой сборки или переконфигурацию, прежде чем я могу приступить к другим вещам
Как мы можем принять во внимание все эти наблюдения?
Мы можем интерпретировать их как проблемы тестирования, или мы можем взглянуть на них с другой стороны: как на результаты тестирования.
|
Подробнее...
|
|