But when I heard the term “manual testing”, I asked my seniors what’s it all about? The answer which I got was “When you test a software yourself and do not use any tools to test it” is called Manual testing.
My second question was “does that mean there are software tools to test a software”. Undoubtedly their answer was, “Yes”. I told myself “you dumb! see you don’t know any automation tools and you thought you know testing very well?”.
After this whenever somebody would ask me what do I do?, and I would say “I do manual testing” and explain I don’t use tools and all that. Somewhere I started feeling that I don’t know something which I should have. But due to the lack of time and lack of enthusiasm of learning tools I didn’t progress in that direction. By the time I accepted and labelled myself as a manual tester, but somewhere the tag manual always hurt.
Why do we split testing into such branches? Why can’t testing be pure testing and what is the need of having so many adjectives? How come my testing becomes manual when I am constantly thinking about what I am seeing on my screen.
If what I do is Manual,
- Why does not my mind rest when I test?
- Why do those questions pop up?
- Why do I keep exploring the product?
- Why do I sense risks?
- Why do I try to convince my team to fix “that” bug?
- Why do I react at that misspelled message?
- Why am I after that unknown?
- Why don’t I say pass at first when it shows it does?
- Why do I feel as if I am the user/customer of the product?
So in manual testing, Manual does NOT mean
- My mind is not a tool.
- My reactions are automatic or well planned
- I should only execute what is predefined.
- I should only execute what I have been asked to.
- Tick mark each step pass or fail.
- Close a bug when told it’s not a bug.
- Ignore my feelings and reactions..
- It involves humans and humans do use mind.
- As it uses tester’s mind in the process, testers need to explore and analyze what they see and what they don’t.
- It tries evaluate and validate “that expected” from the product at “that” time.
- Tester does not know before hand if the expected is not there.
- Tester does not know before hand if the expected is there, but it breaks something else.
- Tester does not know sometimes what is actually expected.
- Tester does not decide the expected.
- Expectations are Client/Customer/Business dependent.
- Expectations are not limited.
- Expectations are not necessarily clearly understood.
- Expectations change for different reasons e.g time, cost, resources, feasibility, risks and the competitions etc.
- Even if expectations meet, there are several other factors and facts which testing brings to the table