- \n
- System Testing<\/li>\n
- Integration Testing<\/a><\/li>\n
- System Integration Testing (SIT)<\/li>\n
- User Acceptance Testing (UAT)<\/li>\n<\/ol>\n
There is always a debate on when to do DITL testing \u2013 whether it is done between SIT and UAT or after UAT and just before Go Live?<\/p>\n
As per best practices, it is suggested to perform Day in Life testing before UAT, as a testing vendor can perform this by mimicking real users, real authorizations, and real data. A testing vendor can ensure that all the business teams are ready for UAT for all business transactions, including real integrations and interfaces.<\/p>\n
Why DITL Testing?<\/h2>\n
Enterprise customers use one or many ERP applications (like SAP, Oracle, MS Dynamics, Infor, etc.) for their core business operations. They also use many 3rd-party applications (upstream and downstream) that are integrated with their ERP applications using many interfaces. All these integrations must work as expected before they move to production. Usually, while performing UAT, some functionalities relating to integrations may get missed out on testing, so it is suggested to conduct Day in the life testing by a testing vendor having good experience in the domains and integrations.<\/p>\n
How to Perform DITL Testing?<\/h2>\n
To perform DITL testing, a testing vendor should have good experience and exposure to the customer\u2019s business processes. So, it is suggested to have due diligence on the business process first and then finalize the scope for DITL testing.<\/p>\n
Solution Approach<\/h3>\n
A testing vendor should leverage their ERP<\/a> expertise, test methodology, reusable templates, and best practices to execute DITL testing successfully.<\/p>\n
As a part of this engagement, the vendor will:<\/p>\n
- \n
- Perform due diligence on a customer\u2019s one-week real business operations<\/li>\n
- Perform a comparison of the data flow between legacy and new applications<\/a> with real user profiles, real authorizations, and real data<\/li>\n
- Execute Day-In-The-Life scenario for a selected business process<\/li>\n
- Submit recommendation report on improvement areas<\/li>\n<\/ul>\n
Why DITL Testing? Define the scope for DITL Testing<\/h2>\n
Analyze the 1-week order business operations of the customer and understand the business scenarios that exist in it<\/p>\n
- \n
- Identify the most used business scenario based on the volume and business criticality<\/a><\/li>\n
- Understand the transactions and navigations of the identified scenario<\/li>\n
- Prepare a detailed test plan<\/li>\n
- Author detailed test steps for the identified scenario and get sign-off on the manually written test case<\/li>\n
- Prepare real (production resembled) test data by collaborating with customer<\/a> team<\/li>\n
- Perform one round of test execution of a test case<\/a> with the required user-profiles and authorizations<\/li>\n
- Publish test summary report<\/li>\n
- Prepare and publish a recommendation report<\/li>\n<\/ul>\n
Service Delivery Approach\u00a0<\/b><\/h3>\n
Testing vendors can follow the below service delivery approach based on the best practices. \u00a0<\/span>
![\"service](\"https:\/\/www.cigniti.com\/blog\/wp-content\/uploads\/service-delivery-approach-555x298.jpg\")
<\/span><\/p>\nSample due Diligence on Business Operations<\/h3>\n
Below table illustrates how due diligence can be carried out on a business\u00a0process<\/span>.
![\"Sample](\"https:\/\/www.cigniti.com\/blog\/wp-content\/uploads\/Sample-due-diligence-on-business-operations-555x274.jpg\")
<\/span><\/p>\nSample Comparison Matrix of a Test Scenario
\nThe table below illustrates the comparison matrix between a legacy system and a new application looks like.<\/span>\u00a0<\/span>\u00a0![\"Sample](\"https:\/\/www.cigniti.com\/blog\/wp-content\/uploads\/Sample-comparison-matrix-of-a-test-scenario-555x262.jpg\")
<\/span><\/p>\nWhat if DITL Testing is Not Done?<\/h2>\n
Indeed, many customers don\u2019t perform DITL (Day-in-the-life) testing during their test phases and instead go for regular tests like System testing, Integration testing, System Integration testing, and User Acceptance testing during their implementation\/migration\/ transformation phases. However, there are incidents where some enterprise-level customers have suffered a lot and lost millions of dollars because of failures in the integrations and interfaces in the production environment just after Go Live. The reason behind these glitches is that they might not have tested properly in their SIT and UAT phases, and had they performed DITL Testing, they wouldn\u2019t have faced such an irreparable loss.<\/p>\n
Benefits of DITL Testing: \u2013<\/h2>\n
Customers get beneficiated in various ways by performing DITL testing like:<\/p>\n
- \n
- Become assured before Go Live that all real integrations and interfaces are working properly<\/li>\n
- Can identify showstoppers before moving to production<\/li>\n
- Can perform an apple-apple comparison between legacy and new applications with respect to their functionalities<\/li>\n
- Can check whether the role of respective users has required authorization access or not<\/li>\n
- Can ensure all volume-based transactions and frequently used transactions are working as expected without any delay<\/li>\n
- Provide readiness to business teams if DITL testing is performed before UAT<\/li>\n<\/ul>\n
Smoothen the Release Management by Incorporating DITL Testing<\/h2>\n
DITL testing significantly reduces defect leakage into production as it is performed using real data, real user profiles, real integrations, and interfaces, thus smoothening the release cycles.<\/p>\n
Customers and testing vendors need to plan the timelines efficiently so that the time spent on DITL testing will yield fruitful results in its upcoming release cycles.<\/p>\n
Conclusion
\nDay-in-life testing is highly recommended for enterprise-level customers as they use several applications with tight integrations and complex interfaces. There is a high probability of connectivity issues with the interfaces in production if they are not tested properly or missed out in SIT.<\/p>\nSince DITL testing uses real data, real user profiles, and real authorizations, a testing vendor can ensure the business teams are ready for UAT \u2013 for an end-to-end business process.<\/p>\n
DITL testing mimics the business operations that happen in production, giving all the business teams confidence regarding smooth operation flow after Go Live.<\/p>\n
Although there is a debate about whether DITL testing should be done before or after UAT. However, as per the best practices, it is suggestable to do that between SIT and UAT so that a testing vendor is given an additional hand of help to business teams regarding the correct functioning of the systems.<\/p>\n
Cigniti maintains a talent pool of deep domain experts who have good working exposure to performing DITL testing for a wide variety of enterprise customers.<\/p>\n