Повышение качества разработки ПО

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

Стоит отметить, что доклады нам читали, можно так сказать, звезды мирового масштаба: Рекс Блек, Чарлз Стерлин, Александр Ложечкин, Дмитрий Андреев, Владимир Гусаров, Шай Райтен и многие другие специалисты в этой области.

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

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

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

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

Ну, это маленькое отступление перед началом моего повествования о самой конференции.

Рекс Блек

И начну я с начала.
Первым перед нами выступал гуру в мире тестирования – Рекс Блек.
Основной темой его доклада стал вопрос о том насколько важно своевременно проводить тестирование на всех этапах разработки ПО.

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

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

Управление процессом тестирования должно проводиться экспертами.  Только эксперт может выделить избыточное тестирование, тем самым сэкономив время и деньги компании.

Создание программного продукта можно разделить на несколько этапов:

1.       Составление спецификации: подробное описание того, что должен делать программный продукт и как он должен работать, в последствии сократит время на переработку ПО, тем самым сократит время и уменьшит затраты на разработку.
2.       Этап разработки программного продукта. Этот этап должен обязательно сопровождаться параллельным созданием UnitTest и проведением тестирования самими разработчиками. Это позволит создать стандартные тесты и проверить часто используемые куски кода автоматически.
3.       Тестирование компонентов системы. Оно проводиться тестировщиками. Они проверяют правильность работы каждого компонента в соответствии с разработанным ТЗ.
4.       Тестирование системы. Проводиться полное тестирование системы.
5.       Выход релизной версии. К сожалению, по статистики большее количество багов системы вылезает как раз на этапе публикации ПО и массового использования.

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

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

 

Для системы тестов выведена следующая формула:

, где UAT defect(User Acceptance Test) – тестирование продукта пользователями.

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

Ниже приведена таблица процента выделения багов на каждом этапе создания ПО:

№	Этапы	% выявления дефектов (начинающий тестировщик- профессионал)
1	Анализ требования	65%
2	Анализ разработки	65%
3	Анализ кода	60%
4	Unit Test	10-25-50%
5	Профессиональное тестирование	70-90-99%

 

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

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

И несколько советов от Рекса Блека:
1.       Необходимо выделить этапы, на которых наиболее часто появляются баги.
2.       Определить отношение ошибок, которые являются известными к неизвестным.
3.       Привлечение квалифицированных тестировщиков.
4.       Использование комплексного подхода.