With the introduction of mobile communication, a whole new industry of mobile application development has come into being. Since JIRA was built primarily to cater to the development needs of the web and desktop applications market, leveraging JIRA for managing mobile application development involves some level of customization. Based on the application requirements, JIRA thankfully allows the flexibility to add custom fields, which is necessary for the excellent communication that a software testing tool is meant to achieve. This article discusses the custom fields that are ideally required in JIRA for mobile application development and how they facilitate the workflow of the software development cycle.
Custom Fields On JIRA Issue Screen
For managing mobile applications in JIRA, these custom fields can be added:
-
OS
Mobile applications are routinely designed to have the same user functionality for different Operating Systems (OS). But, based on the platform on which they are applied, their implementation can be different. These scenarios are possible when we test a mobile app:
- If the OS on which an issue is detected (say, Android) has not been specified in the ticket documentation, the ticket could end up assigned to the wrong team, for example, it could go to the iOS team. This could lead to confusion and a delayed workflow.
- Also, a bug may be detected across all platforms, say, both Android and iOS. If the OS is not specified in the ticket documentation, the same ticket could easily be sent to both developer teams. It may be that the ticket is fixed by the developers working on Android OS and they close it, while the iOS team has yet to look into it. Because of this ambiguity, this bug will persist on iOS, again causing a delay in the workflow.
The solution is the creation of a custom field specifying the exact OS; different tickets can be raised for the different developer teams working on Android and iOS.
-
Affected Build
As discussed in a previous article, developers need their own environment in which they can code and run unit and integrated testing on it (development environment). Since the development environment is dynamic and unstable, it has to be kept separate from the QA environment (staging), which is inherently updated only at controlled times so that QA engineers can conduct their pre-planned functional validation of the components. The production environment is kept exclusive from the development and testing phase so that the end-users and other software interfaces are not affected by the dynamics of development and testing.
A ticket should be closed only in that environment in which it was created. A bug detected in the staging environment will be fixed in the development environment. But, it will be closed in the staging environment only, once it is verified as fixed there. This environment data is not included in JIRA by default. It must be specified as a custom field in the issue documentation as, say, Affected Build.
-
Affected Device OS
Mobile manufacturers are continuously coming up with newer versions of their OS. For instance, Kitkat is a version of the Android OS and it, in turn, has multiple versions. If a ticket has been raised on a device with Kitkat as the OS, the developers may likely need to reproduce it on that same device OS. They can do so most effectively if this is communicated consistently by adding a custom field on the JIRA issue screen to specify the affected device OS. Otherwise, they may end up trying to reproduce the issue on a different version where the same ticket may not be valid.
Android versions like Lollipop and Kitkat have multiple versions. For more information, refer to https://wiki/Android version history
-
Tested Version
The build that was released for testing is the Fix Version; the JIRA issue screen has a default field for this. As developers release newer builds, testing of application components continues in real-time. It might so happen that at one time, a QA engineer might have two versions of the same component for testing; clearly, they will test the latest version. A custom field, say, 'Tested Version' should be created on the issue screen to specify the version of the component that was tested. The fix version and the tested version of the component may be the same, say, 1.1. But, if the fixed version is 1.1 and the tested version is, say, 1.2, having a custom field for the latter will provide more clarity and prevent confusion...as QA engineers we certainly want to spend our time testing only the correct code!
So, it is evident that the rapid changes in the world of mobile communications and development necessitate a proactive testing environment for mobile applications in order to provide superior software quality assurance. The flexibility afforded by JIRA in allowing the addition of custom fields to provide comprehensive test results tracking while maintaining focus on the application workflow and unambiguous communications helps maintain its relevance as a best-in-class software testing tool among project managers and QA engineers.
