Архив за Декабрь, 2010

Борьба с жучиными гнездами

Среда, Декабрь 8th, 2010

… В этом коде не просто живут баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при помощи любимой китайской технологии реиспользования кода - copy/paste. Отсюда баги расползаются в разные стороны посредством статических переменных и переменных, переданных по ссылке ...

Из года в год на форуме тестировщиков задается примерно один и тот же вопрос: “Тестирую один и тот же кусок уже в двадцатый раз, и конца края тестированию не видно. Что делать? Помогите!”
Вот один из последних примеров:

Но увы… первое же тестирование выявило ошибки: каждый мой тест-кейс закончился неудачей.
Разработчик исправлял свои ошибки 2 дня. При этом он “протестировал” сам…
Наступило второе тестирование. Результат ничем не отличался от первого - столько же ошибок (старых и новых).
И теперь решили, что разработчик исправляет найденные ошибки прямо в тесте. Но вот беда: если он исправляет что-то в одном месте, то парочка ошибок возникает в других местах функционала.
Я уже не помню, что работает, а что нет.
Складывается впечатление, что мы собираем конструктор. Причем после каждой сборки постоянно несколько деталей остаются лишними, а некоторые прикручены совсем не в тех местах.
Я уже не верю, что когда-нибудь функционал заработает
.

Пришла пора вынести этот вопрос в ЧаВо.

Надо сказать, что подобный ход событий я наблюдал неоднократно. Примеры из моей практики.
Случай А. Код пишется, отдается на тестирование, в ходе тестирования признается негодным и возвращается на доработку. И так по циклу много - много раз. Очень много.
В какой то момент отладку остановили. Затем последовательно выявили и исправили дефект в архитектуре, а затем дефект в требованиях. После этого код был приведен в норму бостаточно быстро.

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

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

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

Паттерн: “Дефекты нужно править до написания кода, а не после него”. По статистике Макконнелла 30% багов вносится в продукт на этапе создания спецификаций требований. И 25% на этапе проектирования. И зачем эти баги в код тащить?

Антипаттерн: “Автоматизация тестирования”. Имеется ввиду автоматизация через GUI после того как исполняемый код отдан в тестирование. Денег и времени сьест море, а польза очень сомнительна.Скорее, это просто выкидывание денег плюс поднятие ЧСВ у человека, который будет внедрять автоматизацию.

Вопросы кросфункциональному специалисту

Четверг, Декабрь 2nd, 2010

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

Scope. На собеседовании такие вопросы задавать вряд ли стоит, а вот как завязка семинара, тренинга или круглого стола вполне может подойти.

Glossary. Максима — правило поведения или основной принцип, которым человек руководствуется в своих поступках.

Main.

1.
Task condition. Запрет на прямое обращение доступа к БД из кода и предоставление такового доступа через хранимые процедуры позволяет улучшить качество продукта по нескольким критериям. И по некоторым ухудшить.

Question. Перечислите эти критерии. Предпочтительно в классификации ГОСТ 9126 (”Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению”). Дополнительно приведите примеры  для которых такое правило имеет смысл вводить и примеры, для которых это будет вредно. Идеально, если эти примеры будут для одной и той же системы в один и тот же период времени.

Scope. Вопрос на одновременное знание в следующих областей: архитектура приложений, управление качеством, управление процессами.
2.
Task condition. При проектировании распределенной системы часто отказываются от автоинкрементальных идентификаторов в пользу GUID. Такое изменение ухудшает такой критерий качеста продукта как тестируемость. Последующий переход к темпоральной модели БД возвращает этот критерий на прежний уровень.

Question. О каком виде тестирования идет речь? За счет чего происходит улучшение и ухудшение?

Scope. Вопрос на одновременное знание в следующих областей: проектирование БД, тестирование, управление качеством.
3.
Task condition. При сопровождении сложных систем часто вводят максиму: “Код помещаемый в репозиторий должен содержать ссылку на запрос на изменение (баг, фича,…), зафиксированный в трекинговой системе. Код без такой ссылки не может быть выложен в репозиторий кода. Если изменения в коде посили характер рефакторинга и явного запроса на изменение в трекинговой системе не было, то перед выкладкой кода необходимо создать такую запись.”

Question. Вышеприведенная максима является подмножеством более общей максимы иногда применяемой при управлении проектами. Попробуйте сформулировать эту максиму.

Scope. Этот вопрос относится скорее к управлению проектами. Но при этом предполагается неплохое знание кодирования.