Spolsky

Тест Джоэла

1. Пользуетесь ли вы системой контроля версий? -- да, но далеко не в полной мере
   
2. Можете ли вы собрать продукт за один шаг? -- нет, за два
   
3. Выполняете ли вы ежедневные билды? -- нет!
   
4. Используете ли вы базу данных ошибок? -- нет!!
   
5. Исправляете ли вы ошибки перед написанием нового кода? -- нет!!!
   
6. Есть ли у вас актуальный план работ? -- есть, у начальника, и он не исполняется
   
7. Есть ли у вас спецификация? -- нет!!!
   
8. Предоставлены ли вашим программистам спокойные условия для работы? -- нет!
   
9. Используете ли вы новейшее дорогое оборудование? -- нет, в общем-то
   
10. Есть ли у вас тестеры? -- нет!
    
11. Пишут ли кандидаты на работу код во время собеседования?
    
12. Проводите ли вы коридорное тестирование удобства использования программ?  

Десять рекомендаций для успешного отслеживания ошибок

1. Хороший тестер должен всегда стремиться сократить до минимума число действий, необходимых для воспроизведения ошибки. Следование этому правилу может оказать неоценимую помощь программисту, который будет искать эту ошибку.
2. Помните, что закрыть ошибку может только тот, кто её открыл. Кто угодно может решить её; но только тот, кто первым увидел ошибку, может быть уверен, что то, что он видел - исправлено.
3. Существует много способов разрешить ошибку. Программа FogBUGZ, например, позволяет сделать это следующими способами: исправлена, не подлежит исправлению, отложено, не воспроизводится, повторная, особенность дизайна.
4. Не воспроизводится - значит, что никто не смог воспроизвести ошибку. Программисты часто используют этот вердикт, если в описании ошибки опущены шаги для воспроизведения ошибки.
5. Вы должны аккуратно отслеживать версии программы. Каждая сборка программы, которая передается тестеру, должна иметь номер версии, чтобы несчастный тестер не проверял ошибку, которая и не должна быть исправлена в этой версии.
6. Если вы программист, и вам не удается сподвигнуть тестеров на использование базы данных учёта ошибок, перестаньте обращать внимание на информацию об ошибках, переданных вам в любой другой форме. Если ваш тестер присылает вам информацию об ошибке по электронной почте, отправляйте его письма обратно с короткой припиской: "пожалуйста, поместите эту информацию в базу данных. Я не имею возможности отслеживать информацию об ошибках, поданных с помощью электронной почты".
7. Если вы тестер, и у вас проблеммы с программистами, которые не используют базу данных учёта ошибок, не давайте им информацию об ошибках ни в какой другой форме. Помещайте информацию в базу данных, она сама сообщит им об этом через электронную почту.
8. Если вы программист, и некоторые из ваших коллег не используют базу данных учёта ошибок, начните назначать им ошибки через базу. В конце концов, до них дойдёт.
9. Если вы менеджер, и вам кажется, что никто не использует базу данных учёта ошибок, которую вы выбили большой кровью, начните назначать программистам новые задачи в форме ошибок. Система отслеживания ошибок также является отличным средством учёта заданий.
10. Избегайте соблазна добавить новые поля в базу данных. Примерно раз в месяц кому-нибудь в голову приходит "светлая" идея добавить к базе данных новое поле. Вам приносят самые разные мудрые идеи, например: указывать файл, в котором обнаружена ошибка; или вести учёт, в каком проценте повторов ошибка воспроизводится; вести учёт версий всех DLL, которые были запущены на компьютере, когда произошла ошибка; и так далее. Очень важно не поддаваться этим идеям. Иначе рано или поздно экран ввода информации об ошибке будет представлять собой форму с тысячью полей, которые необходимо заполнить, и никто не будет вводить эту информацию. Чтобы база данных учёта ошибок приносила толк, ее должны использовать все. И если ввод информации об ошибке будет требовать слишком больших усилий, люди найдут обходные пути.

Oписание ошибки должно содержать ровно три вещи:

1. Какие шаги привели к ошибке.
   
2. Что вы ожидали увидеть.
   
3. Что вы в самом деле увидели.

ещё хороший ресурс: http://software-testing.ru

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

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

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

Зачастую процесс разработки представляет собой полный бардак, иногда даже люди не очень ясно видят себе цель разработки. Часто пренебрегают простыми средствами организации работы. Я работала первое время без системы контроля версий, без багтракинговой системы и без документации в wiki и было мне очень плохо. Сейчас у нас это все есть.

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


В жизни каждого мало-мальски сложного программного продукта есть стадия, когда система проходит некий порог увеличения этой сложности, за которым наступает состояние, которое я называю "самостоятельной жизнью". Это еще не полный хаос, но уже давно и далеко не порядок. Все попытки как-то организовать процесс разработки программ, всяческие методологии, применение парадигмы конвейера, стандарты и административные меры худо-бедно, но помогают оттянуть этот критический порог на некоторое время. В идеале - до того момента, когда развитие системы останавливается, и она, побыв некоторое время в стабильном состоянии, потихоньку умирает. <...>
Возвращаясь к нашим "жучкам", система, с которой я начал работать уже успешно прошла свой порог еще несколько месяцев назад и жила своей полнокровной, отдельной от авторов жизнью. Определить, что критический порог пройден, несложно, для этого у меня есть один простой признак: "Ты изменил чуть-чуть программу в одном месте, но вдруг появилась ошибка в другом, причем даже автор этого самого "другого" места не может понять, в чем же дело". Существует и второй признак, не менее практичный: "Ты смотришь на чужой текст программы, и тебе непонятен смысл одной его половины, а вторую половину тебе хочется тут же полностью переписать". отсюда