Что пишут в блогах

Подписаться

Онлайн-тренинги

 Все онлайн-курсы

Конференции

Разделы портала

Про инструменты

Лучшие вакансии

.
Управление дефектами
Отчеты об ошибках, или как просто встать на путь постоянного совершенствования
25.10.2016 11:56

Выступление Сергея Атрощенкова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA

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

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

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

Так почему бы нам не пойти по пути постоянного совершенствования в написании баг-репортов вместе? Какими путями я шел и иду к «просветленному» отчету, на что я обращал и обращаю внимание, что исправлял и исправляю в отчетах и почему — об этом и пойдет речь в моем докладе. Не стоит бояться наступать на грабли, совершенствуясь в работе. И даже когда всё кажется превосходным — посмотрите, можно ли улучшить баг-репорты?

Подробнее...
 
Результаты опроса про популярность баг-трекеров
30.08.2016 18:34

Десять дней назад мы запустили опрос про популярность баг-трекеров. Мы предложили ответить на два вопроса: “Какие системы для работы с ошибками вы используете в своей работе?” и “Почему?”

В опросе приняли участие 170 человек.

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

Чаще всего респонденты нашего опроса используют Jira, на втором месте по популярности - Redmine, а на третьем - MS TFS.

Теперь посмотрим на основные причины выбора той или иной системы.

Подробнее...
 
Заступничество, Наблюдения, Будущее
14.03.2016 14:11

Автор: Грег Готьер (Greg Gauthier)

Оригинал статьи: http://www.gmgauthier.com/advocacy-observation-and-the-future/

Перевод: Ольга Алифанова

Ученый, рассказчик, или официальный представитель?

Мне с трудом далась четвертая глава книги Джеймса Баха "Lessons Learned in Software Testing" ("В защиту багов"). Нет, она не была менее понятной или более интеллектуально насыщенной, чем первые три. Просто она полна противоречий.

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

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

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

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

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

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

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

Подробнее...
 
Природная лень, или "У меня все работает"
20.10.2015 10:57

Автор: Maaret Pyhäjärvi.

Оригинал статьи: http://visible-quality.blogspot.ru/2015/09/natural-laziness-and-it-works-on-my.html

Перевод: Ольга Алифанова.

Когда Ллевелин Фалько учит детей программировать, его "первое правило программирования" дети запоминают накрепко. Оно гласит, что программисты очень ленивые. Например, когда они хотят обратиться к некоторой функции, они не пишут её название полностью. Достаточно ввести две-три буквы, и пусть инструменты выполнят всю остальную работу за вас там, где это возможно.

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

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

Подробнее...
 
Сообщения об ошибках
04.08.2015 18:05

Автор: Майкл Болтон

Перевод: портал software-testing.ru

Оригинал статьи: http://www.developsense.com/essays/AReviewOfErrorMessages.html

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

Начальные знания о сообщениях об ошибке

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

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

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

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

При этом не стоит полагаться и на операционную систему. Удивительно, но команды DOS COPY и XCOPY до сих пор не проводят проверку на наличие свободного места на диске перед началом копирования файлов; вместо этого копирование начинается “вслепую” с надеждой на то, что места будет достаточно. Windows ничуть не лучше, эта система тоже не проверяет диск на наличие свободного места перед копированием файлов. Хуже того, если вы одновременно копируете несколько файлов, Windows прерывает процесс копирования после обнаружения первой ошибки и “забывает”, какие файлы были выделены для копирования.

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

Подробнее...
 
JIRA: dashboards и SOAP API
24.03.2014 14:56

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

Отчетность, отчетность, отчетность – разным руководителям, коллегам по цеху, субподрядчикам, заказчикам, себе, в конце концов. Как начинающему и не очень начинающему тест-менеджеру не утонуть в цифрах и отчетах и не сидеть до ночи на работе, подготавливая их каждый день? Вы сможете значительно облегчить себе жизнь, если будете грамотно использовать багтрекер. Например, в JIRA есть средства генерации dashboards и внешнее SOAP API для выполнения рутинных операций.

В данном докладе будут затронуты следующие вопросы:

  • Какие типичные отчеты готовит тест-менеджер
  • Как JIRA фильтрует тикеты
  • Как объединять фильтры в dashboards и получать из этого полезную информацию
  • Что такое JIRA SOAP API
  • Как писать скрипты для сбора статистики по тикетам
Подробнее...
 
JIRA. С добавками. Для тестировщиков
09.07.2013 15:52

Продолжаем публикацию лучших докладов SQA Days 13. Сегодня представляем доклад Кузьмича Максима (Atlassian Expert. Краб на галерах в StiltSoft) "JIRA. С добавками. Для тестировщиков".

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

Вот и при настройке JIRA все обычно делается для удобства разработчиков и менеджеров. А тестировщики-то, хоть и не последние пользователи JIRA, зачастую и не знают, что свою работу с этим issue-трэкером можно сделать более продуктивной и удобной.

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

Требуйте донастройки JIRA после её установки!

Подробнее...
 
Нет бага - нет проблем ?!
16.05.2013 14:54

Автор: Евгений Ткаченко

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

Так где же мы храним эти баги?

Джира, Багзила , Мантис, Редмайн, Берт, Трелло, Мингл, а может кто то использовал Гугл доки или Гугл таблицы для этого, думаю еще есть варианты.

Каждый из нас работает с Багтрекинг системами или когда либо работал в прошлом.

Как же мы с ними работаем?

Стандартная зарисовка из жизни:

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

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

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

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

Давайте теперь сфантазируем другую картину:

Подробнее...
 
Алексей Лянгузов: Грамотная работа с дефект-трекером
16.03.2012 10:58

Практически на каждой конференции можно услышать рассказ про то, как правильно работать с баг-трекером -- как писать сообщения о дефектах, как отслеживать их жизненный путь, какие метрики собирать и как их использовать и так далее. Одним из наиболее полезных выступлений такого рода, пожалуй, является доклад Алексея Лянгузова на прошедшей конференции SQA Days 10. К сожалению, сделанная во время конференции запись оказалась недостаточно качественной, но Алексей проявил мужество и записал свой рассказ заново, опубликовав его в виде слайдкаста, с которым мы и предлагаем вам ознакомиться:

Подробнее...
 
Тестировщики — из какого теста они слеплены и с чем их едят.
05.10.2008 19:05

Оригинальная публикация:http://www.hacknot.info/hacknot/action/showEntry?eid=68

Перевод: Баранцев Алексей, ИСП РАН

Есть реальные преимущества наличия группы людей, отделённых от разработчиков, чья работа состоит исключительно в том, чтобы придираться к вашей работе. Они сохраняют эмоциональную и мыслительную дистанцию от продукта, которую разработчик не может сымитировать даже при всём желании. Тестирование — задача, требующая терпения, внимания к деталям и весьма непрямолинейного мышления. Иногда менеджеры делают ошибку, рассматривая тестирование как работу второго сорта, которую могут выполнять менее квалифицированные или более младшие сотрудники. Такое искажённое восприятие служит плохую службу как проекту, так и сообществу тестировщиков.

Подробнее...
 



Страница 1 из 2