chapter 11 done ✔️

11. Testing/11.1. Mistake.md

@@ -0,0 +1,13 @@
+# 11.1. Mistake
+
+> Find the mistake(s) in the following code
+
+```c++
+unsigned int i;
+for (i=100; i>=0; --i)
+    printf("%d\n", i);
+```
+
+One mistake is syntax in the for, it lacks {}. The printf is taking a digit but i is unsigned int.
+
+Unsigned int is always greater than or qual to zero, it will remain in 0 and the loop will run infinitely.

11. Testing/11.2. Random crashes.md

@@ -0,0 +1,14 @@
+# 11.2. Random crashes
+
+> An app crashes when it is run. After running it 10 times in a debugger, you find it never crashes in the same place. The app is single threaded and only uses the C standard library. What programming errors could be crashing the crash, and how do you test each one?
+
+Some part of the code overloads the memory or something, and it shows up randomly after some time.
+
+## Solution
+
+* The system could use a random variable that is not fixed in every execution.
+* Uninitialized variable: in some languages, uninitialized variables take a random value
+* Memory leak: the program runs out of memory Heap overflow, or corruption of data on the stack
+* External dependencies
+
+Close all other applications, track resource use very carefully. If there are parts of the program that can be disabled, do it. Run it on a different machine and see if the error persists.

11. Testing/11.3. Chess test.md

@@ -0,0 +1,10 @@
+# 11.3. Chess test
+
+> In a chess game there's the following method: boolean canMoveTo(int x, int y). This is part of the Piece class and returns whether or not the piece can move to position (x,y). Test this method
+
+1. Test for normal inputs: values of x,y in the range [1,8]
+2. Test for extreme cases: values of 0, bigger than 8, float inputs
+3. Test for illegal inputs: negative numbers, strings, arrays
+4. Test for strange inputs
+
+Test each piece, all 6 pieces in chess.

11. Testing/11.5. Test a pen.md

@@ -0,0 +1,16 @@
+# 11.5. Test a pen
+
+1. Who would use the pen? Students, painters?
+2. Black box or white box? Can I test components of the pen?
+3. What are the use cases?
+4. What are the bounds of use?
+5. In what conditions should it fail, what would that mean?
+
+Children are going to use the pen, they will be drawing on clothing. The pen is intended to wash off when cleaning the clothing. It will have colors red, green, blue and black.
+
+1. Fact check: verify that the pen is felt tip and that the ink is one of the allowed colors
+2. Intended use: pen writes properly on clothing
+3. Intended use: color washes off when clothing is washed. What about cold water washing, hot water?
+4. Safety: is the pen non-toxic for children?
+5. Unintended uses: what if the children write on other surfaces? The pen should hold up
+

11. Testing/11.6. Test an ATM.md

@@ -0,0 +1,20 @@
+# 11.6. Test an ATM
+
+> in a distributed banking system
+
+1. Black box or white box? Can I test separate components of the ATM?
+2. Users? Clients in the street
+3. Use case? check account, retrieve money, insert money, renew transport card
+4. Bounds of use? Clients cannot retrieve more than 2k€/day. After 3 PIN attempts, card is blocked
+5. In what conditions should it fail? It should never fail... if the machine swallows up the card, it should show instructions on how to proceed now
+
+Tests:
+
+1. Fact check: check that the buttons in the ATM all work, the display too
+2. Intended use: log in as user, enter PIN, retrieve money, put it back in
+3. Safety: try entering wrong PIN, should see the prompt with instructions. If the credit card has a theft alert or something, no operations should be done on it
+4. Unintended uses: user shall not retrieve more than 2k€/day, and if there are less than 2k€ in the account, only the max amount of money should be retrieved as maximum.
+
+## Solution
+
+Take security into account, reliability, that money does not magically disappear when you withdraw it and put it back in.

11. Testing/README.md

@@ -0,0 +1,51 @@
+# 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