API Testing : Why to write Test Cases and use Automated Testing Tools?

Why to write Test Cases and use Automated Testing Tools?

Books written by some leading programmers often told us the importance of TDD (Test Driven Development) and BDD(Behaviour Driven Development) or they emphasize on at least writing Test Cases and doing Automated Testing. So why many programmers don’t write tests? Is that all not practical or all just too bookish, or your project life time is too small, or is it very much time consuming to write test cases? Here are few questions you will have in mind if you aren’t familiar with test cases benefits. So following are those questions answered.

Question: Obviously writing Test Cases take time and it still don’t replace manual testing, then what is the point in writing test cases. You have a QA person for that who can manually test each page then why Test Cases and this Automated Testing?

Answer: Problem is that if your QA person need to test 10 entities and 3 cases for each entity then these are simply 30 Test cases. So with every addition or modification in system, your QA person will need to test all these 30 test cases almost every day which can’t be efficiently done without automated testing.

Question: What if QA team is very efficient and can easily test lot of different scenarios, then why there should be automated testing?

Answer: Even if your QA team is very efficient, testing same things again and again is not a good use of your QA team time. QA team should design more test cases and from different perspective. And they will spend lot more time if there are different users in system are present. QA team will need to test system with different perspective by login with different accounts.

Question: Alright but it will be time consuming to write Test cases and configuring testing frameworks, so why should I not save time instead of writing Test Cases?

Answer: In long run, Test Cases will even save your time, Test Cases you have written once can be used later, and probably you will need to run tests every day after completing a feature or fixing a bug. So testing 30 Test cases is even more time consuming. If you have GUI of system then it will probably take a little less time but if  you only have APIs then it is much more difficult and error prone to test lot of APIs endpoint manually. So it is much better to spend some time on writing Test Cases instead of testing all Test Cases every day manually, so Automated Testing is lot more time saver in long run.

So it is lot better to Test system in a way where all test cases are written , can be tested under same circumstances every day, without manual dependencies once all test cases are written.

So is writing Test Cases really much time consuming?

Yes it is but it still save time. If you will need to Test something manually, you will need to perform same steps again and again for two different cases but while writing Test Cases for automated testing, you are doing all this in code. And in Code you can avoid writing same steps again by utilizing OOP  concepts and reusing code, that will definitely save time. So never be afraid of writing Test Cases. Specially when you are working on APIs then in many opinions writing Test Cases is your only option and if you will try to test APIs manually and these are not just few API calls then you will be in trouble.

So which type of Automated Testing I must use when writing API?

If you have time then better is to use Testing at every level. Do Unit, functional, Acceptance and API testing that would be helpful for debugging things. But if you don’t have as much time and you are working on APIs then you must at least do API Testing. So that if at day end some thing has gone wrong then you can test it by executing single command and know it before shipping buggy code. So it all depend on your need but if you are writing APIs then you must do API Testing other wise it will be really difficult to test different cases on different API calls manually.
To know about Automated Testing Tools selection you can find more information in my next post.