Software Development Models

 Software Development Models

1.V-model (Sequential Development Model)

Although variants of the V-model exist, a common type of V-model uses four test levels, corresponding to the four development levels.

The four levels used in this syllabus are:

o  Component (unit) testing

o  Integration testing

o  System testing

o  Acceptance testing

In practice, a V-model may have more, fewer or different levels of development and testing, depending on the project and the software product. For example, there may be component integration testing after component testing, and system integration testing after system testing.

Software work products (such as business scenarios or use cases, requirements specifications, design documents and code) produced during development is often the basis of testing in one or more test levels. References for generic work products include Capability Maturity Model Integration (CMMI) or ‘Software life cycle processes’ (IEEE/IEC 12207). Verification and validation (and early test design) can be carried out during the development of the software work products.

2.Iterative-incremental Development Models

Iterative-incremental development is the process of establishing requirements, designing, building and testing a system in a series of short development cycles. Examples are: prototyping, Rapid Application Development (RAD), Rational Unified Process (RUP) and agile development models. A system that is produced using these models may be tested at several test levels during each iteration. An increment, added to others developed previously, forms a growing partial system, which should also be tested. Regression testing is increasingly important on all iterations after the first one. Verification and validation can be carried out on each increment.

3.Testing within a Life Cycle Model

In any life cycle model, there are several characteristics of good testing:

o  For every development activity there is a corresponding testing activity

o  Each test level has test objectives specific to that level

o  The analysis and design of tests for a given test level should begin during the corresponding

development activity

o  Testers should be involved in reviewing documents as soon as drafts are available in the development life cycle

Test levels can be combined or reorganized depending on the nature of the project or the system architecture. For example, for the integration of a Commercial Off-The-Shelf (COTS) software product into a system, the purchaser may perform integration testing at the system level (e.g.,

integration to the infrastructure and other systems, or system deployment) and acceptance testing

(functional and/or non-functional, and user and/or operational testing).

Testing Principles

 Testing Principles 

Principle 1 – Testing shows presence of defects
Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are
found, it is not a proof of correctness.


Principle 2 – Exhaustive testing is impossible
Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, risk analysis and priorities should be used to focus testing
efforts.


Principle 3 – Early testing
To find defects early, testing activities shall be started as early as possible in the software or system development life cycle, and shall be focused on defined objectives.


Principle 4 – Defect clustering
Testing effort shall be focused proportionally to the expected and later observed defect density of modules. A small number of modules usually contains most of the defects discovered during pre-
release testing, or is responsible for most of the operational failures.


Principle 5 – Pesticide paradox
If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects. To overcome this “pesticide paradox”, test cases need to be regularly
reviewed and revised, and new and different tests need to be written to exercise different parts of
the software or system to find potentially more defects.


Principle 6 – Testing is context dependent
Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.


Principle 7 – Absence-of-errors fallacy
Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’
needs and expectations.

Types of Test Cases

Types of Test Cases 

    

Reviews

Types of Reviews

A single software product or related work product may be the subject of more than one review. If more than one type of review is used, the order may vary. For example, an informal review may be carried out before a technical review, or an inspection may be carried out on a requirements specification before a walkthrough with customers. The main characteristics, options and purposes of common review types are:


Informal Review
o  No formal process
o  May take the form of pair programming or a technical lead reviewing designs and code
o  Results may be documented
o  Varies in usefulness depending on the reviewers
o  Main purpose: inexpensive way to get some benefit


Walk through
o  Meeting led by author
o  May take the form of scenarios, dry runs, peer group participation
o  Open-ended sessions
•    Optional pre-meeting preparation of reviewers
•    Optional preparation of a review report including list of findings
o  Optional scribe (who is not the author)
o  May vary in practice from quite informal to very formal
o  Main purposes:
learning, gaining understanding, finding defects


Technical Review
o  Documented, defined defect-detection process that includes peers and technical experts with optional management participation
o  May be performed as a peer review without management participation
o  Ideally led by trained moderator (not the author)
o  Pre-meeting preparation by reviewers
o  Optional use of checklists
o  Preparation of a review report which includes the list of findings, the verdict whether the
software product meets its requirements and, where appropriate, recommendations related to
findings
o  May vary in practice from quite informal to very formal
o  Main purposes:
discussing, making decisions, evaluating alternatives, finding defects, solving
technical problems and checking conformance to specifications, plans, regulations, and
standards


Inspection
o  Led by trained moderator (not the author) o  Usually conducted as a peer examination o  Defined roles
o  Includes metrics gathering
o  Formal process based on rules and checklists
o  Specified entry and exit criteria for acceptance of the software product
o  Pre-meeting preparation
o  Inspection report including list of findings
o  Formal follow-up process (with optional process improvement components)
o  Optional reader
o  Main purpose: finding defects


Walkthroughs, technical reviews and inspections can be performed within a peer group,
i.e., colleagues at the same organizational level. This type of review is called a “peer review”.

Re-testing and Regression Testing

 Re-testing and Regression Testing 

After a defect is detected and fixed, the software should be re-tested to confirm that the original defect has been successfully removed. This is called confirmation. Debugging (locating and fixing a defect) is a development activity, not a testing activity.

Regression testing is the repeated testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the change(s). These defects may be either in the software being tested, or in another related or unrelated software component. It is performed when the software, or its environment, is changed. The extent of regression testing is based on the risk of not finding defects in software that was working previously.

Tests should be repeatable if they are to be used for confirmation testing and to assist regression testing.

Regression testing may be performed at all test levels, and includes functional, non-functional and structural testing. Regression test suites are run many times and generally evolve slowly, so regression testing is a strong candidate for automation.

Bug life cycle

decision table

GUIDELINES FOR CONSTRUCTING A DECISION TABLE

Steps to Develop a Decision Table

To Construct a Decision Table:

1)                 Draw boxes for the top and bottom left quadrants.

2)                 List the conditions in the top, left quadrant.  When possible, phrase the conditions as questions that can be answered with a Y for yes and an N for no.  This type of Decision Table is known as a limited entry table.  When a Decision Table requires more than two values for a condition, it is known as an extended entry table.

3)                 List the possible actions in the bottom, left quadrant.

4)                 Count the possible values for each condition and multiply these together to determine how many unique combinations of conditions are present.  Draw one column in the top and bottom right quadrants for each combination.

For example, if there are two conditions and the first condition has two possible values while the second has three possible values, draw six (2 * 3) columns.

5)                 Enter all possible combinations of values in the columns in the top, right quadrant of the table.

6)                 For each column (each unique combination of conditions), mark an X in the bottom, right quadrant in the appropriate action row.  The X marks the intersection between the required action and each unique combination of condition values.

Ensure that the Table is Complete

To complete Step 5 above, ensuring that no combinations are missed, follow these steps:

1)                 Start with the last condition and alternate its possible values across the row.  Note how often the pattern repeats itself.  For a condition with two possible values, the pattern repeats itself every two columns.  If three values are possible, the pattern repeats itself every three columns.

For example, for a table with three conditions each with values Y or N, there are eight (2 * 2 * 2) columns.  Complete the third (last) row by entering Y once across the row followed by one N.  The pattern repeats itself every two columns.

The third row would look like:

Y N Y N Y N Y N

2)                 Move to the condition in the row above the last condition.  Cover each pattern group with a value for this condition.  Note how often the new pattern repeats itself.

For example, complete the second row by entering Y across the row two times followed by two entries of N.  This pattern repeats itself every four columns.  The second row would look like:

Y Y N N Y Y N N

3)                 Repeat step 2 until all rows are complete.

To complete the first row, enter Y across the row four times followed by four entries of N.  The first row would look like:

Y Y Y Y N N N N

Flag Error Conditions

If a specific combination of conditions is invalid, then define one action to flag the error or invalid condition.

How to Simplify the Decision Table

If two or more combinations result in the same action, then the table can be simplified.  Consider the following example:

Condition 1         Y Y

Condition 2         Y Y

Condition 3         Y N

Action 1                   X X

The same action occurs whether condition 3 is true or false.  As a result, one column can be eliminated from the table as follows:

Condition 1         Y

Condition 2         Y

Condition 3         -

Action 1                   X

Example

Company X sells merchandise to wholesale and retail outlets.  Wholesale customers receive a two percent discount on all orders.  The company also encourages both wholesale and retail customers to pay cash on delivery by offering a two percent discount for this method of payment.  Another two percent discount is given on orders of 50 or more units.  Each column represents a certain type of order. 

The Decision Table records the conditions for discounts in the top left quadrant along with the ranges for the conditions in the top right quadrant.  The bottom half of the table lists the actions taken, i.e., the discount rates that apply, based on the conditions.  Each column represents a certain type of order.  For example, column two represents cash on delivery orders of less than 50 units from retailers.