| || |
Percentage of effort distribution between Unit Testing vs Integration vs UAT Testing
What is the total percentage of effort distribution one has to allocate for each of the test phase .
Unit Testing Vs Integration Testing Vs UAT Testing ???
It all depends..
Originally Posted by ravi99
Unit testing, usually you do something like a code coverage %. You might do something like 80% if you have a small team of seasoned engineers. If you have multiple teams, you may opt for a higher number like 95%. In order to achieve high numbers, like 90+, you tend to need to use more advanced programming patterns like Abstract Factory pattern, Service Lookup pattern, Dependency Injection, etc... Achieving near 100% may be a huge detriment of development efficiency, due to the added complexity.
Integration testing you may do more or less depending on risks on outside factors. If you use lots of 3rd party libraries or services that get updated on a regular basis, you may opt to do more integration testing. If you have work that is contracted out, you may opt for more integration testing. A good way of setting a policy on integration testing is use a code coverage percentage policy, like 95% function/module coverage. Reason why i say function/module coverage is at this level, you don't have to worry about your own code (covered by unit coverage), you just worry about mostly the 3rd party stuff.
UAT (User Acceptance Testing) is not an Engineering activity. The reason for UAT is for the end user (customer) or a proxy of the user (some sort of Product or Business Analyst), or customer board or advisors, to review early prototypes to verify you are building the right product (before developers waste time building the product right). Many Jr QA will get this confused because at one point in their careers, you'll work for a company that has a testing environment called "UAT", which probably was a UAT environment at one point when the company didn't have QA, then got repurposed for QA.
From Wikipedia: User acceptance testing (UAT) consists of a process of verifying that a solution works for the user. It is not system testing (ensuring software does not crash and meets documented requirements), but rather ensures that the solution will work for the user i.e. test the user accepts the solution (software vendors often refer to this as "Beta testing").
Acceptance testing - Wikipedia, the free encyclopedia
As said before, it always depends on the project. I believe that all teams must define what is going to be their strategy towards testing and be clear about it. Having said this, Mike Cohn developed a concept which he called Testing Automation Pyramid that might help in this decision. I am posting an image from Martin Fowler's blog that pictures it.
Basically, what this pyramid defines is an heuristic that you should take into account to define the percentage of each kind of type of tests. At the bottom, there's the unit tests which run really fast and therefore, there should be a lot! At the middle, there's service or integration in other graphs which should be less, because they are slower and because there's many tests that prove that the units used to build it work. At the top, there's UI tests which are slower, difficult to maintain and break really easily. It is important to have these tests, but the percentage should be less than the other categories.
Remember this is just a heuristic, define your strategy and be sure it is sustainable. The goal is to be able to keep adding functionality for a long time and not convert your system into a legacy system.
Unit test is done by programmers.It is testing a small piece of code whether it id doing well.Where as integration testing needs more efforts as it is testing whole application.Usually tester execute integration testing by writing test cases.