Ok. I will be as honest as possible here.
What worked for me was actually reversing the process. I first started doing testing and then I slowly started building up my knowledge of concepts and technologies. I don't think this works universally (what you test makes a difference, e.g. testing an airplane system vs. testing an ecommerce platform are two very different products and you need different ...
Corner Case Testing:
When the system breaks only for a specific valid input
Imagine a function getcar() that that takes a number and all numbers from 1-5 are valid inputs:
getcar(wheel=?) function works with all numbers but fails for getcar(wheel=3)
Edge Case Testing:
Here we check that the system handles extreme values of valid limits.
There is a nice article about progressive testing by Mphasis:
Progressive automation is to automate almost every test case instead
of executing test cases manually. This is typically seen with the
projects that run in agile methodology. You ...
I believe it is important to look at test coverage at something that
Needs to be adjusted as features grow and change (proactive)
as opposed to
Ensuring that things that happened in the past are prevented (or at least detected) by adding tests for them (reactive)
The problem with the second approach (particularly common in traditional waterfall and ...
As testers we won't set hard boundaries for testing, that's why organisations push for test automation, CI/CD and so on. We expect to get 100% (almost) test or feature coverage for each new build.
But if you are in an organisation that doesn't have test automation then some times test completion deadlines could make you feel challenged. In such cases, few ...