Test data management and regulatory compliance

Test data management plays a crucial role in ensuring the success of testing any application. Most of us spend a lot of time searching for an accurate test data satisfying the test case pre-requirements. A pre-requisite before procuring test data, would be to sit down during the planning phase with the entire team and document all the scenarios that are to be covered during the course of the test execution. This would eliminate the chances of missing out on any critical/non-critical scenarios in the future. Test data may be contained in a database table or any kind of file or even spreadsheet. It can also be of any format for example xml test data, system test data or even SQL test data, etc. Generation of test data involves a sanity, accuracy and integrity check of the test data in all related database tables. This means before test case execution the existing data is extracted from the database and therefore edited or conditioned to fulfill the test case requirements. Test data can also be categorized to ensure complete functional test coverage. Testers can also be creative, use their own skill and judgments to create different data sets instead of relying on standard production data while testing.

Sensitive personal, financial, and health information are governed by a variety of industry and governmental data privacy regulations like PCI, HIPAA, GLBA and SOX. They should be considered by Project managers when deciding upon test data and test environment.  It is essential that organizations protect their applications and databases from business users, production teams, DBAs, developers, and offshore and outsourced test teams, while allowing them to do their jobs. Basic security measures like authentication, authorization, and access control are not good enough to meet these various requirements. Organizations should consider advanced security measures like data encryption, auditing, data masking and real time monitoring to ensure data privacy and protection. Payment Card Industry Data Security Standard (PCI DSS) mandates strong data security measures. The top four PCI requirements that need attention are:

Requirement 3: Protect stored cardholder data. Sensitive data wherever it may be production or non-production, off-line or on-line, on-site or off-site, disk, tapes or devices. Recommended approaches to protect databases include data masking for non-production, data-at-rest and data-in-motion encryption for production environments. (Requirements and Security Assessment Procedures, 2013)

Requirement 11: Regularly test security systems and processes. All organizations dealing with credit card numbers regularly test their systems from a data privacy point-of-view. Recommended approaches include auditing, monitoring, and encryption. (Requirements and Security Assessment Procedures, 2013)

Requirement 8: Assign a unique ID to each person with computer access. Therefore, some organizations need to consider integrating application users with database user to keep track of who accesses private data. Recommended approaches include auditing and monitoring of sessions across applications and databases. (Requirements and Security Assessment Procedures, 2013)

Requirement 10: Track and monitor all access to network resources and cardholder data. Only authorized users can access networks. In addition, cardholder data needs to be monitored based on who is accessing or changing such information. To meet PCI DSS requirements, organizations must take steps to ensure they are protecting cardholder data with controls such as data masking, encryption and monitoring. (Requirements and Security Assessment Procedures, 2013)

HIPAA mandates all patient records be protected in all environments. All protected health information (PHI)-related data residing on any database needs complete data protection. The key requirements from a database point of view are in Section: 164.308 for administrative safeguards and Section: 164.312 for technical safeguards. (Security Standards: Administrative Safeguards, 2007)


“Build the right software” with the “Need for speed” and “Do it the right way”.

I have always asked myself during the period of my MBA study: Are agile methodologies good for software projects? My answer is “Yes”, they are good but not enough. And then I asked myself why they are not enough? What I have seen in the last 3 years shows that just following the Scrum methodology does not solve all problems. Let’s take a closer look in the three fundamental goals of agile software development to move forward into the future mentioned in Michael Dubakov’s post “The future of agile development”. Every other company in the market wants to „Build the right software” which is also the ultimate goal to generate revenue by catering their users with what they want to see and use. Most of the companies following scrum methodology have done reasonably good and has also generated huge public interest. To understand the needs of its customers, they have created a feedback cycle where the customers are also involved directly or indirectly. These interactions with the customers provide valuable information and many of them are golden opportunities to improve.
The second goal which arises is „Do it the right way”. Often when you create the right software, the job is half done and if it is not done the right way your mission is not complete. Users might be able to solve their problems but with an in-stable software which might crash now and then. When software is poorly coded it is very ambiguous, it might look good on the user interface and also might prove helpful but a reality check could reveal it is a train-wreck which could rattle anytime.
Most of the software companies have already implemented a methodology with a goal to test ideas first and check its viability, which also highlighted the third goal of agile software development: “Need for speed”. Normally these test ideas are transformed into working software with very few unit tests and a lame architecture/framework in the need to launch the idea to a targeted audience as fast as possible and prove that the product concept is viable. Eventually when the product concept works, the whole software block is rewritten right from scratch, keeping in mind the architecture, framework, scalability, and performance with lots of unit tests which might take a few more sprints. So this shows that „Do it the right way” is time-consuming and sometimes fails to catch up with the needs of the users.
When projects are getting complex, the speed drops due to the various factors attached to “Do it the right way” and this speed factor is very important for any competitive company. It is necessary to create software fast so that the firm can test the product concept and its viability. Once this is done the company gets a second chance to try various options to tune it to the user’s behavior and also “Do it the right way”. If a firm does slow work, there would be no second chance and probably would fall to the competition in the market.
Therefore, agile development process should “Build the right software” with the “Need for speed” and “Do it the right way”. Thus we have a development process with clear goals which should guarantee success (hypothetically). But the question that arises in my mind now is: How do we keep all these three goal in sync?

Representation of Agile Development Goals

The circles in the above figure depict how the three goals would overlap each other and also show some pros and cons. It also shows the ideal situation for software development. When “Build the right software” overlaps “Need for speed” without taking “Do it the right way” into consideration it would work for trying out new product concepts. But it would also mean putting off problems to a later date if the product concept is viable. This could be expensive at times.
When “Build the right software” overlaps “Do it the right way” without taking “Need for speed” into consideration it would mean that the company is likely to hit the jackpot if it has no competition. But the firm could completely miss out on market opportunities if the product concept is viable due to slow speed or the company would make huge losses if the product is not accepted in the market.
When “Do it the right way” overlaps “Need for speed” without taking “Build the right software” into consideration meaning the company will have a wrong product in the market which no one needs. The company could learn from the market reaction and understand what went wrong and make fast changes. Ideally this situation should never happen if the product team has done its homework.