Priority based software development and testing technique

PRIORITY-BASED
SOFTWARE DEVELOPMENT
AND TESTING TECHNIQUE
(PBSDT)
By
Boniface C. Nwugwo
http://www.btctechnologies.com

2
OBJECTIVES
• Show how to implement PBSDT
 Who, Where and When to do PBSDT
• Discuss some of the benefits of PBSDT
http://www.btctechnologies.com BTC Technologies

3
THE BAD NEWS
PROBLEMS WITH SOFTWARE DEVELOPMENT:
Software Development Projects are frequently
undertaken with only a vague indication of
Customer requirements
Communication between Customer and
Software Developer is often poor
Customer dissatisfaction with the
“COMPLETED” system is encountered too
frequently
BTC Technologieshttp://www.btctechnologies.com

4
THE GOOD NEWS
Each of the problems described before can
be corrected
The key is an engineering approach to the
development of software, coupled with
continuing improvement of techniques and
tools
Role Playing (this involves actual role plays)

5
PBSDT PROCESS: Who, When
and How (1 of 5)
• PBSDT process is a very simple concept
• Consists of 5 principal activities
During Customer Needs gathering
During SW Requirement Specifications
During SW Development
During SW Test Plan Development
During SW Integration & System Testing
• Each feature of the product is prioritized based on
its relative importance

6
PBSDT PROCESS: Who, When
and How (2 of 5)
• Relative importance of the product feature is
defined based on degree of necessity
• Degree of necessity is the level of importance of a
requirement from the customer’s viewpoint

7
PBSDT PROCESS: Definition of
Degree of Necessity (3 of 5)
DEGREE OF
NECESSI TY MEANI NG
Mandatory Implies that the software will not be acceptable unless these
requirements are provided in an agreed manner
Desirable Implies that these are requirements that would enhance the
software product, but would not make it unacceptable if they
were absent.
Optional Implies a set of requirements that may or may not be
worthwhile, which gives the designers the opportunity to
propose something, which exceeds the SRS.

8
PBSDT PROCESS: Definition of
Priorities (4 of 5)
PRI ORI TY MEANI NG
High Implies that the software will not be acceptable unless these
requirements are provided
Medium Implies that these are requirements that would enhance the
software product, but would not make it unacceptable if they
are absent in alpha and beta releases, but must be in the final
release to the customer
Low Implies a set of requirements that may or may not be
worthwhile, which gives the designers the opportunity to
propose something which exceeds the SRS

9
PBSDT PROCESS DIAGRAM (5 of 5) .
Figure 1. The PBSDT Process
Concept Implementation Team often times has little or no control
Phase over this
Voice of the Customer
Requirements
Definition Phase
- Implementation Team has control over this.
- We clarify our requirements and interpretation of Customer
perceived need for each program feature
Implementation Parallel
Phase Development
Of Code and
Test Cases
Test Phase
Customer Needs Requirements
Each customer requirement is
Classified as either:
• Mandatory
• Desirable or
• Optional
Software Development
• Code
• Inspect code and re-work
• Unit Test
Note: High features are developed first,
followed by Medium, then Low ones
Test Plan Development
• Test Case Design
• Test Procedures
Note: Test Cases and Test Procedures are
developed for all program features without
regard to priority
Integration and System Testing
• Priority-based testing beginning with
High, then Medium and Low
requirements are tested in that order
Software Requirements Specification
Each customer need is mapped into a software
requirement specification.
Mandatory "High"
Desirable "Medium"
Optional "Low"

10
BENEFITS (1 of 10)
• By setting priorities with respect to a deadline, the
client understands which features are most likely to
be implemented in time for the deadline. If the
client disagrees with the priority, he/she has plenty
of time to change it. Since the developers have not
coded much yet at that point, the impact of a
change in priority is minimal.

11
BENEFITS (2 of 10)
• Priorities act as a focus, helping the developers
decide which functions to implement first. If the
software developers think there isn't enough time
to implement all the requirements, they now have
the option of using the priorities as a guide to what
to implement first.

12
BENEFITS (3 of 10)
• Maximize your "bang for the buck". As it happens
so often, coding and integration take longer than
expected. By the time System/Acceptance Testing
starts, there isn't enough time left to thoroughly
test the software. This is when priority-based
testing makes the most of the time left. ”HIGH"
tests are performed first, followed by ”MEDIUM",
and “LOW” test cases. This approach means you'll
lose some efficiency in setting up individual tests,
but you gain the most value from the time you do
spend in testing.

13
BENEFITS (4 of 10)
• The Pareto Principle applies to testing, as well as
other software areas. An often quoted example is
that "20% of the code is executed 80% of the
time," and vice-versa. In testing, it's not uncommon
to find that 20% of the tests are ”High". Another
20% have ”Medium" priority. That means that 60%
of the tests don't really have to be tested until the
next release. That is handy to know when you don't
have enough time to do thorough testing. Just
concentrate on the 40% of the tests that really
matter.

14
BENEFITS (5 of 10)
• Since SQA tests by priority, when a test fails, the
software developers have the longest possible time
to investigate and correct errors with the greatest
impact.

15
BENEFITS (6 of 10)
• Testing by priority automatically does partial
regression testing.
Trunk
Main
Branches
Secondary
Branches
Leaves LOW
HI GH

16
BENEFITS (7 of 10)
• At the end of each testing cycle, SQA produces a
one-page test summary for the project manager as
shown in Figure 2. Based on the results and the
pre-agreed criteria for shipment, SQA can easily
make shipment recommendations based on
quantitative data. As the example shows, the tests
that are yet to be tested are the functions for which
the client is already willing to wait till the next
release. Therefore, the project manager could ship
the software with a fairly high confidence that the
customer would readily accept the software.

17
BENEFITS (8 of 10)
PRI ORI TY PASSED FAI LED UNTESTED TOTAL
1 - High 31 0 0 31
2 - Medium 46 3 13 62
3 - Low 58 12 29 99
TOTALS: 135 15 42 192
Figure 2. Sample summary of test results

18
BENEFITS (9 of 10)
Test Summary Chart
0
10
20
30
40
50
60
PASSED
FAILED
UNTESTED
High
Medium
Low

19
BENEFITS (10 of 10)
• The project manager gets a clear, quantitative one-
page summary of test results. With the criteria for
shipment already pre-agreed to, there is no need
for last-minute uncertainties about whether the
software is "good enough" to ship.
BTC Technollogieshttp://www.btctechnologies.com

20
CONCLUSION
• Priority-based software development & testing
technique delivers more reliable systems on time
compared to development and testing by poking
around.
• It is a rational alternative to managing software
development and testing by “seat of the pants”.
• Perhaps most important, it is driven by real-world
user perspective.

21
REFERENCES
Robert Binder, "Scenario-Based Testing for
Client/Server Systems", Software Development,
August 1995.
Vicki Tom, "Testing by Priority", The Tool-Box:
Kodak's Software Tools Newsletter, Volume IV,
No.4, Nov. 1989

Priority based software development and testing technique

More Related Content

What's hot

Similar to Priority based software development and testing technique

Recently uploaded

Priority based software development and testing technique