Software testing

Question 1

testing enables us to

Answer 1

1. find defects in the product
2. verify the product is fit for purpose
3. measure the quality of the product
4. mitigate rish associated with the product
5. build confidence in the product

Question 2

why is a software testing methodology needed

Answer 2

To meet legal, contractual, industry specific needs etc.

Question 3

1. to find defects in the product

Answer 3

positive testing
- verifies correct operation, does it work, if error -> test fails
negative testing
- ensures application handles invalid or unexpected user behaviour
- try to break the code
- finding defects

Question 4

2. verify product fit for purpose

Answer 4

Project delivers to a set specification - must be correct - must meet the specification
Referred to as :
Validation (correct specification)
Verification (does it meet spec)

Question 5

3. Measuring quality of product

Answer 5

Degree a system meets:
- specified requirements
- user/customer needs and expectations

can be objectively and subjectively measured

Question 6

How testing enhances quality short and long term

Answer 6

ST
- testing finds defects, fixes defects, confirms fixes, software has fewer defects
LT
- finds defects, defect analysis identifies causes, process improvement prevents reoccurence, future systems have fewer defects

Question 7

4. mitigating risk associated with product

Answer 7

categored by impact and probability and organised by risk

Question 8

5. Building confidence in the product

Answer 8

Test coverage
Rate of defect discovery
Number of known defects
Percentage of test cases passed

Question 9

Remember

Answer 9

Testing does not change quality of system (detects defects which are repaired)
Tests should measure functional and non-functional characteristics
Provides a learning opportunity for future projects
Needs to be team wide incorporating different departments

Question 10

Test basis to test case process

Answer 10

Text basis
- Requirements specification
- source for creation of test cases
Test condition:
- an item or event of a component or system that could be verified by one or more test cases (e.g. a function, feature, quality attribute, or structural element)
- test that is is possible to
Test Case:
- a set of input values, execution preconditions, expected results and execution post-conditions, developed for a particular test condition
example:
input - “The beatles, a day in the life”
expecte output: A list of websites relating to the beatles

Question 11

Characteristics of a good requirement

Answer 11

• Unambiguous
• Testable
• Clear
• Correct
• Understandable
• Feasible
• Independent
• Atomic
• Necessary
• Implementation-free

Question 12

write good requirement cardss

Answer 12

write cards

Question 13

fundamental test process

Answer 13

1. Test Planning and Control
2. Test Analysis and Design
3. Test Implementation and Execution
4. Evaluating Exit Criteria and Reporting
5. Test Closure

Question 14

Test planning and control

Answer 14

• define testing objectives
• comparing planned progress and actual progress
• allows for comparison of test process, and compare against previous and future versions

Question 15

Test analysis and design

Answer 15

• Reviewing test basis
• evaluate testability of test basis
• identifying and prioritising test conditions
• designing and prioritising high-level test cases
• identifying necessary test data
• designing test environment set up
• identifying any required testing infastructure and tools
• creating bi-directional traceability (from test basis to case and case to basis)

Question 16

Test implementation and execution

Answer 16

• Finalising and prioritising test cases
• Finalising the test data
• Developing and prioritising test procedures
• Creating the test data
• Preparing test harnesses
• Writing automated test scripts
• Creating test suites from the test procedures for efficiency
• Verifying the test environment has been set up correctly
• Verifying traceability between test basis and test cases
• Executing test procedures in planned sequence
  o Manually or using test execution tools
• Logging the outcome (results) of each test execution
• Comparing actual results with expected results
• Recording discrepancies as incidents
• Analysing incidents for causes
• Repeating test activities (with necessary regression)

Question 17

4: Evaluating Exit Criteria & Reporting

Answer 17

Checking logs against exit criteria specified in Test Planning
(e.g. Are there any critical/high risk defects remaining?
Have all high risk areas been completely tested?)
* Assessing if more tests are required (How successful were our tests?)
* Assessing if exit criteria need changing
* Writing a test summary for stakeholders

Question 18

Test closure

Answer 18

Checking planned deliverables have been delivered
* Closing incident reports (failed tests have an answer/action)
* Raising change records for remaining open incidents
* Documenting the acceptance of the system (acceptance testing)
* Finalising and archiving test-ware and test environment
* Analysing lessons learned (post-mortem follow up meetings)
* Using information gathered to improve test maturity
(retrospective)

Question 19

Seven principles of software testing

Answer 19

1. Testing shows the presence of defects
2. Exhaustive testing is impossible
3. Early testing
4. defect clustering
5. The pesticied paradox
6. Testing is context independent
7. The absence of errors fallacy

Question 20

1. Testing shows the presence of defects

Answer 20

• Testing shows defects but cannot prove there are no defects
• Even if no defects are found, not a proof of correctness

Question 21

Exhaustive testing is impossible

Answer 21

• Not possible to include all testing combinations
• use risks and priorities to focus testing efforts (risk analysis)

Question 22

3. Early testing

Answer 22

• Testing should start as early as possible to save time and resources
• Based on defined objectives

Question 23

4. Defect clustering

Answer 23

• Small number of modules usually have most defects
  
  • can be due to complex challenges
  • external factors such as laws and business challenges
  • team with more skills in one area

Question 24

5. The pesticide paradox

Answer 24

• If the same tests are repeated, test cases will find no new bugs
• Overcome by reviewing test cases regularly
• create new and different test to exercise different areas of the software

Question 25

6. Testing is context dependent

Answer 25

- Safety critical software is different to a mobile game

Question 26

7. Absence of errors fallacy

Answer 26

- If the system built does not fit users needs and expectations, finding and fixing defects will not help

Question 27

how to find as many defects as possible

Answer 27

test early by conducting requirements reviews, design reviews and code reviews