Testing (effective testing I should perhaps say) is linked to the domain that it operates in. Understanding the nature of &quot;what&quot; the software does is often more important than &quot;how&quot; to test.<p>&quot;How&quot; you test will be impacted by other things as well. Some environments (companies) have a need to formally record testing. Others use &#x27;non IT people&#x27; to run the testing. Some have expert users who know the app inside out as &#x27;testers&#x27;. etc etc The need for how much detail is in the test scripts, and in fact if you document manual test scripts will depend on nature of your company.<p>You will find a couple of schools of thought on &quot;how&quot; to test. ISTQB is formal and has a good bag of technique, the other school of though has some good ideas (like session based testing) but IMHO tends to throw the baby out with the bath water. The ISTQB technique can be applied in an agile environment what you would not use the documents they describe.<p>What I have personally found is that a good tester picks up ideas, techniques (BVA, EP etc), and applies these where the will return the best value.<p>I see the arguments in the testing world a bit a kin to dev&#x27;s fighting over strongly typed vs. loosely typed.<p>Automation is good BUT if you don&#x27;t know what you need&#x2F;want to test then really it is a means to get is a mess really quick.