10 Questions of Testing Automation Estimation

You are here

testing automation estimationTesting is the next step of coding and is vital for successful product performance. One of the most frequently asked questions is the possibility of testing automation. Below are the answers for 10 most frequently asked questions we have to offer you. Do not think of them as a rule, but following them will be a rather wise decision.

  1. Is estimating the time needed for testing possible?

    This is actually very hard question, as time needed cannot be estimated easily. Developers can give only the raw estimation, not the exact value of time needed. The same goes to testing, as knowing the exact term is nearly impossible. Thinking on the idea takes nearly equal time as compared to writing the code.

  2. Is it possible to use test scenarios for testing automation?

    This question is a lot like a classic – “how many unicorns can you place inside a case?” The answer depends on what is inside and many other conditions. Answering this with a certain quote of time will be a mistake – or mislead for the customer. However, automation can be roughly estimated, as it does require certain steps to be completed.

  3. What reference should be used for creating your automation solution?

    This should be everything you want to see done right by the application during the testing. A good spot would be creating some sort of a map in your head (or in a document) and pointing out all the features the application has, what data is processed during their work and what checks (word check is the keyword) need to be done to ensure these features work well. That would be the basic reference for your testing process.

    Then assign all the possible cases of these features usage (you cannot assign them all, just mention as many as you can think of) and this will be your working reference model. The more complexity and volume it will have, the better overall results of testing will be.

  4. How do you know if testing goes according to the schedule?

    Do not try to measure the efficacy of the process. Asking simple questions is not relevant – data, process, hybrid, keyword are not measurements, they are merely ideas. Try asking yourself a bit deeper question like – how long will it take me to make an automation function? Ask your developer about it? The less you ask about the efficacy of the process – the more efficient it will be.

  5. How to start then?

    The first question you are to ask is – which block is the smallest one of all my coding units? Will it be function or class? How many different types of blocks you will get as a result? How much time is needed to write 1 block? Try to compare it with atomic model of molecular structure. When you clearly know the answer to that you will be able to calculate the raw size of the job to be done.

  6. How long will it take?

    The wall is built 1 block at a time, so the resulting time might appear to be the sum of all lesser actions, if no issues arise in the process – and they most likely will. However, calculating the sum will give you the minimum time to count on, but expect it to increase with integrating, testing and final setup, etc.

  7. Can it be told if the process moves at all?

    Please understand writing code is not similar to assembling cars, it is not a process of repeating small operations leading to a certain result. Writing a code is much like writing a book – when inspiration is present, the job is going on, but sometimes the whole chapters must be deleted, if they went in the wrong direction. The best way to have the testing done is hiring a skilled developer and leaving him alone with his job.

  8. What is the automation all about then?

    Doing testing automation requires writing the code. This code is usually as complex as the source code of the tested project. It should be written, debugged and tested prior to beginning the testing process itself. Why is it needed then? Because due to being made of standard procedures automated testing allows for efficient evaluating of the main project changes and updates.

  9. What about automated testing tools?

    This question is the same with automated books or article writing tools. If you saw an article written by robot even once, you will not ask such questions again. They are awful, unreadable and useless. The only tools developers have are their brains – and their colleagues’ help, of course. Easy automation advertised by vendors is nothing more than a trick to get your money. Do not fall for it!

  10. Can I name the process with keywords to express what I need?

    Keywords are merely labels. Developers use it to name the smallest and easiest pieces of their work. Phrases like “keyword-driven automation” are never used in IT world nowadays. Those are the 20-years old ideas that were popular on the Internet dawn age, when nobody new how things will go and how will it look. Now we know. Open source coding is the solution. Working in small groups and requesting help from the community when need arises allows shortening the terms drastically.


You can have 10 developers working in a closed space and estimate 6 to 12 months to test a major app. Or you can have 3 developers able to communicate the community and request for help with small portions of code and the overall testing time will be reduced to weeks. In the result you will gain a finely tested product with nicely working automated testing solution for it.

Do not be afraid that someone will use your app – smaller portions cannot be connected to form a solid code, neither any commercial tool can provide automated testing. "Excel-based testing tools" still sold on the market might have worked for your granny, but they will definitely not work today and tomorrow.

Even while industry giants still prefer proprietary development, please keep in mind they usually have hundreds of the best developers available, which form a small community inside the company. All the lesser companies should think of using the outsourcing to gain multiple benefits.