I want to start implementing automation. I just don't know if this would be a good use of resource. The application is growing at an exponential rate but i don't know at what point does automation benefits testing.
Can you give me reasons when you would automate even though you have manual testers?
Make testing more efficient -- even if you have manual testers, if they (or you) can implement automated tests then many more cases can be explored. Writing your own automated tests might also give you insight into your own code.
You automate because pressing "go" and waiting 10min for the results means that your tester can do other useful work during those 10min instead of baby-sitting the application.
Keep in mind that an automated test can run every night while you sleep. Your testers can then use their working hours to write new useful tests instead of running the same old tests over and over again.
The biggest reason is that when you changed some little thing shortly before shipping, with automated tests you won't hesitate to run the tests even though "the change was simple and shouldn't have broken anything" - and then you breathe a sigh of relief when the automated tests catch the bug you had introduced and were about to ship.
Automation is almost always a good way to go for testing. Manual testing is still important, but it's much more error-prone, and if your manual testing process begins to take days or weeks to complete, it becomes difficult to roll out updates at a fast rate. It's usually easier to setup automation at the beginning of a project, because you'll have fewer things to automate, and once you get your automation framework in place, it should be easy to expand as your project grows.
Trying to automate testing on an already fully-implemented project will probably require more work than automating from the beginning, so I'd recommend diving in as soon as possible.
Repeating tests is painful and error-prone with manual testing, and if the application is being changed, tests need to be repeated.
Imagine that the size of the program and the number of tests increases linearly with time, and that you want to do continuous (daily) integration and regression testing. In that case, on the first day you'll test one thing, on the second day you'll test two, on the third day you'll test three, etc.
Total testing effort for manual testing will increase with the square of the size of the program: because of retesting and re-retesting.
If you don't automate, then you won't do regular, complete regression testing.
My reason for automating testing is that it means I can get consistent, repeatable, and timely feedback that what I've just done is correct.
Manual testing also has its place, but it is hard to be as convinced that it's covering everything properly, and certainly doesn't do so as quickly as automated testing.
For example, part of one of my projects is an optimisation algorithm which uses some heuristics to walk around the search space looking for good solutions. There are now approximately 40 different heuristics which can be used individually or in various combinations, and every meeting with a customer seems to involve adding a new heuristic or extending an existing one. I need to be absolutely certain that none of this work for one customer will cause a regression for another customer, which involves running the algorithm on a few hundred different cases and checking that the output is (no worse than) it used to be.
It would be impractical to ask a manual tester to run all these test cases by loading the GUI, opening the input file, and clicking 'run', at least not often enough to be a useful feedback mechanism. The tests are typically run tens of times per day for the short tests and every night for the more heavyweight tests. With a manual process, full feedback would probably take a couple of days, and fixing a bug introduced a couple of days ago is a lot harder than fixing a bug introduced within the last half-hour.
It would also be very difficult to ensure that any 'by-eye' checks of the results are as good as they used to be, so the results checks have to be automated. But if you're going to automate that, you may as well automate the whole thing. It's not hard.
A further advantage of automated testing, from the experience of working with a project that had none, is that if you have manual tests which are not extensively documented, then when the project lies dormant (in 'maintenance mode' apparently) for a year and then restarts active development nobody can quite remember how to do the testing or what the expected outcomes were, and you end up introducing a whole pile of silly regressions that take ages to pin down. On the other hand, if you are going to document your tests in enough detail that they can be picked up a year down the line, you have essentially already automated them: you just need to make the documentation executable.
In my experience, you need to start testing roughly 2 hours before the point at which you suddenly realise that you should have started testing 2 hours ago :)
I think it depends on the people working at the company. Some people love automation, some are less fond of it. If your company doesn't have it by now trying to implement it could be difficult.
I prefer automation, because of the hours (mentioned already) and because for the most part you know what you are going to get with it.
You should have both, but to go without automation and test will get very difficult as product grows.
Can you give me reasons when you would automate even though you have manual testers?
I would automate everything that can be automated. What is the added value of using a human brain for something that can be done by a machine in a repeatable way? And what about personal development? I prefer to use a human brains for something that they can do better than machines: think.
You should automate as soon as possible. Many studies have shown that the later a defect is found in the development cycle the more expensive it is to fix. Automation generally makes it possible to find defects at the earliest possible time (assuming you actually run those automated tests as soon as possible).
The sooner you start writing automated tests, the sooner your developers can start running those automated tests and/or they can be run in a continuous integration environment. And once that happens, you find defects sooner which saves the company money and makes the developers happy because it enables them to release higher quality code. It also gives them confidence to make changes because they can quickly see if it causes a regression.
Plus, it makes your quality engineers much more a part of the overall process rather than feeling like their effort is something tacked on to the end after most of the work has already been done.