What should be the conclusion of this article is going to be the initial approach. Customers (or at least 99% of them) want to see their own content when they are testing features in pre-production. It may sound blunt but it is the harsh reality. You will be surprised how I came to this conclusion.

Clients loved this photo of Dr. Mathew Svenson. My boss even called to congratulate me.

I'm sure your coworkers think you're the life of the party, call you Devops Harlem and laugh their asses off at the comments that you leave hidden in your code. However, I'm also sure that the vast majority of customers are not thrilled that the names of your app's test users are Game of Thrones characters. Forgive them, Lord, for they know not what they do.

What data is expected in the pre-production environment.

- The button should be orange.
- Yes, no problem, this is just a test.
- Yeah, but it's not orange.
- Right, it is a test to see that we can change the color from a configuration panel. You can use any color from the palette.
- But it's green and I want it orange.
- Yes, you can configure it with the color you want, for example orange.
- I see, why isn't it orange?

Example of a conversation with a customer after testing.

In the above case, our customer wants to see an orange button because there was an orange button in the designs and believe me, he will not stop until he achieves his goal: to see an orange button. It will be like the T-800 chasing Sarah Connor until I manage to eliminate it. When we do the next demo with that super mega feature new one that has taken us 2 months will say, all well and good, but why is the button still orange?

Although it may seem outlandish, I have experienced too many situations similar to this one not to learn. The solution is as simple as trying to reflect the data and configurations shown in the designs as faithfully as possible. Doing so will not mean more work but it will avoid possible frictions.

A picture is worth a thousand fixtures

To be honest, texts are not usually a big problem as long as we keep a certain decorum. It's true that it's not always easy and that we are little devils who prefer to have a user named Aitor Tilla than one called Antonio García Perez. The truth is that, having opted for the first option, it is possible that it will go unnoticed and will not cause us any misfortune.

The main complaints are usually given by the use of inappropriate images as this is the aspect that can cause the most friction if it does not meet the expectations of our client. 

To prove that an image is uploaded to a server and displayed correctly, we can use any image that meets the weight, format or dimensions requirements that we have specified, regardless of its content. We know this, but really, sometimes our customers are not aware of it and are unable to visualize the application we are developing in an abstract way. To be fair, they don't necessarily have to have this capability, although it is highly desirable for them to have it in order to work in a less rigid way.

Let's take an example. We are developing an office chairs marketplace and we need to fill our server with test data. Here is our test data:

What better test image for a chair store than a toilet. 

Needless to say, our image of the toilet is at the top of the scale of grindability, and while it is true that we may win the hearts of our most discerning customers, it is also true that we may be able to win the hearts of our most demanding customers. guasones, Others may not understand that this data will be lost in time, like tears in the rain.

In these years I have tried everything: using images from TV series, video games, movies and always ended up causing some kind of friction so I came to the conclusion that the best test data is a plausible data to our platform and, if possible, an existing data. Let me explain.

If we follow the example of the chair marketplace, let's simply try to get content from our customers. If we want to differentiate it, we can simply add a watermark to our image. With this it will be easy to identify our test content and at the same time respect the idea that our client has of the platform. Why being so simple it is so hard for us to do it?

The use of APIs

To help us we can make use of apis that provide flat and bland test data, in short, what we are looking for. For example, randomuser offers test users, you can use lego avatars but you must be strong and not be tempted. Another example would be fakestore, where we will get trial products. These are just two examples but you can find many APIs that will help you and many of them are free.

Conclusion

It is true that in in-house product development there may be more flexibility, but looking at it from the outside, if the effort is the same, why take the path that may cause more problems?

Our customers want to see as true a reflection as possible of what the final product will look like. It is as simple as that. This is just a personal opinion based on all the experiences I have had developing products for third parties, maybe your experience is different and I would love to hear about it if so.

Is it possible that we developers have a gene that makes us behave like morons when we have to enter data for our tests? As I write these lines I am uploading an image to test a feature in a T-shirt marketplace I am working on and I promise you that the T-shirt in question contradicts the whole approach of the article. Maybe I'm trying to put gates in the field.

Discover more articles in our blog