Software Development Life Cycle SDLC

                                                            SDLC
                                          Software Development Life Cycle

What is SDLC?

SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the quality of software and the overall development process.

The following figure is a graphical representation of the various stages of a typical SDLC.

A typical Software Development life cycle consists of the following stages:

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational, and technical areas.

Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the customer or the market analysts. This is done through .SRS. . Software Requirement Specification document which consists of all the product requirements to be designed and developed during the project life cycle.

Stage 3: Designing the product architecture

SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements specified in SRS, usually more than one design approach for the product architecture is proposed and documented in a DDS - Design Document Specification.

This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity , budget and time constraints , the best design approach is selected for the product.

A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle.

Developers have to follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers etc are used to generate the code. Different high level programming languages such as C, C++, Pascal, Java, and PHP are used for coding. The programming language is chosen with respect to the type of software being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However this stage refers to the testing only stage of the product where products defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometime product deployment happens in stages as per the organizations. business strategy. The product may first be released in a limited segment and tested in the real business environment (UAT- User acceptance testing).

Then based on the feedback, the product may be released as it is or with suggested enhancements in the targeting market segment. After the product is released in the market, its maintenance is done for the existing customer base.

SDLC MODEL

Sequential Models: These models are best suitable for small size of applications where all development activities are carried out in a sequential order for the entire project.

Iterative Models: These models are best suitable for big projects in which a big project will be divided into modules then the application will be implemented module by module.

Waterfall Model: It is a beginning approach of development model where all development activities are carried out one after another for the entire project.

*) In this approach tester conduct testing after coding i.e. only validation.

Waterfall Model design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate phases. In Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.

Following is a diagrammatic representation of different phases of waterfall model.divided into modules then the application will be implemented module by module.

*) As flow of all activities look like a waterfall is called waterfall model.

The sequential phases in Waterfall model are:

Requirement Gathering and analysis: All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification doc.

System Design: The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture.

Implementation: With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality which is referred to as Unit Testing.

Integration and Testing: All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.

Deployment of system: Once the functional and non functional testing is done, the product is deployed in the customer environment or released into the market.

Maintenance: There are some issues which come up in the client environment. To fix those issues patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model phases do not overlap.

Waterfall Model Application

Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors. Some situations where the use of Waterfall model is most appropriate are:

• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.

Waterfall Model Pros & Cons

ADVANTAGE
The advantage of waterfall development is that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order.

DISADVANTAGE
The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage.

The following table lists out the pros and cons of Waterfall model:

Defect Reporting

Defect Reporting: 

once a defect is identified we have to document the defect & report the
same to developer

Severity - Stops the system execution. 

Runtime error

Showstopper Severity - Stops the system execution.

Defect Age:    The time gap between date of detection & date of closure I known as the defect

age

Defect Severity: How serious the problem in the system or the impact of the problem in the

system is called defect severity.

Very high - fatal-S0

High - Major-S1

Medium - Minor-S2

Low – Low-S3

Showstopper defect: A defect which is not permitting to continue further test is called showstopper defect.

Defect Priority: The order in which the defect is to be resolved is called defect priority.

***Note :

*) Defect severity may be specified by the tester & defect priority will be assigned by manager

*) In general defect severity and priority’s proposition to each other but in some situation

that may vary.

*) An example of a defect that takes low severity and high priority. - Incorrect company logo and incorrect company title

*) An example for a defect that takes high severity and low priority - A serious problem belongs

to inter release module.

Defect Age: The time interval between date of detection and date of closure is called is defect

age.

*) In other words how long a bug is present in the development life cycle is called defect age.

Test Closure:  It is the last phase of SDLC where the management prepares various test summary reports that explains the complete statistics of the project.

Common Repository: Work Product:

A centralized computer system where you stored and mange all project resources is called

common repository.

Configuration Management: Maintaining all project resources in a centralized system, maintaining appropriate version controlling based on the changes made to them is called configuration management.

Software Configuration Tools:

*) VSS (Visual Source Safe)

*) CVS (Concurrent Version System (open source))

***Note:

*) Quality center test management tools also provide configuration management services.

Test Case

                                                                                Test Case


Test Case: A Test Case is set of preconditions steps to be followed with input data and expected behaviour to validate functionality a system.

In simple words a test case is brief description of what to test and how to test.

***Note :
In Industry practically we prepare only functionality test cases.

Three types of functional test cases:

1) Positive test cases                 2) Negative test cases               3) Business validation test cases


Positive Test Case:  A Test case prepared in a positive perception to check what a system suppose to do is called positive test case.

Example:-
Tc1: Check Login with valid inputs.

Negative Test Case:  A Test case prepared to check what a system not suppose to do is called negative test case.

Example:-
Tc1: Check Login with invalid inputs.

Business Validation Test case: A test case prepared to check business conditions is called business validation test cases.

Example:-
Check fund transfer with 1000, 10000, 15000, etc is called business validation test case.

****Interview Question important****

What is a good test case?

A test case that has high probability of catching defects is called a good test case.

Test case design techniques:,Black box testing introduces the following techniques which help in preparing effective test cases to validate system functionality:

1) Equivalence class partitioning (ECP)

2) Boundary value analysis (BVA)

3) Decision table

4) State transition testing

5) Usecase testing.


Equivalence class partitioning (ECP): According to ECP at first identity all possible test cases
to validate functionality in the system. Then segregate these test cases into groups. While making
a group make sure that all test cases that belong to a group are producing the same out put
then select one test case from each group, preferably middle one for testing.

Boundary Value Analysis: 

It has observed that most of the times programmers are committing mistakes while specifying the boundary conditions to determine these defects BVA is helpful.


According to BVA once equivalence partitions are defined, identify the partition where there are
inputs with range. Determine outer boundary an inner boundaries for this range. For positive
negative testing consider lower boundary value minus one and upper boundary value plus one.


Decision table testing: Decision table testing is helpful to derive the test cases if functionality is
depending on multiple inputs.

As login depending on two inputs i.e., userid, password to check login we can cover a following test

cases

If functionality is depending on more number of inputs we can reduce the test cases based on
the application design

State transition testing:

*) Every software will have various possible states. The state of the application changes
from one to another based on the user actions under input supplied.

*) State transition testing is helpful to derive and prepare test cases in order to cover all possible
states of the application.

Usecase testing: Validating software to confirm whether it is develop as per the use cases or
not is called user case testing.

Requirement traceability Matrix (RTM): Mapping between test cases and requirements is
called traceability mapping.

Advantages of traceability Matrix:

*) To determine the percentage of test coverage.
*) To identify a group of test cases belongs to a requirement which helps in modify build testing
and also implementing the change request easily

Test Scenario

                                                                             

                                                                                          Test Scenario

Test Design: 
 In this phase test engineer will prepare various documents such as test scenario’s test cases etc. which helps in testing a software application effectively.

Test Scenario:  An item or a feature or a functionality to be tested in the application under test
is called test scenario.

                                               Test Scenario of a Calculator Application

Scenario1: Check Addition

Scenario2: Check Subtraction

Scenario3: Check Multiplication

Scenario4: Check Division

                                                 Test Scenario of a Mobile Application

Scenario1: Check switch On /SwitchOff

Scenario2: Check Making a call

Scenario3: Check Receiving a call

Scenario4: Check sending sms

Scenario5: Check receiving sms

***Note :
Once the test scenarios are prepared, reviewed and approved based on these scenario’s test
cases will be prepared.

Software Testing Life Cycle STLC

                                                                                   STLC

Test Planning: It is the first phase of system testing where the management plan the high level
and detail testing activities to be carried out.

Project manager or Test Manager will define test strategy and based on this test strategy the
detail plan called test plan is prepared.

Test Strategy: It is high level management plan and approach that provides sufficient confidence on the project being tested.

Test Plan: It is detail day to day work plan that explains scope, approach resources and work
schedules etc. Test plan can be prepared by test lead.

Test Plan Template:

1) Introduction

2) Scope
2.1) In Scope
2.2) Out of scope

3) Test Approach

4) Resources

5) Work Schedule

6) Entry Criteria & Exit Criteria

7) Test deliverables.

****Interview Question important****

Objectives of a Test Plan: a test plan document explains various procedures to be carried out
while testing a software. The main object to test plan is to determine:

1) Scope of Testing: what are the features to be tested and what are the features not to be
tested. Similarly what types of testing is applicable and what type of testing not applicable.

2) Test Approach: various guidelines to be followed while designing test cases, test data
and defect codes etc.

3) Resources: Hardware, Software and human resources.

4) Work schedules and Test delivery.

Test Analysis: In this phase test engineer will study various project requirement documents

such as BRS, SRS to understand the project requirement.

• While analysing test requirements if there are any questions those will be recorded in requirement clarification note, once analysis is finished you can get the clarification from the domain experts.

BRS Template: A BRS document contains the following sections.

1) Client introduction

2) Project Introduction

3) Existing system

4) Drawbacks in the existing system

5) Proposed system

6) Project Architecture.

SRS / FRS : A typical SRS/FRS document will contain the following sections.

1) Overview

2) Prototype

3) Page elements

4) Use case diagram

5) Use case

Non Functional System Testing

Non Functional System Testing Approach: 


UI / GUI Testing: Validating if all user interfaces are professionally designed or not is called UI Testing.

Check List for UI Testing:

1) Check if all basic elements are available in the page or not.

2) Check spelling of the objects.

3) Check alignments of the objects.

4) Check content displayed in web pages.

5) Check if the mandatory fields are highlights or not.

6) Check consistency in background color, font type and fond size etc.

Usability Testing: Checking how easily the end user is able to understand and operate the
application

Security Testing: Validating whether all security conditions are properly implemented in the
software or not


Check List for Security Testing:

1) Check if the sensitive data such as password, credit card, CVV numbers are getting encrypted or not.

2) Check browser navigation after logout

3) Check direct URL access for the both secured and non secured pages.

4) Check for session expiry

5) Check view source code option for secured pages.

6) Check for Authorization

7) Check for Authentication

8) Check cookies

Performance Testing:

It is a process of measuring various efficiency characteristics of a system such as response time, through put, load, stress transactions per minutes, transaction mix.

Load Testing: Analysing functional and performance behaviour of the application under various load conditions is called load testing.

Stress Testing: Checking the application behaviour under stress conditions is called stress testing
in other words reducing the system resources and keeping the load as constant checking how
application is behaving is called stress testing.

Recovery Testing: C hacking how system is able to handle some unexpected or unpredictable situations is called recovery testing.

Globalization Testing: checking if t he application having a provision of setting and changing
languages date and time format and currency etc.

Localization Testing: checking default languages currency date and time format etc.

Installation Testing: checking if we are able to install the software successfully or not as per
the guidelines given in installation document

Un-Installation Testing: checking if we are able to uninstall the software from the system
successfully or not

Compatibility Testing: checking if the application is compatible with the different software
and hardware environm

Functional Testing

                                                   

Functional System Testing Approach: 

Smoke Testing : It is a kind of quick test carried out on the application to determine whether the application is
testable or not.

Formal Testing: If you tested software application by following all preplan procedures and
proper documentation then it is called formal testing.

Adhoc Testing: If you test software without following any procedures and documentation
then it is called adhoc-testing. It is also called informal testing.

Risk Based Testing (or) Priority Based Testing: Identifying the critical functionality in the
system and testing it first

                                                                               Or

Conducting testing in the same order of priority is called risk based testing or priority based
testing.

Re- Testing: Testing functionality again or testing functionality repetitively is called re-testing.

Re-testing comes in the following 2 scenarios.

1) Testing a functionality with multiple inputs to confirm i f the business validations
are implemented or not

2) Testing a functionality on the modified build to confirm the bug fixers are made correctly or
not.

Regression Testing: It is process of identifying various features in the modified build where there is a chance of getting affected and retesting these features.

1) The new functionalities added to the existing system or modifications made to the
existing system or the bug fixes may introduce side-effects. R egression testing is
helpful to identify these side effects.

End to End Testing: Testing the overall functionalities of the system including the data integration among all the modules is called end-to-end testing.

Exploratory Testing: Exploring the application and testing the functionalities

                                                                                 (or)

Understanding system, modifying existing test cases and executing those

Monkey Testing: Testing conducted on an application unevenly or zig-zag way with an intention of finding tricky defects is called monkey testing.

Non-Functional System Testing: Validating various non functional aspects of the system such
as user interfaces, user friendliness, security, compatibility, load, stress and performance etc is
called non-functional system testing.