Throughout the development workflow, sometimes it’s required to reopen tickets in Jira. This could be due to acceptance criteria not being met, implementation details being missed, bugs arising due to the changes, or something not working as expected. Regardless of the reason, it is sometimes unavoidable to reopen tickets in order to achieve the work item and pass the ticket as done. In this blog, we’ll walk you through some of the reasons why a Jira ticket could be reopened and how code review could help prevent reopens.
Wrong Implementation or Missing Ticket Requirements
At any time during the Jira workflow, if we feel like the work completed does not match the expected requirements of the ticket, the ticket should be reopened and the discrepancies addressed. Reopening the ticket is the best way to track the amount of work put in, actual costs, and time spent.
Ticket failing QA
Once a ticket gets to Quality Assurance testing, the tester will be testing the actual functionality of the work item. Some scenarios in which we should reopen the ticket at the QA stage include:
- Feature is not working as expected
- Feature is breaking on different browsers and devices
- New changes have introduced regression bugs
Code not meeting the set Standards
A main reason for a ticket being reopened in Jira could be that the code does not meet the set standards. A code review checklist is one of the most important steps we can take to make sure that the code that is being pushed meets requirements. With a code review checklist in place, we can be more confident that the code will meet the set standards and requirements of the work item. The list of checks which should be included in the code review checklist are:
Look for obvious bugs:
Checking for bugs is the most important step that the code reviewer takes while checking the code. Even experienced developers can write code that sometimes has defects. Often, those defects are quite trivial: an off-by-one error, a misspelled variable, parameters passed in the wrong order to a method, and so on.
Code reviews offer a great opportunity to catch these defects because while the developer may miss them, a code reviewer with a fresh pair of eyes may spot them more easily. This allows for defects to be addressed before the ticket ever gets to quality assurance testing.
Look for possible Security loopholes
The next most important step that the code reviewers should take while reviewing pull requests is to look for security loopholes in the code. Some items that needs to checked are:
- Cross-Site Scripting (XSS): Lack Of Input Sanitization
- SQL Injection: Writing SQL Queries Directly In PHP Code
- Missing Route Permission And Access Checks
- CSRF (Cross-Site Request Forgery)
- File Uploads: Allowing File Uploads To Unprotected Directories
- Distributed Denial-of-Service (DDoS) Attacks
Check for Code Duplication
As a code reviewer, one should look for areas of improvement in the form of code optimization. Instead of writing the same line of code again and again, we should check if we can create generic functions and use that in the code. This has huge advantages such as the following:
- Merging duplicate lines of code simplifies the structure of the code and reduces file size
- Increases the maintainability of the code and reduces the technical debt over time
- Reduction in the number of security vulnerabilities
- Keeps the code clean which in turn helps in providing feature support and new updates quickly.
Check Whether Names Are Descriptive Enough
Naming is one of the hardest things in software engineering, but that doesn’t mean we should give up. When performing a code review we should look for opportunities to improve the names of variables, constants, class fields and properties, methods, classes, and so on.
Look for Possible Performance Improvements
Performance improvements can be simply monitored by checking:
- An expensive operation inside a loop
- Excessive allocations of objects
- Inefficient string concatenations
- Inefficient logging
- Optional: Code Documentation
- Adding proper comments in the code helps the reviewer to understand the code and provide correct and quick feedback.
Note: In a scenario where all of the requirements of the ticket have been met and we see the functionality of the requested feature in place, the ticket should not be reopened. If a regression or bug is noticed that is outside the scope of the ticket, a new ticket should be created and the old ticket should be linked to it for reference. No ticket should be reopened for new requests that are out of the scope of requirements.
Conclusion
Throughout the development workflow, it is sometimes necessary to reopen tickets in Jira. Maybe the requirements weren’t met, the acceptance criteria wasn’t clear, or there were some issues in the code. The longer that teams work on projects together, the greater the efficiency; however, there still may be scenarios where a ticket has to be reopened. By following a standard code review process, we can help mitigate reopens and address issues before they get to QA, thus reducing the amount of reopened tickets.
