Attaining Operational Efficiency with Independent Software Testing

Technology is evolving fast, really fast. New applications keep spurting each month across platforms and old application upgrades keep piling up! This is making one strong point that is the consumers are more demanding than ever with the hunger for new applications and additional features for the existing ones. This trend is most likely going to head northwards than southwards; Now just imagine the huge code base that we looking at in various platforms across numerous languages and geographies!. Such humongous code needs quite some testing and we are talking about constant and molecular testing on each and every release. Phew! that’s a lot of validation.

The current globally accepted model

Typically the development teams and test teams work in parallel with the following iterative model

Be it Agile or Waterfall model all of them follow the same process unanimously

Challanges of the present industry

Let’s look at a few operational challenges that testing teams under the “same brand dev & testing” Models face.

• The Delivery timeline – The development team which already is under pressure ends up eating Quality Testing time due to Estimation/Change Requests/Poor Development quality etc.
• Testing Seconds development – There is always a misconception within organizations that testing isn’t as important as development and we can manage with little or no testing, This takes away important chunk of estimated test effort from the test team.
• Developer & Tester under the same roof – This kind of a setup though looks appealing for some as people are under the feeling that teams that sit together can always deliver better since the turnaround period is less for clarifications and understanding, but what typically happens is that testing teams end up believing and thinking the way developers think and assume a defect to be functionality as the “developer says so“. This can be catastrophic for the overall product quality.
• Pressure to hide defects – Since Dev and QA both are typically part of the same organization the poor quality code usually is swept under the carpet by managing the QA Defects and showcasing false data. This happens a lot in the service based delivery set-ups where in both dev and test teams work for a client’s product. This leads to inferior QA quality leading to a faulty product in production. Net result = Dollars Lost.

You can clearly see what happens to regular Test teams in the image above; it squeezes the testing time further as the development effort overlapped into test time. Most of the product development and testing under the same roof are facing similar challenges.

The ICE Breaker

Welcome to the realm of independent software testing, an area which is slowly and steadily picking up pace, But why?

We DO-NOT intend to change the way the current “development > testing > Go Live” works, all that independent software testing aims at is process optimization and tweaks to the regular testing cycle which usually is not given priority.

There are a lot of reasons why we certainly need independent testing and a few are listed as below:

• Independent Perspective – With Independent software testing, comes a different perspective. Something which is not polluted with unnecessary product building discussions which leads to confusion at a later stage. Product testing is more robust as it will eliminate the noise which otherwise would have crept into the minds of testers. Independent test teams may find a design flaw which was never thought about.
• End to the Development Bias – Independent testing brings in better requirement brainstorming and will help elicit any flaw in the flow of the requirement (if any). Moreover the testing simulation will be much nearer to the real world users of the application.
• Chuck the Paradox of pesticide – In the initial stages of the application testing, if the build quality of the software is not up to the mark i.e.: If Many basic defects keep pouring in .In such cases the QA team will suffer with something which is referred to as “pesticide of paradox” a phrase which is synonymous to Insects that survive the use of pesticide are those that are more immune to the poison than others. These bugs/offspring are then also likely to be immune to the pesticide. This requires that Pesticide companies continually work at developing new poisons that will kill whatever survived their previous products. The same occurs in software. If we create a layer of fuzzy application that is highly defect prone then we tend to only find particular types of bugs (obvious Ones), other types of bugs will thrive because our attention is focused elsewhere. Independent software test teams operate above these layers of disturbances as the Test build that reaches the test team is assumingly thoroughly unit tested.
• No QA Unit Testing – Testing teams should not be doing Unit Testing, this is a bad practice and it just kick drops overall test productivity, dramatically. Unit testing is a developer’s job, in independent testing setups this is impossible as teams are sitting in different locations and the only builds which are shared with the Testing team is the one which is actually intended to be QA’d. If something is wrong with the QA build then it can be logged as severe defects in the defect tracker and assigned back to the development team. Nothing is informal!
• Amount of time spent on testing – With independent testing setups test teams just focus on testing and eliminate any other noise which might be a disturbance for QA. This not only saves huge amount of time but also ensures that testing, which can save millions of dollars in production is actually carried out in a systematic process oriented manner leading to effective ROI for the overall project. With 3rd party QA Setups we ensure the dev teams DO-NOT eat into the QA time defined by the project.
• No pressure to hide defects – Bad code needs to be eliminated from the system, and that’s exactly what an Independent testing setup aims at! No more hiding defects due to the pressure by the management to hide bad work by either of the teams because at the end of it all when the dust settles any defect slippage is blamed entirely on the QA team. This practice is put to end with the 3rd party teams testing the application leading to a better quality product and unnecessary blame games.
• Stricter Dev Accountability/timelines – With in-house development and Testing the development team is always under the impression that in the worst scenarios we can use a tad bit of testing time and fix all the open issues in the test cycles, This leads to less testing time and inferior product quality. With independent software testing teams coming into the picture the development team will be under pressure and feel accountable to deliver on time for the Test phase to begin. This will usually ensure the teams deliver on time and testing is not impacted. At the end of it all it’s a win-win situation for the overall project as nobody hates meeting deadlines!
• Tester Confidence – Independent software testing eliminates unnecessary extended work hours for the test team in-fact the work gets optimum and effective, leading to a better, a clearer mindset and approach towards finding quality defects. The focus remains purely on getting the project delivered in accordance to the requirement and on time!

Things to ponder upon before you go independent!

Having discussed a lot about independent software testing and the advantages of it, there are a few areas of scrutiny before you chose to operate under this model.

• Effective team – The team which is working on the product testing should be technically and functionally sound on the product requirements as they will NOT interface less with the product team on a daily basis and majority of the communication will happen through emails or phone calls, So the team must be in a position to pick up things at a rapid rate and be quick to react in any situation.
• SMEs for help – The project team should have Subject Matter Experts for each and every module within the application so that the expertise can be utilized optimally.
• Effective Status Reporting – Status reporting proves out to be pivotal for the project and a person with minimum product knowledge should be able to look at the report and understand where the overall project stands. The report should be crisp and should have the completion percentages with a target completion date for each and every task. Deviations/Risks should be highlighted on time in the reports and every stakeholder directly impacted by the risk should be aware any untoward development, so that corrective measures can be taken to eliminate the anomalies on time!
• Be selective on the vendor – There are many players in the market who claim to be the pioneers of independent software testing but we should be careful in selecting the one who is diverse enough to serve any QA need that may arise out of the engagement. A thorough market survey should be conducted before selecting the vendor. A vendor that satisfies the above two criteria and off-course the most important thing – “does not drill a hole in your company’s wallet”.

Final thoughts

Independent software setups can be path breaking towards success of an organization which intends to deliver quality software to the market in time over and over again without delays. Though it may not appear cost effective immediately, but the ROI grows exponentially over time as it’s always cheaper to fix a bug before the software goes live. So it may be time you start thinking about independent software testing for your application, after all no one likes to use buggy software.

Thank you for reading!

By Niranjan Keshavan – Project Lead at Cigniti Technologies