By Preeti Sharma
Do you want a way to perform smoke testing on new builds deployed in Test Environment? Start using Unified Modeling Language (UML) diagrams to make it easier.
Appirio follows the Hybrid Agile Model, where the frequency of change in requirements during the project is very high. Hybrid Agile is a smart approach for adopting different methodologies without compromising the quality of the Application Under Test.
Smoke testing, on the other hand, is equally important in an environment where there are a number of builds and releases. For example, when implementing a sales app for an Ipad, it will need to have changes merged from the release management source to create a build each day.
In the above case, the tester has to ensure that every desired component of the app is working. How should the tester approach this? Should they execute all test cases daily to ensure stability of the build?
For me, it’s a BIG NO! because it’s really cumbersome to re-execute the same set of test cases every time when a build is up. In such a scenario, I’d suggest the tester should create and use “Use Case diagrams”, including all use cases from different Personas (actors in UML). Then, execute them in one go, instead of running them again.
Now the challenge is, how do you frame a Use Case Diagram for a specific set of requirements? To answer that question, let us first understand this one: What is Use Case Diagram(s), and how do you implement them in Smoke Testing?
Use Case Diagram will summarize who uses your application or system, and what they can do with it. They enable you to visualize the different types of roles in a system and how those roles interact with the system. With the help of Use Case Diagrams, the following things are communicated:
- The scenarios in which your system or application interacts with people, organizations, or external systems.
- The goals that it helps those actors achieve.
- The scope of your system.
Smoke testing will ensure the core functionalities/minimal operational existence of the build. And that’s how Smoke Testing plays a key role in deployments done at production or UAT.
So, in order to perform Smoke Testing if I opt to use Use Case diagrams, I need to:
- Put all the main actions of the actors in the Use Cases, considering those to be the first ones to check when we perform a smoke test on the build.
- determine the relation among the Use Cases and actors.
Below is an example of a sprint Use Case Diagram where all the stories are accumulated to be verified with the respective actors:
As you can see above, all the stories in the sprint have direct relation to the actors — say, manager and seller.
- Other use cases represented by “<include>” show the extended functionality that is supposed to work on the application to deploy.
- The sign depicts that the particular use case is not working correctly on the app, and the other symbol depicts correct working functionality.
Now, while performing smoke testing, the major responsibility of the tester is to verify the basic use cases that an actor is supposed to perform. In the diagram above, the following things are verified:-
- Seller’s ability to Search
- Seller’s ability to open the Geopointe App
- Seller’s ability to access Gmail app.
If any functionality fails on the first step, build is obviously not good, and tester should create critical /blocker issue to fix it.
And finally, some helpful tools that we can use for creating use case diagrams are as follows:
Hopefully, this helps you perform smoke testing on new builds. Study up on how to use Unified Modeling Language (UML) diagrams!