Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Computing foundations > Software testing > Flashcards

Software testing Flashcards

1
Q

testing enables us to

A
  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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

why is a software testing methodology needed

A

To meet legal, contractual, industry specific needs etc.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q
  1. to find defects in the product
A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q
  1. verify product fit for purpose
A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q
  1. Measuring quality of product
A

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

can be objectively and subjectively measured

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

How testing enhances quality short and long term

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q
  1. mitigating risk associated with product
A

categored by impact and probability and organised by risk

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q
  1. Building confidence in the product
A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Remember

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Test basis to test case process

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Characteristics of a good requirement

A
  • Unambiguous
  • Testable
  • Clear
  • Correct
  • Understandable
  • Feasible
  • Independent
  • Atomic
  • Necessary
  • Implementation-free
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

write good requirement cardss

A

write cards

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

fundamental test process

A
  1. Test Planning and Control
  2. Test Analysis and Design
  3. Test Implementation and Execution
  4. Evaluating Exit Criteria and Reporting
  5. Test Closure
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Test planning and control

A
  • define testing objectives
  • comparing planned progress and actual progress
  • allows for comparison of test process, and compare against previous and future versions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Test analysis and design

A
  • 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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Test implementation and execution

A
  • 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)
17
Q

4: Evaluating Exit Criteria & Reporting

A

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

18
Q

Test closure

A

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)

19
Q

Seven principles of software testing

A
  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
20
Q
  1. Testing shows the presence of defects
A
  • Testing shows defects but cannot prove there are no defects
  • Even if no defects are found, not a proof of correctness
21
Q

Exhaustive testing is impossible

A
  • Not possible to include all testing combinations
  • use risks and priorities to focus testing efforts (risk analysis)
22
Q
  1. Early testing
A
  • Testing should start as early as possible to save time and resources
  • Based on defined objectives
23
Q
  1. Defect clustering
A
  • 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
24
Q
  1. The pesticide paradox
A
  • 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
25
Q
  1. Testing is context dependent
A
  • Safety critical software is different to a mobile game
26
Q
  1. Absence of errors fallacy
A
  • If the system built does not fit users needs and expectations, finding and fixing defects will not help
27
Q

how to find as many defects as possible

A

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

Computing foundations (14 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions