Software Testing

Question 1

red-green-refactor testing

Answer 1

1. fail - write a test and make sure it fails, before implementing
2. pass - write an implementation, to make the test pass
3. refactor + extend - refactor system

Question 2

Unit Tests

Answer 2

• FAST and ISOLATED
• test a small facet of the code

Question 3

Acceptance/End-to-end Tests

Answer 3

• SLOW and !ISOLATED
• done at the end with the user/person who will use the product

Question 4

System Tests

Answer 4

• SLOW and !ISOLATED
• simulates user
• ties together integration tests and acceptance tests

Question 5

s

Integration Tests

Answer 5

• SLOWER than unit tests
• MORE ISOLATED than acceptance tests

Question 6

Smoke Tests

Answer 6

try to expose a fault as quickly as possible, making it possible to defer running large swaths of unnecessary tests for a system that is known to be broken

Question 7

3w21wq;p

A|B Testing

Answer 7

• for production environments
• comparing 2 versions
• usually used for business decisions rather than functionality

Question 8

4 phase tests

Answer 8

1) set up
2) execute CUT/SUT
3) evaluate the output
4) tear down

Question 9

Given-When-Then

Answer 9

1) start from some given state, where the system’s configuration is understood
2) The key action of the test is the when; this is often described in the test name using plain language (e.g., it(‘should be able to parse a document that has UTF-16 characters’)).
3) The then step involves observing the output to ensure its correctness.

Question 10

TDD biggest strength

Answer 10

you are able to ensure that your system is structured in a testable way

Question 11

4 properties of testability

Answer 11

controllability
observability
isolateablilty
and automatability

Question 12

controllability

Answer 12

• refactoring code in a way that makes test cases more succinct
• red flag:
• when a constructor has new statements
• bc when a constructor is creating its own objects you as the test writer dont have the opportunity to change those objects
• example: using id directly, should pass in jquery object instead

Question 13

Observability

Answer 13

• ability to check the value to make sure a test
• (refactor) often these can be resolved by returning data to the caller that might otherwise just been passed further down a call chain
• (can refactor to return what you want to check instead)

Question 14

Isolatability

Answer 14

• split up code to test subparts
• also test as a whoole but this is the main idea

Question 15

automatability

Answer 15

• easier to autoate if you pass in objects instead of requiring manual use of software to test

Question 16

Glass Box Testing Faults

Answer 16

• confirmation bias

Question 17

pros of using coverage

Answer 17

• cheap to compute in contrast to reasoning
• it is actionable

Question 18

types of coverage

Answer 18

• line
• statement: diff than line bc measures all statements on a line executed
• branch: both conditions of all branch points
• path: all program paths (ie all possible combinations)

Question 19

Boundary Value Analysis

Question 20

BVA: 4 values for boolean testing

Answer 20

true, false, null, undefined

Question 21

BVA: numbers

Answer 21

• number.negative_infinity
• -number.max_value
• number.positive_infinity
• number.max_value
• undefined
• null
• you can have null checks enabled for null and undefined

Question 22

Equivalence Class Partitioning (ECP)

Answer 22

• inputs decomposed into classes and make sure test atleast one from each class

Question 23

state transition testing

Answer 23

• identify states or modes that he program will assume at runtime
• determine how the program flows between states and test the behaviour during these transitions

Question 24

User Acceptance Testing

Answer 24

• also use case testing/user story testing
• tries to simulate interaction with the system
• can also simulate both untrained and adversarial users

Question 25

Input Partition: pros/cons

Answer 25

-pros: - - avoid confirmation bias - - even tho black box -> systematic - - simplifies large domains - cons: - - dependent on specification - - inputs can be less interesting than outputs (output partitioning needed) - - defects can arrive at boundaries (combo input paritioning with BVA)

Question 26

Output Partitioning

Answer 26

- identify the values that test the desired outputs

Question 27

Output Partitioning: pros/cons

Answer 27

- - - - pros - focuses on observable outputs - can encourage diff approach - - - - cons - usually fewer outputs than inputs (might drive easier tests) - effort required to derive inputs to acheive given goal can be challenging

Question 28

fuzz testing

Answer 28

Fuzz testing automates parts of the test writing process by generating inputs programmatically, often with some randomness 1) generates an input 2) executes the SUT with generated input 3) observes if crash 4) if no crash repeat from step 1

Question 29

common use for fuzz testing

Answer 29

- test that hte system does not crash - used to find segmentation faults or other types of runtime errors

Question 30

types of fuzzing

Answer 30

1) random fuzzing: tests completely at random (usually specifies type, can at times be TOO random) 2) generator-based fuzzing: developer writes code that generates random input BUT they are guaranteed to be valid 3) mutational fuzzing: defining mutations—operations that transform one input into another, slightly different input

Question 31

Mutation Testing

Answer 31

Mutation operators are used to create mutant versions of the code under test. Mutants tend to be simple: for example changing bounds checks (e.g., a >= arr.length to a > arr.length), or boolean values (e.g., if (isReady) {} to if (!isReady) {}).