Слайд 2 Программа Курса
Manual Testing : ~ 3-4 недели
Introduction to Data Bases
: ~ 3-4 недели
JAVA(Object-Oriented programming) : ~ 2 месяца
Automation Testing : ~ 2 месяца
Слайд 3 Преимущества курса
Курс длится всего 6 месяцев, после чего:
Вы можете стать
Manual Software Tester
Вы можете стать Automation Software Tester
У вас есть знания в области программирования (JAVA)
Вы можете пройти сертификацию ISTQB
(The Certified Tester Foundation Level in Software Testing)
большинство студентов курса сейчас работают в IT-компаниях (>80%)
Слайд 4Введение в тестирование
Что такое тестирование программного обеспечения?
Проверка соответствия между реальным и
ожидаемым поведением программы
Процесс выполнения программы с целью нахождения ошибок
Техническое исследование программы для получения информации о её качестве с точки зрения производителя и потребителя
Слайд 5Необходимость тестирования
высокие требования в области качества
спецификаций производителя
спецификаций потребителя
низкое качество ПО ведет
к:
потере денег
потере времени
потере репутации
даже к летальному исходу
Слайд 6Стоимости ошибки на каждой из стадии разработки
Не выявленная и не решенная
проблема при использовании программного обеспечения может быть в 40-100 раз дороже при решении чем выявленная проблема на ранней стадии во время разработки ПО
Слайд 7
Ariane 5
4 июня 1996 года Ариане 5 взорвалась через 40
секунд после запуска
Разрушенная ракета и ее груз были оценены в 400 миллионов долларов
было вызвано при выполнении преобразования данных из 64-разрядного числа в 16-разрядное целое число
Слайд 8Mars Climate Orbiter
338-килограммовый робот-спутник, запущенный НАСА в 1998 году
он должен был
изучить климат Марса, изменения атмосферы и поверхности
Не удалось рассчитать правильную орбиту Марса
не удалось преобразовать фунт силы / с (фунты) в ньютон-секунды
Он должен был вращаться вокруг Марса на расстоянии ~ 227 км. Но на самом он опустился на 57 км.
Слайд 9Therac 25
Atomic Energy of Canada Limited in 1982
как минимум 5
смертельных случаев 1987-1989
программное обеспечение было разработано так, чтобы было практически невозможно протестировать его автоматическим способом
плохие методы проектирования и разработки программного обеспечения
Слайд 10Цели и задачи тестирования
Выявление дефектов на различных этапах жизненного цикла приложения
Проверка
того, что выявленный дефект был успешно устранён
Выяснение того, что изменения, связанные с устранением выявленного дефекта, не привнесли новых дефектов в систему
Информирование руководства об уровне качества программного обеспечения и уровне риска
Повысить уровень качества программного обеспечения
Слайд 11Базовая терминология тестирования
Error (ошибка) - ошибка, допущенная человеком
Bug/Defect (Баг/Дефект) - oшибка
в коде
Failure (Отказ) - если выполняется Дефект, это может привести к сбою системы
Requirement (требование) - набор условий / спецификаций того, что должно делать программное обеспечение и как оно должно себя вести
Test Case (тестовый случай) - сценарий с исполняемыми шагами и ожидаемыми результатами
Test Suite - набор тестовых случаев, которые относятся к общей функциональности
Test Data (Тестовые Данные) - конкретные данные, которые используются в тестовых случаях
Test Plan (План тестирования) - документ, определяющий цели тестирования и его деятельность
Слайд 127 принципов тестирования
Тестирование показывает наличие дефектов
(Testing shows the presence of
defects, not their absence)
“Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие.”
Исчерпывающее тестирование невозможно
(Exhaustive testing is impossible)
“Невозможно тестировать все комбинаций пользовательского ввода и состояний системы”
Раннее тестирование
(Early testing)
“Тестирование должно начинаться как можно раньше в жизненном цикле разработки программного обеспечения”
Скопление дефектов
(Defect clustering)
“80% проблем содержатся в 20% модулей”
Слайд 137 принципов тестирования
Парадокс пестицида
(Pesticide paradox)
“ Одни и те же тесты находят
все меньше новых ошибок “
Тестирование зависит от контекста
(Testing is context dependent)
“Выбор методологии, техники и типа тестирования будет напрямую зависеть от природы самой программы”
Заблуждение об отсутствии ошибок
(Absence of errors fallacy)
“Нахождение и исправление дефектов будут не важны если система не будет удовлетворять ожиданиям и потребностям пользователя”
Слайд 14Test Levels
(Уровни Тестирования)
Component/Unit Testing (компонентное или модульное тестирование)
“тестировании различных модулей приложения,
которые могут быть протестированы по отдельности в силу своей автономности”
Integration Testing (интеграционное тестирование)
“представляет собой исследование связей между компонентами приложения”
System Testing (системное тестирование)
“направлено на исследование функциональных и нефункциональных особенностей системы в целом”
Acceptance Testing (приёмочное тестирование)
“соответствует ли система приёмочно/сдаточным критериям”
Alpha Testing - имитацию реального использования продукта штатными разработчиками либо командой тестировщиков
Beta Testing - предполагает привлечение добровольцев из числа обычных будущих пользователей продукта
Слайд 15Тестирование в контексте процесса
разработки ПО
Waterfall Model
(Каскадная модель)
Requirements Analysis
(Анализ требований)
Software Design
(Проектирование
программного обеспечения)
Implementation
(Реализация)
Testing
(Тестирование)
Deployment
(Установка)
Maintenance
(Сопровождение)
Слайд 16Fundamental Test Process
Test Planning and Control
Test Analysis and Design
Test implementation and
Execution
Evaluating Exit Criteria and Reporting
Test Closure Activities
Слайд 17 Testing Types
(Типы тестирования)
Functional Testing – тестирование системы для определения
того,
насколько хорошо система выполняет свои функции на основе
функциональных требований
(“what” the system should do?/ что делает программное обеспечение?)
Non-Functional Testing – тестирование системы на основе нефункциональных
требований
(“how well” the system behaves/как работает программное обеспечение?)
Слайд 18Non-Functional Testing
Performance Testing - Тестирование производительности
Security Testing - Тестирование безопасности
Usability Testing
- связано с оценкой степени удобства использования, а также понятности и привлекательности пользовательского интерфейса приложения
Load Testing - нагрузка в пределах нормы
Stress testing - нагрузки превышающей штатную
Accessibility testing ..
и т.д.
Слайд 19 Testing Methods
Black-Box Testing – тестировщик не имеет доступа к
исходному
коду
White-Box Testing – позволяет тестировщику использовать исходный код приложения (создание unit-test)
Слайд 20Testing Methods
Виды тестирования связанные с изменениями:
Regression Testing – предназначено для проверки
осуществлённых в системе изменений, а так же на подтверждение того, что существовавшая до изменения ункциональность, работает также как и прежде;
Retesting – Повторная проверка дефектов, после исправления бага нужно пройти повторную проверку
Слайд 21Testing Methods
Exploratory Testing (ознакомительное) - одновременное обучение, дизайн теста и выполнение
теста
Scripted Testing (по сценарию) - набор инструкций, которые будут выполняться в тестируемой системе, чтобы проверить, что система функционирует должным образом
Manual Testing (ручное) - Ручное тестирование производиться человеком
Automated Testing (автоматическое) - автоматическое тестирование производиться ПО
Positive Testing
Negative Testing
Слайд 22Test Case
(Тестовый случай)
Test Case - набор шагов и ожидаемых результатов,
выполняемых тестером для проверки функциональности программного обеспечения
Название теста
Предусловия
Шаги + Ожидаемый результат
Слайд 26Exercise
Напишите 1 Test Case, чтобы проверить следующие требования:
System Under Test(SUT): https://edition.cnn.com/
Функциональность:
элементы в меню заголовка связанные с регионами
Requirements(Требования):
1. Ссылка “World”, расположенная в меню заголовка страницы, при нажатии должна открыть меню “Regions”
2. Следующие ссылки: “U.S.” , “Africa” , “Americas”, “Asia”, “Australia”, “China”, “Europe”, “Middle East”, должны перенаправить пользователя на соответствующие страницы, имеющие те же заголовки, что и ссылки.
Слайд 29Defect (Bug) Report
Objectives:
Provide developers and other parties with information about any
adverse event that occurred
Предоставлять разработчикам и другим сторонам информацию о любых неблагоприятных событиях, которые произошли
Provide test managers a means of tracking the quality of the work product and the impact on the testing
Предоставление менеджерам по тестированию, средства отслеживания качества рабочего продукта и влияния на тестирование
Provide ideas for development and test process improvement
Предоставлять идеи для развития и улучшения процесса тестирования
Слайд 30Defect (Bug) Report
A defect report usually includes:
Отчет о дефектах обычно включает:
An
identifier
Идентификатор
A title and a short summary of the defect being reported
Заголовок и краткое описание обнаруженного дефекта
Date of the defect report, issuing organization, and author
Дата отчета о дефекте, организация-эмитент и автор
The development lifecycle phase(s) in which the defect was observed
Фаза (ы) жизненного цикла разработки, в которой обнаружен дефект
Слайд 31Defect (Bug) Report
A defect report usually includes:
logs, database dumps screenshots, or
recordings (if found during test execution)
журналы, скриншоты дампов базы данных или записи (если они обнаружены во время выполнения теста)
Expected and actual results
Ожидаемые и фактические результаты
Scope or degree of impact (severity) of the defect
Степень или степень воздействия (серьезности) дефекта
Urgency/priority to fix
Срочность / приоритет для исправления
State of the defect report
Состояние отчета о дефекте
Steps to reproduce
Шаги для воспроизведения