Getting the Basics for Manual Testing
Getting the Basics for Manual Testing
Manual testing or manual functional testing as being called is a process in which the actual results or behaviour of a system/code/software is compared against the expected results or behaviour without using an automation tool. Firstly testers need to understand the requirements of a system and deduce how the system is to behave(expected results) for each requirement.
Requirements may be documented as a user requirements documents, user stories, business requirement or functional specification documents or may not be documented. You can very well have knowledge of software functionality or you can even guess and then test it one step at a time. You can call it ad-hoc testing or exploratory testing (totally different topic to talk on). If there are no documentation, testers needs to speak to key business stakeholders who understand how the system should work and what is expected. This can then be captured and stand as a basis for testing
Testing skill is something which should be within you. It can be learned, but only when you have few qualities by default in you. When I say it can be learned, I just mean focused and formal education around that particular testing.
Why the Need for Manual Testing
The best part to be a Tester and particularly Manual Tester is the fact that you can’t run only on skillset. You got to have/develop and enhance your thought process. This is something you can’t really buy for few bucks. You yourself have to work on it.
You have to develop a habit of asking questions and you will have to ask them every minute when you are testing. Most of the times you should be asking these questions to yourself than to others.
Consider this scenario
- As a tester you perform an action on a system and during that process you observe an issue/bug/defect (comparing it with what should have happened).Your discipline and observation skills to perform comes in the picture here.
- You observed or notice this defect because you pay attention to details. immediately you are happy you found a you found out an issue , the steps, and the scenario. Now you have to communicate this which is very essential to the development team and other stakeholders in your team. You might do it via some defect tracking tool or verbally, but you got to make sure that you are communicating it constructively.
- you have to then think of many scenarios in which you can also perform this action both positive way of doing it (positive testing) and also negative way of doing it(Negative testing) and then compare the results.
This are the steps taken to achieve what you have actually done
- Test with discipline
- Pay attention to details
- Stay Curious
- Identify descripancies
- Communicate Constructively
In Software Development Life Cycle, for ny development methodology few things always remain constant. As a tester, you will take the requirements, convert them into Test Scenarios/Test cases. You will then execute those test cases or directly automate them (I know few companies perform this). When you automate it, your focus is steady, that is automating the steps written(this will be explained on another post).
Running through each of the test cases developed using the requirement documentation and capturing the results of each of the tests with status either Passed or Fail with results of failure captured and communicated is a very effective way of carrying out manual testing.
You will go on adding your new test cases as you test application. These will be test cases for bugs you encountered for which previously there was no test case written. Or, while you are testing, something triggered your thought process and you got few more test cases which you will like to add to your test case suite and execute.
Even after all this, there is no guaranty that there are no hidden bugs(Absence of error fallacy). Software with zero bugs is a Myth. You can only target to take it close to Zero but that just can’t happen without a Human mind continuously targeting same, similar to but not limited to example process we same above.
At least as of today, there is no software/system or an application that will think like a human mind, observe things like a human eye, ask and get answers to questions like a human and finally perform intended and unintended actions/tests.
Need of Manual Testing when Automation is around
Firstly, Automation Testing has its own share of glory these days and will have even more in coming years but, it simply cannot replace QA manual testing.
There s a saying that - ‘You don’t automate testing, you automate checking’. This sentence alone speaks a lot about where manual testing stands with Automation testing being around. Many big names across the globe have written and spoke about this topic so I won’t stress much on this.
Automation can’t replace Human Testing because:
- It demands clear and constant observation
- It demands questioning
- It demands Investigation
- It demands reasoning
- It demands runtime judgments about everything which is happening in front of your eyes (while you test) and in few cases behind the scenes too
- It demands action (which wasn’t planned) as required while you test
I will be explaining in details for sure in posts to come how and when we need test automation and how it compliments Manual Testing.
In the coming manual testing tutorials, we will cover a generic approach for doing Manual Testing, how it will co-exist with Automation and many other important aspects.
Thank you for reading. Will love to hear from you. Kindly comment and send your feedback. We will also get back to you if you require any clarification