Brainscape's Knowledge GenomeTM

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


See full index

Software Testing > Introduction > Flashcards

Introduction Flashcards

1
Q

Software Project Management

A

Discipline of managing projects to completion (all features/scope) while achieving quality within time constraints & budget.

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

Software Quality

A

Discipline of specifying, assuring, monitoring & controlling quality of software products. In SE, measures how well software designed & how well it conforms to that design.

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

Software Verification

A

Have we built software right? Have we made right decision each step of the way?

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

Software Validation

A

Have we built right software? How well does product address business needs?

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

Software Testing

A

Techniques to execute programs with intent of finding as many defects as possible/gaining sufficient confidence in Software Under Test (SUT).

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

Software Inspections

A

Techniques aimed at systematically verifying software artifacts (design docs, code, tests etc) without executing them, with intent of finding as many defects as possible, as early as possible.

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

What are the factors of software quality?

A

Functional stability, reliability, performance efficiency, operability, security, compatibility, maintainability and portability

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

Functional Stability

A

Functional appropriateness, accuracy and compliance

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

Reliability

A

Maturity, availability, fault tolerance, recoverability and compliance

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

Performance Efficiency

A

Time-behaviour, resource utilisation and compliance

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

Operability

A

Appropriateness, recognisability, learnability, ease of use, attractiveness, technical accessibility and compliance

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

Security

A

Confidentiality, integrity, non-repudiation, accountability, authenticity and compliance

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

Compatibility

A

Co-existence, interoperability and compliance

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

Maintainability

A

Modularity, reusability, analysability, changeability, modification stability, testability and compliance

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

Portability

A

Adaptability, installability, replaceability and compliance

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

Correctness

A

Does software perform as expected?

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

Understandability

A
  • Are var names descriptive of physical/functional property represented?
  • Do uniquely recognisable functions contain adequate comments so their purpose is clear?
  • Are deviations from forward logical flow adequately commented?
  • Are all elements of array functionally related?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Completeness

A
  • Are all necessary components available?
  • Does any process fail for lack of resources/programming?
  • Are all potential pathways through code accounted for, including proper error handling?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Conciseness

A
  • Is all code reachable?
  • Is any code redundant?
  • How many statements within loops could be placed outside loop, reducing computation time?
  • Are branch decisions too complex?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Portability

A
  • Does program depend upon system/library routines unique to certain installation?
  • Have machine-dependent statements been flagged & commented?
  • Has dependency on internal bit rep of alphanumeric/special chars been avoided?
  • How much effort required to transfer program from 1 hardware/software system/environment to another?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Consistency

A
  • Is 1 var name used to rep diff logical/physical entities in program?
  • Does program contain only 1 rep for any given physical/mathematical constant?
  • Are functionally similar arithmetic expressions similarly constructed?
  • Is consistent scheme used for indentation, nomenclature, colour palette, fonts & other visual elements?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Maintainability

A
  • Has some memory capacity been reserved for future expansion?
  • Is design cohesive (does each module have distinct, recognisable functionality)?
  • Does software allow for change in data structures (object-oriented designs more likely to allow for this)?
  • If code is procedure-based (not object-oriented), is change likely to require restructuring main program or just module?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Testability

A
  • Are complex structures employed in code?
  • Does detailed design contain clear pseudocode?
  • Is pseudocode at higher level of abstraction than code?
  • If tasking used in concurrent designs, are schemes available for providing adequate test cases?
24
Q

Usability

A
  • Is GUI used?
  • Is there adequate online help?
  • Is user manual provided?
  • Are meaningful error messages provided?
25
Q

Reliability

A
  • Are loop indexes range-tested?
  • Is input data checked for range errors?
  • Is divide-by-zero avoided?
  • Is exception handling provided?
  • It is probability that software performs its intended functions correctly in specified time period under stated op conditions, but could be issue with req doc.
26
Q

Efficiency

A
  • Have functions been optimised for speed?
  • Have repeatedly used code blocks been formed into subroutines?
  • Has program been checked for memory leaks or overflow errors?
27
Q

Security

A
  • Does software protect itself & its data against unauthorised access & use?
  • Does it allow its operator to enforce security policies?
  • Are security mechanisms appropriate, adequate & correctly implemented?
  • Can software withstand attacks that can be anticipated in its intended environment?
28
Q

Error

A

Root cause, committed by people

29
Q

Fault

A

Result of human error in software doc/code

30
Q

Failure

A

Occurs when fault executes

31
Q

Incident

A

Consequences of failures, failure occurrence may/may not be apparent to user

32
Q

Defects

A

Error/fault/failure/incident, usually a fault (bug)

33
Q

Error-propogation

A

Fault -> causation -> failure -> results in -> incident

34
Q

Test case

A

Set of inputs & expected outputs for unit/module/system under test. Without expected outputs, test case not complete

35
Q

What should a good test case do?

A
  • Be effective at uncovering faults
  • Help locate faults for debugging
  • Be repeatable so precise understanding of fault gained
  • Can be automated to lower cost & timescale
  • Be systematic so it’s predictable
36
Q

What should a good bug report include?

A
  • Function being tested
  • Initial state of system
  • Steps to reproduce defect/bug
  • Expected Outcome
  • Actual Outcome
37
Q

Test suite/set

A

Set of test cases (minimum of 1)

38
Q

Test-case design

A

Art & science of deriving efficient but effective num of test cases. Less is more - less cases, max chance of covering faults

39
Q

Pair testing

A

Software dev technique where 2 people work at 1 keyboard to test software app. 1 tests & other analyses/reviews testing

40
Q

Waterfall Method

A

Testing at end (Test-Last Development, TLD). Bad - too late, too costly & not enough time. Analysis → Design → Implementation → Testing

41
Q

TDD

A

Test-driven development, used in Agile & DevOps, testing throughout

42
Q

Test Coverage

A

Percentage of obligations met

43
Q

Test coverage in black-box testing (functional)

A
  • All use cases
  • All menu items
  • All states
  • All boundary values
  • Derive test cases from specifications/reqs
  • No access to source code
  • Can show missing functionality
44
Q

Test coverage in white-box testing (structural)

A
  • All methods
  • All statements
  • All code branches (if/else)
  • Deriving test cases from implementation (source code)
  • Expected outputs derived from specs/reqs
  • Can show unexpected functionality
45
Q

Exhaustive/complete testing

A
  • Testing software system using all possible inputs
  • Usually impossible
  • Technique used to reduce num inputs
    • Testing criteria group input elements into equivalence classes
    • 1 input selected in each class (notion of test data coverage)
46
Q

Types of non-functional testing

A
  • Testing non-functional reqs
  • Performance testing
  • Load testing
  • Endurance testing
  • Localisation/internationalisation testing
  • Recovery testing
  • Security testing
  • Stress testing
  • Installation testing
  • Compatibility testing
  • Usability testing
  • Scalability testing
  • Reliability testing
47
Q

Types of testing based on test levels

A
  • Unit/Module/Component Testing (Individual Component)
  • Integration Testing (Integrated Component)
  • System Testing (Entire System)
  • User Acceptance Testing (Final System)
48
Q

Regression testing

A

Any type of software testing to uncover new defects (regressions) in existing (old) functionality after new changes made during maintenance (e.g. functional enhancements, patches & config changes)
Intent is to ensure change didn’t introduce new faults.

1 of main reasons for it is that it’s often difficult for software eng to figure out how change in 1 part of software will echo in other parts of software. Can be manual or automated.

49
Q

Functional testing

A

Testing functional requirements and checking correct functionality of system

50
Q

Automated testing

A
  • Specs, models & code used to derive test cases
  • Automated oracle needed
  • Test execution easily repeatable
  • Massive input data possible
51
Q

Manual testing

A
  • Clever test-case design
  • Interaction with system
  • Inspiration for new tests
  • Human oracle
  • Single test case execution
  • Limited data
52
Q

Manual scripted testing

A
  • Oldest, rigorous.
  • Test cases designed & reviewed by team before execution.
  • Can be created at basic functionality level or scenario level.
  • Heavy on doc & requires considerable resources to create test scripts, which often become outdated as SUT changes.
  • Makes test cases repeatable & easy enough for new person to start testing with min supervision.
  • Also used when written software spec must be met for successful implementation of project.
  • Scripted test cases useful when tests for benchmarking & must be same each time.
53
Q

Test evaluation

A

Determine outcome of each test case (pass/fail), report to devs (enter in bug database)

54
Q

Test execution

A

Run tests on software (manual/auto) and record results

55
Q

Test automation

A
  • Using any software tool in any other test activities
    • Auto execute tests on SUT
    • Derive test cases
  • Write code to test code, use “test tools”
56
Q

Test-Case Design (Criteria-Based)

A

Design test values to satisfy coverage criteria, covering all lines of code

57
Q

Test-Case Design (Exploratory - Human Based)

A
  • Design test values based on domain knowledge of program & human knowledge of testing, exploratory testing
  • Commonly used term for testing with little/no planning & doc.
  • Manual, no test script. Tests run once unless defect discovered.
  • Major issues can be found quickly, performed with improvisation - tester seeks to find bugs however they choose.
  • Contrasts to regression testing that looks for specific issue with detailed repro steps & clear expected result.
  • Exploratory testing is generally complementary.

Software Testing (3 decks)

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