What I wish I knew about software testing 🧵 1/12
🎨 Content Creator: @jerry__chang
#Softwaretesting #DevOps
🎨 Content Creator: @jerry__chang
#Softwaretesting #DevOps
2/11 Know the why
Know the “why” is half the battle.
Know the “why” is half the battle.
3/11 Contracts in your code
Think of it as a contract.
When you design your software, you want to be able to say my code should do x, y z under these conditions.
Think of it as a contract.
When you design your software, you want to be able to say my code should do x, y z under these conditions.
4/11 It’s a skill
Just like coding, the more you do it, the better you get!
The skill compounds over time. So, I think it’s even worthwhile to even write tests for your side project!
Just like coding, the more you do it, the better you get!
The skill compounds over time. So, I think it’s even worthwhile to even write tests for your side project!
5/11 The goal isn’t to get 100% test coverage
Don’t get confused, and start writing “fluff” tests to get that 100%.
The goal is ensuring quality and upholding the contract over time!
Don’t get confused, and start writing “fluff” tests to get that 100%.
The goal is ensuring quality and upholding the contract over time!
6/11 Thinking in systems
When analyzing quality of a system, its important to analyze it as individual parts but also holistically.
When analyzing quality of a system, its important to analyze it as individual parts but also holistically.
7/11 Some better metrics
Good metrics informs and helps make better decisions.
For example, if you see a lot of bugs creeping up in one part of a codebase, that could signal deeper issues or architectural design problems.
Good metrics informs and helps make better decisions.
For example, if you see a lot of bugs creeping up in one part of a codebase, that could signal deeper issues or architectural design problems.
8/11 Visualizing software, tests, process and people as a system.
9/11 “testing” does not stop once software is in production.
In fact, learning about your code, tests and process after it goes live very key to a robust process in the long term.
Always ensure that you design software in a way that you can get the right feedback.
In fact, learning about your code, tests and process after it goes live very key to a robust process in the long term.
Always ensure that you design software in a way that you can get the right feedback.
10/11 Improve the process
Once you get the feedback, take those learnings in each cycle, and use them to improve your process.
The improvements compounds over time.
Once you get the feedback, take those learnings in each cycle, and use them to improve your process.
The improvements compounds over time.
11/11 Build in safety
Taking it a step further, you can setup guard rails in your process to mitigate any future issues discovered in production environment.
This creates a layer of safety within your process for yourself, your team and everyone else.
Taking it a step further, you can setup guard rails in your process to mitigate any future issues discovered in production environment.
This creates a layer of safety within your process for yourself, your team and everyone else.
I hope you enjoyed that! If you did, then please like, share or comment!
Follow @probablynull to level up your software engineering skills!
Follow @probablynull to level up your software engineering skills!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
