какие дефекты учитываются в базовых требованиях программирование

Откуда берутся ошибки в ПО?

Почему бывает так, что программы работают неправильно? Все очень просто – они создаются и используются людьми. Если пользователь допустит ошибку, то это может привести к проблеме в работе программы – она используется неправильно, значит, может повести себя не так, как ожидалось.

Ошибка (error) – это действие человека, которое порождает неправильный результат.

Однако программы разрабатываются и создаются людьми, которые также могут допускать (и допускают) ошибки. Это значит, что недостатки есть и в самом программном обеспечении. Они называются дефектами или багами (оба обозначения равносильны). Здесь важно помнить, что программное обеспечение – нечто большее, чем просто код.

Дефект, Баг (Defect, Bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности. Дефект, обнаруженный во время исполнения программы, может вызвать отказ отдельного компонента или всей системы.

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

Сбой (failure) – несоответствие фактического результата (actual result) работы компонента или системы ожидаемому результату (expected result).

Сбой в работе программы может являться индикатором наличия в ней дефекта.

Таким образом, баг существует при одновременном выполнении трех условий:

Важно понимать, что не все баги становятся причиной сбоев – некоторые из них могут никак себя не проявлять и оставаться незамеченными (или проявляться только при очень специфических обстоятельствах).

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

Всего существует несколько источников дефектов и, соответственно, сбоев:

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

Качество (Quality) – степень, в которой совокупность присущих характеристик соответствует требованиям.

Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, отражающих его способность удовлетворять установленные и предполагаемые потребности.

Требование (Requirement) – потребность или ожидание, которое установлено. Обычно предполагается или является обязательным.

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

Во втором случае ошибки были допущены уже при кодировании, что привело к появлению дефектов в готовом продукте. Но на этом уровне баги достаточно легко обнаружить и исправить, поскольку мы видим несоответствие требованиям.

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

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

Условно можно выделить пять причин появления дефектов в программном коде.

Источник

Стиль ведения дефектов

Предисловие

Участвуя в разработке программного обеспечения, видел, что при написании кода программисты обычно задают стандарт оформления кода (codestyle) — следование определённым практикам, призванным улучшить жизнь программистов. Моя роль в разработке программного обеспечения заключалась в тестировании. В качестве одной из своих обязанностей, как тестировщик, я видел производство информации о качестве программного обеспечения. В качестве одной из классификаций, эту информацию можно было поделить на позитивную и негативную. Позитивная информация обычно заключалась в том, что ожидаемое поведение совпадало с действительным, и результаты тестирования можно было предоставить в виде данных в отчете о тестировании (фича 1- работает, сценарий 2 – работает, и т.д.). А вот негативная информация чаще всего производилась и оформлялась в виде дефектов. (конечно же, бывали и другие рабочие элементы, такие, как риски, запросы на изменение, и др.)

Встречал внутри проектов ведение базы знаний (не только дефектов), ориентированное на то, чтоб его «раз-раз и в продакшн». Прямо как у дорожных рабочих – сдать объект, а потом будь что будет.

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

Обычно дефект включает в себя:

1. Название
2. Критичность
3. Описание: Информация о стенде, шагах воспроизведения, фактическом и ожидаемом результате.

В зависимости от багтрекиговой системы могут быть и другие поля.

О том, из чего состоит дефект и и базовых правилах оформления, таких, как задавать наименование дефекта, отвечающее на вопросы «Что, где, когда?» на просторах интернета и в том числе на самом хабре встречал много статей. Здесь хочу поделиться опытом, полученным собственноручно.

1. Название должно отражать суть проявления дефекта на прикладном уровне

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

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

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

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

Когда проект маленький и вы являетесь единственным тестировщиком (возможно, сочетая и другие обязанности, например, программиста), дефекты можно оформлять как заблагорассудится. Но когда вы работаете в команде – требуется иной подход. Когда живете один в доме — можно не мыть посуду, не укладывать вещи на свои места и т.д. А когда живете в большой семье – стоит относиться с уважением к тому, что другие члены семьи захотят видеть чистоту и порядок.

Касаемо стенда:

Стоит учитывать, что изредка дефекты исправляются в условиях жесткого дедлайна, когда множество людей с нетерпением жаждет их исправления или перепроверки, каждая минута идет на счет золота — и стоит сделать так, чтоб время не утекало впустую из-за небрежного оформления.

3. Описание дефекта не должно содержать не относящейся к нему информации

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

4. Описание дефекта должно содержать достаточное для воспроизведения количество информации

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

Следует учитывать, что члены команды в проекте периодически меняются. По моим наблюдениям люди работают над одним и тем же проектом, не меняя его и не переключаясь на другие, порядка 2-х лет. Следует учитывать эффект грузовичка. Еще бывает так, что в компании несколько тестировщиков, и стоит предусмотреть, чтоб при уходе в отпуск другие тестировщики могли перепроверить этот дефект.

5. Базу дефектов в багтрекере стоит вести с расчетом на перспективу

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

Стоит учитывать, что даже после закрытия дефекта он может кому-то понадобиться. Ориентировочная цифра перспективы– 2 года.(ориентировочный расчет).

Например, когда рабочие меняют окна в подъезде, бывает так, что они экономят время и усилия на выносе мусора. Вроде мусор проходу не препятствует, жители спокойно ходят. И ресурсы сэкономлены. НО: через некоторое время наступает момент, когда мусор начинает мешать. А если случится пожар (релиз или еще какое мероприятие), то начинаются неприятности.

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

Много раз замечал, что тестировщики при описании дефекта ориентируются на то, что он будет исправлен командой в тот же день. Примерно с 80% дефектов так и происходит –они исправляются на ходу и становятся мало кому нужны. Но вот порядка 20% дефектов продолжают существовать, причем порядка половины оставшихся — в течение достаточно большого промежутка времени. За это время состав команды, работающей над продуктом, претерпевает изменения. И когда новые члены команды начинают работать, то разбор и воспроизведение существующих дефектов начинает занимать очень много времени. На актуализацию каждого дефекта без адекватного описания, даже зная продукт на уровне документации, может уходить уйма времени.

Приведу грубый расчет. Помню, что за 8-часовой рабочий день мне удавалось актуализировать около 5 дефектов без описания. Если бы тестировщики при заведении дефектов тратили дополнительно по 5 минут на каждый заведенный дефект, делая описание подробнее, то на заведение 100 дефектов ушло бы дополнительно 500 минут = порядка 1 рабочего дня. Из этих 100 дефектов порядка 20 останутся незакрытыми в течение достаточно большого количества времени. На их актуализацию при расчете 5 дефектов/день может уйти порядка 4 рабочих дней.

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

Когда над проектом работает 1-2 программиста, обычно каждый полностью знает весь функционал. Но когда над проектом работает, скажем, 10 программистов – то каждый хорошо знает лишь тот функционал, в который он вносил изменения. И не стоит заставлять программистов изучать поведение незнакомого для них функционала. У них с лихвой достаточно задач по реализации нового функционала.

7. По мере получения информации о дефекте стоит актуализировать шаги воспроизведения

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

8. Если к дефекту требуется прикрепить много файлов, то перед этим удобно задавать им имена, начинающиеся с цифр

Впоследствии, при обсуждении, вложения могут добавляться, их количество может вырастать до десятков. Удобно оперировать указанием на вложения, например: на скриншоте 15… использовать скрипт из вложения 7… см. сообщение в логе архива 25.

9. Стоит отмечать в описании дефекта информацию о частичных исправлениях

Если в одном дефекте собрана информация о нескольких схожих ошибках, например, в описании присутствует:

Ошибка выводится в браузерах:

1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari

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

1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari

10. В компании стоит определиться со стандартом критичности дефектов

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

11. Дефекты следует заводить как можно быстрее

Своевременность заведения дефектов – немаловажное дело. Чем быстрее они будут заведены – тем скорее и лучше будут исправлены. И тем меньше вероятность пропустить что-то критичное в продакшн. После просмотра заведенного дефекта другими участниками команды может выявиться, что критичность выше, чем кажется на первый взгляд.

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

12. Не следует игнорировать мелкие дефекты, стоит оформлять их в багтрекере

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

Когда продукт маленький – мелкие дефекты не очень сильно заметны. Но когда продукт становится большим — сценарии более емкими – наличие мелких дефектов начинает донимать.
Можно привести такую аналогию: представим небольшой населенный пункт, например, деревню из двух улиц, на перекрестке которых одна маленькая ямка с грязью. Вроде на каждом (единственном) перекрестке яма, но передвигаться по деревне легко, просто объезжая всякий раз эту яму. И она мало кому мешает. Проходит время. Населенный пункт увеличивается до города-милионника. На каждом перекрестке по ямке с грязью. Если ездить по такому городу на работу через часть-города – то передвигаться, объезжая по одной ямке на каждом перекрестке, станет уже далеко не так комфортно. И возникнет большое желание перебраться в другой город или переизбрать администрацию города. Аналогично с программными продуктами – следует способствовать тому, чтоб у пользователей было желание в них работать, вместо желания удалять.

13. Если дефект был заведен кем-то помимо тестировщика, то при необходимости стоит его подкорректировать

Другие члены команды тоже заводят дефекты. И они вовсе не обязаны быть знакомы с деятельностью тестировщика, у них может быть дополна своих дел. База дефектов – одно из владений тестировщика, подобно тому, как система хранения кода – владения программистов.
Если вы, будучи тестировщиком, видите, что дефект на ваш продукт заведен не совсем корректно, то стоит подкорректировать его. Подобно тому, как стоит поддерживать порядок у себя в доме, складывая вещи на свои места, если гости поставили что-то не туда.

Источник

Контроль уязвимостей в программных приложениях

Дефекты программного кода

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

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

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

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

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

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

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

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

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

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

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

Откуда берутся дефекты в программном коде?

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

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

Другой причиной появления ошибок и уязвимостей является сложность технологий, использующихся в современной ИТ-индустрии.

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

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

Можно ли контролировать наличие дефектов в программном коде?

На сегодняшний день на рынке представлено несколько инструментальных систем анализа кода, как статического (по исходному коду методом «белого ящика»), так и динамического (без исходного кода методом «черного ящика»). Помимо этого, ведущие инструментальные системы анализа кода от таких производителей, как HP и IBM, предлагают комбинированный статический и динамический анализ, который позволяет отображать результаты динамического анализа на исходный код. Можно сказать, что в настоящее время наиболее эффективным инструментальным средством анализа кода, которое предлагает статический, динамический, а также гибридный анализ в сочетании с удобным интерфейсом и хорошей библиотекой правил поиска уязвимостей, является инструментальное средство HP Fortify.

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

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

Источник