Software:

Set of instructions, programs document to perform specific task in system

Software can be categorized into 2 types:
1. System Software:
Also called as BIOs (Basic Input and Output to system)
These are to provide interface among the system components (i.e.System Booting)
Ex: Device Drivers, OS like Windows, Unix, Linuxetc
2. Application software:
Also called as Front-end applications
These are developed based on customer business transactions
In general application software consist front end or User Interface to
manipulate data into Data Base
Application software can be divided into 2 types
i. Project based:
When we develop the application based on specific client
requirements and that should be deliver that particular client only
Ex: www.mindqsystems.com is a project for Mindq client
ii. Product based:
When we develop the application based on standard
requirements/generic requirements for a particular industry
and that can be sells to any customer in the market
Software Development Life Cycle (SDLC)
It describes development process of software project/product to fulfill the client
requirements within the specified cost and time
Following are the phases involved in SDLC:
Requirements Collection:
In this phase Business Analyst (BA) will collect requirements with an
interaction of client and collected requirements will be documented as BRS/URS/
CRS (Business/User/Client requirement specifications)
BRS describes Core business logic or brief description about client business needs
like who are the users for application and required services for those users
After preparation of BRS they perform feasibility study to check project is
acceptable or not, where as BA will play key role in Feasibility study to analyze
following factors
-Finance Feasibility
-Time Feasibility
-Requirements are reliable or not in terms of technology to develop
If project is acceptable then BA will intimate to the client by releasing Request For
Proposal (RFP) and Service Level Agreement (SLA) doc.
Requirements Analysis:
In this phase System Analyst (SA) will study client business needs which are
specified in BRS and then he will prepare Functional Requirement Specification (FRS)
FRS describes detailed functionality of each component in application
Clear FRS is an essential for successful application implementation
Design:
In this phase Design Architect (DA) will study client requirements which are
described in Requirement documents like BRS & FRS
Then initially he will decide architecture of application like windows or Web
based and then he will select required programming or scripting language and DB technology
Following are the documents will prepared by DA:
i. GUI Design Doc:
It contains dummy screens of application to know the future
implementation of application and to understand navigational flow of functionalities
ii. DB Design Doc:
It describes about DB structure like number of Tables in DB, relation
among those table and Rules implemented in DB
iii. Application Design Doc/Technical Design Doc (TDD)
There are 2 types of documents
a. High Level Design Doc(HLD):
It describes number of modules required in application and relation between those modules
b. Low Level Design (LLD):
For each module there will be individual low-level design doc.
It describes internal logic of each module with help of Data-flow
diagrams and Entity-relative diagrams Coding:
In this phase Developers will write the programs using programming or scripting
languages in order to develop the application
Output of this phase is Source code Doc (SCD) Testing:
After coding programs are available for execution
Initially Developers will perform Unit testing and Integration testing using WBT Techniques
After that separate testing team will perform System testing using BBT techniques
Client also will perform UAT/AT
Release & Maintenance: After system testing and UAT client satisfied on our work product then we
can deliver the application for further usage at live environment is called Go-Live/ Production/Release
While using the application client may identify some defects (i.e. Latent
Defects) or he may required some new features in application then he will send
Change Request (CR) to the development company
Change Control Board (CCB) will work on CR based on initial agreements
and then we deliver modified version to the customer
Note: When project is no longer in use that will be end state for SDLC for that project Common Problems in SDLC:
i. Poor Requirements: when requirements are not clear or incomplete
that will be a problem to develop application
ii. Unrealistic Schedule: if too much of work crammed in a too little time that will be a problem
iii. Inadequate Testing: in present scenario it is difficult to estimate how much testing sufficient to validate application
iv. Dynamic changes: if client continuously sending changes in the requirements
v. Miscommunication: lack of communication among the associated
project members like PM, Domain expert, BA, Developers and Testers
When do defects will arise while developing application?
Scenario-1: Right Requirements- Design to meet requirements Coding to
meet Design Right project/Product
Scenario 2: Right Requirements- Design to meet requirements mistakes in
Coding Coding Defect in project/Product
Scenario-3: Right Requirements- Mistakes in Design Coding to meet Design
Design defects in project/Product
Scenario-4: Wrong Requirements- Design to meet requirements Coding to
meet Design Wrong project/Product
Defect Repair cost w. r. to SDLC phases:
SDLC phases Defect Repair cost (%)
Requirements 0%
Design 10%
Coding 30%
Testing 50%
Maintenance 100%
Note: early stages identified defects will take less cost to resolve those defects
compare to later stages identified defects
Note: S/w testing will help to reduce maintenance cost for a project
Quality Management:
It is a process of preventing defects while developing application to ensure there
are no defects in final product
Quality management is divided into 2 parts:
i. Quality Assurance (QA):
QA team is responsible to define development process of application
in order to prevent defects, where they monitor, measure the
strength of development process if any weakness identified then
they provide suggestion to improve the strength of development process
In general QA team members are Domain expert, Tech. Expert, PMetc
ii. Quality Control (QC)
QC team involve after product is built in order to identify any defects
If any defects are identified make sure those defects should be
resolved before deliver application to the customer
In General White Box testers and Black Box testers involved in QC QA QC
It is a process oriented It is a product oriented
It involve throughout the life cycle
It is a defects preventive approach
Reviews, Auditing are the QA
activities (Outcomes )
It involve after product built
It is defects detective approach
s/w testing is an example for QC activity
SDLC Models:
Based on need of customer and complexity of requirements or functionalities we
can adopt any one of the following SDLC model to develop application
1. Waterfall model
2. Prototype Model
3. Spiral model
4. RAD model
5. Fish model
6. V-model
7. Agile Model/Methodology
1. Waterfall model:
It is also called as linear sequential waterfall model
This model is suitable to develop small applications which have the clear
requirements and routine type of projects (i.e. well known infrastructure of application)
In this model for whole system one phase activities are completed then
only we start next phase activities to develop application
This model contains all the SDLC phases like:
Advantages: It is easy to develop the application
Disadvantages:
i. Early stages identifying defects are not possible due to later stage of testing
ii. This model is not suitable to handle dynamic changes in the requirements
2. Prototype Model:
Prototype: it is a sample application without functionality (i.e. Dummy screens)
Prototype model is preferable when requirements are not clear or incomplete to develop application
In this approach based on initial requirements we develop prototypes and
those are presented to the customer to collect feedback based on that we develop application
Advantages:
i. With help of prototypes we can collect complete requirements before actual coding
ii. With help of prototypes client can estimate strength of development team
Disadvantages:
i. Developing prototypes is an additional task for developers and those
cost to be borne by development team only
ii. Prototypes are not reusable
3. Spiral model\Iterative model\evolutionary model:
This model is preferable for research applications and machine criticality
applications which are not possible to estimate successful implementation at early stages
Ex: Aero space related applications
In this model application divided into modules and then one module
successfully implemented then only they will start next module
implementation activities
Advantages:
i. Quality application we can develop
ii. Less resource required
Disadvantage:Time consuming
4. RAD model:
RADRapid Application Development model
This model is preferable when client required application in an extremely
short span of time like 60-90 days
In this approach we use some pre-defined functionality components in our application
Ex: Date field, Status bar, Mobile No. Edit box from ActiveX controls
Advantage: It quick time we can develop application
Disadvantage:Application may not stable in long run
5. V-Model:
V-stands for verification and validation
In this model application developed in sequential approach
This model is suitable for big projects which have the clear requirements
In this model they provided same weight-age for testing w. r. to
Development activities
Advantages:-testing activities will start early stages with development activities
Disadvantage:-this model is not suitable to handle dynamic changes in the requirements
Note: Meeting point in V-model in Coding
Static Testing:
without executing a program or application finding mistakes is called static testing
Dynamic testing:
while executing a program or application finding mistakes is called dynamic
testing
Ex: verify controls spelling correct or not in www.testingtoolsworld.com
application home page (Static testing)
Ex: verify Training link working correctly or not (dynamic Testing)
Verification:
It is a process to check Are we developing product right or not?
Verification is a static testing approach
In general verification performed on Requirement doc., Design doc., Source code, Test casesetc
Verification techniques are:
Peer Review (Informal Meeting)
Walkthrough (semi-informal meeting)
Inspection (formalized meeting)
Validation:
It is a process to check Are we developed right product or not?
It is a dynamic testing approach
In general validation performed on application source code and functionalities
Validation techniques are:
Unit testing
Integration testing
System testingetc
6. Agile model:
In this approach client closely associates with development team to provide his inputs
In this model application developed like incremental approach
Whenever small unit is implemented that will be delivered to testing
team and client to get an approval before they plan for next unit
implementation, if any changes required in previous unit first they perform
those modification before implementation of next unit
In this model deliverables are expected within a week/2-weeks/3 to 4
weeks this type small life cycles called as Sprits or time boxes
In Agile model followed approaches Scrum and Extreme Programming (XP)
Advantages: -this model is suitable to handle dynamic changes in the requirements-high quality application we can produce
Disadvantage: Strict schedules should be followed
Testing Approaches:
1. Exhaustive testing:
Testing the application with all possible combinations is called Exhaustive testing
In present scenario Exhaustive testing is not possible
2. Optimal Testing:
Testing the application with best possible combinations is called Optimal testing In present scenario we prefer Optimal testing only
Testing methodologies:
To achieve the completeness of source code and functionality validation we following testing methodologies to derive best possible test cases
1. White Box testing:
Using programming knowledge validating source code of application is Called WBT
WBT also called as Open Box testing/Clear Box Testing/Glass Box testing/Structural Testing
In general Developers or White Box testers will use following WBT
techniques to derive test cases in order to validate source code of application
-Statements Coverage
-Path or Branch Coverage
2. Black Box Testing:
It is also called as Closed Box testing
Without any programming knowledge validating application functionalities
using requirements knowledge is called BBT
In general separate Testing team will use BBT Techniques to derive test cases
Following are the BBT techniques:
-Boundary Value Analysis
-Equivalence Class Partition
-Error Guessing
WBT BBT
It is structural and Design based testing
It is internal Logic driven testing It is Business Transaction driven
It will provide code coverage It will provide requirements
Performed by Developers Performed by separate testing team
3. Gray Box Testing:
It is a combination of WBT and BBT
To perform GBT we should have programming knowledge and complete
requirements knowledge
It is specifications based testing
testing coverage