Home

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

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

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

Автор: Scott Berkun

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

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

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

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

Автор: Scott Berkun

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

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

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

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

Автор: Любунь Роман

Когда я пришел на свою первую работу, меня в первую очередь ознакомили с тем, без чего не может обойтись ни один человек на фирме. Ею оказалась моя первая в жизни «система управления ошибками» (СУО) — Bugzilla.

• Интерфейс Bugzilla
• Жизненный цикл бага (Bug lifecycle) в Bugzilla
• Поиск в Bugzilla
• Администрирование Bugzilla
• Безопасность в Bugzilla
• Заключение о Bugzilla

Публикация компании IT-Online

Оригинальная публикация

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

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

Автор: Ольга Рябова

Целью составления отчёта об ошибке является её исправление. О том как описать ошибку, из чего состоит описание ошибки и как оно может выглядеть на примере расскажет этот материал.

Автор: Артём Ваулин

Продолжаю публикацию своих заметок, посвященных тому, какие ошибки допускают тестировщики в своей работе.

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

Такой вот каламбур получается — ошибки про ошибки :)

С первой частью материала можно познакомиться здесь.