October 1st, 2024 by Jeroline
September 30th, 2024 by Jeroline
September 25th, 2024 by Jeroline
September 13th, 2023 by Suyash Dubey
May 19th, 2023 by loginasadmin
May 18th, 2023 by Prashanth M Nair
Code Review in a Startup
Here I bring to you the 5th blog in the DevOps series showcasing our learning while #scalingup. Read our previous blog to know about the bunch of tactics that we used at different times during our evolution to achieve a successful clockwork during our DevOps journey.
Proper optimized code review is something that many startups miss. Some take the easy way out and ignore it and others spend years discussing the best practices, conventions and styles without ever committing code. Both these are slightly over exaggerated examples of paths to failure, but I am sure you can relate to these if you have ever tried to answer the all important question about code review “Exactly how much code review should your team do?”
For perfectionists, the answer is that code should always be reviewed and you should always be refactoring code and improving it wherever you see a scope. I have worked in companies, where people used to spend almost as many hours reviewing code as much as they would writing them. There are some practices like pair programming, which has maximizing code review as one of the results. So this is not exactly a wrong direction of thinking. The problem however is that when you are working with time constrained environments like that of a startup, you will not have a luxury where you can keep revisiting and improving code beyond a reasonable amount of time. And I have seen that surprisingly many people altogether avoid code review because timelines are constrained. I don’t even need to mention how risky this is and how dangerous this course of action is. However it seems many people do exactly that.
In this blog post, I will attempt to throw light on our experiences in deciding how much is enough. We too, like other startups have a time constrained environment, and a few (thankfully only a few) customers who want every feature done yesterday. So as a culture, we too try to make sure that we finish everything faster. Development faster, Testing Faster, Deployment to various environments faster. But we do not ignore code review. We ensure that we do code review. We have a few principles that we followed to make sure that code review happens all the time, and is neither too less nor too much. Here are they. What we have seen is that if you follow all these steps, then you have a sane code review process and you can guarantee a stable flow of god code into your repository. These points are in no particular order of importance.
You should do code review: The first principle is not a lame attempt at a joke. The idea is that code review should happen come what may. Without this principle being followed, every other principle in this list breaks down. We use git-flow as one of our developer methodologies with git. One of the advantages of this system is that code review is built in. Unless code is approved by a designated reviewer, the code does not go to the next level be it Testing or Production. The Approver is as responsible for a piece of code as the original developer. This way the reviewer spends more time reviewing and the original coder also reviews and corrects his code in advance to preempt the reviewer. This adds more points in the system where code review can happen and makes sure that code always gets reviewed and the review is not forgotten.
Requirement Matching: Does your code do what the requirements ask it to do? Are we doing less? Are we doing more? A quick inspection reveals mismatches if any. This goes a long way in finding out if there are any problems in the code.
Readability: There is an apocryphal statement that says that code is written once and read hundreds of times. While the statement may not be accurate, you may write more than once, and may not read hundreds of times, you still do get the picture. The basic premise is that code does get read many far more times than it gets written. Also once written, your code will also be read for review, bug fixes, enhancements, etc and not always by you. Also in the IT Sector, jobs switches happen a lot, so a new person should be able to understand and work with the code as soon as possible.. So it makes sense that whoever looks at your code after you have left is able to understand your code well and can alter if needed and maintain the code well till the product lifetime completes.
Reviewability: A further subset of this is that the code should also be reviewable, you and your code should be able to convey to the reviewer what the code is supposed to do and what the reviewer is supposed to review.
Scalability: Will your code be able to stand frequent and/or continuous requirement changes in the future? Will it be able to handle a reasonable amount of requirement change without having to have to rewrite the entire thing? Overall applications are live, especially in the Agile era, your requirements are never frozen, and hence the code also should never be frozen. It should be able to handle changes in requirements. A word of caution here, do not overdo this. While your code should be able to handle requirement changes, you cannot (and should not) make your code so generic that it can handle the proverbial ‘everything under the sun’. Your code should be reasonably scalable. Too much scalability also is as bad as too little. How much to go down this path will depend on your specific business needs. However it is not a bad idea to talk about specifics to your business stakeholders. They can tell you how and more importantly how much a feature will be used. You can then decide how scalable you want the code for that feature to be. The process of arriving at how much is just right, takes time to set, but once done, you will thank yourselves for the foreseeable future.
Improvements: This is one of the basic purposes of code review. This answers the question, “Can we do the same thing in a better way?”. Better way could mean one or more among, faster performance, better readability, more modularity, and others. You need to keep asking this question in a code review. If you can, then your code review is not complete, if you cannot improve any longer, then probably the code reached here after many rounds of reviews. Or was copied from well reviewed code. Again this is one of those things that has the potential to be overdone, so think carefully how far do you want to go down this rabbit hole without losing your wits.
BNBR: This is lifted from one of the policies of Quora, It means Be Nice, Be Right. The point is that while reviewing , you need to be nice and be right. Being Nice First. The point of a code review is to see if things can be done better by putting multiple heads instead of one. It is not to hurt or massage egos. What can be done by just pointing out issues with data should not descend into a shouting match (verbally or through the keyboard). Make sure that your comments are politely worded and are correct.
Code Scanners: Before you give your code for review, your code should be scanned by tools to make sure that basic checks are done for issues like parenthesis matching, formatting, typos, indentation, naming convention etc. Your reviewers will have a tougher time navigating your code if you do not fix these. If your reviewer finds these issues and not a code scanner, then you have not prepared for your review well.
The Unhappy Path: The code works fine, but some scenarios were not tested. How do you know if your code is able to handle most of the basic errors or exceptions. Your review should make sure that this is in place well before time. Again you need to use this judiciously. You should not overdo it.
Timeliness: Your code review should have a deadline. You cannot indefinitely keep reviewing the code, your review should finish within a deadline. If you ship years late, how will better code help you ?
Dark Spots: Every reviewer may not be able to review all aspects of the code. So it is a good practice to tell in the review comments what aspects were reviewed and what were not, so that everyone knows the extent of the code review. If everyone says it looks good to me, but everyone only happened to review the naming conventions, then it probably was better if only one person reviewed. If each reviewer mentioned this small info, then everyone knows in advance if there were any dark spots in that particular review and they will be able to redress it.
Fatigue: Do not review too many pieces of code at a time. If you happen to be spending a long time reviewing, then probably the code under review is too large or you are reviewing too many PRs at the same time. Reviewing is a thought intensive process and you need to make sure that it is done properly. So please take breaks, if you are tired of reviews and are still somehow powering through that will reflect in the quality of the reviews. A rule of thumb is to not review more than 60 minutes at a time or around 400 lines of code at a time.
Checklists: One good shortcut is to use checklist to review a PR or a piece of code against. These checklists ensure that your mind does not wander, wondering what you have missed and you will also be reviewing against pre decided metrics.
Defects: What do you do with the issues you found ? Not every issue needs to be or can be fixed immediately. You have to decide what to do with each review comment. Whether you will be fixing them, ignoring them or putting back into your backlog. Make sure this is a separate backlog for technical debt.
Overall these are the things that we follow while doing code review. Many of these helped us a lot to make sure that we are reviewing just enough to keep our process wrooming along while at the same time, not ignoring major issues.
May 17th, 2023 by Shivani Sinha
Test cases are the first step in any testing cycle and are very important for any project. If anything goes wrong at this step, the impact gets proliferated in the entire software testing process. This can be avoided if the testers use proper procedure and guidelines while creating the test case template.
In this blog, I am going to share some simple yet effective tips which you could use for writing effective test cases. These tips will save you time and effort while optimizing the use of resources.
How to write test cases in a better way
Let’s have a look a the tips to write better test case template.
1. Detailed Domain Knowledge
Domain knowledge in information technology means deep knowledge of business and operational dynamics, the risks involved and the opportunities in that particular project. It is required to follow the best practices in the domain.
2. Break long test cases into many smaller ones
It is better to break the test case into a group of smaller ones if it has too many steps. It would be easier for the developer to backtrack and repeat the test steps if an error occurs somewhere in the test script. If not done than there are high chances that the developer will miss the bug.
3. Preconditions
Before starting on the test case it is suggested confirm all the assumptions that apply to the test and the preconditions that must be met before execution. There can be data dependency or the dependencies on the test environment or any other test cases.
4. Attach Artifacts
Relevant artifacts should be attached to the test cases. This can be done using a test management tool. At the time of product delivery, It will help to track the changes in the application. I will be easy to understand the flow of the function when there is a change at any step which will not be easy to relate otherwise.
5. Test data input
While writing a new test case a tester can share test data wherever applicable to be used for the Test Case within the test case description or add with the specific test case step. This will save time as there is no need to look for the test data anywhere else.
If the values are to be verified then testers can specify the value range or describe what values are to be tested for a particular field. Choose a few values from each class which will give good coverage for your test.
It’s better not to mention the real test data value but the type of data which is required to run the test. In projects where multiple teams use the test data and it keeps changing, mentioning only the type of data will be a wise choice.
6. Organize your work
Use a test management tool to manages your test cases instead of using a spreadsheet. There are many test management tools that can be used to organize the test cases in one place which will increase the productivity of the team.
7. Stop Assuming
It is better to refer to the specification document. Assumptions about the features or functionalities can lead to disagreements between the client and the developers. This gap between the client’s requirement and the application under development will impact the business.
8. Test Case Naming Conventions
To write tests which are easy to understand, we have to stop coding on autopilot and pay attention to the naming conventions. It is required to name our test classes, fields of our test classes, test methods and the local variables while writing automated tests for our application.
It does not matter which team member wrote the test, others will know what feature is tested under what scenario without even looking at the test code.
9. Meet Customer’s Requirements
If the testers miss a bug or write test cases that do not relate to the real world scenarios then it’s just a waste of resources and time. The goal is to meet the customer’s expectations and that can be attained only if the testers think from the users perspective.
10. Cover All Verification Points
It is important to write well-defined test case verification steps covering all the verification points for the feature under test. To make sure that the test Case covers all the verification points match your test case steps with the artifacts given for your project.
11. Avoid Repetitions
Do test automation when needed as it will reduce the manual effort and save a lot of time. The test scripts should be written in such a way that they can be used afterward for some other project.
12. Make it Reusable
Create test case template which could be re-used in the future by other teams. Also, before writing a new test case for your module, find out if there are similar test cases written already for some other project. Doing this you will avoid any redundancies in your test management tools. Call the existing test case in pre-conditions or at a specific design step if there is a need for a particular test case to execute some other test case.
13. All-Inclusive Test Coverage
Test cases should include all the features and functionalities mentioned in the software requirement. Requirement traceability matrix will help in finding the untested functions of the application.
14. Group Similar Test Cases
A test run is a collection of test cases that testers should execute in a particular order. Test cases are often grouped in test runs. It’s preferred to put preconditions at the beginning of a test run rather than inserting them into each test case.
Actually, only a few of the test cases need preconditions, so the field is often left empty. A test management tool will help to customize your forms and create a test case template which will save your time and effort when writing test cases. Another thing to keep in mind is to avoid writing the same instructions several times by moving repeated preconditions to a test run.
15. Easy to Understand
The test cases should be well defined with comments where ever needed so that any other software tester can work on it in the future. Whatever project you work on, when designing test cases, you should always consider that the test cases will not always be executed by the one who designs them. Therefore, the tests should be easily understandable and to-the-point.
In a scenario where the person who wrote all those test cases leaves for some reason and you have a completely new testing team to work with, the entire effort spent during the design phase could go down the drain.
16. Test Case Description
In the description, the testers need to mention all the details about what is going to be tested, what needs to be verified, the test environment and test data.
The information mentioned below should be there in a well-written test case description:
- Test to be carried out
- Testing tools
- Test Environment Details
- Behavior being verified
- Any dependencies like preconditions and assumptions
- Test Data to be used
17. Maintenance and Update
All the test cases should be updated with the new requirements so it’s easier to execute them in the future if there is a need. Even if some other tester wants to use the test case he/she wouldn’t have to go through the details of the script.
Conclusion
The tester needs to have good domain knowledge and should write presentable test cases from the users perspective. A good test case template will make it easier for testers to write good test cases. If there are only a few test steps, consider making a checklist instead and have a look at some relevant test case examples before working on your test case. A test case example will be helpful in creating test case templates too. A test management tool will definitely help in improving the way test cases are created and managed.
Related Articles:
May 4th, 2023 by Suyash Dubey
In the year 2028, there will be around 7.8 Billion mobile users which accounts for 70% of the world population. More mobile users mean more apps and more competition and to lead the competition we need to make sure that our app is flawless. If nearly half of the bugs in your mobile app are discovered by the users, your app’s ratings are going to decline and so are the downloads. This is why the right choice of mobile app testing techniques must be followed in the decision-making process.
Mobile App Testing Strategies
Today, the mobile app market is highly competitive. To be better every day and survive for long, the QA team has to follow a mix of plans that would be responsible for taking the right testing decisions. The testers have to formulate testing strategies to face every situation fearlessly and immaculately. Mobile apps have to be perfect before reaching to the end users so there have to be certain decisions to be taken regarding the testing plan. The following model of mobile app testing plans can be considered for better execution.
In the planning Stage, decisions like Selection of Device matrix, Test Infrastructure (In-house vs. Cloud, Simulator vs. Real device), Testing scope, Testing Tools, Automation (Framework/Tool) are taken. Since it is the first stage, it is the most important one as all the further stages would depend on these decisions. In the next stage which is execution and review, decisions regarding Test Case Design, Testing of user stories, testing types as per Sprint Objective, Progressive Automation, Regression Testing, Review and course correction are taken.
We are going to discuss the planning stage aspects more elaborately
Device Matrix:
It is an important factor, choosing the device as per your target audience’s behavior matters in decisions regarding resting. There are different approaches to the selection of the device matrix.
Approach 1- Selection of Devices based on market research.
Determine the set of devices with your target operating System that will have the highest occurrence of accessing your application by using app purchase data and analytics. For Example- if you support both Android and iOS, and your application will be used across millions of Samsung, Google Nexus and Moto G devices but only thousands of iPhones, you prioritize testing on the Google Nexus and Moto G above the iPhone device. So, this test plan will consist of testing on devices which are prioritized by your market analysis.
Approach 2: Categorize the devices based on Key mobile aspects
This approach highlights the categorization of the devices based on certain mobile aspects which can be considered in formulating the testing strategy. The categorization goes as:
Test infrastructure
This is another element of the planning stage. This focuses on Strategizing on the Infrastructure components like hardware, software, and network which are an integral part of test infrastructure. It ensures that the applications are managed in a controlled way.
Real device, Emulators or Mobile cloud-Where to test?
Choosing the right platform to test as per the testing needs is very important i.e whether to test on the Real device or an emulator or on the cloud
Real Devices
Testing on a real device is anytime more reliable than testing on a simulator. The results are accurate as real-time testing takes place on the device in a live environment. It carries its own disadvantages as it is a costly affair and not all the organizations are able to afford a complete real device laboratory of their own.
Pros:
Reliable- Testing on Real devices always gives you an accurate result
Live Environment- Testing on real devices enables you to test your application on the actual environment on which your target audience working on. You can test your application with different network technologies like HSPDA, UMTS, LTE, Wi-Fi, etc.
User experience- Testing on Real devices is the only way to test your Real-time User experience. It cannot be tested through Emulators or devices Available on Cloud.
Cons:
Maintaining the matrix- You cannot maintain such a huge matrix of mobile devices in your own test lab.
Maintenance- Maintaining these physical devices is a big challenge for organizations.
Network providers- There are more than 400 network providers all over the world. Covering all these network providers in their own test lab is impossible.
Locations- You cannot test how your application behaves when it is used in different locations.
Emulators
The emulator is another option to test mobile apps. These are free, open source and can be easily connected with the IDE for testing. The emulator simulates the real device environment and certain types of testing can be run on it easily. However, we cannot say that the results of emulators are as good as those of real devices. It is slower and cannot test issues like network connection, overheating, battery behavior, etc.
Pros:
Price- Mobile emulators are completely free and are provided as part of the SDK on every new OS release.
Fast- As Emulators are available on the local machine so they run faster and with less latency than Real devices connected to a local network or devices available on the cloud.
Cons:
The wrong impression- Even if you have executed all test cases on emulators, you cannot be 100 % sure it will actually work in the real environment.
Testing Gestures- Gestures like Pinching, Swipe or drag, long press using the mouse on simulators are different in using these gestures on real devices. We cannot test these functionalities on emulators.
Can’t test Network Interoperability- With the help of Simulators you cannot test your application with different network technologies. Like HSPDA, UMTS, LTE, Wi-Fi, etc.
Testing on Mobile Cloud
Mobile cloud testing can overcome the cost challenges like purchasing and maintaining mobile devices. It has all different sets of device types are available in the cloud to test, deploy and manage mobile applications. The tests run virtually with the benefit of choosing the right type device-OS combinations. Privacy, security, and dependency on the internet can be a challenge in this case but it has many benefits that can cater to different testing scenarios.
The organization can choose the right mix of above-mentioned platforms as every platform carries its own advantages and disadvantages. Sometimes a combination of real and emulators is preferred and sometimes all three can be considered as per the testing strategy.
Pros:
Devices Availability- Availability of Devices and network providers is a big gain for cloud users.
Maintenance- When you are using cloud services. Forget about maintenance. These providers take responsibility for maintaining these devices.
Pay per use- You don’t need to buy a device. You only have to pay for the duration you use that device.
Parallel Execution- You can test your complete test suite on multiple devices.
Cons:
Cost- Some providers are a bit costly
Automation Tools for Mobile App Testing on Android and iOS
Nowadays, there are so many automation tools available in the market. Some are expensive and some are freely available in the market. Every tool has its own pros and cons. Choosing the right tool for testing would reduce the QA team effort providing seamless performance at the same time. We will discuss the best mobile app testing automation tools for iOS and Android platforms in 2018.
1. Appium: It is one of the preferred MAT tools by testers. It is open source and free tool available for Android and iOS. It automates any mobile app across many languages and testing frameworks like TestNG. It supports programming languages like Java, C# and other Webdriver languages. It provides access to complete back end APIs and database of the test codes.
Top Features:
-Appium supports Safari on Ios and Other browsers on Android
-Many Webdriver compatible languages can be used such as Java, Objective-C, JavaScript to write test cases
-Support languages like Ruby, Java, PHP, Node, Python.
2. Robotium: It is a free Android UI testing tool. It supports in writing powerful black box test cases for Android Applications. It supports Android version 1.6 and above. The tests are written in Java language and basically, Robotium contains a library of unit tests. Apart from this, Robotium takes a little more effort in preparing tests, one must work with program source code to automate tests. Robotium does not have play record and screenshot function.
Top Features:
-The tests can be created with minimum knowledge of the project
-Numerous android exercises can be executed simultaneously.
-Syncronises easily with Ant or Maven to run tests.
3. Calabash: It is an open source MAT tool allowing testers to write and execute tests for Android and iOS. Its libraries enable the test codes to interact with native and hybrid apps. It supports cucumber framework which makes it understandable to non-tech staff. It can be configured for Android and Ios devices. It works well with languages like Ruby, Java, .NET, Flex and many others. It runs automated functional testing for Android and ios. It is a framework that is maintained by Xamarin and Calabash.
4. Espresso: It is a mobile app testing automation tool for Android. It allows writing precise and reliable Android UI tests. It is a tool targeted for developers who believer automated testing is an important part of CI CD process. Espresso framework is provided by the Android X Test and it provides APIs for writing UI tests to simulate user interactions on the target app. Espresso tests can run on Android 2.33 and above. Provides automatic sync of test actions with the app UI.
5. Selendroid: An open source automation framework which drives off the UI of Android native, hybrid and mobile web application. A powerful testing tool that can be used on emulators and real devices. And because it still reuses the existing infrastructure for web, you can write tests using the Selenium 2 client APIs.
6. Frank: Is an open source automation testing tool for the only iOS with combined features of cucumber and JSON. The app code needs not to be modified in this tool. It includes Symboite live app inspector tool and allows to write structured acceptance tests. It is tough to use directly on the device but is flexible for web and native apps. It can run test both on simulator and device. It shows the app in action by showing its recorded video of test runs.
Above are a few promising, popular and most commonly used and mobile app testing automation tools. Choice of tools certainly resolves many testing-related problems faster and efficiently. Implementing these tools requires skill and experience and so an organization needs to have a proper testing team in place to make all of this possible.
April 2nd, 2020 by Suyash Dubey
As the world battles with turbulent, uncertain times, most of the workforce across the globe is working remotely. Organizations have acknowledged the importance of remote working as it helps in maintaining business continuity. But in some scenarios, it is difficult to maintain business continuity or distribute resources within the teams while the team is working remotely.
For instance, if you have some physical device infrastructure to test your app on multiple mobile devices, how would you do it? How would you share the devices with other testers and developers in your team working from different locations? Most importantly, how will you make sure that the app works smoothly on all the popular devices? We will address these issues in this blog, so buckle up for some interesting insights into the remote testing advantages that can ensure a better app experience for your users.
1. Abate device fragmentation and ensure better app compatibility with remote testing
Device fragmentation is any testers Achilles heel as it limits their potential of extensive testing. Testing from a physical device lab at this global lockdown situation is not feasible, and testing on a few devices won’t yield good results. But this issue can be rectified by testing on a device cloud. In pCloudy, users can test on multiple devices based on the popularity of devices in a particular region and its penetration to get the optimum device coverage.
Both manual and automation testing can be performed with unlimited parallel test runs remotely on hundreds of real devices. This is also convenient for globally distributed teams, as the users won’t have to wait for the devices to be available for testing.
2. Deliver Better Quality App with Rapid Automation
Enterprises can ensure better quality apps without missing out on any deliveries by leveraging remote devices for automation testing. pCloudy helps in speeding up automation testing with codeless scripting and test orchestration using integrated tools like Jenkins. Capability configurator is a feature in pCloudy that generates the desired capability based on a set of filters, which saves time and effort while performing test automation. Integration with popular automation and collaboration tools like Appium, Espresso, Jira, etc., makes it convenient for users to perform automated testing on remote devices.
3. Better collaboration and continuous feedback
In pCloudy, users can manage teams and distribute credits among themselves. The user management feature allows managers to become the system administrator and create teams to allocate the credits to the members according to the task assigned. This helps in user and task as the hierarchy is maintained to distribute workload systematically.
Once the tests are complete, detailed test reports are generated automatically, which can be easily shared across the team. The progressive reports also show the tests failed, passed, and those with errors. This helps in focusing only on the tests that failed and doing a root cause analysis to rectify the issues. Continuous access to a range of devices available for remote testing will provide stability to your CI/CD pipeline.
4. Assured data privacy and security
Enterprise-grade security gives assurance to our users that their data is safe on the cloud platform. Our data centers comply with internationally recognized security standards like ISO27001, SOC2, and SSAE-16. Keeping your security issues in concern, we have another useful feature called Wildnet. This feature enables you to test your internal sites or apps on your local network, keeping all your data and information secure.
5. Advanced features to improve manual testing
Take advantage of next-gen features like Certifaya, an AI-powered autonomous testing bot to save time and effort. FollowMe is another feature that enables the user to run a test on multiple devices in parallel. This will save your resources while reducing the testing time by multifold. Apart from this, there are many features in pCloudy, like taking screenshots, recording the test video, cross-browser testing, etc. that will make manual app testing a piece of cake.
In a Nutshell
Remote testing is convenient, and it will help you save big bucks while you deliver a better quality app in less time. Continuous access to numerous devices helps in accelerating automation testing, as the app can be tested on multiple devices in parallel. All these advantages of remote testing make it the optimum choice for enterprises.
December 2nd, 2019 by Suyash Dubey
By concentrating our efforts upon a few major goals, our efficiency soars, our projects are completed, we are going somewhere. This quote by Michael Korda signifies the importance of organizing our efforts to gain better efficiency at work. In mobile app testing, efficiency can be achieved by using a multifunctional tool like Jira and pCloudy. pCloudy is integrated with the Jira bug tracking tool to make it easier for testers to log bugs in Jira from pCloudy. Let’s get an overview of Jira and how it can be used for multiple purposes.
An Overview of Jira Bug Tracking
Jira is an open-source tool used for project management, bug tracking, and issue tracking. Jira has many features and functions that make issue handling easy. Customizable reporting allows you to monitor the progress of your issues with detailed graphs and charts. Jira has four major functionalities, project, issue, component, and workflow.
A Jira project is a collection of issues and it is identified by a name and a key. The project key is added to each issue associated with the project. Workflow helps in mapping your business process. So now let’s understand how to use the Jira bug tracking tool and its components.
Jira Workflow
Jira has a function called workflow which is used to make a blueprint of the procedure in any organization. The workflow can be customized to suit the project, issue or any subtask. The Jira defect workflow comprises of colored blocks that represent the status of the task and lines that represent transitions.
Users can build their own workflows from scratch or download the prebuilt workflows and then customize them. Approval requests can be set for users to make changes in the tasks and task status can be set to change with transitions automatically.
Status shows the position of an issue within a workflow and transitions are the bridges between the status to represent how an issue moves from one status to another. Resolution tells why an issue changed from open to close and condition control who can perform the transition. The assignee commands the responsible member for any particular issue. Validator ensures that the transition can happen given the status of the issue and Jira can recognize some properties on transitions.
Creating an Issue in Jira
An issue is the building block of the project and components are subsections of a project used to group issues in smaller parts in a project. To create an issue you need to click on the plus sign located on the left side of the screen. A new window will pop up where you need to fill in the details about the issue that you are creating.
The first step would be to choose the project that the issue is associated with. Just below that is the issue type where you need to select if it is a task, an epic or a story.
Then add a summary about the issue and assign the issue to your team members. Next, you need to choose the priority and add a label to the issue. Once that is done, You can now add a detailed description of the issue to make sure that you and your team members are on the same page.
Below the description, you will find Components dropdown and the Environment where you need to fill in the details appropriate for the issue like Hardware specifications, OS, software platform, etc.
You can also attach files related to that particular issue by clicking on the attachment section and then click on Create to create the issue.
Jira Reports
Jira generates various types of reports on the basis of workflows, issues, task status, and other data fed in by the team. You can track the total work remaining in the burndown chart and manage the progress accordingly. A burnup chart will help in tracking the total scope independently from the total work done. In the sprint report, you get an idea about the tasks that are completed and pushed backed to the backlog in each sprint. Apart from this, there is a cumulative flow diagram, velocity chart, version report, etc.
Users will also get an issue analysis report for a better understanding of the resolved and unresolved issues.
pCloudy integrated with Jira Bug Tracking
pCloudy has the option to log bugs, save screenshots and videos of the test actions. But if you want to use the Jira bug tracking system to log bugs then you can to that though pCloudy as well. Just click on the profile ID and the top right corner of the pCloudy screen and select the user setting from the dropdown list.
In the user setting page click on the JIRA Logs tab. Enter the URL, Email, API Token and login to log bugs in Jira.
This way you can maintain a separate bug log to share with the team apart from the one in pCloudy. pCloudy also generates reports like Jira and those reports can be shared across your team.
Jira supports both Kanban and Scrum agile methodologies. As a matter of fact, scrum is much more popular these days as it gives the project team to plan their work in detail prior to starting the project. When the scrum board is created, a list of items is added and then sprints and versions are created to move the issues from backlogs to sprints. With Kanban, users can start without having a detailed plan and in these issues can be created but that cannot be moved to sprints as we do in the scrum.
Conclusion
There are many uses of Jira in mobile app testing. It’s not just about handling issues or creating workflows, Jira project management is helping the world’s most known brands in the world. If you understand the Jira bug life cycle and follow the Jira bug tracking best practices, it becomes much easier to scale up your testing efforts. Jira bug tracking, when combined with pCloudy, can save your time and resources.
