That's too generic a question. There are many different techniques, frameworks, and approaches, so there's no single universal answer. But assuming you're asking about testing general-purpose software without specific requirements, I'd recommend the following approach:

1. Basic tests that ensure your software runs without crashing or breaking.

2. Specific test cases for various inputs, settings, and invalid scenarios.

3. Edge-case tests covering extreme inputs or unusual combinations.

4. If your software's behavior is predictable or you can easily verify correctness, consider randomized testing to validate thousands of random inputs automatically.

1. Test the outcomes (what), not implementation (how)

2. 1 good e2e test worth thousands unit tests (because unit tests tend to fall into "testing how" category).

3. Unit tests are more often useless than not, they give false sense of reliability.

4. Write explicit straightforward tests, avoid too sophisticated dynamic tests (unless specific requirements call for it). Tests are for people to maintain and fix quickly, not for machines to have fun.

5. Test coverage for the sake of it is a stupid metric. You better cover well 1% of the most important end user use cases than cover 99% of everything else.