52 lines
1.9 KiB
Markdown
52 lines
1.9 KiB
Markdown
# 11. Testing
|
|
|
|
Interviewers are looking for:
|
|
|
|
* Big picture understanding
|
|
* how to prioritize tests, some are more important
|
|
* Knowing how the pieces fit together
|
|
* not just test the product, test the product that the product interacts with. integrations etc
|
|
* Organization
|
|
* break down tests into sections
|
|
* Practicality
|
|
|
|
## Testing a piece of software
|
|
|
|
* Manual vs. automated testing
|
|
* sometimes manual is necessary, human observation can reveal new issues that haven't been physically examined.
|
|
* Black box testing vs. white box testing
|
|
* how much access do we have into the software?
|
|
|
|
An approach from start to end:
|
|
|
|
1. Are we doing black box testing or white box testing?
|
|
2. Who will use it and why?
|
|
3. What are the use cases?
|
|
4. What are the bounds of use?
|
|
5. What are the stress/failure conditions?
|
|
1. Is it acceptable that the product fails, what should failure mean? It shouldn't crash the computer
|
|
6. What are the test cases? How would you perform the testing?
|
|
|
|
## Testing a function
|
|
|
|
1. Define test cases
|
|
1. Normal case: generating the correct output for typical inputs
|
|
2. Extreme cases: empty inputs, very small, very large inputs
|
|
3. Nulls and 'illegal' input: if the function expects a number but a string is given
|
|
4. Strange input: passing an already sorted array to a sort function, or a reverse sorted array
|
|
2. Define the expected results
|
|
3. Write test code
|
|
|
|
## Troubleshooting questions
|
|
|
|
How to debug or troubleshoot an existing issue. Instead of reinstalling the software, we can try a systematic approach
|
|
|
|
1. Understand the scenario
|
|
1. How long has the user been experiencing this issue?
|
|
2. What version of the browser is it? What OS?
|
|
3. Does the issue happen consistently, or how often? When does it happen?
|
|
4. Is there an error report that launches?
|
|
2. Break down the problem
|
|
1. Break down the problem into testable units
|
|
3. Create specific, manageable tests
|