Theory On Lecture 1.3

7/5/23, 2:58 PM Theory on lecture 1
Theory on lecture 1
Site: Andersen Moodle Printed by: Malathy S

Course: Testing Basics Date: Wednesday, 5 July 2023, 11:15 AM
Book: Theory on lecture 1
https://learn.andersenlab.com/mod/book/tool/print/index.php?id=471 1/22
Table of contents
1. Quality assurance and software testing - basic concepts and definitions

1.1. Principles of Testing
1.2. Verification and Validation
1.3. QA, QC and testing
2. The Software Development Life Cycle

2.1. Software Development Models
2.2. Agile (ideology) - software development manifesto
2.3. SCRUM
2.4. Kanban
2.5. Extreme Programming(XP)
3. Software Testing Life Cycle
1. Quality assurance and software testing - basic concepts and

definitions
Software Quality - is the extent to which the software has the required combination of features.
Software Quality -it is a set of software characteristics related to its ability to satisfy stated and implied needs.
Quality Assurance - QA - this is a set of activities covering all technological stages of development, release and operation of software (SW)
of information systems undertaken at different stages of the software life cycle to ensure the required level of quality of the product being
produced.
Quality Control - QC - this is a set of actions carried out on the product during the development process to obtain information about its
current state in the context of: "product readiness for release", "compliance with fixed requirements", "compliance with the declared level of
product quality".
Software Testing - This is one of the quality control techniques that includes the activities of planning work (Test Management), designing
tests (Test Design), testing (Test Execution) and analyzing the results (Test Analysis).
Verification - it is the process of evaluating a system or its components to determine whether the results of the current stage of development
satisfy the conditions established at the beginning of this stage. Those. whether our goals, deadlines, project development tasks, which were
determined at the beginning of the current phase, are being fulfilled.
Validation - this is a determination of the compliance of the developed software with the expectations and needs of the user, the requirements
for the system.
Test Plan - this is a document that describes the entire scope of testing work, starting with a description of the object, strategy, schedule,
criteria for starting and ending testing, up to the equipment necessary in the process, special knowledge, as well as risk assessment with
options for resolving them.
Test Design - this is the stage of the software testing process at which test cases (test cases) are designed and created in accordance with
the previously defined quality criteria and testing objectives.
Test Case - it is an artifact that describes the set of steps, specific conditions, and parameters needed to verify the implementation of the
function under test or part of it.
Bug Report - this is a document describing the situation or sequence of actions that led to the incorrect operation of the test object, indicating
the reasons and the expected result.
Test Coverage - this is one of the metrics for assessing the quality of testing, which is the density of test coverage of requirements or
executable code.
Test Case Specification - is the level of detail in describing the test steps and the desired result that provides a reasonable ratio of travel time
to test coverage.
Test Case Pass Time - this is the time from the start of the test case steps to the receipt of the test result.
Software quality
Every day in our work we come across a rather abstract concept of “software quality” and if you ask a tester or programmer “what is quality?”,
then everyone will have their own interpretation. Consider the definition of "software quality" in the context of international standards:
Software quality is the extent to which software has a desired combination of features.
Software quality is a set of software characteristics related to its ability to satisfy stated and implied needs.
Software Quality Characteristics
Functionality - is determined by the ability of the software to solve problems that correspond to the fixed and expected needs of the user,
under given conditions of using the software. Those. this characteristic ensures that the software operates correctly and accurately, is
interoperable, conforms to industry standards, and is protected from unauthorized access.
Reliability – the ability of the software to perform the required tasks under specified conditions for a specified period of time or a specified
number of operations. The attributes of this characteristic are the completeness and integrity of the entire system, the ability to independently
and correctly recover from failures, fault tolerance.
Usability – the possibility of easy understanding, study, use and attractiveness of the software for the user.
Efficiency – the ability of the software to provide the required level of performance, in accordance with the allocated resources, time and other
specified conditions.
Maintainability – the ease with which the software can be analyzed, tested, changed to fix defects to meet new requirements, to facilitate
further maintenance and adaptation to the existing environment.
Portability – characterizes software in terms of ease of portability from one environment (software/hardware) to another.
Software quality model
At the moment, the most common and used is the multi-level software quality model, presented in the ISO 9126 set of standards.
Who is a tester and what does he do
If you search for information on the key phrases from the title of this chapter, you can find a lot of completely contradictory answers. And the
point here, first of all, is that the authors of most of the "duties" attribute to the whole profession a certain exaggerated set of characteristics of
its individual representatives.
At the beginning of a career, any specialist (and a tester is no exception) is a performer and a student. It is enough to understand well what
test cases are, defect reports, be able to read requirements, use a couple of tools and get along well in a team.
Gradually, the tester begins to immerse himself in all stages of project development, understanding them more and more fully, begins not only
to actively use, but also develop project documentation, make more and more responsible decisions. If we express figuratively the main goal
of the tester, then it will sound like this: “understand what the project needs at the moment, whether the project receives it properly and, if not,
how to change the situation for the better.”
Sounds like a project manager's goal, right? Right. Starting from a certain level of development, IT professionals, by and large, differ only in
their sets of technical skills and the main area of application of these skills. So what technical skills do you need to be successful as a tester?
Before proceeding to the enumeration itself, we will make a special mention: this list is intended, first of all, for those who come to testing from
non-technical professions (although students of technical universities often have to voice it).
1. Knowledge of foreign languages. Yes, it's not a technical skill. But, nevertheless, it goes under the number "zero". You can consider it an
axiom: "no knowledge of English - no career in IT." Other foreign languages are also welcome, but English is primary.
2. Confident computer skills at the level of a truly advanced user and the desire to constantly develop in this area. Can you imagine a
professional cook who cannot fry potatoes (not "not obliged", but "cannot in principle")? Looks weird? No less strange is the “IT” (exactly, in
quotation marks), unable to type sanely formatted text, copy a file over the network, deploy a virtual machine, or perform any other daily
routine action.
3. Programming. It simplifies the life of any IT specialist by an order of magnitude, and for a tester in the first place. Is it possible to test without
knowledge of programming? Yes, you can. Can it be done really well? No. And now the most important (almost religious-philosophical)
question: what programming language to study? C/C++/C#, Java, PHP, JavaScript, Python, Ruby, etc. - start with what your project is written
on. If there is no project yet, start with JavaScript (currently the most versatile solution).
4. Databases and SQL language. Here, the tester is also not required to be qualified at the level of narrow specialists, but minimal skills in
working with the most common DBMS and the ability to write simple queries can be considered mandatory.
5. Understanding the principles of networks and operating systems. At least at the minimum level, allowing you to diagnose the problem and
solve it on your own, if possible.
6. Understanding the principles of web applications and mobile applications. These days, almost everything is written in the form of such
applications, and an understanding of the relevant technologies becomes mandatory for effective testing.
I hope you noticed that the testing itself is not on the list. That's right, because this whole book is dedicated to him, so let's not copy it here.
We also note the personal qualities that allow the tester to quickly become an excellent specialist:
1. Increased responsibility and diligence;
2. Good communication skills, the ability to clearly, quickly, clearly express one's thoughts;
3. Patience, perseverance, attention to detail, observation;
4. Good abstract and analytical thinking;
5. The ability to set up non-standard experiments, a penchant for research activities. Yes, it is difficult to find a person who would equally
possess all of the listed qualities, but it is always useful to have some kind of guideline for self-development.
Where do software bugs come from?
Why does it happen that programs do not work correctly? Everything is very simple - they are created and used by people. If the user makes a
mistake, then this can lead to a problem in the program - it is used incorrectly, which means it may not behave as expected.
Error - is a human action that produces an incorrect result. However, programs are designed and built by people who can (and still do) make
mistakes. This means that there are flaws in the software itself. They are called defects or bugs (both designations are equivalent). The
important thing to remember here is that software is more than just code.
Defect, Bug – a flaw in a component or system that could result in the failure of certain functionality. A defect discovered during the execution
of a program can cause the failure of a single component or the entire system. When executing the program code, defects that were laid down
at the time of its writing may appear: the program may not do what it should, or vice versa, do what it should not - a failure occurs.
Failure – discrepancy between the actual result (actual result) of the operation of a component or system and the expected result (expected
result). A failure in the program may be an indicator of the presence of a defect in it.
Thus, a bug exists when three conditions are met simultaneously: the expected result is known; the actual result is known; the actual result is
different from the expected result. It is important to understand that not all bugs cause crashes - some of them may not manifest themselves at
all and go unnoticed (or only appear under very specific circumstances). Failures can be caused not only by defects, but also by
environmental conditions: for example, radiation, electromagnetic fields or pollution can also affect the operation of both software and
hardware. In total, there are several sources of defects and, accordingly, failures:
errors in the specification, design, or implementation of a software system;

system usage errors;
adverse environmental conditions;
intentional harm;
the potential consequences of previous errors, conditions, or intentional actions.
Defects can occur at different levels, and whether and when they are fixed will directly affect the quality of the system.
Quality – the extent to which a set of inherent characteristics meets requirements.
Software Quality – it is a set of software characteristics that reflect its ability to satisfy stated and implied needs.
Requirement – a need or expectation that is set. Usually expected or required.
Conventionally, there are five reasons for the appearance of defects in the program code
1. Lack of communication within the team. Often, business requirements simply don't reach the development team. The customer has
an understanding of how he wants to see the finished product, but if his idea is not properly explained to developers and testers, the
result may not be as expected. Requirements should be accessible and understandable to all participants in the software development
process.
2. The complexity of the software. Modern software consists of many components that are combined into complex software systems.
Multi-threaded applications, client-server and distributed architectures, multi-level databases - programs are becoming more and more
difficult to write and maintain, and the work of programmers becomes more difficult. And the more difficult the work, the more mistakes
the person performing it can make.
3. Requirements changes. Even minor requirements changes late in development require a lot of work to make changes to the system.
The design and architecture of the application is changing, which, in turn, requires changes to the source code and the principles of
interaction between program modules. Such ongoing changes often become a source of subtle defects. However, today's rapidly
changing business requirements are the rule rather than the exception, so continuous testing and risk management under these
conditions is the responsibility of QA professionals.
4. Poorly documented code. It is difficult to maintain and change poorly written and poorly documented code. Many companies have
special rules for writing and documenting code by programmers. Although in practice it often happens that developers are forced to write
programs first of all quickly, and this affects the quality of the product.
5. Software development tools. Visualizers, libraries, compilers, script generators, and other development aids are also often poorly
performing and poorly documented programs that can become a source of defects in the finished product.
1.1. Principles of Testing
Software testing is a creative and intellectual job. Designing correct and effective tests is a rather difficult task. The principles of testing
presented below have been developed over the last 40 years and are general guidelines for testing in general.
1. Testing shows the presence of defects. Testing can show the presence of defects in the program, but not prove their absence.
However, it is important to write test cases that will find as many bugs as possible. Thus, with proper test coverage, testing can reduce
the likelihood of defects in the software. At the same time, even if defects were not found during testing, it cannot be said that they do
not exist.
2. Exhaustive testing is not possible. It is impossible to conduct exhaustive testing that would cover all combinations of user input and
system states, except for very primitive cases. Instead, risk analysis and prioritization should be used to better allocate software quality
efforts.
3. Early testing. Testing should start as early as possible in the software development life cycle and should be focused on specific goals.
4. Defect clustering. Different modules of the system may contain a different number of defects, that is, the density of accumulation of
defects in different elements of the program may differ. Testing effort should be distributed in proportion to the actual density of defects.
Basically, most of the critical defects are found in a limited number of modules. This is a manifestation of the Pareto principle: 80% of the
problems are contained in 20% of the modules.
5. Pesticide paradox. Running the same tests over and over again, you will find that they find fewer and fewer new errors. As the system
evolves, many of the previously found defects are fixed and old test cases no longer work. To overcome this paradox, it is necessary to
periodically make changes to the test sets used, review and correct them so that they correspond to the new state of the system and
allow finding as many defects as possible.
6. Testing is context-dependent.The choice of methodology, technique and type of testing will directly depend on the nature of the
program itself. For example, medical software requires much more stringent and thorough testing than, say, a computer game. For the
same reasons, a site with a lot of traffic should go through some serious performance testing to show that it can work under high load.
7. Absence of errors fallacy. The fact that testing did not find any defects does not mean that the program is ready for release. Finding
and fixing defects will not be important if the system is inconvenient to use and does not meet the expectations and needs of the user.
And a few more important principles:
testing should be carried out by independent experts;

attract the best professionals;
test both positive and negative scenarios;
do not allow changes in the program during testing;
indicate the expected result of the tests.
1.2. Verification and Validation
These two concepts are closely related to testing and quality assurance processes. Unfortunately, they are often confused, although the
differences between them are quite significant.
Verification is the process of evaluating a system or its components in order to determine whether the results of the current stage of
development satisfy the conditions formed at the beginning of this stage. That is, whether the tasks, goals and deadlines for product
development are being met.
Validation is the determination of the compliance of the developed software with the expectations and needs of the user, the requirements for
the system. The following table will help highlight the key differences between these concepts:
With validation, you can be sure that you have created the “right” product. A product that fully satisfies the customer. With the help of
verification, you can be sure that the product is made "correctly": adhering to the necessary methods, tools and standards. In practice, the
differences between verification and validation are of great importance:
the customer is interested, to a greater extent, in validation (satisfaction of own requirements);

the contractor, in turn, is concerned not only with compliance with all quality standards (verification) in the implementation of the product, but
also with the compliance of all product features with the wishes of the customer.
1.3. QA, QC and testing
So what is the difference between QA and testing and what is Quality Control?
Many people still confuse these concepts, which, in general, is not surprising, given that in our country they can often be used to describe the
same processes. But from a formal point of view, which is what we, as specialists, are interested in, these three concepts have significantly
different meanings. You can arrange their ratio in the form of a table:
Thus, we can build a model of the hierarchy of quality assurance processes: Testing is part of QC. QC is part of QA.
In other words, Quality Assurance ensures the correctness and predictability of the process, while Quality Control involves monitoring
compliance. Testing, in turn, ensures the collection of statistical data and their inclusion in documents created as part of the QC process. If
we draw an analogy with the process of designing, say, a bicycle, we get the following picture:
Through testing, we can determine whether all the parts and the bike as a whole work as we expect. Whether it is made of the right
materials, using the right techniques and tools or not. That is, it is assumed that the object under test already exists.
The task of QA is to ensure that all stages of the design of our bike meet certain quality standards, from planning and creating drawings to
assembling a finished bike. That is, the quality of the object is paid attention even before the creation of the object itself.
2. The Software Development Life Cycle
Testing is not an isolated process. It is part of the Software Development Life Cycle (SDLC) model. That is why the choice of testing tools and
methods will directly depend on the chosen development model. In this section, we will look at the most commonly used approaches to
software development, as well as methodologies and practices that are popular today, such as Agile and Scrum.
The software development life cycle (also called the development cycle) is a notional diagram that includes individual stages that represent
the stages of the software development process. At the same time, different actions are performed at each stage.
The development cycle provides a template that makes it easy to design, build, and release quality software. It is a methodology that defines
the processes and tools needed to successfully complete a project.
Although the implementation of the principles of building a life cycle model for different companies can vary significantly, there are standards,
such as ISO/IEC 12207, that define accepted practices for developing and maintaining software.
The purpose of using the life cycle model is to create an efficient, cost-effective and high-quality software product.
Requirements analysis
The purpose of this stage is to determine the detailed requirements for the system. In addition, it is necessary to make sure that all
participants correctly understand the tasks set and how exactly each requirement will be implemented in practice.
This stage involves the collection of requirements for the software being developed, their systematization, documentation, analysis, as well as
the identification and resolution of contradictions.
Design
During the design stage (also called the design and architecture stage), programmers and system architects use requirements to develop a
high-level system design.
The design is usually fixed in a separate document - the design specification (Design Specification Document, DSD).
At this stage, to simplify the visualization of the design process, so-called notations are used - a schematic expression of the characteristics of
the system.
The main notations used are:
Block diagrams.
ER diagrams.
UML diagrams.
Layouts - for example, a website prototype drawn in Photoshop.
Development and programming
At this stage, programmers begin writing the program code in accordance with previously defined requirements. Programming involves four
main stages:
Development of algorithms - creation of the logic of the program.

Writing source code.
Compilation - conversion to machine code.
Testing and debugging - unit testing.
Documentation
There are four levels of documentation:
Architectural (design) - for example, a design specification. These are documents that describe the models, methodologies, tools, and
development tools chosen for a given project.
Technical - all documentation accompanying the development (various documents explaining the operation of the system at the level of
individual modules).
Custom - includes reference and explanatory materials necessary for the end user to work with the system. These are, for example,
Readme and User guide, a help section for the program.
Marketing - includes promotional materials accompanying the release of the product.
Testing
The testing process consists of the following steps:
Planning and management - testing planning includes actions aimed at determining the main goals of testing and the tasks that need to be
completed to achieve these goals; drawing up a test strategy, test plan.
Analysis and design is the process of writing test cases and conditions based on common test objectives.
Implementation and implementation - writing test cases, based on previously written test scenarios, the information necessary for testing is
collected, the test environment is prepared and tests are launched.
Exit Criteria Evaluation and Reporting - It is necessary to check whether enough tests have been carried out, whether the required degree
of system quality assurance has been achieved.
Actions upon completion of testing - we collect, systematize and analyze information about its results.
The main goals of this stage:
make sure that all the planned functionality has actually been implemented;
check that all bug reports previously filed have been closed in one way or another;
shutdown of testware, test environment and infrastructure;
evaluate the overall results of testing and analyze the experience gained in its process.
Deployment and Maintenance
When the program has been tested and there are no more serious defects in it, it's time to release and transfer it to end users.
In the event that users discover certain post-release bugs, information about them is transmitted in the form of error reports to the
development team, which, depending on the severity of the problem, either immediately releases a fix (hot-fix) or postpones it until the next
version of the program.
2.1. Software Development Models
To better understand how testing relates to programming and other types of project activities, first we will consider the most basic ones -
software development models (as part of the software life cycle). At the same time, we immediately emphasize that software development is
only a part of the software life cycle, and here we are talking about development.
The material in this chapter relates rather to the discipline of "project management", therefore, it is considered extremely concisely here:
please do not take it as an exhaustive guide - it hardly covers even a hundredth of a percent of the relevant subject area. The choice of
software development model seriously affects the testing process, determining the choice of strategy, schedule, required resources, etc.
There are many software development models, but, in general, the classic ones can be considered waterfall, v-model, iterative,
incremental, spiral and agile.
It is necessary to know and understand software development models in order to understand from the first days of work what is happening
around, what, why and why you are doing. Many novice testers note that the feeling of meaninglessness of what is happening visits them,
even if the current tasks are interesting. The more fully you present the picture of what is happening on the project, the more clearly you will
see your own contribution to the common cause and the meaning of what you are doing.
Another important thing to understand is that no model is a dogma or a one-size-fits-all solution. There is no ideal model. There is one that is
worse or better suited for a specific project, specific team, specific conditions.
Waterfall model is now rather of historical interest, because practically inapplicable in modern projects. It involves a single execution of each
of the phases of the project, which, in turn, strictly follow each other (Fig. 1.2). In a very simplified way, we can say that, within the framework
of this model, at any given time, only the previous and next phases are "visible" to the team. In real software development, however, one has
to “see the whole project” and return to previous phases in order to correct flaws or clarify something.
Waterfall
Features of the waterfall model:
high level of formalization of processes;

a large amount of documentation;
a rigid sequence of life cycle stages without the possibility of returning to the previous stage.
Disadvantages :
• Waterfall-the project must always have up-to-date documentation. Mandatory updating of project documentation. Redundant documentation.
• Very inflexible methodology.
• Can create a misleading impression of the project being worked on (eg, the phrase "45% completed" does not carry any useful information,
but is just a tool for the project manager).
• The customer does not have the opportunity to get acquainted with the system in advance, and even with the "Pilot" of the system.
• The user does not have the opportunity to get used to the product gradually.
• All requirements must be known at the beginning of the project life cycle.
• There is a need for tight management and regular monitoring, otherwise the project will quickly get out of schedule.
• There is no possibility to take into account the alteration, the whole project is done at one time.
Advantages:
• High transparency of development and project phases.
• A clear sequence.
• Stability of requirements.
• Strict control of project management.
• Facilitates the work of drawing up a project plan and gathering the project team.
• Well-defined quality control procedure.
Iterative model
Iterative or incremental models (several such models are known) involve breaking the system being created into a set of pieces that are
developed using several successive passes of all or part of the work.
The waterfall model with the possibility of returning to the previous step, if necessary, to revise its results, becomes iterative. The iterative
process assumes that different types of activities are not tightly tied to certain stages of development, but are performed as needed,
sometimes repeated, until the desired result is obtained. Along with flexibility and the ability to respond quickly to change, iterative models add
additional complexity to project management and tracking. When using an iterative approach, it becomes much more difficult to adequately
assess the current state of the project and plan for the long-term development of events, as well as predict the time and resources needed to
ensure a certain quality of result.
Spiral Software Life Cycle Model
This model perfectly combines prototyping and design by stages. And from the ascending and descending concepts, all the best was taken
into this model.
Model advantages:
1. The result is achieved in the shortest possible time.

2. Competitiveness is quite high.
3. When requirements change, you don't have to start from scratch.
But this model has one significant drawback: the impossibility of regulating the stages of execution.
V model — test-driven development
This model has an algorithm that is closer to modern methods, but still has a number of drawbacks. It is one of the main practices of Extreme
Programming and involves regular testing of the product during development.
The V-model provides support in project planning and implementation.
The following tasks are set during the project:
• Risk minimization: The V-shaped model makes the project more transparent and improves the quality of project control by standardizing
intermediate goals and describing the corresponding results and responsible persons. This allows you to identify deviations and risks in the
project at an early stage and improves the quality of project management by reducing risks.
• Quality enhancement and assurance: The V-Model is a standardized development model that enables a project to achieve the desired
quality results. Intermediate results can be checked at an early stage. Universal documentation facilitates readability, understandability, and
verifiability.
• Reducing the overall cost of the project: resources for development, production, management and support can be pre-calculated and
controlled. The results obtained are also universal and easy to predict. This reduces costs for subsequent stages and projects.
• Improving the quality of communication between project participants: a universal description of all elements and conditions facilitates mutual
understanding of all project participants. Thus, inaccuracies in understanding between the user, the buyer, the supplier and the developer are
reduced.
In short, we can express the essence of software development models with a table:
2.2. Agile (ideology) - software development manifesto
Agile (ideology) - software development manifesto
We are constantly discovering better ways to develop software by developing directly and helping others. Thanks to the work done, we were
able to realize that:
People and interaction are more important than processes and tools.
A working product is more important than comprehensive documentation.
Cooperation with the customer is more important than agreeing on the terms of the contract.
Being ready for change is more important than sticking to the original plan.
That is, without denying the importance of what is on the right, we still appreciate what is on the left more.
The Fundamental Principles of the Agile Manifesto We follow these principles:
The highest priority for us is customer satisfaction through regular and early delivery of valuable software.
Changing requirements is welcome even in the late stages of development. Agile processes allow you to use change to provide the
customer with a competitive advantage.
A working product should be released as often as possible, with a frequency of a couple of weeks to a couple of months.
Throughout the project, developers and business representatives must work together on a daily basis.
Motivated professionals should work on the project. To get the job done, create the conditions, provide support, and trust them completely.
Face-to-face communication is the most practical and effective way to share information both with the team itself and within the team.
A working product is the main indicator of progress. Investors, developers and users should be able to maintain a constant rhythm
indefinitely. Agile helps to establish such a sustainable development process.
A constant focus on engineering excellence and design quality enhances project flexibility.
Simplicity—the art of minimizing unnecessary work—is essential. The best requirements, architectural and technical solutions come from
self-organizing teams.
The team should systematically analyze how they can improve performance and adjust their work style accordingly.
2.3. SCRUM
SCRUM
Scrum — this is not an abbreviation, this term is taken from rugby, which means scrum around the ball. The term Scrum itself can be defined
as follows - it is a project management methodology that is built on the principles of time management. Its main feature is the involvement in
the process of all participants, and each participant has his own specific role.
The bottom line is that not only the team is working on solving the problem, but all those who are interested in solving the problem. They didn’t
just set a task and relaxed, but constantly “work” with the team, and this work does not mean only constant control. The main terms used in
the methodology are:
Product owner - a person who has a direct interest in a quality end product, he understands how this product should look / work. This
person does not work in a team, he works on the side of the customer / client (it can be either another company or another department), but
this person works with a team. And this is the person who prioritizes tasks.
Scrum master is a person who can be called a project manager, although this is not exactly the case. The main thing is that this person is
“infected with the Scrum bacillus” so much that he carries it both to his team and to the customer and, accordingly, makes sure that all
Scrum principles are observed.
A Scrum team is a team that accepts all of the Scrum principles and is willing to work with them.
Sprint is a period of time that is taken to complete a specific (limited) list of tasks. It is recommended to take 2-4 weeks (the duration is
determined by the team once).
A backlog is a list of all work. It can be said that this is a general use diary. There are 2 types of backlogs: Product Backlog and Sprint
Backlog.
1. A product backlog is a complete list of all the work that will result in the final product.
2. The sprint backlog is a list of work that the team has identified and agreed with the Product Owner for the next reporting period (sprint).
Tasks in the sprintbacklog are taken from the product-backlog.
Sprint planning is a meeting where everyone is present (Team, Scrum Master, Product Owner). During this meeting, the Product Owner
prioritizes the tasks he would like to see completed at the end of the sprint. The team evaluates over time how much of the desired they can
accomplish. The result is a list of tasks that cannot change during the sprint and must be fully completed by the end of the sprint.
An example of a PR agency. What it might look like if they worked according to Scrum:
The client company "X" wants to hold a large-scale event for its partners and journalists in 2 months. Company "X" ordered services for
organizing such an event from the agency "Z". Company "X" is represented by a PR-manager who is responsible for organizing the event on
behalf of the client. In Scrum terminology, this person is called the "Product Owner". On the agency side, the event is organized by the
account manager (Scrum master), who reports to the team (Scrum team). In a joint meeting (sprint planning) company and agency decide that
they will report/plan every 2 weeks (sprint length). For the first 2 weeks, they planned a list of tasks (sprint backlog), but the team estimated
that they would not have time to complete all of this list. Then the PR-manager (aka Product Owner) says which of this list of tasks are more
priority for the next 2 weeks, after which the team takes on the tasks. The only thing that should be Lecture 1, part 3. It should be taken into
account that, at the time of planning the first sprint, the entire list of tasks for 2 months (product-backlog) should be planned so that it does not
turn out that by the time the event is held, something has not been completed.
Sprint life cycle
1. Sprint planning.
At the beginning of each sprint, planning for that sprint is carried out. Sprint planning involves customers, users, management, Product Owner,
Scrum Master and the team. Sprint planning consists of two consecutive rallies.
1) Sprint planning, meeting one.
Participants: team, Product Owner, Scrum Master, management
Goal: Define the Sprint Goal and Sprint Backlog functionality that will be developed during the next sprint to achieve the Sprint Goal.
Artifact: Sprint Backlog
2) Sprint planning, meeting two.
Participants: team, Scrum Master
Goal: Determine how a particular feature will be developed in order to achieve the sprint goal. For each element of the Sprint Backlog, a list of
tasks is defined and their duration is estimated.
Artifact: Tasks appear in the Sprint Backlog If during the sprint it turns out that the team cannot do what was planned for the sprint, then the
Scrum Master, Product Owner and the team meet and find out how to reduce the scope of work and still achieve the sprint goal.
2. Sprint Abnormal Termination
The sprint is stopped in exceptional situations. The sprint can be stopped before the end of the allotted 30 days. A sprint can be stopped by a
team if they feel they cannot reach the sprint goal in the allotted time.
A sprint can stop the Product Owner if the need to achieve the sprint goal is gone. After the sprint is stopped, a rally is held with the team,
where the reasons for stopping the sprint are discussed. After that, a new sprint begins: its planning is carried out and work starts.
3. Daily Scrum Meeting
This rally takes place every morning at the beginning of the day. It is designed to ensure that all team members know who is doing what in the
project. The duration of this rally is strictly limited and should not exceed 15 minutes. The purpose of the meeting is to share information. It is
not intended to solve problems in a project. All issues requiring special discussion should be taken out of the rally. The Scrum Meeting is
hosted by the Scrum Master. He asks questions to each member of the team in a circle:
• What was done yesterday?
• What will be done today?
• What problems did you encounter?
The Scrum Master collects all questions open for discussion in the form of Action Items, for example, in the what/who/when format, for
example:
Discuss the problem with control rendering.

Petya and Vasya.
Right after Scrum.
Burndown chart
A chart that shows the amount of work done and remaining.
Updated daily to show the progress of the sprint in a simple way. The schedule must be public.
There are different types of charts:
The sprint burndown chart shows how many tasks have already been done and how much remains to be done in the current sprint.
A project release burndown chart shows how many tasks have already been completed and how much remains to be done before the
release of the product (usually built on the basis of several sprints).
Retrospective
At the end of each Sprint, the Scrum Team meets for a retrospective.
Purpose: to review the quality of existing processes, relationships between people and the tools used. The team determines what went well
and what did not go well, and also identifies potential opportunities for improvement. They create an improvement plan for the future.
2.4. Kanban
The term "kanban" has a literal translation: "Kan" means visible, visual and "ban" - a card or board.
In Toyota factories, kanban cards are widely used to avoid cluttering warehouses and workspaces with pre-made parts.
For example, imagine that you are putting doors on a Toyota Corolla. You have a pack of 10 doors near your workplace. You put them one by
one on new cars and when there are 5 doors left in the pack, you know that Lecture 1, part 3. Software development methodologies 35 it's
time to order new doors. You take a kanban card, write an order for 10 doors on it, and take it to whoever makes the doors. You know that he
will make them just in time for you to run out of the remaining 5 doors. And that's exactly what happens: when you place the last door, a pack
of 10 new doors arrives. And so constantly: You order new doors only when you need them. Now imagine that such a system operates
throughout the plant. There are no warehouses anywhere where spare parts lie for weeks and months. Everyone works only on demand and
produces exactly as many parts as requested. If suddenly there are more or less orders, then the system itself easily adapts to changes. The
main purpose of kanban cards in this system is to reduce the amount of "work in progress" at the moment. For example, exactly 10 door cards
can be allocated to the entire production line. This means that at any given time there will not be more than 10 ready doors on the line. When
to order new doors and how much is a task for whoever installs them. Only he knows his needs and only he can place orders with the door
manufacturer, but he is always limited to 10. This Lean manufacturing method was invented by Toyota, and now many manufacturing
companies around the world are implementing it or have already implemented it. But this is all about production, not software development.
But what is kanban development in relation to software and how does it differ from other agile methodologies, be it SCRUM or XP? First, you
need to immediately understand that kanban is not a specific process, but a system of values. As, however, and SCRUM with XP. This means
that no one will tell you what and how to do step by step. Secondly, the whole kanban can be summed up in one simple phrase - “work in
progress reduction”. Thirdly, Kanban is an even more flexible methodology than SCRUM and XP. This means that it will not work for all teams
and for all projects. And it also means that the team needs to be even more agile than even teams using SCRUM and XP.
The difference between Kanban and SCRUM:
In kanban, there are no timeboxes for anything (neither for tasks, nor for sprints).
In kanban, there are more and fewer tasks.
In kanban, task time estimates are optional or non-existent.
In kanban, there is no “team speed” and only the average time to complete a task is considered.
Kanban development differs from SCRUM primarily in its task orientation. If in SCRUM the main orientation of the team is the successful
completion of sprints (it must be admitted that this is so), then in kanban, tasks come first. There are no sprints, the team works on the task
from the very beginning to completion. A task is deployed when it is ready. Presentation of completed work. The team should not estimate the
time to complete the task, because this makes little sense and is almost always wrong at the beginning. If the manager trusts the team, then
why have a time estimate? The task of the manager is to create a prioritized pool of tasks, and the task of the team is to complete as many
tasks from this pool as possible. All. No control is needed. All that is needed from the manager is to add tasks to this pool or change their
priority. That's how he manages the project.
The team uses a kanban board to work. For example, it might look like this:
Columns from left to right:
Project Goals: An optional but useful column. You can put high-level project goals here so that the team sees them and everyone knows
about them. For example, "Increase speed by 20%" or "Add support for Windows 7."
Story Queue: This is where tasks are stored that are ready to start executing. The top, highest priority task is always taken for execution
and its card is moved to the next column.
Design development: this and the rest of the columns up to "Finished" may change, because. it is the team that decides which steps the
task goes through to the state of "Finished". For example, this column may contain tasks for which the design of the code or interface is not
yet clear and is being discussed. When the discussions are over, the task moves to the next column.
Development: the task hangs here until the development of the feature is completed. When completed, it moves to the next column. Or, if
the architecture is not correct or inaccurate, the problem can be returned to the previous column.
Testing: The task is in this column while it is being tested. If errors are found, it is returned to Development. If not, it moves on.
Deployment: all projects have their own deployment. For some, this means uploading a new version of the product to the server, while for
others, it simply means committing the code to the repository.
Done: the sticker goes here only when all work on the task is completed.
In any job, there are urgent tasks. Planned or not, but those that need to be done right now. For such, you can allocate a special place (in the
picture it is marked as “Expedite”). You can put one urgent task in Expedite and the team should start working on it immediately and complete
it as quickly as possible. But there can be only one such task! If another one appears, it should be added to the "Task Queue".
And now the most important thing. See the numbers below each column? This is the number of tasks that can be in these columns at the
same time. The numbers are selected experimentally, but it is believed that they should depend on the number of developers in the team. For
example, if you have 8 programmers in a team, then you can put the number 4 in the “Development” line. This means that programmers will
do no more than 4 tasks at the same time, which means they will have many reasons for communication and exchange of experience. If you
put the number 2 there, then 8 programmers doing two tasks can get bored or waste too much time on discussions. If you put 8, then
everyone will be engaged in their own task and some tasks will linger on the board for a long time, and after all, the main goal of kanban is to
reduce the time it takes for a task to go from start to finish.
No one can tell you exactly what these limits should be, but try dividing the number of developers by 2 first and see how it works for your
team. Then these numbers can be adjusted to your team. By "developers" we mean not only programmers, but also other specialists. For
example, for the "Testing" column, developers are testers, because testing is their responsibility.
2.5. Extreme Programming(XP)
Extreme Programming (XP)
The twelve basic Extreme Programming techniques (according to the first edition of Extreme programming explained) can be grouped into
four groups:
1. Short feedback cycle (Fine-scale feedback):
Development through testing (Test-driven development).

Planning game.
The customer is always there (Whole team, Onsite customer).
Pair programming.
2. Continuous, not batch process:
Continuous integration
Refactoring (Design improvement, Refactoring).
Frequent small releases.
3. Understanding shared by all:
Simplicity (Simple design).

System metaphor.
Collective code ownership or selected design patterns (Collective patterns ownership).
Coding standard or Coding conventions.
Programmer welfare:
40-hour work week (Sustainable pace, Forty-hour week).
3. Software Testing Life Cycle
Following the general logic of iteration that prevails in all modern software development models, the testing life cycle is also expressed as a
closed sequence of actions.
It is important to understand that the length of such an iteration (and, accordingly, the degree of detail of each stage) can vary over a wide
range - from a few hours to tens of months. As a rule, if we are talking about a long period of time, it is divided into many relatively short
iterations, but at the same time it “gravitates” to one or another stage at each point in time (for example, there is more planning at the
beginning of the project, more reporting at the end) .
It is also worth emphasizing once again that the above scheme is not a dogma, but the general essence and key principles remain
unchanged. Let's consider them.
Stage 1 (general planning and requirements analysis) is objectively necessary, at a minimum, in order to have an answer to such questions
as: what we have to test; how much work will be; what are the difficulties; do we have everything we need, etc. . As a rule, it is impossible to
get answers to these questions without analyzing the requirements. it is the requirements that are the primary source of answers.
Stage 2 (clarification of acceptance criteria) allows you to formulate or refine the metrics and signs of the possibility or necessity of starting
testing, pausing and resuming testing, completing or stopping testing.
Stage 3 (refining the test strategy) is another recourse to planning, but at the local level: those parts of the test strategy that are relevant to the
current iteration are considered and refined.
Stage 4 (development of test cases) is devoted to the development, revision, refinement, refinement, processing and other actions with test
cases, test case sets, test scripts and other artifacts that will be used in the direct testing.
Stage 5 (execution of test cases) and stage 6 (fixation of the found defects) are closely related to each other and are actually performed in
parallel: defects are fixed immediately upon their discovery during the execution of test cases. However, often after all test cases have been
completed and all defect reports have been written, there is an explicitly defined refinement stage in which all defect reports are reviewed
again in order to form a common understanding of the problem and clarify such characteristics of the defect as importance and urgency.
Stage 7 (analysis of test results) and stage 8 (reporting) are also closely related and are carried out almost in parallel. The conclusions
formulated at the stage of analysis of the results directly depend on the test plan, acceptance criteria and refined strategy obtained at stages
1, 2 and 3. The conclusions obtained are formalized at stage 8 and serve as the basis for stages 1, 2 and 3 of the next testing iteration. Thus,
the cycle is closed.

Theory On Lecture 1.3

Uploaded by

Document Information

Original Title

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

Theory On Lecture 1.3

Uploaded by

Copyright:

Available Formats

7/5/23, 2:58 PM Theory on lecture 1

Site: Andersen Moodle Printed by: Malathy S

1. Quality assurance and software testing - basic concepts and definitions

2. The Software Development Life Cycle

3. Software Testing Life Cycle

1. Quality assurance and software testing - basic concepts and

Software Quality Characteristics

Software quality model

Who is a tester and what does he do

1. Increased responsibility and diligence;

3. Patience, perseverance, attention to detail, observation;

4. Good abstract and analytical thinking;

Where do software bugs come from?

errors in the specification, design, or implementation of a software system;

Quality – the extent to which a set of inherent characteristics meets requirements.

Requirement – a need or expectation that is set. Usually expected or required.

1.1. Principles of Testing

And a few more important principles:

testing should be carried out by independent experts;

1.2. Verification and Validation

the customer is interested, to a greater extent, in validation (satisfaction of own requirements);

1.3. QA, QC and testing

2. The Software Development Life Cycle

The main notations used are:

Development and programming

Development of algorithms - creation of the logic of the program.

There are four levels of documentation:

The testing process consists of the following steps:

The main goals of this stage:

Deployment and Maintenance

2.1. Software Development Models

Features of the waterfall model:

high level of formalization of processes;

• Very inflexible methodology.

• High transparency of development and project phases.

• Strict control of project management.

• Well-defined quality control procedure.

Spiral Software Life Cycle Model

1. The result is achieved in the shortest possible time.

V model — test-driven development

The V-model provides support in project planning and implementation.

The following tasks are set during the project:

2.2. Agile (ideology) - software development manifesto

Agile (ideology) - software development manifesto

The Fundamental Principles of the Agile Manifesto We follow these principles:

Sprint life cycle

1) Sprint planning, meeting one.

Participants: team, Product Owner, Scrum Master, management

Artifact: Sprint Backlog

2) Sprint planning, meeting two.

Participants: team, Scrum Master

2. Sprint Abnormal Termination

3. Daily Scrum Meeting

• What was done yesterday?

• What will be done today?

• What problems did you encounter?

Discuss the problem with control rendering.

A chart that shows the amount of work done and remaining.

There are different types of charts:

The difference between Kanban and SCRUM:

Columns from left to right:

2.5. Extreme Programming(XP)

Extreme Programming (XP)