Ask a LOT of questions (Brainstorm)

Vector Designed By Charrie Soriaga from pngtree.com

In the previous blog, I spoke about the very basic mantras (ABCs) for testing software, which have been very helpful for me throughout my career.

In this article, I would like to focus on the first mantra which is “Ask a lot of questions”. We will take a case study and see how a very small requirement can be expanded into many more, much needed details by asking the right questions.

Case study: A logistics android app for agents working at the customer collection centres.

Requirements:

Agents present at the customer collection stations will

1. Receive packages from the seller/merchant
2. Handover the packages to customers
3. Handover the overdue or rejected packages back to sellers/merchants

We are going to work through the above 3 lines of requirement, process the information and ask some questions, or a lot of them.

But before we jump onto the requirements, let’s first analyse the case study statement itself.

A logistics android app for agents present at the customer collection centres

So, what’s the info we see here?
a. Android platform
b. Logistics app
c. Users will be agents who are employed at collection centres
d. Application used at Customer collection centres

Here, point (a) gives us information that would have a whole test suite in itself. Note that we don’t even know the behaviour of the app yet, but we can still come up with tests that are required and some questions that will add more tests.

Following are some scenarios that would need elaborate tests:

1. App startup (Auto start?)
2. App login/logout
3. App permissions
4. Android OS version support
5. Memory consumption
6. Background process if any (this would depend on the requirements)
7. Cached data, data saved by app
8. App uninstall
9. Force stop

The above points would need to be converted into detailed test cases by asking more questions to the client or suggesting an optimal approach for the same. There would be many combinations of these with different actions performed in the app.

Now that we’ve had a good start with the case study statement, let’s pick one requirement at a time. Each one of those would contain some important information that would need to be extracted for creating a good test suite.

Agents present at the customer collection stations will — 1. Receive packages from the seller/merchant

Here 2 points are repeated — agents and customer collection station, and some new information comes to light.

1. There are packages involved. These packages come from some sellers or merchants.
2. These packages are received at the station by agents. The agents should be able to mark the packages as RECEIVED in the app and store them at the stations. To mark a package, each package must have a unique identifier.
3. As the packages have come from some seller/merchant, there should be some info related to the merchant attached to the package.
4. There will be multiple packages. So the agent will have to mark each package as RECEIVED, to avoid any confusion about the package status/location.

We’ve extracted as much info as we can from the 1st requirement. Each point has to be confirmed from the business/client, hence each is really a question to be asked. Let’s go ahead.

Agents present at the customer collection stations will — 2. Handover the packages to customers.

Again, we have agent and customer collection centre. We now know some function of the agent from the previous requirement. The current requirement sheds some light on why it is called the customer collection centre.

1. Customers will come to the collection centre to collect their packages. This means that they already know which station their package is at. Hence, the packages should be assigned to some station in the beginning, so as to store & convey this info to the merchant and customer.
2. The agent will retrieve the package that is to be handed over to the customer using the package details, hand it over to customer, mark the package as CUSTOMER_COLLECTED. Maybe get the customer’s signature on the app.
3. There should also be some kind of identification check for the customer to make sure that the package is being handed over to the right customer.

Agents present at the customer collection stations will — 3. Handover the overdue or rejected packages back to sellers/merchants.

What’s new here?

1. Overdue packages- Packages that have been at the station for more than a specified time period. This suggests that when marking packages as RECEIVED, the app will need to capture the timestamp.
2. Rejected packages (customers can reject a package.)
   — Also let’s confirm if the agents can reject a package based on damaged packaging and give those back at the time of receiving itself. If yes, then this can be added to the 1st requirement itself.
3. When these packages are being picked up by the merchant or logistics management, the app should allow the agent to search for these packages, mark them as HANDED_OVER_TO_MERCHANT. As we have realised, capturing the timestamp would be required here.

So let’s collate the information we have and jot down what we understand as the functionality of the app.

1. Station and a customer collection centre are one and the same.
2. The agent works at a station, so when the agent logs in to the app, the app should fetch the list of packages that are assigned to this station only -
   — on startup
   — periodically
   — on a manual trigger
   — or all of the above
3. When the packages reach the station, they are updated in the system as RECEIVED by agent and timestamp is captured.
4. When customers show up to collect their package, verify their identity, take their signature and hand over the package. Agents will mark this package as CUSTOMER_COLLECTED on the app, and take the customer’s signature on the app itself. The app will capture the timestamp.
5. At the point of package collection, the customer might reject the package for various reasons. In such a case, the agent will mark the package as CUSTOMER_REJECTED instead of CUSTOMER_COLLECTED.
6. The agent will mark the packages HANDED_OVER_TO_MERCHANT on the app when doing so at the station.
7. Between the RECEIVE and CUSTOMER_COLLECTED/HANDED_OVER_TO_MERCHANT, the package might go missing. So, the agents should be able to mark them as LOST. As this requirement is not yet given by the client, we can feed this back and the client can think over it and include it in the next iteration/release.

It is very important to get all of the above information verified by the client or the business analyst.

An illustration of the gathered information.

Some technical questions:

• Each of these transactions done by the agents will make changes to the database that holds the package information. As this is an android app, the app would connect to a database that resides on a server via http requests. Where is this DB? What kind of DB? Metadata?
• What requests are made by the app (if any)? Information about the request and response data would be required. Also, if the requests fail, how would the app respond to different failures? How many retries?
• When there are http requests involved, the network connectivity plays an important role. All the user flows need to be checked with some variations of network connections. Can the app function offline? (if yes, then a whole new dimension of tests would be unlocked.)
• What kind of authentication is used for making the HTTP requests?
• Would the session expire anytime for the agent?

These are a lot of questions and I’m sure if we rack our brains some more, there would be many more added to the list. We’ve converted 5 lines of requirement into a big document with lot of assumptions (confirmed by the client), questions & test cases. As you would guess, it’s an exhaustive process to test software, but smooth sailing thereafter, if you are curious.

So, rack your brains, ask questions and happy testing!