Тестирование программного обеспечения. История и основные понятия

Содержание

Слайд 2

Немного истории…

Немного истории…

Слайд 3

60-е годы. 60-е годы – «исчерпывающее тестирование» 20 вложенных операторов if => 1’048’576 ветвей выполнения НЕВОЗМОЖНО

60-е годы.

60-е годы – «исчерпывающее тестирование»

20 вложенных операторов if =>
1’048’576 ветвей

выполнения

НЕВОЗМОЖНО

Слайд 4

70…80-е годы. 70-е годы – «поиск дефектов» 80-е годы – «предупреждение

70…80-е годы.

70-е годы – «поиск дефектов»

80-е годы – «предупреждение дефектов»

НЕЭФФЕКТИВНО

Почему?

Какие методы

предупреждения дефектов Вы знаете?
Слайд 5

60-е годы – «программа работает» 70-е годы – «программа НЕ работает» VS

60-е годы – «программа
работает»

70-е годы – «программа
НЕ работает»

VS

Слайд 6

80-е годы – «предупреждение дефектов»

80-е годы – «предупреждение дефектов»

Слайд 7

80-е годы – «предупреждение дефектов» ЭТО СРАБОТАЛО

80-е годы – «предупреждение дефектов»

ЭТО СРАБОТАЛО

Слайд 8

90-е годы – «обеспечение качества»

90-е годы – «обеспечение качества»

Слайд 9

0-е ☺ годы – «тотальное обеспечение качества»

0-е ☺ годы – «тотальное обеспечение качества»

Слайд 10

Современный этап – «гибкие методологии, тесная интеграция с разработкой, автоматизация» Кстати, о методологиях...

Современный этап – «гибкие методологии, тесная интеграция с разработкой, автоматизация»

Кстати, о

методологиях...
Слайд 11

Классические методологии и модели разработки ПО: водопадная, итерационная...

Классические методологии и модели разработки ПО: водопадная, итерационная...

Слайд 12

http://msdn.microsoft.com/ru-ru/library/ee909663.aspx Каскадный процесс

http://msdn.microsoft.com/ru-ru/library/ee909663.aspx

Каскадный процесс

Слайд 13

Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном

Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном

курорте The Lodge at Snowbird в горах Юты.
Манифест подписали представители следующих методологий:
Extreme programming
Scrum
DSDM
Adaptive Software Development
Crystal Clear
Feature-Driven Development
Pragmatic Programming.

Содержит 4 основные идеи и 12 принципов.
Не содержит практических советов!

Слайд 14

Идеи: Личности и их взаимодействия важнее, чем процессы и инструменты; Работающее

Идеи:
Личности и их взаимодействия важнее, чем процессы и инструменты;
Работающее программное обеспечение

важнее, чем полная документация;
Сотрудничество с заказчиком важнее, чем контрактные обязательства;
Реакция на изменения важнее, чем следование плану.
Принципы:
удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;
приветствие изменений требований, даже в конце разработки;
частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчик <-> разработчики;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор;
работающее ПО — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
постоянное внимание на улучшение технического мастерства и удобный дизайн;
простота — искусство НЕ делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам.
Слайд 15

Гибкие методологии и модели разработки ПО: Agile, Scrum... и множество других.

Гибкие методологии и модели разработки ПО: Agile, Scrum... и множество других.

Слайд 16

Важность тестирования

Важность тестирования

Слайд 17

Тестирование приобрело особую важность в силу нескольких причин… Каких?

Тестирование приобрело особую важность в силу нескольких причин…

Каких?

Слайд 18

Бизнес: «пользователи склонны пользоваться качественными продуктами (даже если они дороже)»

Бизнес: «пользователи склонны пользоваться качественными продуктами (даже если они дороже)»

Слайд 19

Пользователи: «лучше не рисковать личными данными, деньгами и т.п.»

Пользователи: «лучше не рисковать личными данными, деньгами и т.п.»

Слайд 20

Слайд 21

Все: «мы не хотим рисковать»

Все: «мы не хотим рисковать»

Слайд 22

Наконец, тестирование – это… относительно новая; стремительно развивающаяся; интересная; находящаяся на

Наконец, тестирование – это…
относительно новая;
стремительно развивающаяся;
интересная;
находящаяся на

границе многих смежных дисциплин;
… область информационных технологий.
Слайд 23

Brainstorming Как вы думате, что делает тестировщик?

Brainstorming Как вы думате, что делает тестировщик?

Слайд 24

Чем занимается тестировщик? Контроль качества Обеспечение качества («профилактика» и «здоровый образ

Чем занимается тестировщик?

Контроль качества

Обеспечение качества («профилактика» и «здоровый образ жизни»)

Качество продукта,

и в частности тестирование, влияют на конечный результат – удовлетворенность заказчика.
Слайд 25

Фактически, «тестирование ПО» – это «диагностика» и «помощь в лечении» программного

Фактически, «тестирование ПО» – это «диагностика» и «помощь в лечении» программного

средства как такового и всего проекта в целом.
Слайд 26

Brainstorming Как вы думаете, а что хороший тестировщик должен знать?

Brainstorming Как вы думаете, а что хороший тестировщик должен знать?

Слайд 27

Знание иностранных языков. Технические навыки: Программирование: C/C++/C#, Java, PHP, Object Pascal,

Знание иностранных языков.
Технические навыки:
Программирование: C/C++/C#, Java, PHP, Object Pascal, Visual

Basic, JavaScript, HTML, .NET.
Администрирование СУБД: Oracle, MS SQL, MySQL.
Администрирование ОС: Windows, Sun Solaris, HP-UX, Free-BSD, Linux.
Сетевое администрирование: TCP/IP, IPX/SPX, NetBIOS.
Автоматизированное тестирование: Silk*, Rational*, Mercury Interactive *, JUnit, HTTP/HTML-Unit.

Первоначально важно хотя бы "Умение излагать мысли и замечания на родном языке для тестировщиков", а потом уже "Английский для тестировщиков" !

Слайд 28

Тестировщику приходится выполнять ответственную работу и много общаться. Каким он для этого должен быть?

Тестировщику приходится выполнять ответственную работу и много общаться.

Каким он для этого

должен быть?
Слайд 29

Brainstorming А какими психологическими навыками и особенностями должен обладать тестировщик?

Brainstorming А какими психологическими навыками и особенностями должен обладать тестировщик?

Слайд 30

Психологические навыки и особенности тестировщика таковы: Повышенная ответственность. Хорошие коммуникативные навыки.

Психологические навыки и особенности тестировщика таковы:
Повышенная ответственность.
Хорошие коммуникативные навыки.

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

Тестировщик – полноправный участник проекта, но… … какое место он занимает в команде? Кто он?

Тестировщик – полноправный участник проекта, но…

… какое место он занимает в

команде? Кто он?
Слайд 32

Не принципиально, как называется ваш труд и с кем вы сидите

Не принципиально, как называется ваш труд и с кем вы сидите

в одной комнате. Главное – сотрудничество, направленное на достижение общей цели!
Слайд 33

Слайд 34

Поговорим о терминологии

Поговорим о терминологии

Слайд 35

Тестирование программного обеспечения (software testing) – процесс анализа программного средства и

Тестирование программного обеспечения (software testing) – процесс анализа программного средства и

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

выявления дефектов и повышения качества продукта.

Слайд 36

Дефект (баг, глюк; defect, bug) – любое несоответствие фактического и ожидаемого

Дефект (баг, глюк; defect, bug) – любое несоответствие фактического и ожидаемого

результата (согласно требованиям или здравому смыслу).

А что мы сразу же легко определяем как дефект в любой программе, даже никогда не видев требований к ней?

Слайд 37

Ожидаемый результат (expected result) – такое поведение программного средства, которое мы

Ожидаемый результат (expected result) – такое поведение программного средства, которое мы

ожидаем в ответ на наши действия.

Откуда (как) мы можем узнать, что наши ожидания логичны и верны?

Слайд 38

Чек-лист (check-list) – набор идей тестов. Почему мы не сразу приступаем

Чек-лист (check-list) – набор идей тестов.

Почему мы не сразу приступаем к

разработке тестов?

Приведите пример чек-листа из Вашей жизни

Слайд 39

Тест-кейс (test case) – набор входных данных, условий выполнения и ожидаемых

Тест-кейс (test case) – набор входных данных, условий выполнения и ожидаемых

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

Что случится, если у нас не будет:
а) входных данных;
б) условий выполнения;
в) ожидаемых результатов;
г) цели.

Слайд 40

Тестовый сценарий, тест-сьют (test scenario, test-suite) – набор тест-кейсов, собранных в

Тестовый сценарий, тест-сьют (test scenario, test-suite) – набор тест-кейсов, собранных в

группу (последовательность) для достижения некоторой цели.

И снова: а в жизни бывают примеры тест-сьютов?

Слайд 41

Тест-план (test plan) – часть проектной документации, описывающая и регламентирующая процесс

Тест-план (test plan) – часть проектной документации, описывающая и регламентирующая процесс

тестирования.

Что, на ваш взгляд, нужно отразить в таком плане?

Может быть, кто-то приведёт пример похожего плана из жизни?

Слайд 42

Определение теста и тестового набора Тестовый набор – практические соображения: После

Определение теста и тестового набора

Тестовый набор – практические соображения:
После объединения тестов

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

Почему?

Почему?

Слайд 43

Билд («сборка») (build) – промежуточная версия программного средства (финальный билд часто

Билд («сборка») (build) – промежуточная версия программного средства (финальный билд часто

называют релизом (release)).

Можем назвать пример билдов в повседневной жизни?

Слайд 44

Качество (quality) Качество (quality) – показатель степени соответствия продукта его требованиям.

Качество (quality)

Качество (quality) – показатель степени соответствия продукта его требованиям.

Как мы

в повседневной жизни определяем, что какая-то вещь, какая-то работа и т.д. могут быть названы «качественными», например – обувь?
Слайд 45

Качество продукта определяется качеством процесса его разработки Некоторые рассуждения о качестве:

Качество продукта определяется качеством процесса его разработки

Некоторые рассуждения о качестве:
Если

заказчик доволен продуктом – продукт качественный.
Если продукт соответствует требованиям – продукт качественный.
У качественного продукта всегда есть преимущества и нет серьёзных недостатков

Заказчик должен быть отсатисфачен!

Слайд 46

Как посчитать? Оговорить критерии Выяснить, какие показатели будут критичны Заказчику или

Как посчитать?

Оговорить критерии
Выяснить, какие показатели будут критичны Заказчику или Компании

Как они

называются?

Выпуск хорошего продукта это цель не только тестировщика, а всех вместе взятых!

Слайд 47

Метрики качества (quality metrics) Метрика качества (quality metric) – числовое значение

Метрики качества (quality metrics)

Метрика качества (quality metric) – числовое значение некоторого

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

Сделайте мне удобный интерфейс …

Слайд 48

Варианты метрик Покрытие требований тестами – не менее 80% Плотность покрытия

Варианты метрик

Покрытие требований тестами – не менее 80%
Плотность покрытия – не

менее 3
Закрыто 100% известных критических дефектов, 90% дефектов средней критичности, 50% остальных дефектов.
Общий показатель прохождения тестов – не менее некоторого значения: X = (Passed/Executed)*100%
Слайд 49

Есть вопросы? Давайте обсудим!

Есть вопросы? Давайте обсудим!

Слайд 50

Составляющие качества Наука простым языком

Составляющие качества

Наука простым языком

Слайд 51

Функциональные возможности Что я могу с помощью этого сделать?

Функциональные возможности

Что я могу с помощью этого сделать?

Слайд 52

Функциональная пригодность Могу ли я с помощью этого сделать … ?

Функциональная пригодность

Могу ли я с помощью этого сделать … ?

Слайд 53

Правильность (корректность) Правильно ли это сделано (работает)?

Правильность (корректность)

Правильно ли это сделано (работает)?

Слайд 54

Способность к взаимодействию Могу ли я соединить это с …?

Способность к взаимодействию

Могу ли я соединить
это с …?

Слайд 55

Защищённость А если придут злоумышленники?

Защищённость

А если придут злоумышленники?

Слайд 56

Надёжность А оно не сломается?

Надёжность

А оно не сломается?

Слайд 57

Эффективность Ему много ресурсов понадобится?

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

Ему много ресурсов понадобится?

Слайд 58

Практичность (применимость) А я точно смогу с помощью этого ... ?

Практичность
(применимость)

А я точно смогу с помощью этого ... ?

Слайд 59

Сопровождаемость Я смогу это доработать, улучшить?

Сопровождаемость

Я смогу это доработать, улучшить?

Слайд 60

Мобильность Это сможет работать где-то ещё?

Мобильность

Это сможет работать
где-то ещё?

Слайд 61

Основная сложность тестирования программ – это... И что же это? Как вы думаете?

Основная сложность
тестирования программ – это...

И что же это? Как вы думаете?

Слайд 62

Основная сложность тестирования программ – это... невозможность всё предусмотреть в силу концептуальности ПО

Основная сложность тестирования программ – это...

невозможность всё предусмотреть
в силу концептуальности ПО

Слайд 63

Семь шагов к успеху В чём заключается тестирование на каждом из этапов?

Семь шагов к успеху

В чём заключается тестирование на каждом из этапов?

Слайд 64

Что мы можем тестировать А и вправду – что?

Что мы можем тестировать

А и вправду – что?

Слайд 65

Программы при их непосредственном запуске и исполнении (software)

Программы при их непосредственном запуске и исполнении (software)

Слайд 66

Код программ без запуска и исполнения (code)

Код программ без запуска и исполнения (code)

Слайд 67

Прототип программного продукта (product prototype) Что может служить прототипом: Исследование имеющегося

Прототип программного продукта (product prototype)

Что может служить прототипом:
Исследование имеющегося у заказчика

продукта, который следует улучшить.
Исследование продуктов конкурентов.

А что еще может служить прототипом? (подсказка: особенно в Agile разработке)

Слайд 68

Проектную документацию (project documentation): Требования к программному продукту (product requirements). Функциональные

Проектную документацию (project documentation):
Требования к программному продукту (product requirements).
Функциональные спецификации к

программному продукту (functional specifications).
Архитектуру (architecture) и дизайн (design).
План проекта (project plan) и тестовый план (test plan).
Тестовые случаи и сценарии (test cases, test scenarios).
Слайд 69

Сопроводительную документацию (и документацию для пользователей): Интерактивную помощь (on-line help). Руководства

Сопроводительную документацию (и документацию для пользователей):
Интерактивную помощь (on-line help).
Руководства по установке

(Installation guide) и использованию программного продукта (user manual).
Слайд 70

Давайте что-нибудь протестируем!


Давайте что-нибудь протестируем!

Слайд 71

Итого, что мы узнали сегодня?

Итого, что мы узнали сегодня?

Слайд 72

Есть вопросы? Давайте обсудим!

Есть вопросы? Давайте обсудим!