Software Testing, Some myths and the Path forward...

This blog post is about a topic close to my heart - Software Testing
It is going to be a long post highlighting few key points/myths and what I think about them.

Feel free to comment and we can discuss. Ok, let's start.

Case 1: Testing process
Scenario 1: 
You are supposed to test a feature. You receive a requirement document and there is a formal review process. You write test cases based on your understanding of the feature. Add a layer of review process. Start testing executing the test cases. File bugs. Measure how many test cases are executed per day per tester. Write a test case for every bug discovered, if they are found outside the test cases. Reject any new feature addition as it was not planned in your scope. You assure the quality of the product and tell when the product is ready for release.

Scenario 2:
You are suppose to test a feature. You figure out who is the decision maker, the stakeholders involved and try to understand your role. You seek help, remove traps to get access to the product, interact with the programmers and prepare a light-weight document (checklist/mindmap or on a simple sheet of paper ) which acts as a reference. Based on your interactions with people and products, you update your document. You test the product, file bugs, ask questions, seek help/tips from experts and inform the stakeholders about the status of the product and project.

I will let you pick the scenario you like.
If you are more familiar or in favor of Scenario 1, we will have lots to discuss.

Case 2: Manual Testing vs Automation Testing
Have you heard of the word 'Sapience'? Do you use just your hands while testing? Do you think? What happens in your brain when you test? Think for a minute. Yes, THINK.
I feel that the very notion of classifying testing as manual vs automated is wrong. Michael and James have come up with an excellent blog post here highlighting the difference between testing and checking.
Here is the diagram from their post.

 Also, check out this blog post by Michael - http://www.developsense.com/blog/2013/02/manual-and-automated-testing/

These two posts talk about Testing and Checking:
 http://www.satisfice.com/blog/archives/358
 http://www.satisfice.com/blog/archives/856

What is testing then?
Before reading more on what testing is, do check out the slides from BBST Foundations which describe what a computer program is. The same folks who would define a computer program as a set of instructions would define testing as a process to find bugs or assure quality of the product and testers as the gatekeepers of quality.

 

Check out an excellent video on the talk between devil and angel of software testing:

Testing is an intellectual activity. If you can think well, you can test well. Every test is a question to the product, sometimes to the project stakeholder. Check out the lessons #16 and #19

Testing is not about test cases or documentation or tools. These were designed to help you test better, support testing. Instead, what do we see testers focusing on?

Learning new tools, writing better user stories, automating tasks and dreaming of days when testing would be fully automated!!!

Pick any resume and check the Skills section: 7 out of 10 would mention some or the other tool names.
Quick Learning is a skill. Tool is a tool. A fool with a tool is still a fool (maybe, a dangerous fool).

So, what am I proposing?

Focus on skills like Observation, Thinking (Critical, Lateral, Forward/Backward, Parallel, Technical), Reasoning, Preparation, Programming basics, Collaboration, Framing, Reporting, Bug Hunting, Social Skills, Knowledge about Psychology, understand and apply oracles and heuristics, quick learning and many more skills. I suggest two books - Lessons Learned in Software Testing (Cem Kaner, James Bach, Bret Pettichord) and Testing Computer Software (Cem Kaner, Jack Falk, Hung Q Nguyen)

Practice your testing skills at Weekend Testing

Read the blogs everyday from this feed - Ministry of Testing

Watch the videos from BBST courses - Videos

Build your test ideas repository -

Test Heuristics Cheat Sheet,
Mnemonics,
YANDY list
300 common software errors

77 Test Idea Triggers

Pick your topic of interest and become a specialist in that. The Ministry of Testing resources page can help you get started. Resources

Case 3: Automation is the future

If you have been hearing of new tools, new languages every week and wondering which one to learn, here is a simple tip:

Your job is safe if you have the skills. There is no single tool which can replace a working human brain. If tools can replace humans, we would have been jobless long back. If you think automation is the future, I am sorry. You are missing a very key element here - EMOTIONS. Check out the ppt file here - Emotions And Test Oracles by Michael Bolton.

Google for TDD and check how many links highlight why it does not work.

If you think that testers need to learn coding, I am not against it completely. My only question is: How often have we asked programmers to learn testing?

If you think that TDD is the future, remind yourself again that they are good for programmers and do not replace/negate the role of a tester. Read the first comment on this post: http://www.satisfice.com/blog/archives/638

Here is the bumper post: FDA highlighting exploratory approach. 

And if you still think that tools can test mobile applications and there will be no need for testers, I will assume that you have no idea about this excellent keynote by Jonathan Kohl.

And I leave you with this final post: Testers: Get out of Quality Assurance Business by Michael Bolton.