Test Vane

Recap
Software Testing
What is difference between QA, QC
and Software Testing?
Software Testing
Quality Assurance (QA): QA refers to the planned and
systematic way of monitoring the quality of process which is
followed to produce a quality product. QA tracks the
outcomes and adjusts the process to meet the expectation.
Quality Control (QC): Concern with the quality of the product.

QC finds the defects and suggests improvements. The process
set by QA is implemented by QC. The QC is the responsibility of
the tester.
Software Testing: is the process of ensuring that product which

is developed by the developer meets the user requirement.
The motive to perform testing is to find the bugs and make sure
that they get fixed.
Software Testing
When to start QA in a project?
Software Testing
A good time to start the QA is from the beginning of the
project startup. This will lead to plan the process which will
make sure that product coming out meets the customer
quality expectation. QA also plays a major role in the
communication between teams. It gives time to step up the
testing environment. The testing phase starts after the test
plans are written, reviewed and approved.
Software Testing
What are verification and
validation and difference
between these two?
Software Testing
Verification: process of evaluating steps which is followed up to
development phase to determine whether they meet the specified
requirements for that stage.
Validation: process of evaluating product during or at the end of the

development process to determine whether product meets specified
requirements.
Difference between Verification and Validation:

Verification is Static Testing where as Validations is Dynamic Testing.
Verification takes place before validation.
Verification evaluates plans, documents, requirements and
specifications, where as Validation evaluates product.
Verification inputs are checklist, issues list, walkthroughs and inspection,
where as in Validation testing of actual product.
Verification output is set of documents, plans, specifications and
requirement documents where as in Validation actual product is
output.
Software Testing
What is difference between
Retesting and Regression testing?
Software Testing
The difference between Retesting and Regression testing are below:
Retesting is done to verify defects fixes where as regression is perform
to check if the defect fix have not impacted other functionality that
was working fine before doing changes in the code.
Retesting is planned testing based on the defect fixes listed where as
regression is not be always specific to any defect fix. Also regression
can be executed for some modules or all modules.
Retesting concern with executing those test cases that are failed
earlier whereas regression concern with executing test cases that was
passed in earlier builds.
Retesting has higher priority over regression, but in some case retesting
and regression testing are carried out in parallel.
Software Testing
Explain bug life cycle
Software Testing
Bug Life Cycle:
When a tester finds a bug .The bug is assigned with NEW or OPEN
status.
The bug is assigned to development project manager who will analyze
the bug .He will check whether it is a valid defect. If it is not valid bug is
rejected, now status is REJECTED.
If not, next the defect is checked whether it is in scope. When bug is
not part of the current release .Such defects are POSTPONED
Now, Tester checks whether similar defect was raised earlier. If yes
defect is assigned a status DUPLICATE
When bug is assigned to developer. During this stage bug is assigned a
status IN-PROGRESS
Once code is fixed. Defect is assigned with FIXED status.
Next the tester will re-test the code. In case the test case passes the
defect is CLOSED
If the test case fails again the bug is RE-OPENED and assigned to the
developer. That’s all to Bug Life Cycle.
Software Testing
What is severity and priority of
bug? Give some example.
Software Testing
Priority: concern with application from the business point of view.
It answers: How quickly we need to fix the bug? Or How soon the bug
should get fixed?
Severity: concern with functionality of application. It deals with the
impact of the bug on the application.
Software Testing
How much the bug is affecting the functionality of the
application?
Ex.
High Priority and Low Severity:
Company logo is not properly displayed on their website.
High Priority and High Severity:
Suppose you are doing online shopping and filled payment
information, but after submitting the form, you get a message
like "Order has been cancelled."
Low Priority and High Severity:
If we have a typical scenario in which the application get
crashed, but that scenario exists rarely.
Low Priority and Low Severity:
There is a mistake like "You have registered success" instead of
successfully, success is written.
Software Testing
What is the role of QA in a project
development?
.
Software Testing
QA stands for QUALITY ASSURANCE. QA team assures the quality by
monitor the whole development process. QA tracks the outcomes and
adjusting process to meet the expectation.
The role of Quality Assurance is discussed below:
QA team is responsible for monitoring the process to be carried out for
development.
Responsibilities of QA team are planning testing execution process.
QA Lead creates the time tables and agrees on a Quality Assurance
plan for the product.
QA team communicated QA process to the team members.
QA team ensures traceability of test cases to requirements.
Software Testing
What is the difference between
build and release?
.
Software Testing
BUILD: is a number given to installable software that is given to testing
team for testing by the development team. Build number assigned are
incremental and sequential.
RELEASE: is a number given to installable software that is handed over
to customer by the developer or tester.
The information of build, release and version are displayed in software
help page. Using this build and release customer can let the customer
team know which release version build thet are using.
eg "9.4.123.2" (Release Number.Version Number.Build Number.Patch
Number)
Software Testing
What is the basis for choosing the
SDLC model for development of
software. What models do you
know?
.
Software Testing
The choice of SDLC depends on the various factors, how stable are the
requirements:
When the requirements are very clearly know, documented and not
subject to change then we can follow the waterfall model.
Most of the companies follow the V mode for the development
because this model includes both verification and validation activities
and testing is involved in earlier phase.
Iterative model can be used to build application where requirement
changes after a period of times or application features or added on
with smaller release. When the client is ready for the delivery of the
product in parts or phases.
Software Testing
Explain bug leakage
and bug release.
.
Software Testing
Bug Leakage: When customer or end user discovered a bug which
can be detected by the testing team. Or when a bug is detected
which can be detected in pervious build then this is called as Bug
Leakage.
Bug release: is when a build is handed to testing team with knowing
that defect is present in the release. The priority and severity of bug is
low. It is done when customer want the application on the time.
Customer can tolerate the bug in the released then the delay in
getting the application and the cost involved in removing that bug.
These bugs are mentioned in the Release Notes handed to client for
the future improvement chances.
Software Testing
What is regression testing?
Software Testing
Regression Testing: When changes in the code of the software are
made to fix the previous bug. Then testing needs to be perform to
ensure that it will not generate a new bug in the application and it
works as specified and that it has not negatively impacted any
functionality that it offered previously. Regression Testing is important
because of following reason:
That the application works even after the alteration in the code were
made.
The original functionality continues to work as specified even after
doing changes in the software application.
The alteration to the software application has not introduced any new
bugs.
Software Testing
What is alpha and beta testing?
Software Testing
Alpha testing: is performed by the IN-House developers. After alpha
testing the software is handed over to software QA team, for
additional testing in an environment that is similar to the client
environment.
Beta testing: It is performed by end user. So that they can make sure
that the product is bug free or working as per the requirement. IN-
house developers and software QA team perform alpha testing. The
public, a few select prospective customers or the general public
performs beta testing.
.
.
Software Testing
What are the attributes of good
test case?
Software Testing
The following are the attributes of good test case.
- A good test has a high probability of finding an error. To find the
maximum error, the tester and developer should have complete
understanding of the software and attempt to check all the conditions
that how the software might fail.
- A good test is not redundant. Every test should have a different
purpose from other, otherwise tester will repeat the testing process for
same condition.
- A good test should be neither too simple nor too complex. In general,
each test should be executed separately. If we combine more than
one test into one test case, it might be very difficult to execute.
Sometimes we can combine tests but it may hide some errors.
.
.
.
Software Testing
What does the test strategy
include?
Software Testing
The test strategy includes introduction, resource, scope and schedule
for test activities, test tools, test priorities, test planning and the types of
test that has to be performed..
.
Software Testing
Mention the different types of
software testing?
Software Testing
1. By knowledge of the internals of 4. By positivism of test scenarios
the software - Positive testing
- Black box testing - Negative testing
- White box testing 5. By degree of isolation of tested
- Grey box testing components
2. By the object of testing - Component testing
- Functional testing - Integration testing
- UI testing - System (end-to-end) testing
- Usability testing 6. By degree of automation
- Localization testing - Manual testing
- Load/performance testing - Semi-automated testing
- Security testing - Automated testing
- Compatibility testing 7. By preparedness
3. By time of test execution - Formal/documented testing
- Before any release (alpha - Ad hoc testing
testing)
- After a beta release (beta
testing)
.
Software Testing
What is Test case?
Software Testing
A test case is usually a single step, and its expected result, along with
various additional pieces of information. It can occasionally be a series
of steps but with one expected result or expected outcome. The
optional fields are a test case ID, test step or order of execution
number, related requirement(s), depth, test category, author, and
check boxes for whether the test is automatable and has been
automated. Larger test cases may also contain prerequisite states or
steps, and descriptions. A test case should also contain a place for the
actual result. These steps can be stored in a word processor document,
spreadsheet, database or other common repository. In a database
system, you may also be able to see past test results and who
generated the results and the system configuration used to generate
those results. These past results would usually be stored in a separate
table.
Software Testing
What is Test Suite?
Software Testing
The most common term for a collection of test cases is a test suite. The
test suite often also contains more detailed instructions or goals for
each collection of test cases. It definitely contains a section where the
tester identifies the system configuration used during testing. A group of
test cases may also contain prerequisite states or steps, and
descriptions of the following tests.
Software Testing
What is Ad Hoc testing?
Software Testing
It is a testing phase where the tester tries to break the system by
randomly trying the system’s functionality. It can include negative
testing as well.
Software Testing
What are SDLC phases?
Software Testing
There are following six phases in every Software development life cycle
model:
Requirement gathering and analysis

Design
Implementation or coding
Testing
Maintenance
Software Testing
What is a Review?
Software Testing
A review is an evaluation of a said product or project status to
ascertain any discrepancies from the actual planned results and to
recommend improvements to the said product. The common
examples of reviews are informal review or peer review, technical
review, inspection, walkthrough, management review. This is one of the
manual testing interview questions.
Software Testing
What is compatibility testing?
Software Testing
Compatibility testing is a part of non-functional tests carried out on the
software component or the entire software to evaluate the
compatibility of the application with the computing
environment. It can be with the servers, other software, computer
operating system, different web browsers or the hardware as well.
Software Testing
Explain performance testing?
Software Testing
It is one of the non-functional types of software testing. Performance of
software is the degree to which a system or a component of system
accomplishes the designated functions given constraints regarding
processing time and throughput rate. Therefore, performance
testing is the process to test to determine the performance of software.
Software Testing
What is meant by functional
defects and usability defects in
general? Give appropriate
example.
Software Testing
Let’s take the example of ‘Login window’ to understand functionality
and usability defects.
A functionality defect is when a user gives a valid user name but

invalid password and the user clicks on login button. If the application
accepts the user name and password, and displays the main window,
where an error should have been displayed.
On the other hand a usability defect is when the user gives a valid user
name, but invalid password and clicks on login button. The application
throws up an error message saying “Please enter valid user name”
when the error message should have been “Please enter valid
Password.”
.
Software Testing
What is Code Coverage?
Software Testing
An analysis method that determines which parts of the software have
been executed (covered) by the test case suite and which parts have
not been executed and therefore may require additional attention.
.
Software Testing
What is Code Inspection?
Software Testing
A formal testing technique where the programmer reviews source
code with a group who ask questions analyzing the program logic,
analyzing the code with respect to a checklist of historically common
programming errors, and analyzing its compliance with coding
standards..
Software Testing
What is End-to-End testing??
Software Testing
Testing a complete application environment in a situation that mimics
real-world use, such as interacting with a database, using network
communications, or interacting with other hardware, applications, or
systems if appropriate.
Software Testing
What is Glass Box Testing
Software Testing
A synonym for White Box Testing.
Software Testing
What is Software Requirements
Specification?
Software Testing
A deliverable that describes all data, functional and behavioral
requirements, all constraints, and all validation requirements for
software.
Software Testing
What is Test Plan??
Software Testing
A document describing the scope, approach, resources, and
schedule of intended testing activities. It identifies test items, the
features to be tested, the testing tasks, who will do each task, and any
risks requiring contingency planning.
Software Testing
What is difference between
Smoke testing and Sanity Testing?
Software Testing
The difference between smoke and sanity testing is described below:
Sanity testing is performed when new build is released after fixing bugs
where as smoke testing is performed to check the major functionalities
of the application.
Smoke testing is performed earlier where as sanity is performed after
the smoke testing.
Sanity testing is narrow and deep approach of testing and smoke
testing is focused testing based on major functionalities.
Software Testing
Практическо въведение в софтуерното тестване 
CSCB800, четвъртък 09:40-11:00, зала 702, II корпус
Яна Дамянова, SAP Labs Bulgaria

04.Март.2021
PUBLIC
За какво ще си говорим
▪За мен
▪За вас
▪За курса
▪Какво прави един тестер
▪Качества на добрия тестер
© 2019 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC -2

За мен
Operations
Quality Assurance
Project Coordination
Testing
Travelling
Skiing/Biking

Кои сте вие и какво очаквате?

Къде е пандата?




За какво ще си говорим на курса?
04.Mar.2021 1. Въведение в софтуерното тестване
11.Mar.2021 2. Какво е тестване, термини и процеси?
18.Mar.2021 3. Какви видове тестове има?
25.Mar.2021 4. Какво е test case? Как се пише?
01.Apr.2021 5. Принципи на тестването
08.Apr.2021 6. Как се разработва софтуер и къде се включва тестването?
15.Apr.2021 7. Какво е грешка (bug)? Как да тестваме и защо?
22.Apr.2021 8. Преговор и подготовка за контролната работа
29.Apr.2021 9. Контролна работа №1

За какво ще си говорим на курса?
13.May.2021 10. Как тестваме нова и стара функционалност?

20.May.2021 11. Документацията, свързана с тестването. Защо е важна тя?
27.May.2021 12. Автоматично тестване. Кога да го ползваме и защо?
03.Jun.2021 13. Основи на Linux
10.Jun.2021 14. Контролна работа №2
17.Jun.2021 15. Лекция по избор (или подготовка за изпит)
24.Jun.2021 17. Изпит
Въпрос
Какво според вас прави един тестер?
TESTER = QA?
Въпрос
Какво, според вас, е
софтуерното тестване и контрол на качеството?
Какво представлява тестването?
▪Процесът, при който се проверява дали системата работи коректно

▪Идеята е да се намерят грешки в системата
Какво е контрол на качеството?
▪Всички дейности, свързани с това да се осигури, че процесите по разработка

и/или поддръжка са достатъчно адекватни, за да подсигурят, че продуктът е
направен спрямо изискванията
▪Контролът на качеството се грижи за това да има дефинирани адекватни

процеси
Защо е важно да се тества?
Нещо, което сте си купили и е

имало проблем?
Защо е важно да се тества?
▪Всички грешим
▪Някои грешки са фатални
▪Загуба на пари и доверие
▪Доволни клиенти
▪Предимство пред конкурентите
Какви са необходимите качества на
добрия QA?
Качества на добрия QA
▪Внимание към детайла
▪Внимание към детайла
▪ Комуникация
▪ Вашият колега разработчик е допуснал фатална грешка и
функционалността, която тествате, не работи. Какво точно ще му кажете?
▪Търпение
▪Търпение
▪Вече е минала една седмица, а вашият колега разработчик все още не е
оправил проблема, за който говорихте...
▪Не може да продължите тестването без да го оправи. Усещате ли
напрежение? Какво ще направите?
▪Желание за учене
▪Любопитство
▪Приоритизиране
▪Как да преценя кое да свърша първо?
▪Организация на работата
А сега?
▪Представете си следната ситуация, случваща се в 16 часа следобед:
1. Вашият шеф ви е дал задача, която трябва да се свърши до края на деня

(18 часа)
2. Намерили сте критичен бъг (грешка), който е оправен и трябва да се
тества веднага
3. Ваш клиент се обажда и иска незабавна помощ
▪Какво ще направите?
▪Адаптивност! Но защо?
Въпрос
▪Какви са предимствата на това да бъдем QA?

▪Какво печелим и защо си заслужава?
▪Какъв е пътят на развитие на един QA?
Вдъхновението QA
▪Тестването е предизвикателство
▪С тестването можеш да погледнеш продукта от различни страни, можеш да
бъдеш клиент, разрушител или вдъхновител
▪Доброто тестване е свързано с доволни клиенти
▪Можеш да оказваш влияние и да променяш
▪Тестването ни учи да бъдем много организирани, подредени и
дисциплинирани
▪Предизвикателство е да покрием най-важната функционалност, която може
да даде най-много дефекти и да открием най-добрия тест
▪Тестването ни учи да учим бързо, да се адаптираме и да даваме нови идеи

▪Тестването ни учи да приоритизираме
▪Да анализираме резултати
▪Да търсим там, където другите не виждат
▪Тестването е креативност, динамичност и непрекъсната промяна
▪Тестването ни учи да учим бързо, да се адаптираме и да даваме нови идеи

▪Тестването ни учи да приоритизираме
▪Да анализираме резултати
▪Да търсим там, където другите не виждат
▪Тестването е креативност, динамичност и непрекъсната промяна
Въпроси?
Thank you.
Contact information:
Yana Damyanova
E-mail: yana.doneva@sap.com
Какво е тестване, термини и процеси
11.Март.2021
PUBLIC
▪Преговор
▪Какво е тестване и кой тества?
▪Ръчно и автоматично тестване
▪Митове в софтуерното тестване
▪Verification & Validation - разлики
▪Testing, Quality Assurance и Quality Control
▪Audit и Inspection / Testing и Debugging
▪Тестване и стандарти
Преговор
▪Каква е разликата между тестване и контрол на качеството?

▪Защо тестваме?
▪Какви са необходимите качества за добрия специалист по качеството?
Въпрос
▪Как се тества асансьор?!
Въпрос – как се тества асансьор?
▪Асансьорът трябва да се движи нагоре и надолу

▪Трябва да спира на всеки етаж, за който е извикан
▪Движи се до точно този етаж, за който бутона е натиснат
▪Движи се нагоре, когато е извикан отгоре и надолу, когато се извикан отдолу
▪Чака, когато е натиснат бутона за отваряне на вратите
▪Вратите се затварят, когато се натисне бутона за затваряне на вратите
▪Ако някой стъпи между вратите, докато се затварят, трябва да се отворят
отново
▪Има лимит за тежест, който се обозначен
▪Не тръгва, ако е превишен лимита за тежест – load test?
▪Ако двама човека извикат асансьора от два различни етажа, асансьорът

трябва да отиде до най-близкия етаж първо (т.е., ако асансьорът е на 5тия
етаж, движи се към 8мия етаж, и двама човека го извикат от 7мия и от 2рия
етаж, асансьорът първо трябва да спре на 7мия етаж и след това на 2рия)
▪Трябва да издава сигнал, когато достигне етажа, на който трябва да спре
▪Трябва да показва на кой етаж се намира в момента (вътре в кабината)
▪Трябва да показва на кой етаж се на мира в момента и в коя посока отива
(пред вратите на всеки етаж)
▪Когато влезете в асансьора и не направите нищо първите 10сек, трябва да
се затворят вратите
▪Когато натиснете бутона за етажа, на който искате да отидете, той трябва да

светне
▪Когато асансьорът достигне съответния етаж, той трябва сам да спре и
вратите трябва да се отворят
▪Ако токът спре, асансьорът трябва да спре на най-близкия етаж и да се
отворят вратите
▪Вратите на асансьора трябва да се задържат отворени поне 5сек.
▪Трябва да има авариен бутон
▪Трябва да има работещ авариен телефон
Какво представлява тестването?
▪Тестването е процес на оценка на системата с намерението да се открие

дали тя отговаря на определени изисквания или не
▪Тестването се изпълнява, за да се идентифицират евентуални пропуски,
грешки или противоречия с реалните изисквания
Защо тестваме?
▪За да намерим проблема преди потребителите ни и да го адресираме

▪Ако много потребители открият проблеми, това може да доведе до тяхното
недоволство и до желанието да отидат при конкуренцията ни
▪За да открием бъгове, които не са били оправени
▪Тестването е необходимо, за да се уверим, че продуктът е според
спецификацията
▪За да предотвратим нежелано поведение
▪За да запазим репутацията на фирмата
Кой участва в тестването?
▪В различните фирми процесът е различен

▪Екип по качеството
▪Разработчици, които създават Unit test-ове
▪Тийм лийд
▪Крайни потребители
Кога да започнем да тестваме?
▪Колкото по-рано, толкова по-добре

▪Цената на откритите грешки е много по-ниска, ако ги открием по-рано
▪Добре е тестването да започне още при събирането на изискванията за
продукта и да продължи до даването му на крайния потребител
Waterflow
Agile
DevOps
Задача
▪Разделете се по двойки и си намислете продукт. Нека да е простичък –

химикалка, маса, стол, тетрадка, врата
▪Опишете продукта на партньора си
▪Споделете с нас
Задача
Кога да започнем да тестваме?
▪Тестването може да бъде напрaвено по различно време

▪Анализа и верификацията на изискванията (requirements)
▪Прегледа на дизайна в етапа на създаването му
▪Тестването от разработчика на собствения си код
Кога да спрем да тестваме?
▪Няма 100% изтестван продукт

▪Можем да спрем, при някой от следните критерии:
– Дошъл е крайният срок
– Всички тестови случаи са изпълнени
– Изпълнени са определени функционални тестове, които покриват
определена предварително част от кода
– Откритите проблеми са по-малко от това, с което сме се съгласили в
началото и няма открити проблеми с висок приоритет
–Взето е решение от мениджмънта да се прекрати тестването
Ръчно и автоматизирано тестване
Ръчно:
▪Когато тестването не може да се автоматизира
▪Тестване без скрипт или тул за тестване
▪Тестерът гледа софтуера от гледната точка на краен потребител
▪Има различи етапи и фази
▪Тестерите използват сценарии, планове, тестови случаи, за да тестват
Ръчно и автоматизирано тестване
Автоматизирано:
▪Тестване със скрипт или тул за тестване
▪Автоматизиране на ръчни стъпки
▪Ползва се за повтаряеми стъпки, които са били изпълнявани ръчно
▪Изпълнява се, за да се провери издръжливостта на продукта (load, stress,
performance testing)
▪Пестят се време и пари, повишава се точността
Кога да автоматизираме?
▪За големи критични проекти

▪Неща, които имат нужда да се тестват многократно
▪Изисквания, които не се сменят често
▪Тестване за издръжливост с много потребители
▪Стабилен софтуер
▪Достатъчно време за тестване
▪Местата, които ще бъдат ползвани от много потребители като логон форми и
регистрационни форми, могат да бъдат автоматизирани.
Как да автоматизираме?
▪Като използваме скриптове и тулове

▪Преди да го направим трябва да имаме процес за автоматизация, включващ
следните стъпки:
– За коя част от софтуера ще автоматизираме
– Какъв тул ще ползваме
– Какви скриптове ще пишем
– Как ще развием тестовите сценарии
– Как ще ги изпълняваме
– Как ще записваме резултатите
– Как ще идентифицираме проблемите, свързани с функцията и
поведението
Тулове, които можем да ползваме за автоматизация
▪HP Quick Test Professional

▪Selenium
▪IBM Rational Functional Tester
▪SilkTest
▪TestComplete
▪Testing Anywhere
▪WinRunner
▪LoadRunner
▪Visual Studio Test Professional
Митове за софтуерното тестване
Мит 1: Тестването е твърде скъпо

Истина:
▪колкото по-рано, толкова по-добре
▪ранното тестване пести време и пари
Мит 2: Тестването отнема твърде много време

Истина:
▪самото тестване не отнема време, но оправянето на откритите проблеми е
времеотнемащо
Мит 3: Само напълно разработен продукт може да се тества

Истина:
▪Дори проверка на документацията може да открие потенциални проблеми
Мит 4: Всичко може да се изтества

Истина:
▪Невъзможно е да покрием 100%
Мит 5: Добре изтестваният софтуер няма проблеми

Истина:
▪Няма как да се покрие всичко с тестването
Мит 6: За неоткритите проблеми е виновен тестера

Истина:
▪При промяна на изискванията могат да се появят проблеми
▪Тестоватa стратегия може да доведе до изпуснати проблеми
Мит 7: Тестерите са отговорни за качеството на продукта

Истина:
?
Мит 8: Трябва да се автоматизира на всяка цена, за да се спести време

Истина:
▪Не винаги има смисъл
▪Смяна на изисквания
▪Стабилни ръчни тестове
Мит 9: Всеки може да тества

Истина:
▪Хората, които са разработили софтуера трудно биха намерили креативни
начини за неговото счупване
Мит 10: Единствената работа на тестера е да тества и да намира проблеми

Истина:
▪Тестерите имат поглед върху целия софтуер
Validation and Verification
Software Testing - QA, QC & Testing
Audit and Inspection
Одит:
▪Прави се, за да се определи как действително се провежда процеса на
тестване в рамките на една организация или екип; ревю на документацията,
описващата процесите в една организация
Инспекция:
▪Процесът, при който се проверяват детайлно изискванията за продукта,
дизайна и написаният код на продукта
Testing and Debugging
Тестване:
▪Идентифицирането на грешки, което не включва тяхното опрваяне
Дебъгване:
▪Идентифицирането, изолирането и оправянето на грешки. То се извършва от
разработчиците, когато се окаже, че има грешка в кода.
Стандарти
Много организации включват стандарти за качество, за да осигурят по-добро

качество и сигурност на продуктите си:
▪ISO (International Organization for Standardization)
▪IEC (International Engineering Consortium)
▪IEEE (Institute of Electrical and Electronics Engineers)
Задача
Едно голямо човече и едно малко човече се разхождали в гората.

Малкото човече било син на голямото, но голямото човече не му било баща.
Какво било то на малкото?
Задача
Намирате се в стая без прозорци и херметически затворена (идеално гладка

и без отвори) врата.
Стаята е цилиндрична и вие сте в центъра ѝ.
Цялата вътрешност на стаята е облицована с огледала.
Въпросът е:
Колко свои отражения виждате?
Да преговорим
Кои са 3-те неща, които ще запомните от днес?
Въпроси?
Thank you.
Yana Damyanova
Видове тестване
18.Март.2021
PUBLIC
1. Преговор
2. Видове тестване
▪By knowing internal structure
▪By object of testing
▪By time of test execution
▪By positivism of test scenarios
▪By degree of isolation
▪By degree of automation
▪By level of preparation
Експертът
Какво си спомняте от миналата лекция?
Видове тестване
▪ Black box testing

The black box approach assumes that the tester usually doesn’t know how the back end
was written, so ideas for testing come from expected patterns of user behavior. Expected
patterns of user behavior are scenarios that we expect will be (OR are already) taking
place as users use our software.
– Test Cases are created based on functionalities of the system
– What is the system doing
– Internal structure is not considered, only user behaviour
▪ White box testing
– Test Cases are created based on code structure
– How is the system doing it
▪ Grey box testing
– Combination of both Black and White box testing
– Most effective, increased test coverage
Black box testing
▪The black box approach:

– assumes that the tester usually doesn't know how the back end was written
– ideas for testing come from expected user behaviour
– expected patterns of user behaviour are scenarios that we expect will be (OR
are already) taking place as users use our software
Black box testing
How can we figure out expected patterns of user behavior?

▪We can take them from the specification
▪We can figure them out by exploring
▪Scenarios can be a gift from our intuition. You can just wake up in the middle of
the night and think: “What if a user would do that?” Intuition is one of the greatest
assets that software tester might have.
▪The PM or programmer might give you some valuable ideas.
▪There are many other sources. For example, you can read an article about how
users interact with similar Web sites.
White box testing
White box testing is also known as "glass box testing," "clear box testing," and
"open box testing"
In real life, white box testing usually exists in the form of unit testing performed by
the programmer against their own code.
White box testing
If we simply develop test scenarios using direct ideas from the spec, we will create
legitimate test cases, but those test cases won’t necessarily be effective bug
finders.
Tests based on use case
Black box testing and white box testing are a great combination that helps to find
bugs by improving:
▪Test comprehensiveness - i.e., checking the software from different angles
▪Test coverage
Grey box testing
Grey box testing combines the elements of black and white box testing:
▪On the one hand, the tester uses black box methodology to come up with test
scenarios
▪On the other hand, the tester possesses some knowledge about the back end,
AND they actively use that knowledge
By object of testing – functional testing
Functional Testing
▪ Most common type of testing
▪ Verifies system functionalities
Example:
Here is a typical test case where we just use UI to test logic of the code:
1. Go to www.sharelane.com.
2. Click the "Sign up" link.
3. Type "2008" into "ZIP code" text field and press the "Continue" button.
Expected result:
Error message that ZIP code must have 5 digits.
By object of testing – UI testing
UI Testing
▪ Verify UI is as in specification
Example:
Here is typical test case for UI testing:
1. Go to www.sharelane.com.
2. Click the "Sign up" link.
3. Check the number of characters that can be typed into the "ZIP code"
text field.
Expected result: 5
Do you have examples to share?

Conclusion:
▪ Functional testing is much more important and much more difficult than UI testing.
▪ Most software testing activities are about functional testing
By object of testing – usability testing
Usability Testing
▪ Evaluate user experience with software
▪ Conducted with target group of the software
▪ Tasks are given to people and tasks completion is measured
Example 1: "genius" web site interfaces that are like an intricate puzzle when you attempt
to perform some basic action
Example 2: One of the reasons why folks prefer Facebook to MySpace:

▪ Facebook has a neat, conservative look
▪ MySpace users often abuse their ability to change the look of their Web pages by
producing ugly monsters that hurt your eyes by flashing pictures and white text on a
yellow background
By object of testing – acceptance testing
Acceptance Testing
• Normally this type of testing is done to verify if the system meets the customer
specified requirements
• The user or the customer do this testing to determine whether to accept the
application
Interview TIP
What is the difference between usability testing and user acceptance testing?
PUBLIC
By object of testing – usability testing
Usability Testing - to find errors in the system

User Acceptance Testing - to prove that the system is ready
▪Usability testing
– is usually confined in a laboratory setting/strictly observable environment
– selected users perform certain tasks and the usability engineer makes notes,
observations, interviews, etc.
– can also involve something more, such as intensive recording - eye-tracker,
hand-movement, etc.
– can evaluate different aspects of your application and test its usability
By object of testing – user acceptance testing
Usability Testing - to find errors in the system

User Acceptance Testing - to prove that the system is ready
▪User Acceptance testing

– think of it is as alpha/beta testing
– it is open to a wider audience, usually concerns with feedback on how usable
the system is, comments, suggestions, ratings, etc.
– they are not in strictly observable environment and do not involve high end
observational values such as eye-tracking (as you would have guessed, given it
is open to a wider audience etc).
By object of testing – localization testing
Localization Testing
▪ Adaptation of software for different locations

▪Verify UI in case of different translations
▪Handling of different input text encoding
Example:
If our Web site was created for an English-speaking audience and we want to
localize it for a Japanese-speaking audience, we’ll have to check if Kanji symbols
can be used to create a username.
http://msdn.microsoft.com/en-us/library/aa292138(v=vs.71).aspx
Examples from real life
Usable vs Beautiful
Similarity
Conventions
Make things obvious
By object of testing – performance testing
Performance testing is done to:

▪check the response time of our Web site or its components
▪find and remove/workaround bottlenecks
Performance testing should have specific objectives:

▪can the system handle 100 simultaneous users with response time < 1 second
and no error?
▪how the system behaves with 1000 users?
▪when will the system crash?
▪what is the slowest module of the system?
By object of testing – performance testing
Types of performance testing
▪Load Testing is a type of performance testing conducted to evaluate the

behavior of a system at increasing workload.
▪Stress Testing a type of performance testing conducted to evaluate the behavior
of a system at or beyond the limits of its anticipated workload.
▪Endurance Testing is a type of performance testing conducted to evaluate the
behavior of a system when a significant workload is given continuously.
▪Spike Testing is a type of performance testing conducted to evaluate the
behavior of a system when the load is suddenly and substantially increased.
By object of testing – security testing
Security Testing
▪Security testing refers to testing the protection against security breaches

▪It checks to see if the application is vulnerable to attacks, if anyone hack the
system or login to the application without any authorization
▪It is a process to determine that an information system protects data and
maintains functionality as intended
▪Simulates hacker attacks
By object of testing – security testing
Example :
▪Log into the web application.
▪Log out of the web application.
▪Click the BACK button of the browser (Check if you are asked to log in again or if
you are provided the logged-in application.)
▪Most types of security testing involve complex steps and out-of-the-box thinking
but, sometimes, it is simple tests like the one above that help expose the most
severe security risks.
▪More info here:

http://softwaretestingfundamentals.com/security-testing/
By object of testing – compatibility testing
Compatibility Testing
▪ Test with different OS or browser
▪ Most common OS/Browser combinations are fully tested
▪ Statistics are used to determine most common combinations
1. Compatibility testing involves a variety of third party hardware and/or software with
which our software must be tested.
2. Compatibility problems are a reality, and a user might have a really bad experience
because of those problems.
3. For a Web project, it’s a good idea to have a test lab with computers that have different
OS and Web browsers.
By object of testing – sanity testing
Sanity testing
▪determine if a new software version is performing well enough to accept it for a

major testing effort
Example:
When a new release/version of the software is uploaded on the test environment
By object of testing – regression testing
Regression testing
▪Testing if old functionality is not affected by new functionality or bug fixes
Example:
Usually it is performed against new versions of the product after the new
functionality is tested or re-testing of bugs is performed
By object of testing – installability testing
Installability Testing
▪Checks the guideline provided in the installation document if it is suitable for
installing the application into environment properly or not
3 main cases to be considered:

▪Install the software on a clean machine
▪Upgrade to an already existing version
▪Uninstall the software
Other cases:
▪Disk space not enough
▪OS not supported
By object of testing – stress testing
Stress testing
▪System is stressed beyond its specifications to check how and when it fails.
▪Performed under heavy load like putting large number beyond storage capacity,
complex database queries, continuous input to system or database load.
Time and way of execution
Alpha Testing
▪Takes place at developers' sites
▪Simulated or actual operational testing
▪Real customers or independent test team
▪Outside development organisation
Beta Testing
▪Takes place at customers' sites
▪Operational testing by potential or existing customers
▪Good for feedback gathering
Positivism
Positive Testing
▪Executed first to verify system functions as expected
▪Different use case scenarios are covered
Negative Testing
▪Test system response in case of
errors made by users
▪Verify error messages are useful for users and support
▪Many negative combinations are possible
▪More bugs are found by negative testing
Testing by degree of isolation
Component Testing
▪Component is minimal software that can be tested in isolation
▪Test component to ensure it functions as per specification
Integration Testing
▪Functional testing of the interaction between two or more integrated components
System (end-to-end) Testing

▪Functional testing of a logically complete path consisting of two or more
integrated components.
▪Testing of the system as a whole
Testing by degree of isolation – component testing
Component Testing
▪Component testing is a method where
testing of each component in an application
is done separately.
▪Suppose, in an application there are 5
components
▪Testing of each 5 components separately
and efficiently is called as component testing
Example:
Program code is needed
▪to find the full names and emails of all users who spent more than $1000
shopping at ….
▪send those users an email with a gift certificate (gift code) giving them a 5%
discount on a single purchase
▪those certificates will be able to be used through November 17th. This feature is
called "5% discount"
Example:
Program code is needed
▪Component 1: Generation of certificate codes and the generation of a data file
with names and emails
▪Component 2: Generation of and sending emails
▪Component 3: Usage of certificate codes
Testing by degree of isolation – integration testing
Integration testing
Component 1 -> Component 2 (data file generated by
Certification_generator.java is used by Certification_sender.java)
Component 2 -> Component 3 (certificate code taken from email message

constructed and delivered by Certification_sender.java is used to get 5% discount)
Component 1 -> Component 3 (certificate code generated by

Certification_generator.java is used to get 5% discount)
Testing by degree of isolation – system testing
System (end-to-end) testing

Component1 - > Component 2 - > … - > Component n
Testing by degree of automation
Manual Testing
▪Test cases, test data are created and executed manually
Automation Testing
▪Test cases are executed by automation testing tools
▪Automation test cases are created manually can be automated
Testing by degree of preparedness
Formal/Documented Testing
▪Planned and documented testing effort
▪Test cases are mandatory
Ad-hoc/Exploratory Testing
▪Testing performed without any planning or specific purpose
▪Testing is performed without any test cases
▪Depends on QA experience and imagination
▪Can catch interesting bugs
Summary
1. By knowledge of the internals of the software

▪ Black box testing
▪ White box testing
▪ Grey box testing
2. By the object of testing
▪ Functional testing
▪ UI testing
▪ Usability testing
▪ Localization testing
▪ Load/performance testing
▪ Security testing
▪ Compatibility testing
Summary
3. By time of test execution

▪ Before any release (alpha testing)
▪ After a beta release (beta testing)
4. By positivism of test scenarios
▪ Positive testing
▪ Negative testing
5. By degree of isolation of tested components
▪ Component testing
▪ Integration testing
▪ System (end-to-end) testing
Summary
6. By degree of automation
▪ Manual testing
▪ Semi-automated testing
▪ Automated testing
7. By preparedness
▪ Formal/documented testing
▪ Ad-hoc testing
Questions
▪What is the main difference between black box testing and white box testing?
▪What are advantages of grey box testing?
▪What are the benefits of using black, grey and white box testing techniques
against the same piece of code?
▪Why in your opinion ad-hoc testing often brings amazing bug finding results?
▪What is the difference between positive testing and negative testing?
▪What is the difference between component and integration testing?
Въпроси?
Thank you.
Yana Damyanova
Test Cases
25.Март.2021
PUBLIC
1. Какво е Test Case

2. Примери
3. Ползи от писането на test cases
4. Структура на test case-a
5. Резултат от изпълнението на test cases
6. Поддръжка на test cases
7. Видове test cases
8. Добри и лоши практики
9. Test suite
10. Домашно
Какво е Test Case?
▪Преди да отида на фестивала по народни танци, направих следния списък:

– дрехи за танци
– обувки за танци
– колан за танци
– цвете за косата
– бутилка вода
– дребни неща за хапване
– кърпа
▪ Утре сутринта ще взема списъка и ще проверя дали всичките 7 неща са в
раницата ми
▪Всяко нещо в списъка е Test Case

▪Самият списък е Test Suite
▪Процесът на измисляне и записване на всяко нещо в списъка, е генериране
на Test Case
▪Процесът на проверка на раницата за наличието на всяко нещо от списъка,
е изпълнение на Test Case-a
▪Но в света на софтуерното тестване, имаме нужда и от инструкции как да

постигнем резултата, който трябва, и точно това прави Test Case-a
▪Задача:
Как ще генерирате процес стъпка по стъпка, за да тествате дали химикалката
ви пише както трябва?
Какво е Test Case? - задача
▪Какво ни трябва?
– лист хартия
▪Стъпки:
1. Взимаме химикалката
2. Включваме я
3. Пишем нещо на листа
4. Проверяване дали написаното е гладко, без прекъсване на мастилото по
време на писане
Какво е Test Case? - задача
▪Какъв е очакваният резултат?

▪Какъв е постигнатият резултат?
Резултат от изпълнението на Test Case-а
▪Изпълнението на test case-a е приключило, когато сме сравнили очаквания

резултат с постигнатия резултат
▪ Възможни статуси след изпълнението:
– PASS – когато постигнатият резултат е равен на очаквания резултат
– FAIL – когато постигнатият резултат не е равен на очаквания резултат
– BLOCKED – когато има бъгове или други причини, които не ни позволяват
да изпълним test case-a
▪FAIL test cases имат нужда от последващо проучване на причината за

провала
– основни причини могат да бъдат промени по продукта, които не са били
комуникирани с тестера, грешно дефинирани очаквани резултати или
истински бъг в софтуера
Резултат от изпълнението на Test Case-а
▪ ISTQB (International Software Testing Qualifications Board) дефиниция:

A set of input values, execution preconditions, expected results and execution post-conditions,
developed for a particular objective or test condition, such as to exercise a particular program path
or to verify compliance with a specific requirement.
▪ Друга дефиниция:
Set of conditions or variables under which a tester will determine whether an application, software
system or one of its features is working as it was originally established for it to do.
▪ Test case дефиниция (as per IEEE 610):

– Pre-conditions
– Set of input values
– Set of expected results
– How to execute the test and check the results
– Expected post-conditions
Групова задача
1. Изберете си съществуващ ваш e-mail account. Може да си направите и

тестов.
2. Тестът ви трябва да описва и валидира опит за влизане в съществуващ e-
mail account с неправилна парола.
Стандартни полета на Test Case template-а
▪Test case ID
Уникално ID за всеки test case. Следвайте някаква конвенция за именоване
на типа на теста. Например, ‘TC_UI_1’ което показва ‘test case user interface
#1’.
▪Test priority (Low/Medium/High)

Това е полезно по време на изпълнението на теста. Приоритетът на
фукционалните test cases и бизнес логиката обикновено е Medium или High,
докато по-малки user interface cases могат да бъдат Low приоритет.
▪ Module Name
Името на главният модул или sub module-а.
▪ Test Designed By
Името на тестера
▪ Test Designed Date

Датата, на която трябва да се пусне теста
▪ Test Title/Name
Името на test case-a. Например, “Verify login page with valid username and password”
▪ Pre-condition
Условията, които трябва да бъдат изпълнени преди изпълнението на test case-а.
▪ Dependencies
Тук са споменати всякакви зависимости към други test case-ове или test изисквания
▪ Test Summary/Description
Кратко описание теста
▪ Test Data
Данни, които да се използват за test case-а. Например, може да има различни сетове
от данни с конкретни стойности, които да бъдат използвани
▪ Test Steps
Подробен, последователен списък на стъпките за изпълнение на теста
▪ Expected Result
Детайлно описание на очаквания резултат след изпълнение на теста
▪ Post-condition
В какво състояние трябва да бъде системата след изпълнение на този test case?
▪ Actual result
Реалният резултат след изпълнението на теста и описание на поведението на системата като последствие
▪ Status (Pass/Fail)
Ако реланият резултат е различен от очаквания, тестът трябва да е маркиран като FAILED, противен случай, е PASSED
▪ Test Executed By
Тестерът, който е изпълнил теста
▪ Test Execution Date

Датата на изпълнение на теста
Revision History
▪Полезно е да се пази история на промените на test case-а
▪Трябва ви следната информация:

Created (date/name) – кога е създаден test case-a
Modified (date/name) – кога и от кой е бил променен
Reason – какво и защо е било променено
Задача
▪Използвайте Template-a (в Moodle) и се опитайте да направите test case за

теглене на пари от ATM
Поддръжка на test cases
▪Поддръжка – Test case-овете като правило са лесни за промяна, когато има

промени в софтуера
▪Добри практики за лесна поддръжка

– Документиране на стъпките на test case-a – важно е, особено когато
имаме големи test case suites и големи проекти. Обикновено
информацията се съхранява в т.нар. Knowledge base
– Колкото по-детайлно е описанието, толкова по-добре
– Всяка информация, касаеща изпълнението на test case-а е добре дошла,
особено за нови хора, които се заемат с изпълнението му
Допустим брой Очаквани резултати
▪В идеалния случай, е добре да има само ЕДИН очакван резултат на test

case
▪Реално, обаче, може да има и повече от един очакван резултат
▪Добра практика е очакваните резултати да са сведени до 1-3 за всяка
стъпка
▪Само сходни очаквани резултати е добре да се комбинират
Лоши практики
▪Според вас, какви са лошите практики при писане на test cases?
▪Зависимости между test case-ове

– ако вашият test case зависи от резултата на изпълнението на други test
case-ове
▪Лошо описание на стъпките на test case-a

– не са ясни и конкретни
– могат да се изпълнят само от автора
▪Лошо описание на test case-a и/или очакваните резултати

– използване на референции към външни документи в описанието или в
описанието на очакваните резултати
– идеята е да има добро описание, не го пропускайте
– Очаквани Резултати: “everything is ok” не е особено добро описание на
един очакван резултат
– Очаквани Резултати: трябва да са достатъчно ясни и прецизни
Добри практики
▪Според вас, какви са добрите практики при писане на test cases?
▪Независимост на test cases

▪Ясно и прецизно описание на стъпките на test case-а
▪Ясна идея и/или Expected Results
▪Написаните test cases трябва да са достатъчно лесни за разбиране и за
изпълнение от всеки, който ги вземе за изпълнение
▪Добре е да се покрият първо позитивните сценарии
▪Не е хубаво да има излишни стъпки
▪Test case-овете трябва да са сравнително кратки и да са описани с прости
изречения
▪Трябва да има някаква конвенция за наименование на test case-овете
▪Според вас, какви са ползите от писането на test cases?
Ползи от писането на test cases
▪Процесът на планиране, дизайн и писане на test cases
▪Проследяване на изискванията
▪Проследяване на извършеното тестване
▪Възможност за преизползване
▪Одит на дизайн фазата преди имплементацията
Кога пишем test cases и от къде взимаме идеи
▪Колкото по-рано се напише един test case, толкова по-добре

▪В най-добрия случай, трябва да използваме документацията с изискванията
и use cases, или сценариите на използване
Видове test cases
Категории по ниво на детайлност
▪ High Level
Няма нужда от въвеждане на данни, но има конкретни стъпки и очаквани резултати
Всеки QA може да го изпълни по различен начин и да намери нови грешки
Лесна поддръжка
Не гарантира особено голямо покритие на функционалностите
▪ Low level
Има нужда от въвеждане на конкретни данни
Има детайлни стъпки за изпълнение и очаквани резултати
Изпълнението е абсолютно еднакво всеки път
Трудни за поддръжка
Ясно е точно коя функционалност е покрита
Видове test cases
Категории по Очаквани резултати
▪ Positive
Проверка дали функциите работят коректно
Покриват основните стъпки, през които преминава ползвателя
Подсигуряват, че клиента получава това, което трябва
Трябва да се изпълняват винаги (редовно)
▪ Negative
Проверява дали системата ще загине при въвеждане на невалидни данни
Проверява как се държи системата при некоректно ползване
Негативните test cases трябва да бъдат опивани след позитивните
Обикновено се изпълняват на критични системи (Canary)
Test suite
Test suite-ът е:
▪Контейнер, който съдържа сет от тестове, които помагат на тестера при
изпълнение и репортване на статуса на изпълнение на тестовете
▪Може да има следните статуси: Active, In Progress, Completed
▪Един Test Case може да бъде добавен в няколко Test Suites и Test Plans
▪След създаването на Test Plan, се създават Test Suites, които могат да
съдържат произволен брой Test Cases
▪Test Suites обикновено се създават въз основа на тест фазата
Test suite
Домашно
▪Създайте test cases за проверка на налични средства по сметка на ATM.

Използвайте темплейта. Изпратете ми резултата по мейл.
Въпроси?
Thank you.
Yana Damyanova
Принципи на тестването 
Април 01, 2021
INTERNAL
▪ 7 принципи на тестването
▪ Разликата между грешка, дефект и неуспех в софтуерното тестване
▪ Какъв е фундаменталният процес на тестване на софтуер
▪ Техники за тестване
© 2021 SAP SE or an SAP affiliate company. All rights reserved. ǀ INTERNAL -160
Publi
Publi
Въпрос от интервю
Един човек се настанява в хотел.
Отива си в стаята.
Там има бюро, стол, лампа, легло, часовник, прозорец, врата.
Погледнал колко е часът и легнал да спи. Събудил се през нощта. Отишъл на рецепция и
казал: „В стаята ми има труп“.
Какво е накарало човекът да се събуди през нощта и да потърси трупа?
Publi
7 принципи на тестването
Принципите:
1. Тестването показва наличието на дефекти
2. Изчерпателното тестване е невъзможно
3. Ранното тестване е препоръчително
4. Събиране на подобни дефекти
5. Парадокс на пестицидите
6. Тестването зависи от контекста
7. Заблуда при липсата на грешки
Publi
1. Тестването показва наличието на дефекти

▪ Тестването може да покаже дефекти, които са на лице
▪ Тестването не може да докаже, че няма дефекти
▪ Дори когато изтестваме апликацията или продуктът из основи, не можем да кажем, че той е
100% без дефекти
▪ Тестването винаги редуцира броят на неоткрити дефекти, които остават в софтуера
▪ Ако не сме открили никакви дефекти, това въобще не означава, че няма такива
Publi
2. Изчерпателното тестване е невъзможно

▪ Тестването на всичко, включително и всички комбинации от входящи данни и
предварителни изисквания, не е възможно
▪ Вместо да тестваме изчерпателно, можем да фокусираме усилия върху най-приоритетните
и високорискови тестове
Например: в дадена апликация има страница, на която се намират 15 полета за въвеждане

на данни, всяко от които има по 5 възможни стойности. Така че за да тествате всички
възможни комбинации, ще ви трябват 30517578125(515) теста. Много малко вероятно е
времето за изпълнение на проекта да ви позволи да направите толкова много тестове.
▪ Оценка и управление на риска са едни от най-важните дейности и причини за тестване на

всеки проект.
Publi
3. Ранното тестване е препоръчително

▪ В жизненият цикъл на разработката на софтуера, дейностите по тестване трябва да
започнат възможно най-рано и трябва да бъдат ориентирани към вече дефинираните цели
Publi
4. Събиране на подобни дефекти

▪ Малък брой модули събират в себе си повечето дефекти, които биват откривани по време
на тестването преди издаване на готовия продукт; или показват най-много оперативни
грешки
Publi
5. Парадокс на пестицидите
▪ Ако еднакъв вид тестове се повтарят отново и отново, с времето тези тестове няма да могат
да намират нови грешки
▪ За да се превъзмогне този „парадокс на пестицидите“, е наистина много важно редовно да
се преглеждат тестовете, както и да се добавят нови и различни тестове, за да има
потенциал в откриването на повече дефекти.
Publi
6. Тестването зависи от контекста

▪ Тестването основно зависи от контекста
▪ Различни видове софтуер или уебсайтове биват тествани по различен начин. Например,
софтуер, който е критичен за безопасността или за здравето, се тества по различен начин
от уебсайт за електронна търговия.
7. Заблуда при липсата на грешки

▪ Ако софтуерът е неизползваем и не покрива нуждите и очакванията на клиента, тогава
намирането и оправянето на дефекти, няма да помогне и няма да има смисъл.
Publi
ЗАДАЧА
Как ще изтествате този стол?
Publi
ЗАДАЧА
За какво да проверите…
▪ Има ли 5 крака?
▪ Колко тежест може да поеме?
▪ Удобен ли е столът за почивка?
▪ От какъв материал е направен столът?
▪ Разполага ли с колелца и колко на брой са те?
▪ Има ли възможност за наклон на облегалката?
▪ До колко градуса се накланя облегалката?
▪ Има ли опора за главата?
▪ Може ли да се променя височината на облегалката?
▪ Може ли да се променя височината на подлакътниците?
▪ Може ли да се променя височината на седалката?
▪ Материята има ли перфорация за преминаване на въздух?
Publi
ЗАДАЧА
Проверка на уеб сайт за грешки

▪ Изберете уеб сайт, който посещавате сравнително често
▪ Погледнете го с око на тестери
▪ Помислете как може да бъде подобрен
Имате 15 минути
▪ Ако ви трябва вдъхновение, може да пробвате:

▪ Сладкарници Неделя
▪ Заведение Петлето
▪ Мобилната версия на gabco
Publi
Разликата между
грешка, дефект и повреда
(error, defect and failure) в софтуерното тестване
Publi
Разликата между грешка, дефект и повреда в софтуерното тестване
Грешка (error)
▪ Грешките, допуснати от разработчиците на софтуер, се наричат ERRORs. Такива грешки
могат да възникнат:
▪ При разминаване в разбирането на функционалността на софтуера
▪ При неправилна калкулация на стойности
▪ Поради неправилна интерпретация на стойност или функция и т.н.
Publi
Разликата между грешка, дефект и повреда в софтуерното тестване
Дефект (defect)
▪ Бъговете, които да допуснати от разработчиците на софтуера, в кода, са дефекти.
▪ Могат и да са в следствие на програмни грешки.
Повреда (failure)
▪ Ако по някаква причина дефектният код се изпълни от тестера по време на тестване, това
ще доведе до софтуерна повреда (software failure).
Publi
Какъв е фундаменталният тестови процес?
Тестването
Е процес, а не еднократна активност.
Започва с планиране на самото тестване и продължава с дизайн на тестовите случаи,
подготовка за изпълнение и оценка на статуса до затваряне на тестовата фаза.
Може да разделим дейностите по следния начин:
▪ Планиране и контрол
▪ Анализ и дизайн
▪ Имплементация и изпълнение
▪ Оценка на изходните критерии и докладване на резултатите
▪ Активности по затваряне на тестовата фаза
Publi
Тестови процес – Планиране и контрол
Планиране
Включва следните по-големи задачи:
▪ Да се определят обхвата и рисковете и да се идентифицират целите на тестването
▪ Да се определи подходът за тестване
▪ Да се приложи тестова политика и/или тестова стратегия
▪ Да се разбере какви ресурси са нужни – хора, тестова среда, компютърна мощност и др.
▪ Да се назначат задачи за тестови анализ и дизайн, изпълнение и оценка на тестовете
▪ Да се определят изходните критерии
▪ Да се определи процентът на тестово покритие
Publi
Тестови процес – Планиране и контрол
Контрол
Включва следните по-големи задачи:
▪ Да се измерят и анализират резултатите от тестването
▪ Да се наблюдава и документира прогресът, покритието на тестовете и изходните критерии
▪ Да предоставя информация по прогреса на изпълнение на тестовете
▪ Да се задействат процеси по взимане на мерки за поправка на грешките, произлезли от
изпълнените до сега тестове
Publi
Тестови процес – Анализ и дизайн
Анализът и дизайнът на тестовете

Включват следните по-големи задачи:
▪ Да се прегледа тестовата база
Тестовата база включва информацията, която ни е нужна, за да запоочнем тестовия анализ и
да създадем свои тестови случаи. Като цяло, това е документацията, върху която са
базирани тестовите случаи - изисквания, дизайн спецификация, анализ на продуктовия риск,
архитектура и интерфейси
▪ Да се идентифицират условията не тестване
▪ Да се направи дизайн на тестовете
▪ Да се направи оценка дали системата е достатъчно стабилна, за да бъде тествана
▪ Да се направи дизайн на тестовата среда, нейната подготовка, и да се разбере каква
инфраструктура е нужна
Publi
Тестови процес – Имплементация и изпълнение
Имплементацията и изпълнението на тестовете

Включват изпълнение на следните елементи на база на тестовите условия:
▪ Тестови случаи и процедури
▪ Скриптове за автоматизация
▪ Подготовка на тестова среда и инфраструктура
▪ Изпълнение на тестовете според установените вече процедури
▪ Преизпълнение на тестовете в случай, че има такива, които са се „счупили“ – това се
нарича повторно тестване (confirmation testing, re-testing)
▪ Записване на резултатите от изпълнение на тестовете. Тези резултати се записват в т.нар.
test log, който може да се използва за последващ одит.
Publi
Тестови процес – Оценка на изходните критерии и докладване на
резултатите
Въз основа на оценката на рисковете на проекта, поставяме критерии за всяко ниво на

тестване, след което да можем да кажем, че тестването е „достатъчно“. Тези критерии
варират от проект на проект и се наричат изходни критерии. Идват на дневен ред, когато:
▪ Са изпълнени максимален брой тестови случаи с определен процент на успеваемост
▪ Крайният срок е достигнат
▪ Нивото на грешки, които са открити, падне под определена степен
Задачите по време на оценката могат да бъдат следните:

▪ Да се проверят логовете от изпълнението на тестовете и да е сравнят с изходните критерии
▪ Да се направи оценка дали има нужда от повече тестове
▪ Да се направи оценка дали изходните критерии имат нужда от промяна
▪ Да се напише репорт за заинтересованите от тестването страни
Publi
Тестови процес – Активности по затваряне на тестовата фаза
Включват изпълнение на следните елементи:

▪ Проверка дали всъщност планираното е изпълнено
▪ Проверка дали всички инциденти са вече разрешени
▪ Прехвърляне на тестовете към организацията за поддръжка, ако съществува такава
▪ Оценка на процесът по провеждане на тестването и отбелязване на процеси, които могат в
бъдеще да бъдат подобрени
Publi
Техники на тестване – Black Box – Equivalence Partitioning
Разделяне по еквивалентност
▪ Може да бъде използвано във всяко ниво на тестване и обикновено е добра техника като за
начало
▪ Идеята е да се раздели набор от условия за изпитване на групи, които могат да се считат за
еднакви, или еквивалентни – тоест „разделяне по еквивалентност“. Може да го срещнете
като EP, Equivalence Partitioning, Equivalence Classes – всичко това се отнася за едно и
също нещо
▪ В тази техника трябва да тестваме едно условие от всяка група 
Publi
Пример
▪ Спестовна сметка в банка има различни проценти на лихва спрямо това колко ви е
балансът на сметката. За да тествате дали софтуерът смята правилно лихвеният процент,
може да отделите няколко групи:
▪ 3% лихва, ако балансът на сметката е от $0 до $100
▪ 5% лихва, ако балансът на сметката е от $1000 нагоре
▪ Така ще имаме три валидни групи и една невалидна: 
Publi
Пример
▪ Искате да купите самолетни билети за вас и приятелите ви
▪ Резервационната система ви позволява да закупите до 10 билета наведнъж
▪ Невалидните групи са ви стойностите под 1, например 0, и над 10, например 11. Както може
да се включи и група от трицифрени числа, например 100 и -100. 
Publi
Техники на тестване – Black Box – Boundary Value Analysis (BVA)
Анализ на гранична стойност

▪ Базира се на тестване на гранични стойности между дялове
▪ Тук имаме и валидни гранични стойности (във валидни дялове), и невалидни гранични
стойности (в невалидни дялове)
Пример
Представете си принтер, който може да принтира между 1 и 10 копия. За да приложим
анализа на гранична стойност, ни трябва минималната и максималната стойност (гранична)
от валидния дял (в случая – 1,2 и 9,10), заедно с първата или последната стойност от всеки
невалиден дял граничещ с валиден такъв (в случая – 0 и 11).
Publi
Техники на тестване – Black Box – Boundary Value Analysis (BVA)
Publi
Техники на тестване – Black Box – Decision Table
Таблица за взимане на решения

▪ Прецизен и в същото време компактен начин за решаване на сложни казуси, както и
определяне на действията в следствие на решаването на тези казуси
Пример
Предоставяте лоялна карта за отстъпки на клиентите си и имате следните правила:
▪ Всеки нов клиент получава 15% отстъпка
▪ С лоялна карта всеки клиент получава 10% отстъпка
▪ Всеки, предоставил ваучер за отстъпка, получава 20% отстъпка
Publi
Техники на тестване – Black Box – Decision Table
Пример
Може да разделите правилата на общо 8.
▪ Забележете, че имаме Х в клетките с намаление на правило 1 и 2. Защо? Защото не може
да дойде нов клиент, който да има и карта за лоялност. Но пък правило 3 е възможно – да
имаме нов клиент БЕЗ карта за лоялност, но с ваучер за намаление. В случая
предполагаме, че според правилата на фирмата не можем да комбинираме отстъпки, и за
това предоставяме по-голямата отстъпка на стойност 20%.
Publi
Техники на тестване – Black Box – State Transition Testing
Тестване на преходно състояние

Системата, която тествате, може да има определен брой статуси и преходът между всеки от
тях се определя от правилата. Всяка система, която ви предоставя различен резултат след
подаване на еднакви данни, спрямо това, което се е случило преди това, се нарича система с
определен брой статуси.
Publi
ЗАДАЧА
Според следната диаграма, кое от следните последователни действия е НЕВАЛИДНО и би
индикирало проблем с дизайна на системата за онлайн поръчка:
A. Login, Browse, Basket, Checkout, Basket, Checkout, Pay, Logout
B. Login, Browse, Basket, Checkout, Pay, Logout
C. Login, Browse, Basket, Checkout, Basket, Logout
D. Login, Browse, Basket, Browse, Basket, Checkout, Pay, Logout
Publi
ЗАДАЧА
Според следната диаграма, кое от следните последователни действия е НЕВАЛИДНО и би
индикирало проблем с дизайна на системата за онлайн поръчка:
A. Login, Browse, Basket, Checkout, Basket, Checkout, Pay, Logout
B. Login, Browse, Basket, Checkout, Pay, Logout
C. Login, Browse, Basket, Checkout, Basket, Logout
D. Login, Browse, Basket, Browse, Basket, Checkout, Pay, Logout
Publi
Техники на тестване – Black Box – Decision Table - ДОМАШНО
Създайте таблица за взимане на решения със следните условия:

▪ Пасажери под 2г. възраст получават 80% намаление на вътрешни полети
▪ Пасажери под 2г. възраст получават 70% намаление на международни полети
▪ Пасажери на възраст между 2г. и 16г. получават 10% намаление за всяка дестинация
▪ Пасажери с карта за лоялни клиенти получават 20% намаление за всяка дестинация
▪ За международни полети, пасажерите получават 15% намаление, ако пътуват извън сезона
▪ Няма намаление за международните полети, освен ако пасажерите не са между 0г. и 16г.
или не пътуват извън сезона
▪ Пасажери, които са направили резервация 5 месеца преди датата на отпътуване получават
10% отстъпка
▪ Пасажери, които са направили резервация 5 месеца преди датата на отпътуване и имат
карта за лоялни клиенти получават 15% отстъпка
▪ Отстъпките се акумулират
▪ Максималната отстъпка за пасажерите до 16г. е 80%, а за всички останали – 20%.
Publi
Въпроси?
Publi
Thank you.
Яна Дамянова
yana.doneva@sap.com
Software Development Lifecycle 
Жизненият цикъл на разработката на софтуер
Yana Damyanova, SAP Labs Bulgaria
08.April, 2021
INTERNAL
За какво ще си говорим?
1. Идея и изисквания
2. Дизайн
3. Код
4. Тестване и поправяне на грешки
5. Релийз и поддръжка
6. Waterfall
7. V-model
8. Agile
9. Scrum
10. Dev-Ops
Интро
Жизненият цикъл на разработката на софтуер

(SDLC) е рамка, определяща задачите,
изпълнявани на всяка стъпка в процеса на
разработка на софтуер.
SDLC е структура, последвана от екип за

разработка в рамките на софтуерната
организация.
Състои се от подробен план, описващ как да се

разработи, поддържа и заменя конкретен
софтуер.
Идея и изисквания
Описание на целта
▪ „Би било хубаво да имаме тези функционалности в нашия уеб сайт“
▪ Идеите идват от:

– Маркетинг или продуктов мениджмънт
– Потребители или клиенти
– Всеки във фирмата - няма такова нещо като „тъпа идея“
– Конкуренти
Идеите, ако бъдат приети, се формализират и се превръщат в Изисквания:

„Това са функционалностите, които ще имплементираме в нашия уеб сайт.“
Дизайн / Планиране
Описание на начина, по който да постигнем целта

▪ След като изискванията са събрани от клиента, се създава документ за обхвата, в
който се определя и документира обхвата на проекта.
▪ Изисквания и спецификации
– BRD (Business Requirements Design)
– MRD (Marketing Requirements Document)
– PRD (Product Requirements Design)
– FSD – Functional Specifications Document; PSD - Product Specifications Document;
SRS - Software Requirements Specification 
▪ Разликата между идея и дизайн

– Идеята е описанието на целта: „Искам хората да могат да правят това и това.“
– Дизайнът е описанието на начина, по който да се достигне тази цел: „За да могат
хората да правят това и това, трябва да направим следното…“
Спецификацията има следните характеристики

▪ Заглавие, например „Функционални подобрения на Търсенето“
▪ Уникален идентификационен номер, например #8765
▪ Хубаво е да бъде разделена на секции
▪ Трябва да има приоритет, който обикновено се поставя от продуктовия мениджър
▪ Трябва да има логическа структура и пълнота
▪ Не трябва да има място за интерпретации
▪ Трябва да отговаря на бизнес практиките и законите
След одобряване на спецификацията:

• Не трябва да има промени
• Ако се наложат промени, те трябва да бъдат комуникирани до целия екип,
включително QA и Operations
• Ако се стигне до промени, те биха могли да доведат до появата на бъгове
• Колкото по-рано се въвлече QA в планирането, толкова по-добре
Код / разработка на софтуера
Софтуерните инженери започват да пишат кода според изискванията на клиентите.

Задачите по време на този процес може да включват:
• Реализиране на идеите по спецификацията
• Архитектурен дизайн на документацията
• Инспекция на кода
• Планиране
• Стандарти на кода
• Контрол на версията на кода (git, mercurial, etc.)
• Среда за писане на код
• Код ревю
• Юнит тестове (unit tests)
Тестване и поправяне на грешки
Това е процесът на намиране на дефекти или грешки в създадения софтуер и

включва:
• Тестване, когато кодът вече е стабилен. Тестване на нестабилен код е загуба
на време.
• Подсигуряване, че има подходяща среда за тестване с коректна версия на
кода
• Бъговете се поправят и се тества наново
• Тестове за регресия
• Acceptance тестове от клиента
Релийз и поддръжка
Релийз, или т.нар. пускане на готовия софтуер може да се случи наведнъж или
на части:
• Алфа версия
• Бета версия
• Кандидат за пускане (release candidate)
• GA (general availability) – когато софтуерът е готов за ползване
Waterfall (водопад) моделът
• Този модел включва завършване на всяка

фаза напълно, преди да започне следващата.
• Когато всяка фаза е завършена успешно, тя
се преглежда, за да се види дали проектът е
на път и дали е възможно да продължи.
• Изисква внимателно първоначално
планиране
• Не може да се адаптира по реални
изисквания
Waterfall (водопад) моделът – Предимства и недостатъци
Предимства
• Прост и лесен за разбиране и използване.
• За по-малки проекти, моделът работи добре и се получават съответните резултати.
• Тъй като фазите са конкретни и точни и се извършват една след друга, е лесно да се
поддържа.
• Критериите за влизане и излизане, са добре дефинирани, така че лесно и систематично
да се пристъпи към постигане на качеството.
• Резултатите са добре документирани.
Waterfall (водопад) моделът – Предимства и недостатъци
Недостатъци
• Предполага се, че системата е „замразена“ и изискванията и желанията на клиента няма
да се променят, което е трудно постижимо в реалния свят
• Изключително трудно може да се върне екипа на предишен етап, който вече е завършил
• Има твърде малко гъвкавост по регулацията на обхвата на проекта и всяка промяна по
него е трудоемка и скъпа
• Трябва да се избягва за сложни и дългосрочни проекти
V-образен модел
V-образният модел за SDLC е разширен

вариант на Водопадния модел:
• Вместо процесът на разработка на
софтуера да се движи линейно надолу,
след фазата на разработка, процесите
се „извиват“ нагоре, като по този начин
графиката придобива характерната за
модела V-образна форма.
V-образен модел
Използва се, когато са изпълнени

следните условия:
• известни и ясно дефинирани
изисквания за софтуера
• екипът е добре запознат с
технологиите и инструментите, които
се използват при разработката на
програмния продукт
V-образен модел – предимства и недостатъци
Предимства
• Методологията е проста и лесна за прилагане
• След всяка фаза има очаквания за конкретни резултати, което прави разработката лесна
за проследяване
• По-големи шансове за успех в сравнение с Водопадния модел
• Това се дължи на изготвянето на тест планове в началото на всеки ден по време на
жизнения цикъл на софтуерната разработка.
• В комбинация с лесно разбираеми изисквания, това води до добри резултати.
V-образен модел – предимства и недостатъци
Недостатъци
• Недостатъчно гъвкав, подобно на Водопадния модел
• Малката гъвкавост води до трудноемко и скъпо адаптиране към промени в обхвата на
проекта.
• Софтуерът се разработва по време на фазата на имплементация, което означава, че
няма как да се произведат предварителни прототипи на програмния продукт
• Моделът не дава възможност за бързо и лесно отстраняване на проблемите, открити по
време на фазите на тестване и качествен анализ.
V-образният модел е скъп и времеемък процес, който обаче започва с подробен план и
завършва с ясна и пълна документация за проекта и софтуерния продукт
Гъвкави методологии (Agile) – 12 принципи (1/2)
1. Удовлетвореност на клиентите чрез ранна и непрекъсната доставка на ценен софтуер
2. Променящите се изисквания са добре дошли, включително и късното развитие
3. Често се доставя работен софтуер (в рамките на седмици вместо месеци)
4. Ежедневно се търси тясно сътрудничество между бизнеса и разработчиците
5. Проектите се основават на мотивирани хора, на които трябва да се има доверие
6. Личният разговор е най-добрата форма на комуникация (съвместно местоположение)
7. Работният софтуер е основната мярка за напредък
Гъвкави методологии (Agile) – 12 принципи (2/2)
8. Устойчиво развитие, което е в състояние да поддържа постоянен темп
9. Непрекъснато внимание към техническите съвършенства и добрия дизайн
10. Простотата - изкуството да максимизирате натоварването - е от съществено значение
11. Най-добрите архитектури, изисквания и проекти произтичат от самоорганизиращи се

екипи
12. Екипът редовно мисли как може да бъде по-ефективен и се адаптира съответно
Scrum
Scrum е гъвкава рамка за разработване, доставяне и поддържане на сложни продукти:

• С първоначален акцент върху разработването на софтуер, въпреки че е бил използван в
други области, включително изследвания, продажби, маркетинг и модерни технологии. [2]
• Предназначен за екипи от десет или по-малко членове, които разбиват работата си на
цели, които могат да бъдат изпълнени в рамките на итерации, наречени спринтове, не
повече от един месец и най-често две седмици.
• Екипът проследява напредъка в 15-минутни ежедневни срещи с часови рамки, наречени
ежедневни синкове.
• В края на спринта екипът провежда преглед на спринта, за да демонстрира свършената
работа, и ретроспекция на спринта, за да се подобрява непрекъснато.
Scrum
• Роли
• Product owner
• Scrum master
• Екип
• Церемонии
• Планиране (на спринта)
• Ежедневни 15-минутни срещи
• Ревю / демо (на спринта)
• Ретроспектива
• Артефакти
• Продуктов беклог
• Беклог на спринта
• Burndown чартове
Scrum - Роли
Product Owner
Собственикът на продукта, представляващ
заинтересованите страни на продукта и гласа на клиента,
е отговорен за:
• Постигането на добри бизнес резултати

• Изоставането на продуктите
• Максимизиране на стойността, която екипът предоставя
• Дефиниране на продукта в ориентирани към клиента
термини (обикновено потребителски истории), добавя ги
към списъка с продукти и ги приоритизира въз основа
на важността и зависимостите
Scrum - Роли
Scrum master
Scrum master-ът е отговорен за:
• Премахването на пречките пред способността на екипа

да постига целите и резултатите на продукта.
• Действа като буфер между екипа и всякакви

разсейващи влияния
• Гарантира, че scrum framework-ът се спазва
• Помага да се гарантира, че екипът следва договорените

процеси в Scrum рамката, често улеснява ключови
сесии и насърчава екипа да се подобри
Scrum - Церемонии
Планиране
В началото на спринта екипът провежда събитие за планиране на спринта, за да се:
• Обсъди обхвата на работата, която е предвидена да бъде извършена по време на този

спринт
• Изберат изостаналите задачи, които могат да бъдат завършени за един спринт
• Се съгласят с целта на спринта - кратко описание на това, което те прогнозират да доставят
в края на спринта
• Вземе решение за цел за спринта въз основа на приоритетите, определени от собственика
на продукта
• Изберат задачите, които според тях трябва да бъдат направени в спринта
Максималната продължителност на планирането на спринта е 8 часа за 4-седмичен спринт
Дейли
Всеки ден по време на спринта, екипът провежда ежедневна 15-минутна среща (изправена)
със специфични насоки:
• Всички разработчици идват подготвени
• Трябва да се случва по едно и също време и място всеки ден с ограничено (с часово време)
до 15 минути
• Всеки е добре дошъл, макар че само разработчиците и QA/Ops трябва да участват
• От екипа зависи как ще провежда ежедневната среща, но много често всеки човек се редува
да отговори на три въпроса:
• Какво завърших вчера, което допринесе за екипа?

• Какво планирам да завърша днес, за да допринеса за изпълнението на нашата спринтова
цел?
• Виждам ли някаква пречка, която би могла да попречи на мен или на екипа да изпълним
целта си за спринта?
Ревю
В края на спринта екипът провежда две събития: спринт ревю и спринт ретроспектива. На
спринт ревюто екипът:
• Преглежда работата, която е завършена и планираната работа, която не е завършена
• Представя завършената работа на заинтересованите страни (известна също като

демонстрацията)
• Си сътрудничи със заинтересованите страни по това, върху което да работи по-нататък
Указания за спринт ревюта:
• Неизвършената работа не може да бъде демонстрирана
• Препоръчителната продължителност е 2 часа за двуседмичен спринт
Ретроспектива
На ретроспективата на спринта екипът:
• Отразява миналия спринт
• Идентифицира и се съгласява за непрекъснати действия за подобряване на процеса
В ретроспективата на спринта възникват три основни въпроса:
• Какво мина добре по време на спринта?
• Какво не мина добре?
• Какво може да се подобри за по-добра производителност при следващия спринт?
Препоръчителната продължителност е час и половина за двуседмичен спринт.
Scrum - Артефакти
Беклог на продукта
Беклогът (натрупването) на продукта е разбивка на работата, която трябва да се свърши, и
съдържа подреден списък с изисквания за продукти, които екипът на scrum поддържа за даден
продукт
• Общите формати включват потребителски истории и случаи на употреба
• Изискванията определят функции, поправки на грешки, нефункционални изисквания и т.н. -

каквото и да се направи, за да се достави жизнеспособен продукт
• Собственикът на продукта (PO) приоритизира задачите въз основа на съображения като

риск, бизнес стойност, зависимости, размер и необходими данни, и крайни дати.
Scrum - Артефакти
Burndown chart
Диаграмата за изгаряне на спринта (burndown chart) е публично показана диаграма, показваща
оставащата работа за спринта.
• Актуализира се всеки ден
• Дава прост поглед върху напредъка на спринта
• Осигурява бърза визуализация, за да може всеки в екипа да има яснота
DevOps
DevOps е набор от практики, който съчетава

разработка на софтуер (Dev) и ИТ операции
(Ops)
• Целта му е да съкрати жизнения цикъл
на разработката на системите и да
осигури непрекъсната доставка с високо
качество на софтуера
• DevOps е част от разработването на
софтуер по Agile методологията
• Няколко аспекта на DevOps идват от
Agile методологията
DevOps – по-добрата дефиниция
DevOps: A culture where people, regardless of title or background,

work together to imagine, develop, deploy and operate a system.
- Ken Mugrage, ThoughtWorks
DevOps: Култура, при която хората, независимо от титла или

произход, работят заедно, за да си представят, разработят,
внедрят и управляват система.
- Ken Mugrage, ThoughtWorks
DevOps – как се връзва с непрекъснатата доставка на софтуер
Continuous Deployment
Continuous Delivery DevOps

maturity
Continuous Integration
DevOps – как се връзва с непрекъснатата доставка на софтуер
Непрекъсната доставка (Continuous delivery) и DevOps имат общи цели и често се използват
заедно, но има фини разлики:
• Непрекъснатата доставка е фокусирана върху автоматизиране на процесите при доставка

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

сътрудничество между многото участващи функции по пътя
SDLC еволюцията
Въпроси?
Thank you.
Bug Reporting
15.Април.2021
INTERNAL
1. Bug tracking система

2. Bug tracking процедура
3. Как определяме Сериозност (Severity) и Приоритет (Priority)
За какво си говорихме миналия път?
Какво помните от миналата лекция?

И намерихте ли отговора на въпроса от интервюто?
Г-н и г-жа Иванови имат 6 дъщери. Всяка от дъщерите има

един брат. От колко човека общо се състои семейство
Иванови?
Отговор
9 
В семейството има един син, който е брат на всички дъщери.
Тоест - 1 майка, 1 баща, 6 дъщери и 1 син.
Намирате се в стая с 3 ключа за лампа, които съответстват на

3 крушки в другата стая и не знаете кой ключ на коя крушка
отговаря. Можете само веднъж да влезете в стаята с
крушките. НЕ можете да използвате външно оборудване
(захранвания, резистори и т.н.). Как да разберете коя крушка
на кой ключ отговаря?
Отговор
Включете 2 ключа. 
Изключете единия ключ след няколко минути. 
Влезте в стаята с крушките. 
Крушката, която е включена, е единственият включен ключ.
Крушката, която е изключена, но гореща, е изключеният ключ.
Крушката, която е изключена и студена, е третият ключ.
7-те най-важни умения за постигане на добро описание на бъговете
1. Страхотни технически умения

2. Добра комуникация
3. Дипломация
4. Добри умения за преговари
5. Добри умения в тестването
6. Вникване в детайлите
7. Разбираане на продукта от гледна точка на крайния потребител 
Какво представлява описването на бъгове
• Целта на тестването е да се намерят и адресират грешки

• Грешките се намират при изпълнение на тестовите случаи
• Грешката може да бъде адресирана посредством:
• Докладване на грешката в системата за проследяване на грешки (BTS – Bug Tracking
System)
• Повторно тестване (retest) и проверка дали грешката е наистина отстранен
• Проверка дали от корекцията не е въведена нова грешка
Отсега нататък бъг ще означава две неща:
• Несъответствие между действителните и очакваните резултати
• Записаното в системата за проследяване на грешки несъответствие 
• Реални примери
• „Исках бира, но жена ми ми донесе сладолед.“
• „Исках сладолед, но мъжът ми ми донесе бира.“
• Лошо описание
• „Не получих това, което исках.“
 
Помните ли тези картинки от миналите ни лекции? 
Какво представлява BTS – Bug Tracking System
Система за проследяване на бъгове

Система за проследяване на грешки (Bug tracking system) или
Система за проследяване на дефекти (Defect tracking system)
• Софтуерно приложение, което проследява докладвани софтуерни грешки
• Може да се разглежда като тип система за проследяване на проблеми
• Позволява на потребителите на софтуера, както и на QA екипа, а и на всеки друг
ползвател на софтуера директно да въвеждат отчети за грешки
• Обикновено е необходим компонент на професионалната инфраструктура за
разработване на софтуер
Фактът, че е открита грешка, няма практическа стойност, докато не

споделим информация за нея. 
Защо следенето на грешките е важно?

• Тестването на софтуера е от съществено значение за изолиране и
оправяне на грешки
• Един добър QA процес може да разкрие стотици или дори хиляди дефекти
и екипите за тестване трябва да управляват всички тях
• Интегрирането на система за проследяване на грешки в работния процес
на тестване подобрява ефективността
• Помага на тестерите да определят приоритетите, да наблюдават и
докладват за състоянието на всяка грешка
 
Защо следенето на грешките е важно?

• Проследяването на дефекти помага да се гарантира, че грешките, открити
в системата, действително се отстраняват
• Инструментите за проследяване не само осигуряват начин за осигуряване
на последващи действия, но също така предоставят ценни показатели
• В зависимост от използвания инструмент, екипът може да обвърже
дефектите с променен код, тестове или други данни, които ще позволят
проследимост или анализ на тенденциите на дефекти
• Ако даден модул е осеян с дефекти, може да е време да го прегледате и
пренапишете 
BTS – Bug Tracking System - упражнение
1. Създайте акаунт в ShareLane и влезте -> http://www.sharelane.com/

2. Отидете на Test Portal -> Bug Tracking -> Training BTS -> Submit new
bug
3. Логнете грешка за каквото се сетите (попълнете само Summary)
4. Прегледайте грешката и променете състоянието й на Closed
5. Прегледайте грешката и променете състоянието й на Re-Open 
BTS – Bug Tracking System - Summary
В зависимост от ситуацията Summary би следвало да е някой от следните

варианти:
• SpecID, напр.: Spec2345
• Името на функционалността или компонента, напр.: Registration
• Името на файла, или точното местоположение на грешката, напр.: shopping_cart.py
Има поне две причини за това:
• Възможността да се обединят бъговете чрез еднакви първи думи в Summary
• Възможността да предоставяте незабавна информация относно областта на грешката
Докато пишете Summary, помислете за вашата целева аудитория – мениджъри на

проекти, разработчици, тестери
 
BTS – Bug Tracking System - Summary
Добра идея е да създадете конвенция (във вашата компания) или поне някои
насоки за това как да пишете Резюмета (Summary) на грешки. Например,
можем да се съгласим, че ако запишем Summary с идентификационния
номер на спецификацията, трябва да го направим по определен начин:
• “Spec2345:” (no space)
• “Spec 2345:” (space)
• “#2345:” (pound, no word “Spec”), etc.
Погледнете в официалния ShareLane BTS, наречен Bug Vault (Test Portal> Bug Tracking>
Bug Vault) за примери за Summary. Щракнете върху идентификатора на грешката, за да
отворите уеб страница с пълни подробности за конкретната грешка.
BTS – Bug Tracking System - Description
Атрибутите на грешките са необходими, за да:

• Опишете проблема
• Отразите дейностите, насочени към решаване на проблема
• Предоставете друга полезна информация за грешката
Bug Severity:
• Сериозността и важността на грешката не винаги е пряко свързана с
комплексността на отстраняването ѝ
• Mоже да има различни мнения сред мениджърите и архитектите 
BTS – Bug Tracking System - Attachment
Прикачен файл - кога да качите такъв?

• Може да отнеме много време, за да напишете добро текстово описание на грешката
• Едно от най-добрите решения е да се илюстрира грешката с прикачен файл
• Ако прикаченият файл напълно обяснява грешката, тогава е добре, ако вашето описание
се състои само от една фраза: „Вижте прикачения файл“
• ВИНАГИ пишете „вижте прикачения файл“ в описанието, ако има прикачен файл
• Прикачените файлове не са ограничени до изображения. Можете също да прикачите
други видове файлове (например текстови файлове и т.н.)
• Идеята е да предоставим възможно най-добрата илюстрация на грешката. 
BTS – Bug Tracking System – Assigned To
Възложено на:
• Падащото меню „Възложено на“ (Assigned to) е необходимо, за да се посочи псевдоним
или име на собственика на грешката.
• Когато подава грешка, тестерът е хубаво да я възлага на човек или поне на компонентът,
който е собственик на съответния модул/продукт/технология и т.н.
• Собственикът на грешки е конкретният човек, отговорен за следващата стъпка към
затваряне на грешки
• Как да разберете кой е „подходящият разработчик“?
• В повечето случаи разработчикът е този, който е написал кода
• Лицето, което в момента отговаря за тази функционална област
• Или на човек, който би пренасочил грешката на подходящ разработчик. Този човек
обикновено е мениджърът на разработчиците 
Възложено на:
• Най-доброто решение е да се създадат и поддържат два много важни документа:
• Кой какво прави (Who does what)
• Кой какво притежава (Who owns what)
• Тези документи трябва да бъдат публикувани в Wiki
• Изключително важно е тези два документа да бъдат актуални и да се попълват с
правилната информация 
BTS – Bug Tracking System – Severity
Сериозност:
• Това е падащо меню със стойности S1-S4 включително
• Сериозността се определя от сериозността на
въздействието на грешката върху софтуера
• Сериозноостта е техническа характеристика
За да определим сериозността, трябва да намерим

съвпадение между:
• Категорията на сериозността и
• Видът на въздействието на бъговете
Пример - S1:
Блокер (blocker)
Ако въведете потребителско име и парола в страницата на Gmail, веднага излиза страница
за грешка или страницата за входящи съобщения не се вижда.
• Тези грешки трябва да се разглеждат като блокиращи (blocker/showstopper)
• Нарушават дадена функционалност, поради което грешката трябва да бъде поправена
от разработчика, преди да може да се извърши допълнително тестване на тази
функционалност
• Водят до блокиране на тестването на приложението.
Пример - S2:
Сайтът зависва
• Това обикновено е проблем с производителността - например, отнема много време за
зареждане на уеб страницата
• Потребителите са блокирани и не могат да купуват книги в ShareLane, защото Checkout
не работи.
Много важен термин, който е свързан с блокиращи ситуации, е заобиколно решение
(workaround). Например, ако Създателят на акаунти (Test Portal>Helpers>Account Creator),
използван от тестерите за автоматично генериране на акаунти, не работи, това не е
проблем, който блокира тестването, тъй като новите потребителски акаунти могат да
бъдат създадени ръчно. Така че в тази ситуация ръчното създаване на акаунт е
заобиколно решение. Ако има разумно решение, проблемът не може да се счита за
блокиращ (blocker).
Пример - S3:
Функционален проблем
Тази категория е за всички функционални грешки, които не попадат в S1 или S2. Не е
чудно, че повечето грешки ще бъдат S3. Ето защо S3 по правило е стандартно по
подразбиране, когато тестерите подават грешка.
Пример - S4:
Друг проблем
Това включва всички грешки, които не попадат в S1, S2 или S3. Като правило тук ще
намерите грешки в потребителския интерфейс (напр. проблеми с оформлението, правопис
и т.н.).
BTS – Bug Tracking System – Priority
Приоритет
• Това е падащо меню със стойности P1-P4 включително
• Приоритет е степента на въздействие на грешката върху бизнеса на компанията
• Често има объркване между Приоритет (Priority) и Сериозност (Severity), така че нека
посочим разликите:
• Сериозността (Severity) се отнася до техническия аспект на грешката
• Приоритетът (Priority) се отнася до бизнес аспекта на грешката
С други думи, Severity използва технически критерии, за да оцени грешката, докато
Priority използва бизнес критерии.
Ето защо почти винаги е ясно коя тежест да се присвои на грешката, докато
Приоритетът на конкретна грешка често е предмет на спорове и политически игри.
Приоритет – пример:
• Да предположим, че има банкомат, който се използва за банкови транзакции
• Ако при използване на банкомата се случи следната ситуация:
• Потребителят тегли пари от банкомата на същата банка, в която има банкова
сметка, и му се начислява такса от $2 на транзакция
НО
• Според банковата политика, тегленето на пари от собствения им банкомат, не
подлежи на таксуване
Очевидно ще има проблем, ако клиентите бъдат таксувани, когато не трябва
BTS – Bug Tracking System – Priority and Severity Levels
Нива на приоритет и сериозност:

Приоритетът и сериозността имат някои
класификации сред тях, които помагат при
определянето на начина, по който дефектът
трябва да бъде обработен.
Различните организации имат различни
инструменти за регистриране на дефекти, така че
нивата могат да варират. Това са различните нива
както за приоритет, така и за тежест:
• High Priority, High Severity

• High Priority, Low Severity
• High Severity, Low Priority
• Low Severity, Low Priority
Въпрос:
Системата се срива, след като сте извършили плащането в уеб сайта или когато не
можете да добавите артикулите в количката.
Тази грешка каква степен на сериозност (Severity) и приоритет (Priority) има?
Отговор:
Системата се срива, след като сте извършили плащането в уеб сайта или когато не
можете да добавите артикулите в количката.
Тази грешка каква степен на сериозност и приоритет има?
Този дефект е означен като дефект с:

• Висок приоритет (High Priority)
• Висока степен на сериозност (High Severity)
Въпрос:
Представете си логото на yahoo.com.
Да предположим, че при актуализиране на yahoo.com по погрешка са актуализирали
грешно лого, напр. yaho.com тук 'o' липсва. Трябва да е Yahoo.com.
Какъв приоритет (Priority) и сериозност (Severity) биха били това?
Отговор:
Тази грешка е с висок приоритет (High Priority) - Yahoo.com е фирмено лого и грешка
във фирменото лого трябва да бъде отстранена с висок приоритет, за да се запази името.
Тази грешка е с ниска сериозност (Low Severity) - Тъй като това е само правописна
грешка в логото, въздействието върху потребителя не е толкова голямо. Потребителят все
още може да използва уебсайта.
Въпрос:
В сайт за социални мрежи (напр. Facebook) е пусната бета версия на нова функция с
малко на брой активни потребители, които я използват към днешна дата.
Как би се класифицирал всеки дефект на тази функция?
Отговор:
В сайт за социални мрежи (напр. Facebook) е пусната бета версия на нова функция с
малко на брой активни потребители, които я използват към днешна дата.
Как би се класифицирал всеки дефект на тази функция?
• Нисък приоритет (Low Priority) – въпреки, че тази функция има функционален дефект,
тя не засяга пряко крайните клиенти от бизнес гледна точка и може да бъде коригирана
със следващото издание като заявка за промяна
• Висока сериозност (High Severity) – защото е важно всяка грешка, намерена по време
на тестване на бета версията, да бъде поправена, преди функцията да бъде пусната
към всички потребители
Въпрос:
На страници 3 и 4 от политиката за поверителност на уебсайта има правописна грешка.
Как би се класифицирал този дефект?
Въпрос:
На страници 3 и 4 от политиката за поверителност на уебсайта има правописна грешка.
Как би се класифицирал този дефект?
Всякакви правописни грешки/некоректен шрифт/разминаване в абзаца на 3-та или 4-та

страница на приложението, а не в основната или първа страница, или в заглавието, се
класифицират като:
• Нисък приоритет (Low Priority)
• Ниска сериозност (Low Severity)
BTS – Bug Tracking System – сравнение на софтуерни решения
Ако в екипа ви се наложи да смените системата за следене на грешки, може

да използвате следният източник за сравнение на различните софтуерни
решения:
https://www.wikiwand.com/en/Comparison_of_issue-tracking_systems
Въпроси?

Test Vane

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Test Vane

Uploaded by

Copyright:

Available Formats

Recap

Quality Control (QC): Concern with the quality of the product.

Software Testing: is the process of ensuring that product which

Validation: process of evaluating product during or at the end of the

Difference between Verification and Validation:

Requirement gathering and analysis

A functionality defect is when a user gives a valid user name but

Яна Дамянова, SAP Labs Bulgaria

© 2019 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC -2

© 2019 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC -3

© 2019 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC -4

© 2019 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC -5

© 2019 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC -6

© 2019 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC -7

© 2019 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC -8

© 2019 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC -9

13.May.2021 10. Как тестваме нова и стара функционалност?

Какво според вас прави един тестер?

Какво, според вас, е

софтуерното тестване и контрол на качеството?

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

▪Всички дейности, свързани с това да се осигури, че процесите по разработка

▪Контролът на качеството се грижи за това да има дефинирани адекватни

Нещо, което сте си купили и е

▪Внимание към детайла

▪Внимание към детайла

▪Представете си следната ситуация, случваща се в 16 часа следобед:

1. Вашият шеф ви е дал задача, която трябва да се свърши до края на деня

▪Какви са предимствата на това да бъдем QA?

▪Тестването ни учи да учим бързо, да се адаптираме и да даваме нови идеи

▪Тестването ни учи да учим бързо, да се адаптираме и да даваме нови идеи

▪Каква е разликата между тестване и контрол на качеството?

▪Как се тества асансьор?!

▪Асансьорът трябва да се движи нагоре и надолу

▪Ако двама човека извикат асансьора от два различни етажа, асансьорът

▪Когато натиснете бутона за етажа, на който искате да отидете, той трябва да

▪Тестването е процес на оценка на системата с намерението да се открие

▪За да намерим проблема преди потребителите ни и да го адресираме

▪В различните фирми процесът е различен

▪Колкото по-рано, толкова по-добре

▪Разделете се по двойки и си намислете продукт. Нека да е простичък –

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

▪Няма 100% изтестван продукт

▪За големи критични проекти

▪Като използваме скриптове и тулове

▪HP Quick Test Professional

Мит 1: Тестването е твърде скъпо

Мит 2: Тестването отнема твърде много време

Мит 3: Само напълно разработен продукт може да се тества

Мит 4: Всичко може да се изтества

Мит 5: Добре изтестваният софтуер няма проблеми

Мит 6: За неоткритите проблеми е виновен тестера

Мит 7: Тестерите са отговорни за качеството на продукта

Мит 8: Трябва да се автоматизира на всяка цена, за да се спести време

Мит 9: Всеки може да тества

Мит 10: Единствената работа на тестера е да тества и да намира проблеми

Много организации включват стандарти за качество, за да осигурят по-добро

Едно голямо човече и едно малко човече се разхождали в гората.

Намирате се в стая без прозорци и херметически затворена (идеално гладка

Кои са 3-те неща, които ще запомните от днес?

Какво си спомняте от миналата лекция?

▪ Black box testing

▪The black box approach:

How can we figure out expected patterns of user behavior?