Category: DataOps

You may have heard of code smells or even smelly test environments.

But, what about Data Smells?

In this post we discuss top smells that indicate you need Test Data Management.

Foreword

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem.^[1][2] Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

The term was popularised by Kent Beck on WardsWiki in the late 1990s. Ref Wikipedia.

Invariably every IT problem has a symptom that we call smells.

In this post lets focus on the most popular ones associated with Test Data Management

Top 15 TDM Smells

1. Testers waste large amount of time creating data rather than testing the application.
2. Data provides doesn’t meet the requirements for testing (has incorrect mix of data).
3. DevTest cycle /and project slippage to data unreadiness.
4. Dependency on other experts to provide the Test Data (experts that may have other priorities).
5. System Data lacks integrity (is incomplete) and limits System Testing.
6. Up or Down stream data hasn’t been prepared in similar fashion, causing E2E integrity issues.
7. Data Related defects caused by data being in unrealistic state i.e. False Positives.
8. Test Data Creation is (or is deemed) too complicated or time consuming.
9. Test Data is too large causing refreshes to take too long.
10. Test Data size (production size) causes performance bottlenecks & broken batch processing in smaller test environments.
11. Data has been copied from production and has PII data i.e. Data is insecure.
12. Testers (& developers) don’t understand what the platform data looks like. Resulting in the engineers fumbling in the dark as they try to exercise it effectively.
13. Due to Data complexity, Testers can’t easily find (mine) the data sets once it has been deployed.
14. Test results are being corrupted by testers “only” using/reusing the same small data sets  (data contention).
15. Lack of data reuse (or automation) resulting in continuous reinvention and repeated mistakes.

In Conclusion

Test Data is an essential, if not somewhat complicated, and often ignored, aspect of effective Devops & Quality engineering. However treating it as an after thought will invariably result in the smells described above. Smells that will introduce suboptimal DevOps/DataOps operations, unwanted project delays and poor testing.

Do you have other ideas on Test Data Management Smells, then please let us know?

Post By Jane Temov

Jane is an experienced IT Environments Management & Resilience Evangelist. Areas of specialism include IT & Test Environment Management, Disaster Recovery, Release Management, Service Resilience, Configuration Management, DevOps &Infra/Cloud Migration. 

This post aims to answer a simple question. Namely, what is data provisioning in the context of Test Data Management (TDM.)

Socrata’s glossary of technical terms defines data provisioning as:

The process of making data available in an orderly and secure way to users, application developers, and applications that need it.

But remember what we want here is to understand what data provisioning is in TDM. While the question itself is—seemingly—simple, you’ll see that it can quickly generate a lot of other questions that need answering if we are to see the big picture.

We start by taking a look at the current state of affairs in the software development world. You’ll understand why applying automation to the software development process is vital for modern organizations and what roles the automated testing plays in this scenario.

We then give an overview of TDM. You’ll learn what Test Data Management is and why it is essential for a healthy testing strategy.

With all of that out of the way, it’ll be time for the main section of the post, where we’ll see what data provisioning is and how it fits into the TDM puzzle.

Let’s get started.

Continue reading “What Is Data Provisioning in Test Data Management?”