Ловить баги что это

Словарь современного языка

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

Использование

Программа работает в тестовом режиме, о багах сообщать в техподдержку. На ловлю багов у нас всего неделя. Система работает ужасно, постоянно лагает, и багов немеряно.

Добавить значение

Как называется фотография девушки с именем на теле?

80% пользователей знают ответ на этот вопрос, а ты?

Как искать и находить баги? (подія в архіві)

Описание:
Вы уже освоили основные техники тест-дизайна? Отлично! Значит, Вы — квалифицированный тестировщик. Но куда двигаться дальше? Что делать, чтобы стать высококвалифицированным тестировщиком? Как научиться находить баги, которые не находят другие тестировщики, несмотря на то, что они знают те же самые техники? Освоение техник — это лишь первый шаг на пути к мастерству. Как нотная грамота и гаммы для музыканта. Как умение держать ракетку и наносить удары слева и справа для теннисиста. Как знание дебютов и эндшпилей для шахматиста. Разумеется, техники надо знать. Но для осмысленного, а тем более творческого их применения требуется ещё кое-что — нужны дополнительные профессиональные навыки.

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

Почитайте внимательно статьи и учебники про техники тест-дизайна. Они правильные, и они работают. Но в них не хватает чего-то неуловимого. Откуда берутся пропущенные баги, которые тестировщик «не заметил»? Почему не заметил? Техники не виноваты. В них ничего не говорится о том, как надо проверять результат. Просто не хватило наблюдательности.

Почему в продуктив попадают баги, для которых тестировщик «не придумал» подходящего теста? Техники не виноваты. Просто неверно выбрана модель или техника применялась не там и не так.

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

В этом тренинге по согласованию с Майклом Болтоном (автор книги и одноименного тренинга «Rapid Software Testing») используется методика и упражнения из всемирно известного тренинга Rapid Software Testing. Для подготовки к тренингу тренер Алексей Баранцев трижды провел совместные с Майклом тренинги в качестве ассистента и второго тренера.
После него вы вернётесь на своё рабочее место «намагниченным» и «заряженным» на поиск багов. И они это почувствуют, не сомневайтесь!

Специальное предложение: до 1 февраля 2014 г. стоимость курса — 3000 грн, после — 3 500 грн.

Цели:

После прохождения тренинга слушатели научаться:
— систематически анализировать документацию, прослеживать путь от спецификации к тестам и дальше, к багам;
— видеть не только то, что очевидно, чтобы замечать неочевидные баги;
— переключать внимание с одного аспекта на другой, чтобы ловить «интеграционные» баги;
— определять, что является багом, а что не является;
— доказывать, что баг — это действительно баг;
— задавать правильные вопросы заказчику, менеджеру, аналитику и даже программисту;
— придумывать тесты без использования техник не хуже, чем с техниками;
— строить разные модели — ментальные, формальные, концептуальные.

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

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

Разбираемые темы:

День первый
1. Подготовка инфраструктуры, знакомство.
2. Тестирование учебной программы (упражнение и разбор), обсуждение на тему «Что важнее — техники или навыки?».
3. Тестирование новой программы, искусство задавания вопросов (упражнение и разбор).
4. Что делать, когда ты нашел баг? Глобализация и локализация (демонстрация и обсуждение).
5. Искусство описания багов (упражнение и разбор).
6. Регрессионное тестирование и перепроверка багов — как и зачем много раз выполнять одни и те же тесты?
7. Моделирование: умение смотреть на программу под разными углами (упражнение и разбор).
8. Тестирование юзабилити: поселите у себя в голове персонажей (упражнение).
День второй
1. Стратегия тестирования (обсуждение).
2. Сравнение двух программ: какая лучше? (упражнение и обсуждение).
3. HICCUPPSF: эвристики построения оракулов (демонстрация, упражнение и разбор).
4. Построение тестов для сложной функциональности (упражнение и разбор).
5. Тест-кейсы, чеклисты, тестирование методом свободного поиска — в каком соотношении смешивать? (обсуждение).
6. Тестирование методом свободного поиска (упражнение и разбор).
7. Регрессионное тестирование и перепроверка багов — как и зачем много раз выполнять одни и те же тесты? (обсуждение).
8. Автоматизация тестирования (демонстрация и обсуждение).
9. Завершение курса, подведение итогов.

Тренер — Алексей Баранцев.

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

Профессиональная деятельность
Оказывает консультационные услуги в области тестирования, читает лекции о тестировании студентам ГУ ВШЭ, проводит тренинги для тестировщиков, участвует в организации профессиональных конференций, обеспечивает поддержание и развитие крупнейшего русскоязычного сайта о тестировании Software-Testing.ru.

Специализация
Алексей специализируется в тестировании функциональности и производительности, а также в тестировании удобства использования и безопасности компьютерных программ.
Считает своей сильной стороной знания и опыт в автоматизации тестирования — понимание потребности в автоматизации, умение выбрать подходящий инструмент, хорошие навыки программирования, умение работать с различными видами интерфейсов: программными (API), сетевыми, пользовательскими (GUI).
Предпочитает пользоваться бесплатными инструментами тестирования, такими как Selenium, AutoIt, JMeter, не навязывая своим клиентам потребность в приобретении дорогостоящих лицензий на использование коммерческих инструментов автоматизации. Но если уже есть лицензия на какой-либо инструмент — готов использовать его.
Кроме того, готов взять на аутсорсинг сложные задачи по тестированию, как самостоятельно, при небольшом объёме работ, так и осуществляя руководство командой с многолетним опытом тестирования.

Стоимость:
до 01.11 — 3000 грн.;
после 01.11 — 3500 грн.

БОНУС.
При регистрации 3 и более человек от одной компании скидка 10 %!

Целевая аудитория:
Тестировщики, тест-дизайнеры, тест-менеджеры.

Исследование плавающих багов

Что вы знаете о тестировании ПО? А об исследовании плавающих багов? Роль тестирования в современном мире нельзя преувеличить, а получить знания и даже углубить в перспективной отрасли Вы можете на курсах тестирования ПО в Минске.

Если вы способны уверенно справляться с плавающими багами – вы входите в тот процент хороших тестировщиков. Именно самые интересные истории в тестировании ПО связаны с охотой на “белых китов” в океане сложного кода.

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

К слову, плавающие баги не проблема. Все программирование крутится вокруг контроля неустойчивого поведения. Итак, в чем проблема?

Нас не должно беспокоить неустойчивое поведение, если:

так и задумано
данное поведение не несет в себе угрозы

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

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

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

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

Принципы работы с плавающими багами:

Успокойтесь, баги, скорее всего, не проявление агрессии злых духов.
Подумайте, багов проявился один разы – значит, он проявится снова.
Если не исправить бга, врядли можно говорить о гарантии качества.
С осторожностью относитесь к исправлениям плавающих багов. Исправленный баг и неисправленный плавающий баг практически невозможно отличить друг от друга в течение какого-то времени и/или при определенных условиях.
Любое состояние системы, переход в которое занимает длительное время в обычных условиях, можно достигнуть в непредсказуемых ситуациях.
Сложное и непонятное поведение обычно вызвано причиной, которая, на самом деле, лежит на поверхности.
Сложное и непонятное поведение иногда вызвано целым рядом причин.
Зачастую, плавающих баги могут помочь узнать свой продукт чуточку лучше.
Если вы думаете, что вы абсолютно правильно предполагаете о причинах багов, скорее всего, вы не правы.
Иногда соверешенно другой человек может дать вам ключик от разгадки.
Скорее всего, выявленный баг в руках тестировщика также проявится в руках пользорвателя.
Принцип Pentium 1994: плавающая техническая проблема может привести к систематическим и очень дорогостоящим проблемам.
Даже если баг “плавающий”, риск всегда стабилен.
Чем выше тестируемость продукта, тем легче исследовать плавающие баги.
Когда вы перепробовали все невозможное, то то, что осталось, каким бы невероятным оно ни казалось, могло уже принести не мало убытков! Поэтому не ждите момента, когда вы вызовите баг снова, фиксируйте его!
Если вы не успеваете выловить плавающий баг до релиза, сделайте все, что в ваших силах, чтобы все-таки поймать его и исправить.

Общие советы по исследованию плавающих проблем:

Перепроверьте свои базовые предположения: используете ли вы именно тот компьютер?
Тестируете ли вы именно то, что нужно? Верны ли ваши наблюдения?
Слова постронних людей иногда могут принести большую пользу, но все таки полагайтесь на себя.
Пригласите других тестировщиков, подключите к процессу большее количество людей.
Просите людей сообщать о плавающих проблемах.
Если вам сказали, что причина проблемы точно не в этом, обратите на это особое внимание.
Проверьте сайты технической поддержки каждого из используемых сторонних компонентов.
Возможно, ваша проблема там указана.
Ищите инструменты, которые помогут вам наблюдать за поведением системы и контролировать его.
Налаживайте коммуникацию с юзерами (особенно с реальными пользователями).
Объедените все плавающие баги, чтобы легче было отслеживать закономерности.
Пройдитесь по списку багов, попробуйте найти в нем похожие на плавающий баг проблемы.
Относитесь серьезнее к фиксированию багов, используйте специальные инструменты.
Точнее контролируйте данные, которые вы вводите (включая их последовательность, время, типы, размеры, источники, итерации, комбинации).
Систематически покрывайте тестами данные ввода и состояния системы.
Сохраняйте абсолютно все логи. Возможно, позже вам понадобится сравнить новые логи со старыми.
Если проблема чаще возникает в одних ситуациях и реже в других, проведите статистический анализ разницы между закономерностями в этих ситуациях.
Начните контролировать то, что раньше казалось не важным.
Упрощайте. Пробуйте менять одну переменную за раз, делить систему на части (помогает узнать природу и изолировать проблему).
Усложняйте. Пробуйте менять несколько переменных за раз, устройте в системе бедлам (помогает выявить баги-лотереи).
Добавьте элемент случайности в состояния системы и обрабатываемые данные (возможно, при помощи менее жесткого контроля), чтобы добиться состояний, которые, возможно, не вписываются в ваш обычный шаблон использования.
Создайте нагрузку на систему (большие объемы данных).
Поставьте ловушку, чтобы при возникновении проблемы в следующий раз вам удалось изучить ее получше.
Подумайте насчет код-ревью.
Узнавайте и держите в голове случаи локализации плавающих багов.
Систематически размышляйте о причинах плавающих багов.
Перед тем, как потратить много времени на исправление мелкого бага, подумайте, стоит ли он того.
Если ничего не помогает, попробуйте отвлечься от всего и заняться другими проблемами, чтобы понять, удастся ли выявить плавающих баг в этом случае.

Возможные причины плавающих багов:

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

Причина 1: Поведение системы не отличается от ее исходного поведения. Кажущийся сбой поведения – артефакт, относящийся к вашему восприятию.

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

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

Неправильаня атрибуция. Наблюдатель может приписать свое наблюдение не тому, чему нужно. Например, “Microsoft Word упал” может означать, что упала Windows, и этого не будет связано с прогарммой никаких образом. Word вообще ничего не сделал. Этот феномен еще называют “ложной корреляцией” и часто встречается, когда одно событие следует сразу же после другого, и кажется, что это причина и следствие. Благодаря ложной корреляции плавающие баги зачастую считаются обычными багами, появившимися из-за крайне сложного и маловероятного ряда причин.

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

Ненадежная коммуникация. Коммуникация с наблюдателем может быть неполной. У нас создается ощущение, что мы нашли плавающий баг, потому что сообщения о нем не всегда до нас доходят, даже если проблема вполне предсказуема. Фраза “Мне кажется, проблема больше не проявляется” может означать, что люди просто перестали о ней сообщать.

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

Причина 2. Система ведет себя иначе, потому что это другая система

Deus ex machina. Разработчик мог специально что-то поменять, а затем октатить изменения. Довольно расспространенное явление, когда над разными частями платформы одновременно работает несколько разработчиков или команд, при этом не координируя свои действия друг с другом. А возможно, это просто модификации приложения хакерами.

Случайное изменение. Разработчик мог внести правки случайно. (Возможно, именно внесение изменений приводит к появлению плавающих багов..

Изменение платформы. Один из компонентов платформы мог быть заменен или переконфигурирован. Пользователь мог что-то изменить в компоненте, от которого зависит четкая работа продукта. Довольно расспространенный источник таких проблем – автоматические обновления Windows, изменения в конфигурации памяти и дискового пространства.

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

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

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

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

Причина 3. Система ведет себя иначе, потому что находится в другом состоянии.

Замершее условие. Решение, которое должно основываться на статусе условия, могло перестать проверять это условие, застряв в состоянии “всегда да” или “всегда нет”.

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

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

Прогрессивное повреждение данных. Система могла превратиться в хаос из-за постепенно накапливающихся мелких багов. Проявлением может быть рассинхрон временных циклов.

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

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

Другой режим или настройки. Система может работать при разнообразных режимах, и пользователь может установить какой-то другой. Отличия могут быть незаметны с первого взгляда.

Причина 4. Система ведет себя иначе, потому что получила другие вводные данные.

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

Секретные границы и условия. Софт может вести себя иначе в некоторых частях ввода данных, чем в других. Это может произойти из-за скрытых границ или областей падения, которые никем не зафиксированы и которых вы не ожидаете, предполагая совсем другой исход.

Другой профиль. Использование приложений некоторыми пользователями может чем-то отличаться от других пользователей. Немного отличающийся ввод данных может привести к соверешенно неожиданному результату.

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

Deus Ex Machina. Кто-то еще работает с продуктом в то же самое время, что и пользователь – другой тестировщик, другой пользователь, хакер.

Дефектный ввод. Данные ввода могли быть повреждены или перехвачены на пути к системе. Особенно это касается клиент-серверных приложений.

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

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

Комбинационная лотерея. Вариации ввода, которые обычно не имеют значения, могут вызвать проблему, если они скомбинированы определенным образом.

Причина 5. Другие причины связаны с тем, что ваша ментальная модель системы и того, что на нее влияет, неверна или неполна.

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

Как ловить невоспроизводимый баг?

Фотография

Здравствуйте!
Я новичок в тестировании. Долго искала себе сферу занятий. Наткнулась на профессию тестировщика ПО. Пару месяцев читала книги, блоги, смотрела вебинары. Зарегистрировалась на фиксбере и ю-тесте. И вот первая проба пера — тестирование приложения на ipad. Нашла несколько багов, копаюсь дальше. Вдруг, мимо пробегает жирнющий баг. Не опечатка там какая-нибудь, а сочный, с уничтожением данных. И тут я понимаю, что воспроизвести не получается. Сажусь, записываю все, что делала и нажимала, но, видимо, руки бежали впереди мозга в тот момент, и что-то я упустила. Есть ли какие-то способы по максимуму избегать таких ситуаций, помимо того, чтобы надавать себе по рукам, и начать сначала думать, а потом кнопочки тыкать? Сидеть под записывающей вебкамерой? Логи? (но я сунулась тут в лог крэша одного, не очень понимаю, что там написано). Буду очень благодарна за идеи!

P.S. Перечитала свое сообщение, и поняла, что неправильно назвала тему. Скорее должно быть — «Как сделать так, чтобы баги были воспроизводимы?»

Сообщение отредактировал Marvel07: 14 сентября 2013 — 08:44

#2 Лелик32

Members

235 сообщений

Отправлено 14 сентября 2013 — 11:10

Логи? (но я сунулась тут в лог крэша одного, не очень понимаю, что там написано). Буду очень благодарна за идеи!

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

Есть ли какие-то способы по максимуму избегать таких ситуаций, помимо того, чтобы надавать себе по рукам, и начать сначала думать, а потом кнопочки тыкать?

Ловить баги что это