By Mauricio Navarro – GlobalNow Senior QA Engineer
Manual testing is alive and well. Even though our industry is going strong into the land of automated testing, the truth of the matter is that manual software testing is still necessary and very much being used by many QA engineers.
Why is this?
1. Budget
Every project is unique and so is its budget; unfortunately one of the first areas that suffers from budget cuts is QA. Management is not always willing to pay for supporting tools or resources to do a complete QA plan, least of all to create automated tests. Often, a project manager will find a QA specialist or business user and specifically ask them to test without creating formal Test Plans since the objective is to make the QA portion of delivery as fast and cheap as possible. This is often a sign of a project being run on a very low budget that is emphasizing the development time while hoping for a project free of issues, clearly this is not healthy and normally the results will be negative.
- Speed
How many time have we heard the phrase “This must be done ASAP”? I bet the answer is too many times. This is another clear sign that QA needs to be done too fast – which then requires manual testing. In some cases the team leader will even ask the QA specialist to start testing without a final release of the code. If this case automated testing is not a good option – since it will most likely be doomed to fail because many objects (such as object name, size, color, existence, etc.) will change as code is completed. It is better to tackle the QA portion of this type of project manually.
3. Methodology
There are some code development methodologies for which of automation is not always effective. For example if you are using Test Driven Development methodology the developers will code with the objective to pass test cases. In those scenarios the developer will often need to change pages/views/modules as soon as a new test case come to light. This could make many of the automated test cases require modification; if the new code development is happening in the same view then it could cause failure among a significant portion of the previously created automated scenarios. In this case, creating automated test may be more of a hassle then a helping tool. QA engineers should determine if the project methodology will allow efficient automation with sufficient ROI, or if it will be better to incorporate a manual testing approach. Often the best option is to combine both techniques by using manual testing during development and then creating automated tests once the code has been released (for regression and incidental functional testing).
- Size
Some projects are just too small to even consider the possibility of creating automated testing. They are just not worth the effort (budget/time) to create a complete set of automated test. When your project is simple or small, with few anticipated future enhancements, then you should consider manual testing as your first priority. If your project may grow and evolve over time then it’s probably a good idea to have at least a regression scenario of automated test cases. However if this is not the case then stick with manual testing.
5. Intangibles
There are still many things that software alone can’t do, there are a few “interpretative” things that are still unreachable for software, and (does the page presentation look good and make sense? Is this button correctly placed? Should we make an image larger/smaller?), an example of the types of questions that a manual tester can ask himself and share with the design/development team. Also, when assessing a tool’s results – judgement will be required. An automated test will always be able to tell you if the test was a success or a fail, but it may not behaving in the best way possible when applied to test scenarios.
These are just a few examples where manual testing is probably the best option. Manual testing is very much alive and I believe it will continue to be for a very long time.
SIgn up