1. Dummy Data

Dummy data is an in-house solution for generating test data. Developers commonly create it as a placeholder for actual data. The data doesn’t often look like real data — an address field might contain random characters rather than something resembling an actual address. 

Dummy data is quick and easy to make. It can be useful for testing a specific edge case, as developers can more carefully craft the data to align with their needs. 

The problem? It isn’t a scalable solution, making it viable only for small-scale, ad hoc testing.

2. Mock Data

Mock data is another in-house solution, but can also be created using generators or open-source libraries. Mock data is similar to dummy data. However, because developers use automated tools to develop it, it is typically more consistent.

Mock data can be generated against a set of rules to ensure this consistency. This enables it to integrate into a software development pipeline, automating the creation of test data before tests are run. 

For example, mock data can generate long or short strings, add special characters to strings, and include random NULL fields. It can often generate data that resembles real data, such as people's names, company names, and addresses. 

The problem? Although this data better mimics reality, it remains challenging to maintain referential integrity between mock data tables within more complex systems.

3. “Anonymized” Data

Another common solution is anonymized data. This involves taking real data and masking any personally identifiable information (PII). Anonymized data provides the benefits of realism without the security risks associated with using PII.

The problem? If done in-house, using anonymized data significantly increases the burden on in-house development teams, as they must ensure that anonymization software works correctly and all PII data points are identified.