Crafting a Flawless Software Release

In the world of software development, taking a project from the Product Requirement Document (PRD) to a successful release should involve a well-structured and comprehensive approach but it’s not the case in most organizations. This process, often fraught with challenges, necessitates a coordinated effort to bridge the gap between the Product Manager, Designer, Developers, Copywriter, and Quality Assurance (QA) team.

I’ve organized the steps and provided a detailed breakdown of each stage in the process:

1. Kick-Off Calls:
— Meeting between all the key stakeholders before the product development process begins
— Objective, scope, requirements, timelines, and milestones should be finalized in this call for smooth development later on.

2. PRD Creation and Review:
— Product Manager creates the PRD.
— PRD is reviewed by the relevant stakeholders, and changes may be suggested by the team.
— Finalize the PRD, ensuring that it reflects the agreed-upon functionality.
— PRD with wireframe should come out of this step before starting on Design.

3. Design Phase:
— Designers start working on the user interface (UI) and user experience (UX) design.
— Any changes or additions to functionality during this phase should be communicated and should be updated in the PRD as well.
— Design freeze: Once the design is finalized, make sure that changes are communicated to all team members.

4. Test Case Preparation:
— QA (Quality Assurance) begins writing test cases based on the design and PRD.
— Test cases are reviewed by the Product Manager to ensure comprehensive coverage.
— Share the finalized test cases with developers to consider while coding.
— QA test cases cannot be frozen, but most of the test cases should be covered during this phase.

4. Development and Design Handoff:
— Designers provide a handoff to developers, including all design assets and guidelines.
— Developers review the design to ensure it’s technically feasible and make any necessary clarifications.
— Developers should estimate the timelines and keep them with them for their own tracking.
— Copywriters can work on content during this phase.

5. Development and Testing:
— Developers start coding based on the PRD, design, and test cases.
— Developers update copy and content as needed.
— Developers test against the QA test cases to identify and fix issues, which is known as DevTesting.
— Share the developed feature with QA for the first round of testing.

6. First Round of QA Testing:
— QA tests the feature and logs any defects.
— QA should test the test cases that he has created earlier and map the newly created test cases separately as they should have come up in the first go (Might look aggressive approach on QA, but in the long run, it will just reduce the defects in the team)
— QA should focus on qualitative testing rather than quantitative testing. For eg, Copy update as 5 places should be 1 defect rather than 5 defects.
— QA should map test cases at the end of the day to some category.
— If defects exceed a predefined threshold (e.g., 10), QA communicates with developers to address issues and stop the testing immediately as there is no sense in these tests if it’s full of defects (Saves the time of QA). This shouldn’t come up if the developer has done the proper DevTesting.
— Developers make necessary fixes and retest.

7. Second Round of QA Testing:
— QA performs a second round of testing to ensure all issues reported in the first round have been resolved.
— QA verifies that the changes made to fix defects did not introduce new issues.

8. QA Sign-Off:
— QA provides sign-off on the feature, indicating it meets the specified requirements and is ready for further testing.

9. User Acceptance Testing (UAT):
— The feature is subjected to two rounds of UAT to validate its functionality and usability.
— UAT may involve end-users, stakeholders, or a designated UAT team.

10. Team Testing and Feedback:
— The feature is made available for your entire squad to test and provide feedback.
— Any suggested changes or improvements are considered and, if feasible, implemented.

11. Release to Main Channels/Production:
— After successful testing, including PRD alignment, design, QA, UAT, and team testing, the feature is deemed ready for production.
— Prepare the feature for release to the main channels or production environments.
— Feature Flag and Account Mapper should be kept handy in case the release needs to be reverted.

11. Release Plan:
— Keep everything ready for release, then do a private beta release with very few customers. Address all the bugs raised.
—The reason is if there are some major bugs/security issues, then other customers won’t face issues and reputation will also not get affected.
— Then open it for all the customers.

12. Continuous Monitoring and Feedback:
— After release, continue to monitor the feature in production.
— Collect user feedback, address issues, and make improvements as needed through an iterative process.

The process cannot be followed completely as we are humans and not machines and we try to bypass the process as human beings, but everything should be documented at the place it’s required to be when someone refers back to this. Main goal of the process is to improve the productivity of everyone and things get freeze so the quality of work will also come up.

Please feel free to drop in comments on how can we make this better.

• If you enjoyed this article, please give it a clap and leave a comment. Your support means a lot to me!
  — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Feel free to reach out and follow me on these social media platforms — LinkedIn, YouTube, Twitter, and Instagram.

Or Let’s connect via your favorite medium:
FlowCode: https://www.flowcode.com/page/jainprayush9