QA must follow a checklist for production release readiness - Fleek IT Solutions
16414
single,single-post,postid-16414,single-format-standard,ajax_fade,page_not_loaded,,qode-title-hidden,qode-content-sidebar-responsive,qode-theme-ver-9.5,bridge-shared-by-themes24x7-com,wpb-js-composer js-comp-ver-4.11.1,vc_responsive
production release - Fleek IT Solutions

QA must follow a checklist for production release readiness

Almost every project have its own process to manage their release cycles and deploying updates to the production server. QA team is an integral part of every production release and it is the utmost duty of the QA team to make sure that we are deploying the correct release to production and doing it correctly. No one could ever afford to have a mess after the production release and even worse if we cannot fix or revert it.

We (Fleek IT Solutions) adhere to strict rules and policies while making any production release which consists of a number of specially designed checkpoints by our team and agreed with the every project stakeholder. We perform a thorough regression test cycle which covers the complete analysis of the functionality, impact analysis, bug fixes, improvements, logs, UI/UX, data migration, versioning and lots of other factors which depend on the agreed deployment process. Our dedicated team is available during all phases of the release cycle, and provide QA support before and after the release. As per our commitment, we keep monitoring the production system even after several hours of release to make sure nothing goes wrong.

Are you ready to deploy the release on the production server?

A very common question being asked to the QA team during the release process. In order to answer this question with confidence, there are few points that a QA team should keep in mind during the test cycle.

  1. Are you clear with the scope and the requirements of the release? Lack of scope definition can lead to insufficient or over testing which may lead to either inefficient test results or missing the deadline for the release.
  2. Do we have all the required resources or tools available to us for the testing of the release? The resources or tools may include the pre-defined test scripts, virtual machines, application builds and so on.
  3. Do we have enough understanding of the features, improvements or bug fixes that we are going to release?
  4. All functional tests executed (manual and automated) and no blockers defects present in the release?
  5. All regression tests executed (manual and automated) and passed successfully?
  6. All backward or forward compatibility tests executed?
  7. Do you have a rollback plan in place? Have you tested this rollback plan?
  8. Do you have a complete list of configuration options that are added/updated with this release? Have you verified this release with default configuration options?
  9. Load test executed and successfully passed all performance parameters?
  10. Have you tested this release on pre-production or staging environment?
  11. Was there any migration scripts involved in this release? If yes, have you tested these migration scripts on the replica of production database?
  12. Have you prepared the open defects list and shared with stakeholders for approval as known issues?
  13. Have you reviewed the release notes to make sure all features are covered and known issues are well documented?

When should we call the production release as a success?

There are several factors and checkpoints that the QA team should validate when calling the production release as a successful release. Some of these checkpoints could be :

  1. It is not always possible to verify all new features, improvements and bug fixes on the production environment. However, QA should verify as much as possible to make sure all changes deployed successfully?
  2. If you have access to production logs then make sure there is no errors or exceptions being logged after production deployment. Otherwise, you can ask devops or any responsible person production logs verification.
  3. All automated tests and monitoring tests should be passed successfully.
  4. Post-release activities should be completed by all stakeholders. For example, Publishing the documentation and release notes, publishing installation packages etc.
  5. Release announcement broadcasted to all the users and customers.
  6. QA along with devops should keep monitoring the production environment for the next 24 hours to make sure that nothing unexpected creeps in.
No Comments

Post A Comment