31–40 of 46 posts
I agree that it's largely a mindset. From https://twitter.com/sempf/status/514473420277694465 : "QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv."
Don't forget, he came in on February 29th.
"How" you test will be impacted by other things as well. Some environments (companies) have a need to formally record testing. Others use 'non IT people' to run the testing. Some have expert users who know the app inside out as 'testers'. 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.
You will find a couple of schools of thought on "how" 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.
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.
I see the arguments in the testing world a bit a kin to dev's fighting over strongly typed vs. loosely typed.
Automation is good BUT if you don't know what you need/want to test then really it is a means to get is a mess really quick.
The Ministry of Testing is a good starting point, http://www.ministryoftesting.com If doesn't sound like you are providing an API but if you are feel free to mail me directly (email is in my profile) for some resources; my company works in that area of testing.
> (email is in my profile) The "Email" field in your profile is private, others can't see it. You need to put your email in the "About" field for it to be publicly visible.
Hmmm. I think you're looking at this the wrong way: it is not he who should be learning more about manual testing, it is you who needs to learn about how to write manual tests. Manual testing is not at all that different from, say, integration testing: you write a specification of a task that needs to be performed, you write down the expected output, and you compare it with the actual output. What you end up with is…
What you are describing is exactly the type of test that should be automated. Manual testing should be exploratory, it shouldn't be following a script. Computers are there to follow scripts.
Even exploratory has written tests that basically say "explore," and they are often assigned with a particular focus.