This post is on Software Testing and is done to aid my exam revision
(from
SW testing : Principles and Practice ,
https://www.pearsonhighered.com/program/Desikan-Software-Testing-Principles-and-Practices/PGM237788.html):
some definitions/acronyms:
SLDC
Software Development Life Cycle, eg waterfall, Spiral, prototype, RAD, V-Model, Modified V-Model, Agile/ XP.
Waterfall Model Phases:
Requirements Analysis
Planning
Hi level Design
Lo level Design
Dev / Coding
Testing
Chacteristics of the Waterfall Model
Distinct phases
each phase feeds into the next
Advantages of the Waterfall Model
simple
Disadvantages of the Waterfall Model
Sequential, if errors are detected it can be hard to trace their point of origin
potentially large amount of re-work to be done if an error is found in a previous phase
testing is left to the end of the life cycle (not ideal) !
Phases of the V-Model
Overall Business Requirements Analysis
Software Requirements analysis
Hi level design
Lo level Design
Characteristics of the V-Model
Overall business Req's
UA test design
SW Req's
Sys test design
Hi Level Design
Integration Test design----------
Lo level DesignComponent Test design
Dev / Coding - Unit test Design
Testing:
Unit testing
Integration testing
Component Testing
System Testing
User Acceptance Testing
The process flow is from top to bottom on the left and from bottom to top on the right like the OSI model, or like drawing a 'V' shape
The test design phase is brought over to the left hand side of the model
test design happens earlier and corresponds to the initial development phases of the model, and
also the test phases of the model.
Planning as a phase (as present in the waterfall model) is omitted as all phases have a degree of planning in them
The V-Model recognizes that different types of testing can be incorporated into the SDLC
Advantages of the V-Model
the tests are designed early - the earlier defects are found the better / cheaper the SDLC
the developers are in a good position to design the tests since they're familiar with the code
Disadvantages of the V-Model
rather than a model tracking the SDLC overall, the modified VModel recognises that various modules and components can be developed at different schedules - they are not sequential like the waterfall Model - and allows the tracking of individual modules but assigning each one entry and exit criteria to mark the start and end of their own VModel progression.
XP
Extreme Programming / the Agile Model
12 characteristics
1. the customer / client is kept happy with early and frequent deliveries of product iterations
2. changes to requirements re welcomed even late in the life cycle
3. deliveries of updates are frequent
4. there is close daily cooperation between the developers and the client
5. the developers are motivated individuals who can be trusted
6. co-location - face to face communication is possible
7. working software is the primary measure of progress
8. developers are able to maintain a constant pace
9. continuous attention to technical excellence and good design
10. simplicity
11. best architectures, emerging from self-organising teams
12. regular reflection on how to become more effective and adjust accordingly
Quality: is meeting the requirements of customers consistently and predictably - where customers need not be paying customers - they can be testers or developers depending on the perspective.
Quality Assurance is more of a process oriented paradigm executed during the SE development phases, and has a defect prevention through hi-quality processes philosophy.
Quality Control is more like a post process, it follows more of a defect detection and correction paradigm rather than prevention. Quality Control can be seen as a sub-process of Quality Assurance, and may have its own dedicated team in a SW-dev company.
Requirements Tracability Matrix
As part of Black Box Testing, the RTM (Requirements Tracebility Matrix) maps the requirements to testing tasks through the use of ID codes / numbers. Implicit requirements are mapped to explicit requirements.
Testing
Testing is basically a QA and QC process. The aim is to find as many defects as possible before the customer does. Rarely do we find all defects.
Software
Defects found sooner in the development cycle are cheaper to fix than those found later,
so the sooner defects are found the better.
Dijkstra's Doctrine:
Program testing can never prove the absence of defects...only their presence.
Principles of Testing
Sometimes, most times, you simply cannot test all possible inputs to your program , so you have to be smart about what you test, or what inputs you pass to your tests. Constructing tests for even simple programs is not trivial.
ie even for a program that accepts combinations of only 6 32-bit integers - you cannot test all possible combinations easily. (6 possible 32-bit ints = (2^32)^6....if each one takes only 1 ns to test, thats still in the billions of years ) your tests must be chosen intelligently with strategies like Equivalence Partitioning and BVA Boundary Value Analysis.
Tests can be prioritized with their ability to find defects, ie Boundary Tests are more likely to uncover defects than testing of random input data.
We don't want tests to be too easy - just like exams...easy exams are not so informative to Academic staff on the students performance.
If defects are not detected in the beginning, they can propagate through the dev process, just like bugs can become resistant to pesticides.
Never assume that the discovery of many defects means there must not be many defects remaining, probably there are many more remaining - as they tend to reside in clusters or convoys.....probably.
Even if lots of code defects are found and corrected - if the requirements have defects, the final product will simply be wrong....(see the Waterfall model)
Likewise if the design is wrong, this will propagate through to the customer as well, so the early stages have the highest consequence of getting it wrong. An error found in the requirements stage will be much cheaper (exponentially) than the cost of a defect found after the software had been deployed.
Costs go up.
Validation can be described as the process of evaluating a system or component during or at the end of the development process, to determine if satisfies the SRS.
to do:
Verification
Verification vs Validation
Metrics
Posts
No comments:
Post a Comment