 Саймон Тэтхем, профессиональный программист и разработчик свободного ПО
Любой, кто написал программу для публичного использования, получил, по крайней мере, одно плохое сообщение об ошибке. Сообщения, которые не говорили ни о чем («Это не работает»); сообщения, которые не имели смысла; сообщения, которые не давали достаточной информации; сообщения, которые давали неправильную информацию. Сообщения о проблемах, которые оборачивались ошибками пользователя; сообщения о проблемах, которые оборачивались дефектом в чьей-то другой программе; сообщения о проблемах, которые оборачивались сбоями сети.
Существует причина, по которой техническую поддержку считают работой, которой отвратительно заниматься, и эта причина — плохие сообщения об ошибках. Однако не все сообщения об ошибках такие отталкивающие: я поддерживаю свободное ПО, когда не зарабатываю на жизнь и иногда я получаю удивительные, ясные информативные сообщения.
 Автор: Вячеслав Дукальский
Для фиксирования багов во многих организациях приняты различные CTS (Change Tracking Systems). Все эти системы могут отличаться исполнением, дизайном, возможностями, но всегда будет то общее, сама суть, что их объединяет — наличие сообщения о найденной ошибке.
Первое, что должно быть создано после запуска трекинг-системы (или проекта в ней), это создание шаблона сообщения (кейса). Наличие продуманного шаблона, учитывающего все возможные повторяющиеся сведения один из основных принципов успешной эксплуатации подобной системы.
 Оригинальная публикация:http://www.hacknot.info/hacknot/action/showEntry?eid=68
Перевод: Баранцев Алексей, ИСП РАН
Есть реальные преимущества наличия группы людей, отделённых от разработчиков, чья работа состоит исключительно в том, чтобы придираться к вашей работе. Они сохраняют эмоциональную и мыслительную дистанцию от продукта, которую разработчик не может сымитировать даже при всём желании. Тестирование — задача, требующая терпения, внимания к деталям и весьма непрямолинейного мышления. Иногда менеджеры делают ошибку, рассматривая тестирование как работу второго сорта, которую могут выполнять менее квалифицированные или более младшие сотрудники. Такое искажённое восприятие служит плохую службу как проекту, так и сообществу тестировщиков.
 Автор: Scott Berkun
Перевод: Андрей Олищук
Материал публикуется при согласии редакции электронного журнала для веб разработчиков PHP Inside.
Статья переведена с разрешения ONLamp.com
В работе с ошибками есть одно золотое правило: исправлять ошибки нужно в том порядке, который вероятнее всего приближает к успеху. Звучит банально, не правда ли? Неправда. Могу поспорить, что свыше половины «глючных» и ненадёжных программ, которые вам приходилось использовать, были такими не потому, что разработчикам не хватило времени сделать их лучше. Просто они исправляли не те ошибки. Желание исправить «нужные» ошибки и знание того, каким образом это сделать, — две разные вещи.
Автор: Scott Berkun
Перевод: Андрей Олищук
Материал публикуется при согласии редакции электронного журнала для веб разработчиков PHP Inside.
Статья переведена с разрешения ONLamp.com
Легко определить когда кончаются шоколадные печенья или лазанья — их просто не остается на тарелке. Но более сложные вещи, такие как программное обеспечение, не так прозрачны (и не так вкусны). Вы должны заранее запланировать те критерии, по которым вы определите, что работа завершена. Если вы не сделаете этого, то потратите дополнительные часы на споры о том, все ли сделано, и на лишний кодинг. Если у вас достаточно трезвого ума, и вы заранее определите критерии выхода, то ваша команда израсходует время на достижение цели, а не на споры.
 Автор: Любунь Роман
Когда я пришел на свою первую работу, меня в первую очередь ознакомили с тем, без чего не может обойтись ни один человек на фирме. Ею оказалась моя первая в жизни «система управления ошибками» (СУО) — Bugzilla.
- Интерфейс Bugzilla
- Жизненный цикл бага (Bug lifecycle) в Bugzilla
- Поиск в Bugzilla
- Администрирование Bugzilla
- Безопасность в Bugzilla
- Заключение о Bugzilla
Публикация компании IT-Online
Оригинальная публикация
Тестирование небольших Интернет-проектов может провести сотрудник, не обладающий большим опытом тестирования, например, руководитель проекта. В этом случае необязательно использовать профессиональные системы фиксации и отслеживания проблем. Приводимая в статье форма позволяет наладить адекватный процесс фикcации результатов тестирования для небольших проектов.
Разработайте формализованную систему для регистрации и исправления ошибок. Вы можете регистрировать ошибки и изменения в базе данных (для больших проектов), или пользоваться простыми контрольными списками необходимых изменений. Независимо от того, как вы это делаете, вы должны регистрировать изменения. Почему это необходимо?
Автор: Ольга Рябова
Целью составления отчёта об ошибке является её исправление. О том как описать ошибку, из чего состоит описание ошибки и как оно может выглядеть на примере расскажет этот материал.
 Автор: Артём Ваулин
Продолжаю публикацию своих заметок, посвященных тому, какие ошибки допускают тестировщики в своей работе.
Вторая часть материала посвящена, на мой взгляд, одному из самых важных аспектов процесса тестирования — управлению ошибками. А именно, тем проблемам, которые с этим самым управлением связаны.
Такой вот каламбур получается — ошибки про ошибки :)
С первой частью материала можно познакомиться здесь.
|
