Лекция 1. Тестирование как часть процесса верификации программного обеспечения

МДК 01.02 Поддержка и тестирование программных модулей

https://sergeygavaga.gitbooks.io/kurs-lektsii-testirovanie-programnogo-obespecheni/content/vvedenie-v-testirovanie-zhiznennii-tsikl-produkta-metodologii-razrabotki-programmnogo-obespecheniya.html

https://topuch.ru/obespechenie-kachestva-i-testirovanie-programmnogo-obespecheni/index.html

https://ulearn.me/course/testing-2022/

Лекция №1

Тестирование как часть процесса верификации программного обеспечения

https://sergeygavaga.gitbooks.io/kurs-lektsii-testirovanie-programnogo-obespecheni/content/vvedenie-v-testirovanie-zhiznennii-tsikl-produkta-metodologii-razrabotki-programmnogo-obespecheniya.html

Лекция №1

Тестирование как часть процесса верификации программного обеспечения

https://sergeygavaga.gitbooks.io/kurs-lektsii-testirovanie-programnogo-obespecheni/content/vvedenie-v-testirovanie-zhiznennii-tsikl-produkta-metodologii-razrabotki-programmnogo-obespecheniya.html

План

• Понятие тестирования
• История развития тестирования
• Качество программного обеспечения
• Кто такой тестировщик и что он делает
• Принципы тестирования
• Верификация и валидация
• QA, QC и тестирование

Тестирование

• Тестирование программного обеспечения — процесс анализа программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта.

Этапы развития

• 50–60

Этапы развития

представьте, что ваша программа по трём введённым целым числам определяет, может ли существовать треугольник с такими длинами сторон.

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

Вы используете автоматизацию, и компьютер может провести 100 миллионов проверок в секунду. Сколько займёт проверка всех вариантов?

Этапы развития

• 50–60
• 70 гг -
• 80 гг
• 90 гг
• 2000
• Наше время

Д/з

Найти и записать краткую характеристику понятий TDD, BDD, DDT, KDT.

Качество программного обеспечения

Качество программного обеспечения

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

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

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

Модель качества программного обеспечения

Функциональность:

-функциональная исправность;

-соответствие стандартам;

Удобство использования:

-удобство изучения;

Эффективность:

-функциональная совместимость;

-эффективность по времени;

-понятность;

-безопасность;

-эффективность использования ресурсов

-удобство и простота использования.

-точность;

Надежность:

-завершенность;

-восстанавливаемость;

-устойчивость к отказам

Качество ПО

13

Модель качества программного обеспечения

Функциональность

Портативность (Portability):

Удобство использования (Usability):

(Functionality):

-удобство установки;

-удобство изучения;

-заменяемость;

функциональная исправность;

-понятность;

-совместимость.

-соответствие стандартам;

-удобство и простота использования.

-функциональная совместимость;

-безопасность;

-точность;

Качество ПО

Надежность

(Reliability):

-завершенность;

-восстанавливаемость;

-устойчивость к отказам

Удобство сопровождения (Maintainability):

-стабильность;

-анализируемость;

-контролепригодность;

-изменяемость.

Эффективность

(Efficiency):

-эффективность по времени;

-эффективность использования ресурсов

14

Кто такой̆ тестировщик и что он делает?

14

Главная цель тестировщика

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

14

технические навыки нужные, чтобы успешно начать работать тестировщиком

• Знание иностранных языков.
• Уверенное владение компьютером на уровне по-настоящему продвинутого пользователя и желание постоянно развиваться в этой области.
• Программирование.
• Базы данных и язык SQL.
• Понимание принципов работы сетей и операционных систем.
• Понимание принципов работы веб-приложений и мобильных приложений

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

Знание иностранных языков. Да, это не технический навык. Но, тем не менее, он идёт под номером «ноль». Можете считать это аксиомой: «нет знания английского — нет карьеры в IT». Другие иностранные языки тоже приветствуются, но английский первичен.

Уверенное владение компьютером на уровне по-настоящему продвинутого пользователя и желание постоянно развиваться в этой области. Можете ли Вы представить себе профессионального повара, который не может пожарить картошку (не «не обязан», а «не умеет в принципе»)? Выглядит странно? Не менее странно выглядит «IT’шник» (именно так, в кавычках), неспособный набрать вменяемо отформатированный текст, скопировать файл по сети, развернуть виртуальную машину или выполнить любое иное повседневное рутинное действие.

Программирование. Оно на порядок упрощает жизнь любому IT’шнику, а тестировщику — в первую очередь. Можно ли тестировать без знания программирования? Да, можно. Можно ли это делать по-настоящему хорошо? Нет. И сейчас самый главный (почти религиозно-философский) вопрос: какой язык программирования изучать? C/C++/C#, Java, PHP, JavaScript, Python, Ruby и т.д. — начинайте с того, на чём написан ваш проект. Если проекта пока ещё нет, начинайте с JavaScript (на текущий момент — самое универсальное решение).

Базы данных и язык SQL. Здесь от тестировщика тоже не требуется квалификация на уровне узких специалистов, но минимальные навыки работы с наиболее распространёнными СУБД и умение писать простые запросы можно считать обязательными.

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

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

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

14

личностные качества

• Повышенная ответственность и исполнительность;
• Хорошие коммуникативные навыки, способность ясно, быстро, чётко выражать свои мысли;
• Терпение, усидчивость, внимательность к деталям, наблюдательность;
• Хорошее абстрактное и аналитическое мышление;
• Способность ставить нестандартные эксперименты, склонность к исследовательской деятельности.

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

Знание иностранных языков. Да, это не технический навык. Но, тем не менее, он идёт под номером «ноль». Можете считать это аксиомой: «нет знания английского — нет карьеры в IT». Другие иностранные языки тоже приветствуются, но английский первичен.

Уверенное владение компьютером на уровне по-настоящему продвинутого пользователя и желание постоянно развиваться в этой области. Можете ли Вы представить себе профессионального повара, который не может пожарить картошку (не «не обязан», а «не умеет в принципе»)? Выглядит странно? Не менее странно выглядит «IT’шник» (именно так, в кавычках), неспособный набрать вменяемо отформатированный текст, скопировать файл по сети, развернуть виртуальную машину или выполнить любое иное повседневное рутинное действие.

Программирование. Оно на порядок упрощает жизнь любому IT’шнику, а тестировщику — в первую очередь. Можно ли тестировать без знания программирования? Да, можно. Можно ли это делать по-настоящему хорошо? Нет. И сейчас самый главный (почти религиозно-философский) вопрос: какой язык программирования изучать? C/C++/C#, Java, PHP, JavaScript, Python, Ruby и т.д. — начинайте с того, на чём написан ваш проект. Если проекта пока ещё нет, начинайте с JavaScript (на текущий момент — самое универсальное решение).

Базы данных и язык SQL. Здесь от тестировщика тоже не требуется квалификация на уровне узких специалистов, но минимальные навыки работы с наиболее распространёнными СУБД и умение писать простые запросы можно считать обязательными.

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

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

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

14

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

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

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

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

Баг существует при одновременном выполнении трех условий:

• известен ожидаемый результат;
• известен фактический результат;
• фактический результат отличается от ожидаемого результата.

14

Источники багов

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

14

Уровни возникновения дефектов

УРОВЕНЬ ТРЕБОВАНИЙ

УРОВЕНЬ ПРОЕКТИРОВАНИЯ(ДИЗАЙН)

УРОВЕНЬ КОДИРОВАНИЯ

14

Уровни возникновения дефектов

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

14

Причины появления дефектов в программном коде

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

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

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

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

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

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

14

Принципы тестирования

14

Принципы тестирования

1. Тестирование показывает наличие дефектов

2. Исчерпывающее тестирование невозможно

3. Раннее тестирование

4. Скопление дефектов

5. Парадокс пестицида

6. Тестирование зависит от контекста

7. Заблуждение об отсутствии ошибок.

И еще несколько важных принципов:

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

1. Тестирование показывает наличие дефектов

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

2. Исчерпывающее тестирование невозможно

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

3. Раннее тестирование

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

4. Скопление дефектов

Разные модули системы могут содержать разное количество дефектов, то есть плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.

5. Парадокс пестицида

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

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

6. Тестирование зависит от контекста

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

7. Заблуждение об отсутствии ошибок.

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

И еще несколько важных принципов:

тестирование должно производиться независимыми специалистами;

привлекайте лучших профессионалов;

тестируйте как позитивные, так и негативные сценарии;

не допускайте изменений в программе в процессе тестирования;

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

14

Верификация и валидация

14

Верификация и валидация

Верификация (verification) – это процесс оценки системы или её компонентов с целью определения того, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. То есть выполняются ли задачи, цели и сроки по разработке продукта.

Валидация (validation) – это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

14

Верификация и валидация

№

Верификация

1.

Валидация

Делаем ли мы продукт правильно ?

2.

Делаем ли мы правильный продукт?

Реализована ли вся функциональность?

3.

Правильно ли реализована функциональность?

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

4.

5.

Производится разработчиками

Валидация происходит после верификации и, как правило, отвечает за оценку продукта в целом.

Производится тестировщиками

Включает статический анализ – инспектирование кода, сравнение требований и т.п.

6.

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

Основывается на объективной оценке реализованных функций

Субъективный процесс, включающий личную оценку качества работы ПО

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

С помощью  верификации  Вы можете увериться в том, что продукт сделан «правильно»: придерживаясь необходимых методик, инструментов и стандартов.

На практике отличия верификации и валидации имеют большое значение:

заказчика интересует, в большей степени, валидация (удовлетворение собственных требований);

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

QA, QC и тестирование

QA, QC и тестирование

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

Контроль качества (Quality Control - QC) -  это совокупность действий, проводимых над продуктом в процессе разработки для получения информации о его актуальном состоянии в разрезах: "готовность продукта к выпуску", "соответствие зафиксированным требованиям", "соответствие заявленному уровню качества продукта".

Тестирование программного обеспечения   (Software Testing) -  это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

QA, QC и тестирование

Quality Assurance(обеспечение качества)

Quality Control(Контроль качества)

Комплекс мероприятий, который охватывает все технологические аспекты на всех этапах разработки, выпуска и введения в эксплуатацию программных систем для обеспечения необходимого уровня качества программного продукта

Фокус в большей степени на процессы и средства, чем на непосредственно исполнение тестирования системы

Тестирование

Процесс контроля соответствия разрабатываемой системы предъявляемым к ней требованиям

Фокус на исполнение тестирования путем выполнения программы с целью определения дефектов с использованием утвержденных процессов и средств

Процессно-ориентированный

Процесс, отвечающий непосредственно за составление и прохождение тест-кейсов, нахождение и локализацию дефектов и т.д.

Фокус на исполнение тестирования как такового

подход

Продуктно-ориентированный

Превентивные меры

Подмножество процессов Software Test Life Cycle - цикла тестирования ПО

Корректирующий процесс

Продуктно-

подход

ориентированный подход

Превентивный процесс

Подмножество процессов QA

Подмножество процессов QC

QA, QC и тестирование

Тестирование – часть QC.

QC – часть QA.

QA

QC

Тестирование

Иными словами, Quality Assurance обеспечивает правильность и предсказуемость процесса, в то время как Quality Control предполагает контроль соблюдения требований. Тестирование же, в свою очередь, обеспечивает сбор статистических данных и внесение их в документы, созданные в рамках QC-процесса.

Если провести аналогию с процессом конструирования, скажем, велосипеда, то получим такую картину:

С помощью тестирования мы можем определить, работают ли все детали и сам велосипед в целом так, как мы ожидаем. Из правильных ли материалов он сделан, с применением нужных методик и инструментов или нет. То есть подразумевается, что тестируемый объект уже существует.

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

32