{"id":16776,"date":"2022-02-28T20:20:25","date_gmt":"2022-02-28T14:50:25","guid":{"rendered":"https:\/\/coforge.site\/cigniti\/blog\/?p=16776"},"modified":"2022-02-28T21:49:15","modified_gmt":"2022-02-28T16:19:15","slug":"independent-software-testing","status":"publish","type":"post","link":"https:\/\/coforge.site\/cigniti\/blog\/independent-software-testing\/","title":{"rendered":"Why is Independent Software Testing Critical?"},"content":{"rendered":"

The Story<\/span><\/b><\/h4>\n

It was about a decade ago, and the Northern California sun shone in its full glory as I crossed the Bay Bridge enroute to the East Bay town of Concord. I was about to take on the largest testing programme I\u2019d ever managed: the global implementation of SAP\u2019s full suite of applications for one of the largest petrochemical concerns on the planet. Although based in San Francisco, the $500m project employed 1,000 people in California, Manila, Rio, and Cape Town. The task was daunting: with a team of 225 people scattered around the world, ensure that this system would run as intended and not impede the USD150b company\u2019s ability to function. Failure would be professionally fatal.<\/span>\u00a0<\/span><\/p>\n

I remember my meeting with the General Manager of the programme, a slightly frail, wispy man with a huge heart and an even bigger mind. He was crystal clear on what he expected from me, and I will never forget his words: “Rule with an iron fist”, was his guidance. These were not the words I would ever have expected to emanate from the mouth of an aging Northern California hippie. But his objectives were abundantly transparent. The huge team tasked with designing a massive, unimaginably complex system had a very finite budget of time and currency. Despite this, the standard process of running through 3 cycles of System Integration Test was extended to 5. This programme would have quality at the forefront of its philosophy, and nothing would compromise this. As the System Readiness Lead, I was given an independent reporting line directly to the General Manager and was directed to brief him, the CIO, and the programme leaders on the health of the quality effort without mute or a filter.<\/span>\u00a0<\/span><\/p>\n

The reason for the mandate should be obvious. A project organisation of 1,000 people possesses endless opportunities to veil the real state of quality. The belief was that only by positioning a neutral and independent party in the thick of things could those ultimately accountable for success feel certain they had their finger on the pulse of the project.<\/span>\u00a0<\/span><\/p>\n

Testing is, by design, in a precarious position for any software project by virtue of its location at the end of the delivery lifecycle. The concept of \u2018squeeze\u2019 will be familiar to anyone who has ever run a testing programme. Its most typical meaning is a reduction in the time available to the test team to get their work done because of overruns upstream in the delivery cycle. This situation places the owner of testing at a very precarious decision point: where do we cut corners to make our cost and time budget? Or do I stand my ground and rule with an iron fist? These questions are best answered in the context of testing independence.<\/span>\u00a0<\/span><\/p>\n

The Why<\/span><\/b>\u00a0<\/span><\/h4>\n

The answer to the question of \u2018why\u2019 test independence is critical should now be abundantly clear. In a situation where one organisation running the full project, like a systems integrator, for instance, has allowed upstream activities like design or building to run overbudget, the owner of that budget must either absorb those overruns by compromising on the last phase of the project, i.e. testing, or go \u2018back to the well\u2019 and ask for more money, time, or both. In a situation where testing was run by an independent entity with their own budget, this could not happen. But aside from the budget, there are myriad reasons why a segregation of duties makes sense.\u202f\u00a0\u00a0<\/span>\u00a0<\/span><\/p>\n

Bias \u2013 Testing one\u2019s own code<\/span><\/b>\u00a0<\/span><\/p>\n

Developers are people too, right? And like all people, they have feelings and egos that can be bruised. And while no one would contend that testing is not a part of a developer\u2019s daily routine, once outside of unit testing and as part of a larger system, the validation of code should become the domain of an unbiased party.<\/span>\u00a0<\/span><\/p>\n

Resources dependencies and constraints\u00a0<\/span><\/b>\u00a0<\/span><\/p>\n

Finances are finite in our world, so unless your budget is a blank cheque, you will have choices to make. Hiring a permanent staff for a temporary project simply makes no economic sense. This is where engaging a third party for the lifetime of your project not only brings unbiased quality, it also enables costs budgeted for a project to be time limited. Testing service providers offer the right skills when you need them and, especially when using an offshore force, at a cost that will please your CFO.<\/span>\u00a0<\/span><\/p>\n

Acceleration\u00a0<\/span><\/b>\u00a0<\/span><\/p>\n

Being able to ramp up quickly and utilise the knowledge that has been built through front-line experience across the industry spectrum is why consulting as a business model exists. Where an in-house team or an external development partner may be accessible, tapping into the specialist skills of an organisation solely focused on independently validating the quality of the solution you are implementing makes good business sense. Partners like this bring methodology, tools, and artefacts like automated test scripts to the table, as well as hard to find niche expertise like performance and security testing, data validation, cutover, disaster recovery, cloud migration, and a slew of other capabilities that are extremely difficult to maintain in-house.<\/span>\u00a0<\/span><\/p>\n

Conflict of interest<\/span><\/b>\u00a0<\/span><\/p>\n

You may have a great systems integrator. Speaking as a former SI, I can attest to the fact that there are many consultants out there with exemplary ethics. The fact remains that a programme manager or development lead is judged on his or her ability to manage a project to budget. It is here that, shall we say, an “obfuscation of the facts” may occur. A hesitancy to reveal issues and cut corners to preserve margins is tempting in the closing phases of a large IT project. Removing this temptation by eliminating the conflict of interest and segregating responsibilities is the right thing to do.<\/span>\u00a0<\/span><\/p>\n

Cost<\/span><\/b>\u00a0<\/span><\/p>\n

The implications for the budget are multifaceted. The efficiencies associated with using a quality assurance specialist have already been discussed. Engaging a team based in lower-cost regions of the world further stretches your currency. But one critical cost component that often flies under the radar is the opportunity cost of using your business analysts or developers for testing work. One theme has come up often during conversations with clients about using your own people for work like testing: They are not trained for it, they don\u2019t particularly enjoy doing it, and diverting them to a project means that other valuable work may suffer.\u00a0<\/span>\u00a0<\/span><\/p>\n

The How<\/span><\/b>\u00a0<\/span><\/h4>\n

The benefits of testing independence resemble a bell curve plotted along the timeline of the waterfall SDLC. In the development phase of the project, developers will unit test their own code. Once we move to system testing, independent testers can be phased in as the system becomes increasingly stable. Once system integration testing begins, function-driven testing and the defects that this throws off (in addition to the manpower required) is where independent testing pays dividends in efficiency and honesty. The objective of this phase is not only to ensure that the integrated system holds together, but also to make sure that your business users tasked with User Acceptance Testing do not throw their computers out of the window in protest at a system that is not ready for prime time. It is here that an independent testing team may be used to augment your business team and help facilitate the test itself.<\/span>\u00a0<\/span><\/p>\n

Models for Enterprise SW testing<\/span><\/b>\u00a0<\/span><\/p>\n

There is no titanium-clad methodology to ensure you can realise the benefits of test independence in your organisation. The main facet of the approach is to stick to a \u2018segregation of duties\u2019 rule. Think of an automobile assembly line: one worker installs the drivetrain into the chassis, and the unit moves on to a totally separate group to validate that the bolts are torqued. Some derivatives can include the following:<\/span>\u00a0<\/span><\/p>\n