The Test & QA Temperature – Environments and Data

Publish date:

As an executive responsible for a Software Testing and Quality Assurance consulting practice –focusing on Financial Services, I find myself on the road quite a bit talking with clients about their issues, concerns and lessons learned.  Of late, I’ve been having conversation on Test Environments and Test Data. The climate on Test Environments seems to […]

As an executive responsible for a Software Testing and Quality Assurance consulting practice –focusing on Financial Services, I find myself on the road quite a bit talking with clients about their issues, concerns and lessons learned.  Of late, I’ve been having conversation on Test Environments and Test Data.

The climate on Test Environments seems to be moving quite a bit.  I receive feedback that ranges from the distraught to the content, with all of it moving toward the same direction; cloud.  The Cloud offers tremendous flexibility when it comes to scaling test operations up or down, without all of the “commitment” required for in-house infrastructure.  As long as the test environments and tools are up and running with solid source control for the code base, what’s not to love?  As a former test engineer myself, I remember the days of “hurry up and wait” as test environments were secured and provisioned prior to test execution.  For the large part, most discussions with my Financial Services (FS) clients have been about private cloud.  However, there are a few daring FS souls that are investigating and experimenting in public cloud solutions.  Let’s hear it for the pioneers…..

On the test data front, I continue to hear varying discussion regarding test data obfuscation.  One consistency I’ve found is that there appear to be two separate camps on the topic.  Camp #1: data must be obfuscated.  Camp #2: If the infrastructure that the data sits on is secure, why the need to obfuscate the data?  Focus on securing the container, not the contents.
Personally I’m of the opinion that data should be properly obfuscated.  Given that a large percentage of data security breaches are “inside jobs”[1], it only makes sense to protect the data versus securing access to it.  

I understand the complexity of this position, especially in the end-to-end testing space –where numerous systems and data sources are used to create a single business process.  However, given the complexity I still believe it to be the right path to take.  Further, the complexities can be overcome.  I have been working with our Business Intelligence Practice lately, as they have developed a framework for what I call “holistic obfuscation”.  In other words, a means for comprehensively obfuscating data across systems and data stores with consistency.  By creating the equivalent of a “cross-reference map” the solution has the ability to follow transactions and their corresponding data through a business flow.  This approach accommodates the multiple systems and data stores that most large enterprises cross when conducting end-to-end business transactions.  It is a very interesting offering that couples nicely with my team’s Test Data Management framework.

Stay tuned for more to come next month on my travels and conversation regarding the Software Testing and QA industry.  In the meantime….”trust, but verify”.
-Dr. Kapfhammer
 


[1] Understand The State Of Data Security And Privacy: 2013 To 2014., http://www.forrester.com/Understand+The+State+Of+Data+Security+And+Priva…

Related Posts

Customer Experience

A practical guide to superior performance: Focusing on the portal and policy administration

Chad Hersh
Date icon September 17, 2020

To fully benefit from modernization, an insurer must understand all of the available options...

commerce

Converse to engage: The rise of conversational commerce

Nilesh Vaidya
Date icon September 15, 2020

The rising popularity of voice assistants ‒ together with BigTechs pioneered social media...