Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Саймон Тэтхем, профессиональный программист и разработчик свободного ПО

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

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

Автор: Вячеслав Дукальский

Для фиксирования багов во многих организациях приняты различные CTS (Change Tracking Systems). Все эти системы могут отличаться исполнением, дизайном, возможностями, но всегда будет то общее, сама суть, что их объединяет — наличие сообщения о найденной ошибке.

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

Автор: Scott Berkun

Перевод: Андрей Олищук

Материал публикуется при согласии редакции электронного журнала для веб разработчиков PHP Inside.

Статья переведена с разрешения ONLamp.com

В работе с ошибками есть одно золотое правило: исправлять ошибки нужно в том порядке, который вероятнее всего приближает к успеху. Звучит банально, не правда ли? Неправда. Могу поспорить, что свыше половины «глючных» и ненадёжных программ, которые вам приходилось использовать, были такими не потому, что разработчикам не хватило времени сделать их лучше. Просто они исправляли не те ошибки. Желание исправить «нужные» ошибки и знание того, каким образом это сделать, — две разные вещи.