Курс качество на софтуера - част 1

ОСНОВИ НАОСНОВИ НА

СОФТУЕРНОТО ТЕСТВАНЕ

КАКВО СЕ СЪДЪРЖА КУРСА ?

концепцията на софтуерните тестове – термини, основни принципи и техники на провеждане на софтуерни тестове

основни техники при провеждането на whitebox и blackbox тестовете

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

автоматизирани тестове за валидиране на софтуера

мениджмънт системи

тестове за ползваемост и UI тестове

стандарти

финален тест

ОРГАНИЗАЦИИ

ISTQB

www.istqb.org

GASQ (Global Association for Software Quality

www.gasq.org

iSQI (Internation Software Quality Institute)

www.isqi.org

IEEE Institute of Electrical and Electronic Engineers

www.ieee.org

ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ

Защо тестването става все по-важно ?

- Y2K проблем

- EMU (икономически и паричен съюз)- EMU (икономически и паричен съюз)

- eCommerce

- Увеличаване на потребители

- Повишаване на сложността

ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ

Защо се срещат грешки ?

- Няма перфектни неща

- По-голямото напрежение в работата ни - По-голямото напрежение в работата ни кара да правим повече грешки

- Ограничени бюджет и време

- Лоши практики

ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ

Защо се срещат грешки ?

- Лоша комуникация

- Липса на точни изисквания

- Промяна на изискванията. Липса на документиране

- Незавършени спецификации

РАЗМЕР НА ГРЕШКИТЕ

Една грешка = милиони

Проекта тръгва в грешна посока

Екстремни условия = човешки живот

Критични системи полежат на задълбочени тестове

ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ

Например:- Малко градче в Илинойс, САЩ, получава сметка за ток в

размер на 7мил. Долара през Март 1999. Това е повече от 700 пъти от нормалното. Проблема не се решава до другата проблема и фирмата се принуждава да я плати заради Y2K проблема и проблем в софтуера.заради Y2K проблема и проблем в софтуера.

- Проблем в банков софтуер, кара системата за изтегли от сметката на 823 клиента сума в размер на близо 930мил. Долара. Най-големият банков проблем в историята.

ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ

Защо тестове ?- Откриване на грешки

намаляване на живите грешки

повишаване на качеството

повишаване на сигурността

редуциране на бъдещи разходи

клиентски изисквания отговарят на реалните функционалности

повишаване на репутацията и доказване на фирмата

- Доставя мерки за качество

ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ

Колко тестове са достатъчни ?

- Как да разберем кога да спрем ?

- Ако спрем прекалено рано с тестовете рискуваме живота на систематарискуваме живота на системата

- Прекалено тестове ще отложат пускането на продукта на пазара. Губим пари и представяне.

ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ

Ако не можем да тестваме всичко, какво да правим ?

- Управление и редуциране на риска

- Изследване и анализ на риска в - Изследване и анализ на риска в приложението и ключови моменти

- Приоритизирайте тестовете

- Разбиране на риска от бизнес гледна точка - функционалност

ЗАЩО Е НЕОБХОДИМО ТЕСТВАНЕ

Не трябва да спираме да тестваме продукта, дори да е пуснат на пазара

Гаранция за откриване на “скрити” дефекти и грешкигрешки

ТЕСТВАНЕ И КАЧЕСТВО

Целта е да намерим най-много дефекти. Ползата е:

- Намаляване на броя на грешките преди официалното стартиране на проектаофициалното стартиране на проекта

- Повишаване на качеството

- Повишаване на сигурността

КАКВО ТРЯБВА ДА ИЗМЕРВАМЕ

Коректност

Надежност

Ползваемост

Издръжливост

Използваемост

Еквивалентност на изискванията

ОБОБЩЕНИЕ

Целта на тестовете е да открие дефекти- Грешките могат да бъдат отстранени

- По-добрият софтуер е по-надежден, по-малка вероятност от грешки

Тестването е свързано с връзката между - Тестването е свързано с връзката между софтуера и изискванията

- Тестовете ни дават възможност да измерваме качеството на софтуера

КАКВО СА СОФТУЕРНИТЕ ТЕСТОВЕ

Няколко определения:

- “процес на изпълнение на програмата, като се набляга на нейното качество”

- “процес на изпълнение на програмта, с цел намиране на грешки”намиране на грешки”

- “процес на изпълнение на програта с цел намиране на грешки и потвърждаване на функционалните и нефункционални спецификации”

ОСНОВНИ ПОНЯТИЯ В SQA

ISTQB определение

“Процес на последователност от всички действия в жизнения цикъл на продукта, включващо статични и динамични действия, концентрирани статични и динамични действия, концентрирани върху планирането, подготовката и развитието на софтуерния продукт и свързан с работата на самия продукт”

ОСНОВНИ ПОНЯТИЯ В SQA

Грешка

“Човешко действие, което предизвиква некоректен резултат”

ОСНОВНИ ПОНЯТИЯ В SQA

Дефект = Дефект= Бъг = Проблем

“Недостатък в компонент или в системата, която предизвиква некоректно поведение на предизвиква некоректно поведение на

компонента или системата”

ОСНОВНИ ПОНЯТИЯ В SQA

Неуспех

“Реално отклонение на компнент или системата от очакваните резултати, услуги или резултати”очакваните резултати, услуги или резултати”

ОСНОВНИ ПОНЯТИЯ В SQAАномалия

“Всяко условие, което се отклонява от очакванията, които се базират на

функционалните изисквания, документацията, функционалните изисквания, документацията, потребителските изисквания, стандартите”

ОСНОВНИ ПОНЯТИЯ В SQAАномалия

“Всяко условие, което се отклонява от очакванията, които се базират на

функционалните изисквания, документацията, функционалните изисквания, документацията, потребителските изисквания, стандартите”

ОСНОВНИ ПОНЯТИЯ В SQA

Недостиг

“Липса на нужното качество или елемент или липса на изпълнение на очаквани резултати”липса на изпълнение на очаквани резултати”

ОСНОВНИ ПОНЯТИЯ В SQA

Маскиране на дефекта

“Явление при което даден дефект предизвиква друг дефект”друг дефект”

ОСНОВНИ ПОНЯТИЯ В SQAТест

“Набор от един или няколко тест сценария”

Тест сценарии

“Набор от входящи стойности, изпълнение на предусловия, очаквани резултати и изпълнение на предусловията, изпълнение на определени

тест условия, чиято цел е да потвърдят и сравнят състоянието на системата с описаните в

изискванията”

ОСНОВНИ ПОНЯТИЯ В SQA

Маскиране на дефекта

“Явление при което даден дефект предизвиква друг дефект”друг дефект”

ОСНОВНИ ПОНЯТИЯ В SQAНадежност

“Възможност на софтуерния продукт да функционира според зададените изисквания под определени условия и време, или за определени определени условия и време, или за определени

специфични дейности/операции”

ОСНОВНИ ПОНЯТИЯ В SQAПолзваемост

“Способност на софтуерния продукт да бъде разбиран, научаван, използван и атрактивен за

потребителите при определени условия”потребителите при определени условия”

ОСНОВНИ ПОНЯТИЯ В SQAПроизводителност

“Способността на софтуерните продукти да осигурявя подходящо поведение, свързано с

размера на ресурсите използвани при размера на ресурсите използвани при определени условия”

ОСНОВНИ ПОНЯТИЯ В SQAПоддръжка

“Свободата на софтуерния продукт да бъде модифициран и да се отстраняват лесно

дефектите, да се изменя според нови дефектите, да се изменя според нови изисквания или при смяна на средата”

ОСНОВНИ ПОНЯТИЯ В SQA

Преносимост

“Способността на софтуерния продукт да бъде пренасян от една хардуерна или софтуерна пренасян от една хардуерна или софтуерна

среда на друга”

ОСНОВНИ ПОНЯТИЯ В SQA

Тестването не създава КАЧЕСТВО на софтуера, а само определя качеството на

разработвания продуктразработвания продукт

ОСНОВНИ ПОНЯТИЯ В SQAКачество на софтуера (QA)

“Всички планирани действия, които се прилагат, за да се осигури качество на продукта”

Качествен контрол (QC)Качествен контрол (QC)

“Управление на процеса при създаване на софтуер, с цел да се осигури, че QA

процедурите и стандартите ще бъдат спазени”

ОСНОВИ НА ТЕСТ ПРОЦЕСА

Тест мениджмънт / Управление на процеса

ПланСпецифи

кацияИзпълне

ние Запис СправкПлан кация ние Запис Справка

Допълнително управление

Управление на тест средата

ТЕСТ ПРОЦЕС

Има 5 основни стъпки:

- Тест планиране и контрол

- Тест анализ и дизайн

- Тест изпълнение

- Оценка на поставените критерии и докладване

- Прекратяване на тестовете

ТЕСТ ПЛАНИРАНЕ И КОНТРОЛ

Тест плана ни дава насоки как да изградим и изпълним тест стратегията

Последователност на тестовете

Какво трябва да се тества, как да се тества, какви са нужните и др.какви са нужните и др.

Видове тестове – функционални, нефункционални, автоматизирани

ТЕСТ ПЛАНИРАНЕ И КОНТРОЛ

Тест контрола ни дава възможност за:

- Измерване и анализ на резултатите

- Наблюдение и документиране на процеса, обхват на тестовете и критерии процеса, обхват на тестовете и критерии за качество

- Определяне на допълнителни ресурси

- График на тестовете

- Обхват на тест средата

ТЕСТ АНАЛИЗ И ДИЗАЙН

Има три основни стъпки:

- Подготовка и анализ

- Изграждане на тест сценарии

- Дефиниране на критериите за успеваемост

ПОДГОТОВКА И АНАЛИЗ

Подготовката на тестове включва:

- Анализ на приложението

- Определяне на тест условията

- Определяне на тест сценариите

- Документация

ИЗГРАЖДАНЕ НА ТС

Всеки един ТС трябва да съдържа информация за:

- Предусловие

Входящи данни- Входящи данни

- Извършвани действия

- Очаквани ресултати

ТЕСТ ДОКЛАД

Трябва да се включва:

- Версията на софтуера/продукта, който тестваме

- Спецификация, на която се базираме

- Избор на тестове

- Тест резултати

реални резултати

очаквани резултати

- Описание на намерените бъгове

КАКВО ПРАВИ ДОБРИЯТ ТЕСТЪР?

Интелектуални знания

- Поемане на незавършените факти

- Работи с незавършени задачи

- Учи се бързо на много нива

- Добри комуникативни способности

- Може да категоризира и приоритизира

- Самоподготовка

КАКВО ПРАВИ ДОБРИЯТ ТЕСТЪР?

Познания

- Как проекта работи

- Какви са нуждите на системата и бизнеса

- ИТ технологии

- Комерсиални аспекти на ИТ сферата

- Тест техники

- Най-добрите тест практики

- Да мисли в и отвъд спецификацията на системата

КАКВО ПРАВИ ДОБРИЯТ ТЕСТЪР?

Допълнителни умения

- Способност да открива грешки – планиране, подготовка и изпълнение

- Способност да разбере системата, с която работи- Способност да разбере системата, с която работи

- Способност да чете и разбира спецификацията

- Способност да отсява ключовите моменти

- Способност да работи надеждно и качествено

- Способност да се фокусира върху важните неща

ДОКЛАДВАНЕ НА ГРЕШКИ

Откритите грешки трябва да се докладват на

- разработчиците, за да могат да ги отстраняват

- Мениджърския екип, за да могат да следят прогреса

Комуницията между двете групи е жизнено важна

КОМУНИКАЦИЯ С РАЗРАБОТЧИЦИТЕ

Добрите взаимоотношения са най-важни

Програмистите, трябва да информират своевременно QA за всяка една промяна

QA трябва да информира програмисите за всеки един бъг, за да може той да бъде остраненедин бъг, за да може той да бъде остранен

КОМУНИКАЦИЯ С МЕНИДЖМЪНТА

Мениджърите трябва да следят прогреса на докладваните грешки

Най-добрия начин е да се използват следните мерки:

- Брой на планираните и подготвени тестове

- Брой на изпълнените тестове до момента

- Брой на документираните бъгове и брой на корегираните

- Колко време отнема планирането, подготовката и изпълнението на тестовете

МОДЕЛ НА РАЗРАБОТКА

Има много модели, които се използват:

- V-модел е най-често прилаганият

- Последователен модел (Waterfall)

- Повтарящ се модел

Основните действия в моделите са:

V, V&T – Валидация, Верификация и Тестване

МОДЕЛ НА РАЗРАБОТКА

Валидация

“Потвърждаване чрез изследване и осигуряване на данни/доказателства на обектитеза

коректност при изпълнение на действията от коректност при изпълнение на действията от дадената система”

МОДЕЛ НА РАЗРАБОТКА

Верификация

“Потвърждаване чрез изследване и осигуряване на данни/доказателства за изпълнени

функционални изисквания”функционални изисквания”

МОДЕЛ НА РАЗРАБОТКА

Тестване

“Процеса включва всики действия от жизнения цикъл на продукта, включително статични и

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

и свързан с работата на продукта, за да се определи дали отговарят на изискванията и

дали функционират коректно, като същевременно се намират дефекти и бъгове”

V-МОДЕЛ

V-Модел

- Най-използвания модел в софтуерните разработки

- Представя жизнения цикъл на Представя жизнения цикъл на разработката на проекта

- Показва различни етапи на разработката и тестването

- Показва връзката между различните етапи

V-MODEL

Бизнес изисквания

Тестове за приемане

Техническа спецификация

Тестове за интеграция

Системни Функционална спецификация

Системни тестове

Дизайн спецификация

Тестове за интеграция

Кодиране Unit тестове