You are on page 1of 10

SAP TESTING GURU

TARAKESH

SDLC is an acronym for Software Development Life Cycle. It is also sometimes referred to
as System Development Life Cycle. In simple words it the process, methods or a set of
methodologies applied to create or alter software projects. Each of these methodologies
defines unique way to create a new software module or program.

What is SDLC methodology?


There are basically five common types of approach and techniques which defines the
foundation pillar of the software development life cycle. These techniques are called sdlc
methodology. They are Waterfall model, Incremental Model, Spiral model, Prototyping
model and Win-Win Spiral Model.

SDLC Definition
SDLC is a process used by IT analysts in order to develop or redesign high quality software
system which meets both the customer and the real world requirement taking into
consideration all associated aspects of pros and cons of software testing, analysis and post
process maintenance.
Waterfall model has the simplest life cycle whereas Win-Win spiral model has the most
complex one. How can you decide which method or process to implement while developing
a software model? It all depends on the feasibility analysis and requirement factor. For larger
projects it is advisable to use Spiral and Incremental model. Using this process you can
develop the programs in modules and parts which bring in more flexibility to the large
project. Whereas if you have a smaller project with fixed requirement which does not require
any changes during the development you can decide to go with the waterfall model.
For more information about various sdlc models and methodologies you can check out the
following documents:

tarakeshsaptesting@gmail.com

Page 1

SAP TESTING GURU

TARAKESH

Waterfall Model
Spiral Model
Prototyping Model
Incremental Model
Win Win Spiral Model
We have also prepared a wonderful set of commonly asked interview questions with
answers on sdlc. If you are a software developer looking for white papers you can check
out sdlc documentation page.

Before the acceptance of software development as an engineering stream, the process of


developing software was an adhoc activity with no formal rules or standards. As a result,
software projects faced serious problems in terms of schedule slippage, cost overrun, and
inferior quality of software.
Software Development Life Cycle (SDLC) was introduced to address the problems faced
during the software development process. SDLC is a disciplined and systematic approach
that divides the software development process into various phases, such as requirement,
design, and coding. The phase-wise development process helps to track schedule, cost, and
quality of the software projects life cycle.

SDLC Phases
Feasibility analysis
Includes analysis of project requirements in terms of input data and desired output,
processing required to transform input into output, cost-benefit analysis, and schedule of the
project. The feasibility analysis also includes the technical feasibility of a project in terms of
available software tools, hardware, and skilled software professionals. At the end of this
phase, a feasibility report for the entire project is created.

tarakeshsaptesting@gmail.com

Page 2

SAP TESTING GURU

TARAKESH

Requirement analysis and specification


Includes gathering, analyzing, validating, and specifying requirements. At the end of this
phase, the Software Requirement Specification (SRS) document is prepared. SRS is a formal
document that acts as a written agreement between the development team and the
customer. SRS acts as input to the design phase and includes functional, performance,
software, hardware, and network requirements of the project.

Design
Includes translation of the requirements specified in the SRS into a logical structure that can
be implemented in a programming language. The output of the design phase is a design
document that acts as an input for all the subsequent SDLC phases.

Coding
Includes implementation of the design specified in the design document into executable
programming language code. The output of the coding phase is the source code for the
software that acts as input to the testing and maintenance phase.

Testing
Includes detection of errors in the software. The testing process starts with a test plan that
recognizes test-related activities, such as test case generation, testing criteria, and resource
allocation for testing. The code is tested and mapped against the design document created
in the design phase. The output of the testing phase is a test report containing errors that
occurred while testing the application.

Maintenance
Includes implementation of changes that software might undergo over a period of time, or
implementation of new requirements after the software is deployed at the customer location.
The maintenance phase also includes handling the residual errors that may exist in the
software even after the testing phase.

************************************************************
tarakeshsaptesting@gmail.com

Page 3

SAP TESTING GURU

TARAKESH

What is STLC?
Software Testing Life Cycle process is an integral part of the Software Development Life
Cycle. The overall aspect of STLC phase deals with testing and rectifying any error code
generating within the program under various test conditions.
STLC is a part of SDLC and is basically the Testing phase of SDLC.
SDLC- Requirement gathering, designing, coding, testing, implementation, while the testing
part of it is STLC which stands for software testing life cycle and it includes
Requirement Analysis- BRD and FRDs are studied and if any questions are raised to BA, PM.
KT sessions are conducted with testers, where KT sessions are knowledge transfer sessions.
Test Planning- here the scope of testing is decided like what to be tested, what not to be
tested, what kind of testing is done, what tools will be used.
Test Case Development- Cases are developed and designed based on the requirements.
where each test case will have details like case ID, priority test name, steps descriptions,
expected result of particular test.
Environment Setup- where we decide the software and hardware to be used for testing.
Test Execution- where we put cases into action and before it is done the cases are validated
if they are going to give the desired result.
Test Cycle Closure- after testing is completed, test cycle closure is prepared stating all
defects are closed and software is defect free.

What is STLC?

STLC is simply a testing phase in the SDLC development. Validation and Authentication is
tried and tested in this phase. The only limitation of this cycle is that it is limited to respective
individual phase and is carried out by a group of skilled testers and technology evangelistic.

STLC Life Cycle


Like SDLC, STLC has fixed phases which is mentioned in hierarchy below:
1. TEST PLANNING Preparing the test strategy & planning
2. TEST DEVELOPMENT Creating the testing environment
3. TEST EXECUTION Writing the test cases/Creating & Executing the Test Script

tarakeshsaptesting@gmail.com

Page 4

SAP TESTING GURU

TARAKESH

4. RESULT ANALYSIS Analysis result and Bug report


5. BUG TRACKING - Analyse Bugs and application errors
6. REPORTING This is a post conditional process which involves collecting data from end
users

Difference Between SDLC and STLC


As we can see that SDLC and STLC have some common aspects but they differ completely
from each other. SDLC vs STLC is a complex debate and hence we have provided some
examples to make this point clear 1. STLC is a part of SDLC. It is like a SET and a SUBSET. We cannot have STLC running
individually on its own. It needs to wait for its roll call before implementing its phases.
2. STLC is limited to Testing software module. SDLC is rather a vast model with more inputs
and executions.
3. STLC is the most important part of the SDLC life cycle. One cannot release the final
product without running it through STLC process.
4. STLC team requires skilled developers and Testers. The efficiency demand is rather high
here in comparison to other parts of the SDLC module.
5. STLC is also a part of the post release update cycle. The bug fixes and end user reports are
logged by the application. This log is checked and fixed while building and releasing the new
version of the software or Program module.
You should now have a firm understanding about the Software Testing Life Cycle. If you
should not understand any point in this tutorial you can ask back in the comment section. I
will make sure all your queries are individually replied and explained.

**********************************************************************************

Defect life cycle:


Defect life cycle is a cycle which a defect goes through during its lifetime. It starts when defect is
found and ends when a defect is closed, after ensuring its not reproduced. Defect life cycle is related
to the bug found during testing.
The bug has different states in the Life Cycle. The Life cycle of the bug can be shown
diagrammatically as follows:

tarakeshsaptesting@gmail.com

Page 5

SAP TESTING GURU

TARAKESH

1. New: When a defect is logged and posted for the first time. Its state is given as new.
2. Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is
genuine and he assigns the bug to corresponding developer and the developer team. Its state
given as assigned.
3. Open: At this state the developer has started analyzing and working on the defect fix.
4. Fixed: When developer makes necessary code changes and verifies the changes then he/she
can make bug status as Fixed and the bug is passed to testing team.
5. Pending retest: After fixing the defect the developer has given that particular code for retesting
to the tester. Here the testing is pending on the testers end. Hence its status is pending retest.
6. Retest: At this stage the tester do the retesting of the changed code which developer has given
to him to check whether the defect got fixed or not.
7. Verified: The tester tests the bug again after it got fixed by the developer. If the bug is not
present in the software, he approves that the bug is fixed and changes the status to verified.
8. Reopen: If the bug still exists even after the bug is fixed by the developer, the tester changes
the status to reopened. The bug goes through the life cycle once again.
9. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer
exists in the software, he changes the status of the bug to closed. This state means that the
bug is fixed, tested and approved.
10. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug,
then one bug status is changed to duplicate.

tarakeshsaptesting@gmail.com

Page 6

SAP TESTING GURU

TARAKESH

11. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of
the bug is changed to rejected.
12. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next
releases. The reasons for changing the bug to this state have many factors. Some of them are
priority of the bug may be low, lack of time for the release or the bug may not have major effect
on the software.
13. Not a bug: The state given as Not a bug if there is no change in the functionality of the
application. For an example: If customer asks for some change in the look and field of the
application like change of colour of some text then it is not a bug but just some change in the
looks of the application.

There are two things in defects of the software testing. They are:
1)

Severity

2)

Priority

What is the difference between Severity and Priority?


1) Severity:
It is the extent to which the defect can affect the software. In other words it defines the impact that a
given defect has on the system. For example: If an application or web page crashes when a remote
link is clicked, in this case clicking the remote link by an user is rare but the impact of application
crashing is severe. So the severity is high but priority is low.
Severity can be of following types:

Critical: The defect that results in the termination of the complete system or one or more
component of the system and causes extensive corruption of the data. The failed function is
unusable and there is no acceptable alternative method to achieve the required results then the
severity will be stated as critical.

Major: The defect that results in the termination of the complete system or one or more
component of the system and causes extensive corruption of the data. The failed function is
unusable but there exists an acceptable alternative method to achieve the required results then
the severity will be stated as major.

Moderate: The defect that does not result in the termination, but causes the system to produce
incorrect, incomplete or inconsistent results then the severity will be stated as moderate.

Minor: The defect that does not result in the termination and does not damage the usability of the
system and the desired results can be easily obtained by working around the defects then the
severity is stated as minor.

tarakeshsaptesting@gmail.com

Page 7

SAP TESTING GURU

TARAKESH

Cosmetic: The defect that is related to the enhancement of the system where the changes are
related to the look and field of the application then the severity is stated as cosmetic.

2) Priority:
Priority defines the order in which we should resolve a defect. Should we fix it now, or can it wait?
This priority status is set by the tester to the developer mentioning the time frame to fix the defect. If
high priority is mentioned then the developer has to fix it at the earliest. The priority status is set
based on the customer requirements. For example: If the company name is misspelled in the home
page of the website, then the priority is high and severity is low to fix it.
Priority can be of following types:

Low: The defect is an irritant which should be repaired, but repair can be deferred until after
more serious defect have been fixed.

Medium: The defect should be resolved in the normal course of development activities. It can
wait until a new build or version is created.

High: The defect must be resolved as soon as possible because the defect is affecting the
application or the product severely. The system cannot be used until the repair has been done.

Few very important scenarios related to the severity and priority which are asked during the
interview:
High Priority & High Severity: An error which occurs on the basic functionality of the application and
will not allow the user to use the system. (Eg. A site maintaining the student details, on saving record
if it, doesnt allow to save the record then this is high priority and high severity bug.)
High Priority & Low Severity: The spelling mistakes that happens on the cover page or heading or
title of an application.
High Severity & Low Priority: An error which occurs on the functionality of the application (for which
there is no workaround) and will not allow the user to use the system but on click of link which is
rarely used by the end user.
Low Priority and Low Severity: Any cosmetic or spelling issues which is within a paragraph or in the
report (Not on cover page, heading, title).

There are two techniques for estimation:


One involves people with expertise on the tasks to be done and
1. Other involves consulting the people who will do the work .
The first one involves analyzing metrics from past projects and from industry data.

tarakeshsaptesting@gmail.com

Page 8

SAP TESTING GURU

TARAKESH

Lets look at both of them one by one.


1. People with expertise on the tasks to be done:
In this process we ask the individual contributors and experts involves working with experienced staff
members to develop a work-breakdown structure for the project. With that done, you work together to
understand, for each task, the effort, duration, dependencies, and resource requirements. The idea is
to draw on the collective wisdom of the team to create your test estimate. Using a tool such as
Microsoft Project or a whiteboard and sticky-notes, you and the team can then predict the testing enddate and major milestones. This technique is often called bottom up estimation because you start at
the lowest level of the hierarchical breakdown in the work-breakdown structure the task and let the
duration, effort, dependencies and resources for each task add up across all the tasks.
Analyzing metrics can be as simple or sophisticated as you make it. The simplest approach is to ask,
How many testers do we typically have per developer on a project? Or another more reliable
approach involves classifying the project in terms of size (small, medium or large) and complexity
(simple, moderate or complex) and then observing on average how long projects of a particular size
and complexity combination have taken in the past. Sophisticated approaches involve building
mathematical models in a spreadsheet that look at historical or industry averages for certain key
parameters number of tests run by tester per day, number of defects found by tester per day, etc.
and then plugging in those parameters to predict duration and effort for key tasks or activities on your
project. The tester-to-developer ratio is an example of a top-down estimation technique, in that the
entire estimate is derived at the project level, while the parametric technique is bottom-up, at least
when it is used to estimate individual tasks or activities.
We prefer to start by drawing on the teams wisdom to create the work breakdown structure and a
detailed bottom-up estimate. We then apply models and rules of thumb to check and adjust the
estimate bottom-up and top-down using past history. This approach tends to create an estimate that
is both more accurate and more defensible than either technique by itself.
2. Consulting the people who will do the work:
Even the best estimate must be negotiated with management. Negotiating sessions exhibit amazing
variety, depending on the people involved. However, there are some classic negotiating positions. Its
not unusual for the test leader or manager to try to sell the management team on the value added by
the testing or to alert management to the potential problems that would result from not testing enough.
Its not unusual for management to look for smart ways to accelerate the schedule or to press for
equivalent coverage in less time or with fewer resources. In between these positions, you and your
colleagues can reach compromise, if the parties are willing. Our experience has been that successful
negotiations about estimates are those where the focus is less on winning and losing and more about
figuring out how best to balance competing pressures in the realms of quality, schedule, budget and
features.

tarakeshsaptesting@gmail.com

Page 9

SAP TESTING GURU

TARAKESH

What is Verification in software testing? or What is software verification?

It makes sure that the product is designed to deliver all functionality to the customer.

Verification is done at the starting of the development process. It includes reviews


and meetings, walkthroughs, inspection, etc. to evaluate documents, plans, code,
requirements and specifications.

Suppose you are building a table. Here the verification is about checking all the
parts of the table, whether all the four legs are of correct size or not. If one leg of
table is not of the right size it will imbalance the end product. Similar behaviour is
also noticed in case of the software product or application. If any feature of software
product or application is not up to the mark or if any defect is found then it will result
into the failure of the end product. Hence, verification is very important. It takes
place at the starting of the development process

What is Validation in software testing? or What is software validation?

Determining if the system complies with the requirements and performs functions for which it
is intended and meets the organizations goals and user needs.

Validation is done at the end of the development process and takes place after verifications
are completed.

It answers the question like: Am I building the right product?

Am I accessing the right data (in terms of the data required to satisfy the requirement).

It is a High level activity.

Performed after a work product is produced against established criteria ensuring that the
product integrates correctly into the environment.

Determination of correctness of the final software product by a development project with


respect to the user needs and requirements.

tarakeshsaptesting@gmail.com

Page 10

You might also like