This is a blog where I (Ajay Balamurugadas) write about my experiences with SOFTWARE, testing software, enjoying defects in software and my learnings in software testing :)
Most challenging course in terms of the content to be skimmed, understood and put in practice.
Add some travelling and festivals in between and the challenges multiply.
Thanks to all the participants, the instructors, my course sponsor Ilari Henrik Aegerter and my family members, I could complete the course on time.
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/
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)
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
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.
