QA as a Career - should I choose Manual or Automated Testing path?

Which one is more important for QA person – learning automated testing or learning the fundamental of testing, learning how to find issues/ bugs of a Software/ Firmware. 

For last few years, what I have seen many people are more interested of taking the Software Testing as their career. There could be many reasons why they were thinking of choosing this as their career. I welcome them all for feeling interested in this field. What I have seen is –  they are taking a short course on Software Testing which will teach them about Software Testing concepts and automation tools as well, which is good. They are educating themselves before coming to the practical job field, which is the right way to do it. I had the opportunity to meet some of teacher and student of some of those courses. Talked about their courses a little bit, talked about these with the students who were so excited. Sounds all good so far. Then I get scared a bit when I came to know why they are so excited.

When talked with few of them, they said, they will be learning all the new automation tools and there is a big market for automated Software tester. So they concentrated more on automation testing then the concepts of Software Testing. I would not say its bad, but it will have effects at the end. I talked with them about the Manual Testing, did they have any plan to learn how to do it. It seemed they were more interested about automated testing than the manual testing as Manual Testing is dead/ Backdated method.

When people want to start their career in this field, few fundamental things one need to learn/ study about. Once that part is done then they can advance towards the automation testing. Automation testing is for those who know how to test, how to test software thoroughly. 

When anyone learned how to do the software testing, in other words manual testing, then they can advance their level up with the automated testing. What automation testing does is to help minimize the effort for Regression Testing of the software. It definitely not a tool that will identify the issues, does not help finding/reporting issues. So, before learning automation, I would prefer learning the software testing (manual) first and then go with the automated tools. 

What we do with the automation is write some scripts that will automatically read input data from somewhere and then will apply those inputs to software UI. For example, lets say I’m given to test a web application that will calculate how much student loan I need from the bank. There are three parts of that web application. One take the input, then process the input and then display the amount that is needed for loan from the bank. There are some input fields on the application categorized under Expenses and Income. Once those Expense and Income fields are populated with data, clicking the calculate button will calculate the loan amount. 

As a tester my job is to identify all possible scenarios that can happen on/with that screen. Start planning about what type of Testing you want to perform – Functional testing, Regression testing, Performance testing, load testing. And then write down those possible scenarios in the Test Cases. Find out all the valid, invalid set of inputs for each field. Write down the expected results. Once these things are done then I can say I’m ready for actual testing on the software. 

With the Manual Testing, enter all those values, checking all those combination of inputs with valid and invalid data sets, checking the output whether it matches with the expected results or not. If there is any problem then I will have to report the issue. These are few steps with Manual testing. Same thing apply with automated testing. I’ll have to do all these test scenarios. Only difference is, I’ll write some scripts, will run it with some automated tools. I will have an Excel sheet that will have some Test Data as input. On the automated tools I’ll write the code that will read from the excel sheet and will apply the data on the web application and then store back the calculated output to the excel sheet. Then looking at the excel sheet I can tell whether any test data set failed or not. 

Advantage of using automated tools is, I can run multiple times to check the integrity of the software. It’s faster any than the human effort of doing it same amount of time. Only side effect is, additional learning is required based on which automated testing tools will be using. 

The point I wanted to focus through out this writing is, I’ll have to know, develop myself to identify all the possible scenarios, all the possible test I can and should perform on the software. Running and maintaining script for automation testing is not the key, the key is developing the skill for finding issues of the software, methods to find issues, learn to know which tools to apply, when to apply. Tools come and goes, but the concept, methods stays. 

Have fun testing! Cheers! 

Update: 12/24/2013
In this writing I was referring  the "Manual Testing" as the basis of "Software Testing Concept". It's Testing Concept that is more important to learn/ study about and that's what I was trying to point out. Manual or Automated method both has their own pros and cons and can be argued both ways. It's like if you want to learn driving a car, would you prefer learning a car with stick or the auto. Decade ago this could be a choice, now its very rare to find a car with stick shift. Anyway, the goal is to learn the driving concepts.

Self Motivation in Software Testing

Self-motivation is a key factor of quality the Software Testing. Software testing is monotonous, working with same interface / screen over and over could be a boring at times. One will have to find out a way to avoid that scenario where they will feel bore about it and that would be the end of testing. Once  bored, one will find fewer issues about the software and the quality of the software will be compromised. There are many outside issues/ problems that can cause the frustration for the person who will be testing the software, but just being with one software/ product for a longer period of time, can affect largely finding software issues. So, we will have to find/ apply different techniques (no hard and fast rules) to keep ourselves motivated. Following  I’ll be trying to share my experience which worked for me in many projects to keep myself motivated in software testing. 

Testing Approach- Any software that I’ll be testing, prior to look into the software, I usually try to learn/study the details of the software/ product. Even if it’s written on the Specs, I try to get info from different related people through questionnaires. This gives me broader idea of what was supposed to be built, what was designed, and how it supposed to behave. Then I can double check my testing procedure (Test Plan, Test cases) whether I planned to cover most scenarios. 

Perform a Smoke Testing on the software before starting the testing according to the test cases.  Smoke testing actually gives the idea whether this software is ready for testing or not. If I find issues that Software does not run or crashes now and then, I ask for a rebuild of the project and then a newer version. This saves my time and effort to start the formal lengthy testing procedure. 

Prior starting the formal testing procedure, I start with light things like the User Interface stuff- alignment issues, correct text, correct icons on different states, and clean UI etc. No matter how silly, non-functional, less important issue it would be, User Interface is the first thing that User will look at. That’s the first impression user will get about the software. So, it’s important to have a good, clean, simple, understandable UI and my job is to make sure of it. When I find issues, I write them down (leaving the priority of the issue as blank). 

The next thing I do is another easy task, field validation-valid, invalid inputs, min-max checking of each field, tab orders(if applicable), size etc. Whatever Issue I find, I write them down. Most of the time, these issues gets the low/ lowest priority. 

At this point, if I have a good understanding & access to the developer, I can send them the issues so far I have found. If agreed, they can fix the low priority issues while I will be concentrating for main/ major issue findings. From my experience what I have seen is, at the initial stage after releasing the software for testing, developers have some time that they can use to look into low priority/ UI issues that they will not have the time later when I start to find the major issues. Finding major issues takes time. So for an optimum use of resources, I try to keep the developers busy (if agreed among all concern parties) fix those issues. If not, then I start recording the issues, prioritize them consulting with concerned parties.  

While I have few issues on board, I then start to follow the formal steps.  This may look like informal testing procedure, may go beyond my teams boundaries, but I have found it useful in-terms of optimize use of resources. For the formal steps, it’s quite common among the software industries. So I’m going to describe them here. 

One Important thing I have learned from my experience in software testing, as team member and/or as team lead is....

At no point of time, one should wait for another person to finish some task. For example, testing should not wait for the development to finish. Development and Testing should go side by side. This sometimes becomes a demotivated factor for the Testing Team members. They should be engaged in testing through out the whole SDLC. 

Some Suggestions -  During this process, like any other human being, I also get bored about the software after a while. I try to take different measure to keep myself motivated during this testing process. Few things I do (works for me, may not work for others) and suggest are:- 

• Primary motivation comes from finding and reporting Issues. When I starts to report issues, in those easy areas (mentioned before), the number it-self motivates me. When I see I have like 20 issues already on board, it gives a good feelings and I get motivated enough to increase the number by finding more issues.  I use some numbers as Milestone - 25, 50, 100 number for reporting issues. The more I find issues, the more the number gets increased and I feel like i'm on right track. (I usually try to report quality issues, not just issues to reach milestones). 

• I frequently take breaks out of this testing procedure. Looking at the same screen time after time makes me more familiar with the screen. Once I get too familiarized, I started to feel that everything is as it should be. So, when I take a break, when I come back I can get a fresher look at the screen and sometimes I find issues from that. Btw, do not lose your focus/ concentration with the break.

• When I feel like I’m running out of testing idea’s I go back to my drawing board and review all the things I was supposed to do and what I have done so far. Sometimes I find idea that I didn’t planned for before using the software. I update my document as well when I find things like this. 

• Another thing I do when I run out of ideas, I intentionally plan to talk with developers to get more inner knowledge of the software. Black box testing is basis on without knowing internal knowledge. When I talk with them, little chitchat about how did they develop one particular features, or what conditions they used to plot a graph line etc. helps me to think of different testing ideas. And when there is broader area, more chances to find issues and number will increase. 

For example, software supposed to plot a line graph based on a test result and date. On a date, a test can be performed, or can skipped but recorded. If there are test results for two dates, the line goes straight on the graph. If more than two and test performed on each day, then it connect all three points using curve line. If first day has a skip, then for next two day results will be a straight line, and there will not be any line drawn for first two points. If there is more than 10 points for multiple days, then logic is different then others. In short, there were different logic used for different case, single point, multiple point - 2, 3, 10, 11, 12 etc data set. Before knowing these logic, I was just testing it for few test data. When I came to know these logic, I started to layout different technique to test these scenarios.  

With the ideal world, these things can be handled or tested on the white box testing level, but as an end user tester, I don’t believe what other did. I don’t assume even that this was tested at unit level. Caution: do not get biased developer.

• Sometimes, when I feel that something is not right, may be it's according to the specs, I usually report it as Enhancement/ Observation just to avoid any further objection. And I support my findings with logical arguments from a user point of view. Enhancement is category where I actually can contribute my idea for the improvement of the product. Observation is something that I noticed, may be its working as designed, but something to discuss it further. I may not be the person who will take the final decision about the changes, at least, contributing ideas as Enhancement / Observation would definitely feel happy!

Feel free to test anything and everything. Do not care the limit, do not care what you were not supposed to do it or not. Free your mind. Play the role of different level of a user. Find the things that you feel it can motivate you for testing. Use those techniques.

Automating our testing is okay, helps us not to get monotonous/ bored. It’s the human being that designs the automated testing script. If you feel bored, it will affect you writing and updating scripts. Scripts can only do what you think about. If the thoughts are bounded by the tiredness, then it won’t help whether we use automated testing or manual testing.

Lastly, to keep yourself self motivated in software testing, don't just test a software that is given to you, feel the ownership of the software. Have fun in Testing!