Сообщений в теме: 28

[Olga]

Коллеги, поделитесь Вашими впечатлениями от анализа кода. Насколько это эффективно? Зависит ли эффективность от языка программирования, технологии, размера системы? Часто ли Вы используете анализ на практике? Какую самую серьезную проблему отловили таким образом?

[Case]

Не могли бы Вы более подробно задать вопрос, о каком анализе кода идёт речь?

Если идёт речь о процессе анализа кода на совместимость его с "конвенцией о кодировании", то есть о критических просмотрах кода, которые рекомендуют делать практически все методологии разработки и обеспечения качества, то подобные мероприятия довольно полезны. Полезность скорее не столь осязаемая как даже от обычного "ручного" тестирования, результатом которого является вполне реальный change request (запрос на изменение в программе), сколь хороший вклад в дальнейшую разработку и повышение уровня качества полуемой системы. Код, который пишется согласно правилам принятым в компании впоследствии легче поддерживается и естевственно легче даётся в изучении как разработчику, который будет принмать проект, так и тестировщику.

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

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

[Olga]

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

[Case]

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

[Olga]

Меня интересует следующие вопросы:
1) В какой ситуации Вы стали бы применять или применяли анализ кода (сквозные просмотры, инспекции)?
2) Для нахождения каких видов ошибок?
3) Стоит ли использовать такой вид тестирования при
- высокой сложности проекта
- большом объеме кода, подлежащего анализу
- если в коллективе тестеров 1-2 человека.

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

[Case]

Если человек 1-2 - то вот Вам и ответ: при большом обьёме кода - функциональности как я понимаю тоже с головой, времени на инспекции у вас просто не будет. То есть тестирование логики на уровне разбора кода не ваш метод.

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

[chuk]

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

[Case]

возникает необходимость оценить качество отдельного блока

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

[chuk]

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

А в общем, даже не могу четко сказать - просто иногда чуствуешь, что надо глянуть - это, конечно, не объяснение, но и так бывает.

[Olga]

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

А стали бы Вы проводить анализ блоков, в которых ошибки были найдены, но исправлять их по какой-либо причине не стали?

[Case]

Ольга, можно Вам комплимент сделать?
Можно? Спасибо.
У Вас настолько нестандартные вопросы - приходится перечитывать по нескольку раз :D
Чувтсвуется богатый опыт, делитесь, не стесняйтесь.

Ольга, а почему найденную ошибку не исправили? Это и такое теперь бывает?

[chuk]

В этой ситуации надо знать причину, по которой фиксинг ошибки отложен.
У нас чаще всего такое случается, когда:
- мы определили проблему системы, как ошибку, но на самом деле она возникла из-за недоработки в
спецификации требований пользователя - и тогда фиксинг ошибки переходит в дополнительный
системный анализ, изменение требований пользователя и доработку системы.
- фиксинг ошибки отложен по каким-либо организационным вопросам (нехватка времени, ресурсов и
т.д). Тогда, если ошибка имеет категорию некритичной, то переводится в состояние "отложено",
фиксируется в "Релиз Ноутс" и ждет своего решения.
- Есть очень сложные ошибки, на фиксинг которых уходит много времени. Вот с этими ошибками и
возимся, но они тоже очень специфичны. В первую очередь выясняем, почему в принципе они вылезли.
И чаще всего получается, что это глобальные ошибки при проектировании всей системы, т.к. просто
грубые ошибки кодирования вылазят уже на первом проходе при выполнении "smoke" теста и быстро
устраняются.

[Olga]

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

[chuk]

У нас система качества немного не так построена.
Програмист не может в принципе убедить Project менеджера в том, что это фича, до тех пор, пока не убедит в этом меня.
QA менеджер и Project менеждер равносильны в принятии решении, и програмист может говорить сколько угодно, что это фича, что у него все работает - честно говоря, я даже слушать это не буду.
Есть спецификация на систему, есть Assessment спецификация, и в конечном счете есть заказчик.
Выпустить неготовую систему мы не можем в принципе.
Она может быть недоделана, но ровно настолько, чтобы заказчик остался доволен.
Или суеметь убедить заказчика о переносе сроков, вариантов оплаты и т.д. - но неготовая система - "это провал" :-)))

[Case]

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

Про "у меня всё работает" - кого это интерсует? Это не работает на тестовом окружении. Вот сценарий вопроизведения ошибки. Вот что ожидается при такой последовательности действий - вот что получилось (или не получилось)

Если кто-то прибегает с криками "выпускаем" - нет вопросов. Формальный документ руководству - даже если это он и прибежал :) С пояснениями почему этого делать нельзя, и обьяснением, что дальнейшие претензии к качеству не приимаются.

Если кто-то сумел кого-то убедить в том что это фича, но этой фичи не было в тест планах выхода два:
1) менять требования, тест план, наборы скриптов и сценариев использования. Как следствие откладывать дату выпуска все действия документируются и ставится в известность тот кого переубедили и ваше непосредственное руковоство.
2) формальными методами обьяснять, что фича, которая случайно всплыла и не была запланирована и задокументирована как требование к системе есть баг.

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

[Case]

2chuk:
Поностью поддерживаю. Я просто уж больно долго писал ответ - но суть таже.
Есть PM, ниже по иерархии идут ведущий программист, постановщик и тестировщик. Мы принимаем решение втроём, если это серьёзные изменения затрагивающие дату выпуска или человеко-ресурсы - тогда РМ принимает решение более концептаульное - по принципу "делаем-не делаем" в этой версии. Он же проводит переговору с заказчиком, согласует сроки, наполнение функциональностью версии системы и так далее.
Разговоры разработчика очень интересны его непосредственному руководителю, но никак не мне или моим сотрудникам, равно как и РМ-у.

[Olga]

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

[chuk]

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

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

[Case]

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

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

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

[Guriy]

Собственно объясните мне в чем проблема?
За выпуск версии отвечает ПМ, наша задача сказать работает/не работает с достаточной аргументацией.

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

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

Правда прийдется выслушать кучу объяснений по типу "ой, а это сорцы какие-то старые",
"ай, а я метки не те/не туда проставил", и тому подобное.

Но аудит в стартиме - рулит форевер. :D