IBS Journal May 2015


Diagram 3 – Expected Progressive Development


Organisation maturity is needed to ensure the following:


o requirement traceability; o embedded project plan; o embedded team; o frequent communication; o collective response to any changes.


60 per cent of testing done during the development window


This concept works on a basic fact that


a defect caught during the development phase (at offshore) is much easier to fix in comparison to fixing the same defect dur- ing onsite testing with the business. Since the test cases are already supplied to the vendor, it makes it easy for that vendor to execute and certify them. After all, the ven- dor’s testing organisation is usually more capable and mature than the bank’s quality assurance team. Diagram 2 demonstrates that defects


are being detected at the early stages when the product is still on the vendor’s premises, so the turnaround time for fix- es should be minimal. The objective of embedded testing is to catch 60 per cent of product defects even before the formal user acceptance test (UAT) begins. The challenge with embedded testing


approach is that it puts more stress on fore- seeing and documenting test scenarios at an earlier stage when the solution is still in the process of being designed. Though it might seem this adds undue pressure, the results have proved that the benefits are tremendous. This approach gives more clarity to the vendor’s development team of what is expected, it also reduces the number of defects to be later caught by business. This, in turn, builds the business’


52


confidence in the system as well as saves precious time during the UAT stage. The same concept can be applied in the


interface development, where one part is being developed by the bank and the other is done by the vendor. If more defects can be caught during the development phase, it will surely save everyone lot of time and effort during the system integration test. Embedded testing can also be called


iterative testing, as the testing does not wait for a finished product but rather starts as soon as any component is developed. Test cases are shared with the development team, and implementation testers work hand in hand with developers during unit testing to catch maximum defects upfront. Embedded testing thrives more when


the requirements are approved in a stag- gered manner so that the test scenarios are also prepared in a staggered manner along with development releases. As stated in Diagram 3, organisa-


tion maturity is needed to ensure prop- er requirement traceability, as the bank is not waiting for all the requirements to get finished and changes are expected. Thus, traceability plays a critical role. The chang- es should be limited as test scenarios are being worked upon signed-off require- ments.


© IBS Intelligence 2015 www.ibsintelligence.com


The testing organisation needs to work hand in hand with the solution require- ments and design teams. In fact, it is pre- ferred that same resources flow into the testing organisation (this topic will be discussed in future articles). Test scenari- os should be reviewed thoroughly so that they reflect the correct requirements and cover enough boundary conditions along with negative scenarios. Also, a project plan needs to be embedded so that any changes in requirements delivery or devel- opment delay can be easily reflected and consumed by the testing organisation. An embedded team pertains to the idea of one team that is shared across various streams during the implementation (roles and responsibilities were discussed in the previous article, published in the February 2015 issue of IBS Journal). Agility comes as serendipity in embed-


ded testing, as it is designed to accom- modate changes without much overhead, and perhaps this is why it is often con- fused with Agile development, where the requirements are delivered in chunks. How- ever, in the banking industry most vendors follow the Waterfall model, as core trans- formations tend to follow rigorous docu- mentation and are driven by sign-offs and approvals.


analysis: core system transformation


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56