Введение в тестирование

ПО

Преподаватель: Алтынник Александр

 Пару слов о себе
Алтынник Александр

ХАИ (кафедра информационно управляющих систем) магистр

QA engineer Grade 3 в компании G5 Entertainment

5 лет в области обеспечения качества

30 игровых проектов, под iOS, Android (GP, Amazon), Windows, Facebook,

Mac, Web

Mail: aleksandr.altynnik@g5e.com

Slack: Aleksandr Altynnik

 Давайте познакомимся с
вами

Я буду называть имя фамилию человека, а ему нужно

ответить на следующие вопросы:

- Где учились/учитесь/работаете?

- Что успели прочитать о тестировании?

- Какие ожидания от курса?

 Структура курса

Курс состоит из двух частей.

1 часть: 21 час (продолжительность 1 месяц)

● Теория
● В начале каждого следующего занятия контрольная
● Домашние задания
● В конце 1 части письменный экзамен (теория + практика) + устное собеседование. На основании этого будет принято
решение, с кем мы попрощаемся, а кто переходит ко второй части курса. Если все хорошо справитесь, то пройдете
все!

ВАЖНО! Для допуска к экзамену, к моменту старта 8 лекции должны быть сданы и приняты все домашние задания.

2 часть: 19 часов (продолжительность 1 месяц и 1 неделя)

● Практическая работа над задачами, с которыми придется столкнуться в реальной работе в нашей компании
● В начале каждого занятия контрольная по материалу предыдущего. Также за каждое практическое получаете оценку.
Оценивание также по 100 бальной системе
● Собеседование на позицию Grade Basic QA в компанию G5 для кандидатов с лучшими результатами

ВАЖНО! За просроченный срок сдачи ДЗ будет штраф!

 План 1 части
курса
- 1 Лекция. Введение в тестирование - 2 часа
- 2 Лекция. Основные модели разработки ПО - 2,5 часа
- 3 лекция. тестирование требований - 2,5 часа
- 4 лекция. Классификация видов тестирования - 2 часа
- 5 лекция. Альтернативная классификация видов тестирования и жизненный цикл Бага - 2,5 часа
- 6 Лекция. техники тест дизайна - 2 часа
- 7 Лекция. Тестовая документация - 2 часа
- 8 Лекция. Тестирование мобильных приложений - 3 часа
- Экзамен - 2.5 часа
 Давайте выполним небольшой тест кейс:

Краткое описание: Присоединиться к курсу

тестирования ПО в google class

Preconditions

1. В наличии код курса:

Шаги воспроизведения:

1. Зайти в предоставленный вам аккаунт

Google !!!
2. Выбрать приложение Google Glass
3. Нажать на кнопку "добавить курс" и выбрать
"присоединиться"
4. В появившемся окне ввести код курса "6sghblo"
без кавычек, нажать кнопку "присоединиться"

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

курсу и он отображается в списке доступных вам
курсов
Лекция 1. Введение в тестирование ПО
 Стандарты отвечающие за тестирование ПО

SWEBOK (Software Engineering Body of Knowledge)

ISTQB

ISO 9000
SWEBOK (Software Engineering Body of Knowledge) — документ, подготавливаемый комитетом Software Engineering
Coordinating Committee. Назначение SWEBOK — в объединении знаний по инженерии программного обеспечения.
Документ призван обеспечить следующее:

● определить необходимый набор знаний и рекомендуемые практики;

● определить этические и профессиональные стандарты;

● определить учебную программу для студентов, аспирантов и продолжающих обучение.

ISO 9000 - Серия международных стандартов, содержащих термины и определения, основные принципы
менеджмента качества, требования к системе менеджмента качества организаций и предприятий, а также
руководство по достижению устойчивого результата. Серия стандартов ISO 9000 разработана Техническим
комитетом 176 (ТК 176) Международной организации по стандартизации. В основе стандартов лежат идеи и
положения теории всеобщего менеджмента качества.
ISTQB® (International Software Testing Qualifications Board) – организация по сертификации тестировщиков ПО.
Основанная в Эдинбурге в ноябре 2002 года, ISTQB является некоммерческой ассоциацией, официально
зарегистрированной в Бельгии. ISTQB® отвечает за международную схему квалификации называемую ISTQB®
Certified Tester. Квалификация основывается на программе обучения (Syllabus), и состоит из нескольких уровней.
ISTQB® является крупнейшей организацией в области квалификации тестировщиков программного обеспечения,
представленной более чем в 60 странах мира.

Содержание программы Базового уровня:

● Основы тестирования программного обеспечения

● Жизненный цикл тестирования

● Динамическое тестирование

● Статическое тестирование

● Управление тестированием

● Средства тестирования
 Что такое тестирование?
Мы тестируем каждый день, сами о том не задумываясь!

Определений в разных источниках наберётся больше 20-ти. Давайте рассмотрим самые распространённые.

Вариант 1. iSTQB. Процесс, содержащий в себе все активности жизненного цикла, как динамические, так и
статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим
результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они
подходят для заявленных целей и для определения дефектов.
Вариант 2. Процесс исследования программного обеспечения с целью выявления ошибок
и проверки его качества. Также тестирование ПО можно описать как процесс проверки
соответствия между реальным и ожидаемым поведением программы. Тестирование
включает в себя активности по планированию работ (Test Management), проектированию
тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных
результатов (Test Analysis).

Вариант 3. Процесс исследования/испытания программного обеспечения с целью

получения информации о его качестве.
Что качественнее? Давайте обсудим!
 Что такое качество?

Вариант 1. Качество программного

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

Вариант 2. Качество — это степень

соответствия совокупности реальных
характеристик требованиям (ISO 9000-2005)

Вариант 3. Ожидание vs Реальность

Что такое Баг?
Вариант 1. Баг - отклонение фактического результата от ожидаемого

Давайте поищем баг вместе

Вариант 2. Баг (англ. bug — первичные значения: клоп,
любое насекомое, вирус) — жаргонное слово, обычно
обозначающее ошибку в программе или системе, из-за
которой программа выдает неожиданное поведение и, как
следствие, результат. Большинство багов возникают из-за
ошибок, допущенных разработчиками программы в её
исходном коде, либо в её дизайне. По одной из версий, в
отношении программной ошибки этот термин впервые
применила в 1946 году Грейс Хоппер, программировавшая
в Гарвардском университете вычислительную машину
Harvard Mark II. Проследив ошибку в работе программы до
электромеханического реле машины, она нашла мотылька,
застрявшего между контактами. Извлеченное насекомое
было вклеено скотчем в технический дневник с
сопроводительной надписью: «Первый реальный случай
обнаружения жучка» (англ. First actual case of bug being
found).
 Как же найти баг?

• Узнаем ожидаемый результат

• Узнаем фактический
результат

• Сравниваем два результата

 Но где же взять информацию про
ожидаемый результат?

1. Спецификация - детальное описание того как должна работать программа.

2. Гайдлайны – руководящие принципы, в которых описаны определенные требования

к программному обеспечению.

3. Жизненный опыт, здравый смысл, общение, устоявшиеся стандарты,

статистические данные, авторитетное мнение и др.
 Давайте подведем небольшой итог
1. Итак у нас есть спецификация, гайдлайны, здравый смысл. В них описано как должен работать наш продукт.
2. На их основании мы выделили список требований и для каждого придумали тест. У теста есть ожидаемый
результат (соответствие требованиям).
3. Если ожидаемый и фактический результаты не совпадают мы пишем баг.

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

ВАЖНО! Саму спецификацию тоже нужно тестировать.

 Как выглядит тест и сообщение о том что вы нашли баг?
Баг (Баг репорт)
Тест (тест кейс)
Summary. Некорректное содержание соли в супе
Short description Тест на соль в супе
Precondition
Precondition
1. Для тестирования предоставлен суп
1. Суп сварен поставлен на плиту 2. В наличии ложка для тестирования
2. В наличии есть ложка для
Steps to reproduce
тестирования
1. Открыть крышку кастрюли
Test Steps
2. Набрать в ложку суп
3. Попробовать суп
1. Открыть крышку кастрюли 4. Обратить внимание на результат
2. Набрать в ложку суп
3. Попробовать суп Actual result: Суп пересолен, есть невозможно.

Expected Result: Суп в меру солёный, такой Expected Result: Суп в меру солёный, такой как вам нравится.
как вам нравится.
Justification of the expected result: Личный опыт.
 Важно! Тесты бывают позитивные и негативные

Позитивное тестирование - это тестирование с применением сценариев, которые соответствуют нормальному

(штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для
чего и была создана. Например, вы ввели для авторизации на сайте ваши логин и пароль (правильные).
Авторизация прошла успешно.

Негативное тестирование - тестирование, в рамках которого применяются сценарии, которые соответствуют

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

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

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

Валидация (Validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям

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

Среди вакансий на разных сайтах вы могли встретить: QA

engineer, QC engineer, Тестировщик.

Давайте разберемся в чем разница.

Quality Assurance - предотвратить ошибку

Quality Control - анализировать ошибки которые были найдены,

разрабатывать тесты (верификация и валидация)

Тестирование - обнаружить ошибку

Тестовое Покрытие ( Test Coverage ) - это одна из метрик оценки качества тестирования, представляющая из
себя плотность покрытия тестами требований либо исполняемого кода.

Тест дизайн ( Test Design ) - это этап процесса тестирования ПО, на котором проектируются и создаются
тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями
тестирования.

Фича - какая-либо полезная особенность, специфическая черта, дополнение в программном обеспечении.

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

ВАЖНО! Не то, сколько вы найдете ошибок,

а сколько их найдут пользователи.
 Задачи тестирования

1. Проверить, что система работает в соответствии с определенными временами отклика клиента и

сервера.

2. Проверить, что наиболее критические последовательности действий с системой конечного

пользователя выполняются верно.

3. Проверить работу пользовательских интерфейсов

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

программные модули.

5. При проектировании тестов свести к минимуму переработку тестов при возможных изменениях
приложения.

6. Использовать инструменты автоматизированного тестирования там, где это целесообразно.

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

8. При проектировании автоматизированных тестов использовать стандарты разработки таким образом,

чтобы создать многократно используемые и сопровождаемые скрипты
 Цели тестирования

1. Снижение стоимости разработки

2. Повысить вероятность того, что приложение,

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

3. Повысить вероятность того, что приложение,

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

4. Предоставление актуальной информации о

состоянии продукта на данный момент.

5. Провести полное тестирование приложения за

установленный срок.
S (Specific - конкретика) - Какого результата я хочу достичь за счет выполнения цели и почему?

M (Measurable - измеримость) - Когда будет считаться, что цель достигнута?

A (Achievable - достижимость) - В моих ли силах осуществить это?

R (Realistic - реалистичность) - Реалистична ли поставленная задача?

T (Timely - ограниченность во времени) - За какой срок должна быть достигнута цель?

R (Relevant - значимость) - Какие выгоды принесет мне решение поставленной задачи?

 Принципы тестирования
Существует 7 основных принципов тестирования ПО они являются общим руководством для тестирования в целом.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Роман Савин. Тестирование DOT COM или Пособие по жестокому обращению с

багами в интернет- стартапах
2. Сэм Каннер. Тестирование программного обеспечения (про принтеры можно не
читать)
3. ISTQB базовый уровень
4. Словарь IT сленга
 Seniority pyramid для QA в компании G5

Общепринятое разделение таково:

Intern (Это Вы) - Учится основам профессии. Закрепляя теорию на практике и постепенно знакомиться с проектами, которые
будут в реальной работе. Ребятам, которые отличились в процессе обучения, предлагается позиция в компании.

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

Middle - Может самостоятельно выполнять простые и средние по сложности задачи. С некоторой помощью решать более
сложные. Может обучать начинающих сотрудников.

Senior - Может самостоятельно решать сложные задачи. Проводить ревью решений других сотрудников.

Team Lead - Постановка задач команде и контроль выполнения. Помимо высоких технических скиллов должен обладать,
сильными софт скилами.

В нашей компании такое разделение более гибкое:

Grade Basic
- Умение документировать отчеты о своей работе
- Умение документировать дефекты под контролем наставника
- Умение выполнять тестирование под контролем наставника
Grade 1
- Умение документировать отчеты о своей работе
- Умение самостоятельно документировать дефекты
- Умение выполнять тестирование под контролем наставника

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

Grade 3
- Умение документировать отчеты, касающиеся проекта в целом или направления
- Умение самостоятельно документировать дефекты
- Умение самостоятельно выполнять тестирование
- Умение координировать выполнение тестирования группой
- Умение выполнять оценку временных затрат на собственную работу
- Умение выполнять оценку временных затрат на часть проекта
- Умение обучать документировать дефекты, выполнять тестирование по тестовой документации
- Умение обучать создавать тестовую документацию
- Умение создавать тестовую документацию: (Тест-планы, кейсы, инструкции, задачи, и т.д.). Умение подготавливать
документацию для аутсорс тестирования. Умение проводить ревью тестовой документации
- Умение планировать работы по тестированию фичи/платформы.
Grade 4
- Умение документировать отчеты, касающиеся проекта в целом или направления.
- Умение самостоятельно документировать дефекты для внешних ресурсов (Google, Apple etc)
- Умение координировать выполнение тестирования группой
- Умение выполнять оценку временных затрат на работу по проекту в целом
- Умение обучать создавать тестовую документацию
- Умение создавать тестовую документацию: (Тест-планы, кейсы, инструкции, задачи, и т.д.). Умение
подготавливать документацию для аутсорс тестирования. Умение проводить ревью тестовой
документации.
- Умение планировать работы по тестированию проекта
- Умение имплементировать новый инструментарий для отдела QA
- Умение проводить внешние собеседования

Grade 5
Все вышеперечисленное в других грейдах.

Плюс умение грамотно и полно сформулировать и донести до команды идеи по улучшению проекта на
основании анализа своего проекта и проектов-конкурентов. На данной должности сотрудник занимается
разработкой глобальных стратегий по улучшению проекта.
 Какие игры делает наша компания
HOG (Hidden Object Game) - это логические мини-игры, в которых основной задачей игрока являются поиски различных
предметов (списки предметов подают в виде слов, силуэтов и анаграмм, ограничивают во времени прохождение уровня,
разными способами усложняя процесс) разнообразные детективные расследования, решение логических задач, разгадка
секретов, проверка на наблюдательность.
HOPA (Hidden Object Puzzle Adventures) - расширенный вариант HOG присутствует не только поиск
предметов, но и различные механики позволяющие более широко взаимодействовать с миром.
Match 3 - Игры этого жанра характеризуются тем, что их игровой мир состоит из таблицы или сетки
элементов, а задачей игрока является манипулирование элементами таким образом, чтобы совпали
заданные игрой шаблонные комбинации, и после выполнения условия собранные элементы исчезают.
Mahjong - основанная на классической китайской игре маджонг. Однако, в ней изображена не настоящая
игра в маджонг, а скорее пасьянс маджонг.

Пасьянс Маджонг - игра-головоломка, основанная на одинаковых фишках. Цель состоит в том, чтобы
сопоставить открытые пары одинаковых плиток и удалить их с доски, выставив плитки под ними для игры.
Игра заканчивается, когда все пары плиток удалены с доски или когда не осталось открытых пар.
Word - игры в которых необходимо из предоставленного набора букв складывать различные слова
Simulation - симулятор некоего процесса. Например постройки города или обслуживания клиентов в
супермаркете.
Card - карточные игры. Например солитер. Убирание карт с доски посредством составления
соответствующих комбинаций, по аналогии с маджонгом.
Adventure - один жанров компьютерных игр, представляющий собой интерактивную историю с главным
героем (или героями), управляемым игроком. Важнейшими элементами игры в жанре Adventure являются
собственно повествование и исследование мира, а ключевую роль в игровом процессе играет решение
головоломок и задач, требующих от игрока умственных усилий.
 Домашнее
задание
1. Прочитать материал лекции и подготовиться к тесту.
2. Описать цель от курса по SMART.

Цель: Я хочу получить знания по тестированию

S - За счет этих знаний я хочу пройти собеседование

M - и тд.

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

https://docs.google.com/document/d/13mGoJEmph7YYKwvVKxTZBiiRqxYSwKn4mpb7eVmq7VI/edit