Every application, web or non-web-based, has to deal with data. Even though there are static websites, where data is somehow embedded, most sites and applications rely on dynamic data stored somewhere and somehow.
What testing can you do around data handling? Can you use exploratory testing to uncover problems related to data? What type of problems?
In this article, you’ll get some guidelines for your exploratory testing sessions around data. And by guidelines, I mean more rough ideas, not an exhaustive list, that can get you started. Let’s dive into that.
Looking at data from different angles
Let's explore "data" from multiple perspectives by asking questions to spark testing ideas based on your experience. Some questions will be built on previous ones, potentially shifting your focus. And that's fine - you need to decide whether to stay on track or follow the new direction.
1. Sources
- Where does data originate from?;
- Is the source/channel relevant to the data that is created? (e.g., fewer/more fields, additional relations);
- If data is originated or even accessed using APIs:
- Are there any rate limits in place?;
- Are there any API tokens that can be revogated on-demand or based on a time frame?
2. Modeling and storage
- Which entities do we have represented?;
- What attributes does each entity have?;
- Are there any relations between entities? Which ones?;
- Is data versioned? Is it needed?;
- Are data changes/history being tracked? Is it needed?
3. CRUD
CRUD stands for the four essential operations a software application should perform – Create, Read, Update, and Delete. Users should be able to create data, view it in the UI, update or edit it, and delete it. And the following questions are based on that methodology:
- What are the different ways of adding, retrieving, editing, deleting data? (e.g., UI, public APIs, private APIs, CLI tools, back office...);
- What operations are we supposed to be able to perform, based on the interface being used, credentials, etc.?
4. Usage
- How is this data shown? And where? And to whom?;
- Can data be filtered based on some attributes or even based on some pseudo-attributes (e.g., like a calculated field)?;
- When certain data is changed, how does that change affect APIs and all relevant UI elements? Notice that the same data can often appear in multiple places.
5. Security and Integrity
- Are there layers to access the data?;
- Authentication and authorization - how is it implemented and managed?;
- Is it possible to tamper with data?;
- Is there a built-in data integrity mechanism?
6. Performance
- What happens if the number of certain entities stored becomes huge?;
- Is there pagination in APIs/UIs?;
- Are there any expectations in terms of performance?
7. Documentation
- Is this data documented internally or externally?;
- Is the access to this data and its APIs documented?
8. O&M (Operations and Maintenance)
- Is there a built-in data integrity mechanism?;
- Is there any data replication being made?;
- Are backups made? How?;
- What's the process to restore backups? How can it fail?;
- What happens whenever these backups are huge?
Now, it’s your turn!
In this article, you've seen a testing subject around data, using several angles to get some questions and testing starters.
The main point is that exploratory testing always leaves room for additional testing. And if you need ideas, you can consider different aspects or quality criteria to get unstuck.
You can follow your data from its beginning until its end and all the different ways it is instantiated, changed, presented, documented, preserved, restored, or deleted.
Have fun discovering your product and uncovering problems around your data!
