Test Data – Tracking the discrepancies and Issues patterns

Management needs to look at statistics to understand the situation on the data discrepancies.  What I am doing is to consolidate the report to understand the behavior and frequency of the test data that are kept requesting from the Customer to create and reload into the test system for the affected test cases.

With the recent issues with the Customer’s test data preparation that are blindly dumped from Production to the test environment without proper validation , the team is going into the details of the issues. This is where we breakdown the information

1. Nos of test data requested on a specific date
2. Nos of complete test data set that is ready for testing
3. Nos of incomplete test data set that needs to clarify
4. Nos of “re-open” test data set that we need to create and reasons for failing the validation

Being a Forward Thinker and Good Decision Making Skill

Everyone will experience times when to decide  to raise an alarm to the stakeholders on any potential issues that post risk to the project schedule, cost and scope.   In fact, majority will feel that it is not the right time to do so or may feel that it is unnecessary while getting the project teams to solve those problem before the risks accumulate.  As the saying goes, the project team is supposed to solve the problems, rather than disturbing the stakeholders with trivial issues that do not post any risks at that moment.

Good decision making doesn’t means you have pointed out a good decision, rather it is the process to flag any issues for discussions and result in the decision making with the stakeholders.  Even if the decision is not made at that time, we have take the opportunity to reason, analyse and do not allow any chance for a problem to suddenly present itself as an obstacle to complete the project.

The process in decision-making involve:

1. Collects all relevant information
2. Asks for recommendations and advice from other stakeholders
3. Sets deadline before the decision must be made
4. Make the decision and announce it with the reasons behind it to all who are involved

Nobody will be a perfect decision-maker but without using the proper process to derive the reasonings, wrong reasons are dervied for the wrong decision after the project delay.

Risk Assessment for Software Project Delay

Critical bugs found in SIT, delay in other development components, inadequate test data and incomplete UAT test cases.  These are the issues that the project team have decide to raise to senior management for delaying the user acceptance testing (UAT) by 3 weeks.

Before the official communication is released to both Customer and internal management, we work out the risk assessment to justify the reasons for the proposed go-live date in February next year.  The proposal that we do covers the 5 areas of the software life cycle phases in sequence.

1. SIT Testing – unforeseen critical bugs detected and code changes required to ensure right system and solution; inadequate test data from Customer.
2. UAT Testing – Schedule changed due to task #1; resources  as  Dec 16 to Dec 30 was originally planned to be of blackout period (due to holiday/annual leaves by all team members).  Hence UAT can’t start from this period, instead postponed to early Jan.
3. User Training – Should training is conducted at the same time as UAT, users will be trained with incorrect information if bugs are found during UAT testing; the trainers are involved in the UAT testing; we only have one test environment that is used for both UAT testing and training.
4. Deployment – Development is working on data migration scripts after SIT End2End testing (12 days efforts);  system readiness is on Jan 25
5. Go-live – Operations need to stop to enable data migration that involves stock checks, validation etc for 2 days (over the weekend) on Feb 4.

Checkpoints for Test Data Validation

Before we start any testing, we need to include a milestone to validate all needed test data are setup correctly at the test environment.

Few things to be done for the various checkpoints:

• Obtain the test data’s details from the Customer
• Validate the test data against the physical test server, at the database server to ensure the information provided by the Customer are correct
• Looks into the data contents of each test record and highlight any incomplete information of that data to the Customer to verify.
• Once validated, Customer is to re-send the amended test data to the test environment.
• The test datas are to record in the UAT test plan with information on which test scenario that test data is used for that testing.
• 3 days before the exit criteria, ensure all test data are valid and can be used for testing.

Localisations for Client-side applications

When there are user requirements on localizations, we always refer to the user interface or client-side applications.  This is more on the usability and ‘look & feel’ of the user interfaces to be in the users’ native languages, the inbound data’s encoding settings that are imported from gateway to data repository and the inputs of native words into the data repository and transmit to external sources via the gateway.

1. Determine if the encoding conversion is implemented at the gateway, database or application level for inbound and outgoing data.
2. Determine the encoding and charset of the native language to use.
3. Test the encoding code to ensure native characters are displayed correctly from inbound files and data entry via keyboard at  the application level.
4. Ensure the encoding code works after the conversion at gateway or database level (if require).

Calcuation for Shipments’ Estimated vs Actual Delivery Dates

Customers like to get their shipments to reach the required destinations on time as to fulfill the customer satisfaction.  The calculation fo the estimated delivery dates/times varies on the user requirements and expectation to track each shipment milestone.

The works to do to get the calculation are:

• Understand the various shipment milestones and what are the end-to-end processes involved
• Indicate in each milestone what are the process and the event to trigger the milestones
• Calculate the turnover time to automate the calculation of  the actual event date/timestamp for each trigger event
• From the actual event, calculate the time difference (in hours) between the planned delivery and actual delivery timestamps to get the overall response time (part of key performance index metric).  This applies to all time differences to measure for the response time as per milestone.

System Specification Document for Warehouse Management System

In business computing, we understand that we need to capture and translate the business requirements into technical specifications in assist and understand what and how the proposed system is going to be designed.  Due to different solution for the different industries, the contents in a system specification document will vary but it should capture all the required information for the solution design.

For our warehouse management system we identify the following information to be captured into the system specification document:

1. System Architecture - A description of the network and hardware design for the solution.
2. System Design – A description of the system flow and integration with internal and external systems that includes communication protocols, formats and frequency.
3. System Process Flows – A collection of all the system process flows showing all the key points of system interaction and integration with internal and external systems.
4. Data Dictionary – Shows all the tables, primary and foreign key constraints, fields’ values, stored procedures and triggers that provides its propose and usage.
5. Message Mapping – A description of the mapping requirements between the message and the system.
6. Message Management – A description of the message execution and error handling within the system, includes staging tables, validation rules and error handling.
7. Screen Design and Execution – a description of the screen layout, field validation, database mapping/computation formula for each field and action upon clicking.
8. RF (Radio Frequency) Design Flow – a description of the RF flow and explanation of the logic including exception handling on each RF screen.
9. Reports – a description of all the reports required (operational and planning).  The details should include descriptions of all online reports, purpose/usage, intended audience, parameters and corresponding validations on screen, data extration source and logic, report format/layout and report export requirements.

Effective Meetings with Stakeholders

Most project meetings are always over-do or not following according to the agenda or the topics are out of sync from what the presenter is really trying to bring out.

We need to acquire the effective ways to bring out the points to the stakeholders to deliver and close with the maximum impacts that are to bring to the stakeholders.  Herewith are my personal tips on how to prepare for effective meetings.

1. Keep the meeting on time
2. Keep it short and sharp
3. Involve your audiences
4. Open the meeting effectively to stimulate interest
5. Communicate persuasively and effectively
6. Involve your stakeholders in discussions

When preparing the presentation materials:

• Understand your objectives for the meeting
• Understand your audience’s needs and their expectations
• Highlight key issues for discussion
• Use visual aids appropriately

Missing Data via Web Service Request

In all testing, one of the important test scope that need to be implemented in any web interface is data loading testing.  In this type of testing, mass records from a single message interface are generated to stimulate any possibility of encountering data loss and the immediate solution to rectify the problem.

Currently my project is going through SIT (system integration testing) and we recently experienced multiple records “missing” from the web service request.  We validated the total records of this message interface “A” with the Customer and gone through a couple of rounds on that testing with the same set of data and this incident still happened and the defect pattern is different (initial = 765 missing, 1st retry = 349, 2nd retry = 428).

Further analysis, we tracked our error log and realized for those missing records that we attempted to download, they flagged an error status with reason code “Timeout Error”.  The connection to the client’s web service gateway is via HTTPS and every time our program triggers to establish the connection we are to provide valid user information as provided by the Customer that will authorize us to have the access and setup the connection with the gateway.

We tackle the issue on “Timeout Error” and we includes the below codes to extend the receiving timeout:

HTTPConduit http = (HTTPConduit) client.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(36000);
httpClientPolicy.setAllowChunking(false);
httpClientPolicy.setReceiveTimeout(120000);
http.setClient(httpClientPolicy);

With the above, we retry and able to grab all the records from the web service gateway.   This is not a permanent solution to the “timeout error” and the team will monitor this scenario as we go along with the project.

Scopes for Freight Implementation

We had got the business for ODM Shanghai Freight.  The implementation that we need to work on is to receive the shuttle manifest from the Customer’s AS2 gateway and also to send back EDI214 back to the gateway as well.

The scopes involves data-mappings, application interfaces at both origin and destinations for the shipment receiving and infrastructure setup at the origin/destination facilities to cater this new business.

From IT perspective,  we need to do the following scopes:

1. SCAC – Standard Carrier Alpha Codes – to use for EDI214
2. Track and Track Status Code and Reason Code
3. RF Scanning
4. Application to track shipment’ status and invoicing details.