Syensqo IS - Customer Support

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Table of Contents


  • Testing Strategy Definition

    • Overview of Testing Strategies
    • Importance of a Defined Strategy
    • Components of a Testing Strategy

  • Defining the Testing Process

    • Key Steps in the Testing Process
    • Roles and Responsibilities
    • Entry and Exit Criteria

  • Managing Test Plans

    • Overview of Test Plans
    • How to Create and Update a Test Plan
    • Managing Changes to Test Plans

  • Test Scripts Repository

    • Defining a Test Scripts Repository
    • Organizing Test Scripts
    • Version Control for Test Scripts

Test Repository :: This will be our test case Library with following limitation ie test repo is a project level feature, so each test repository can only contain test from its projects (we cannot mix tests from multiple projects into a single repository and organize them together)

All test cases which we create end up in Test Repo by default.


Test Sets :: Is a group of tests , we can consider this to be the equivalent of a single folder inside the test repository.

Test sets are more flexible than test repository and that a test set can contain tests from multiple projects and a single test case can live in multiple test sets.

Under test sets we create All E2E , Regression tests , Test Release plans.


Following are Agreed by Dina ::

Test Repository Decison:

  • Folders - will be used to structured the repository by Application >> Process >> Test Type - this folders will contain all test scripts that will be created by BAs, QA Lead will maintain the structure, and Test Scripts cannot be cloned.




  • Test Sets - will be used to include all scripts needed for a certain release, this will be managed by QA Lead

  • Test Sets will contain the regression pack, EtE test per release, this will be managed by QA Lead






  • Test Plan - Create test plan according to Monthly Releases for INT and UAT & Prod testing i.e





  • Test Executions - Test Executions are created as children under Test Plan and will be by Release and Envoirment: INT, UAT, PROD (Sanity PROD), this will be managed by QA lead.


The BAs will need to create or update test scripts, identify if the test Script needs to be executed for a certain release by adding or updating the fix Version >> this will allow QA lead to create the Test Sets, Test Plan and Test execution.


  • Test Executions

    • Types of Test Execution
    • Monitoring Test Execution Progress
    • Handling Test Execution Failures

  • Bug Reporting

    • Guidelines for Reporting Bugs
    • Information to Include in a Bug Report
    • Bug Reporting Workflow

  • Bug Creation

    • How to Create a Bug Report
    • Common Bug Types
    • Tools for Bug Creation

  • Fixing a Bug

    • Steps in Bug Fixing
    • Coordination with Development Teams
    • Verifying the Bug Fix


Once a story is created on Jira, the testing process generally follows these steps:

  1. Story Refinement Session: A story refinement session is a collaborative meeting where the development team, product owner, and stakeholders review and clarify user stories in the product backlog. The goal is to ensure that stories are well-understood, properly scoped, and ready for upcoming sprints. During the session, the team clarifies requirements, estimates effort, discusses technical challenges, reviews and refines acceptance criteria, and prioritizes the stories. The outcome is a set of clearly defined, estimated, and prioritized stories that are ready for development, helping streamline the subsequent sprint planning process.


  1. Test Case Design: Test Case Design involves QA engineers creating detailed test cases that outline how to validate a story's functionality. These test cases cover all possible scenarios, including both expected (positive) outcomes and potential errors or edge cases (negative scenarios). Each test case is carefully linked to the relevant user story in Jira, ensuring traceability and making it easy to track testing progress and results against specific requirements.

Naming Convention for Test Description of a test case (This helps in identifying the test case related to the story in test)

Ex :: iCARe_Story Number :: Description of Test / Core_Story Number :: Description of Test

iCARe_CCCME-1234 :: Verify that the user successfully logged into iCARe application.

Core_CCCME-6789 :: Verify that the user successfully logged into Core application.



  1. Test Execution: Once the development is complete, and the code is deployed to the testing environment (usually in the Integration Testing (INT) phase), the QA team executes the test cases. Any issues or bugs encountered are logged as separate Jira tickets, The story is marked as failed and the bug is linked to the original story, and assigned to the relevant developer.

Naming Convention for Bug Description (This helps in identifying in which env the bug was raised).

Ex :: INT_iCARe :: Description of Bug/ INT_Core :: Description of the bug

INT_iCARe :: User unable to log into iCARe application.

PO Testing :: After Integration Testing (INT) is a phase where the Product Owner (PO) personally verifies that the completed story meets the business requirements and acceptance criteria before it moves to User Acceptance Testing (UAT). During PO Testing, the PO reviews the functionality to ensure it aligns with the expected outcomes and overall product vision. If the PO identifies any issues, they can request changes or adjustments, and any bugs found are logged in Jira for the development team to address. Once the PO is satisfied with the implementation, the story is typically approved to proceed to UAT.

  1. Bug Fixing and Retesting: Developers work on fixing any reported bugs, updating the status of the bug tickets in Jira (e.g., from "Open" to "In Progress," and then "Resolved/ Done"). The QA team then retests the fixes and updates the status of the bug tickets accordingly.

Once the bug is passed and closed, QA Team retests the associated Story and marks its status accordingly.

  1. User Acceptance Testing (UAT): User Acceptance Testing (UAT) is the final testing phase, where the story is validated by business users or stakeholders after it has passed Integration Testing (INT). In UAT, these users ensure that the implementation meets the defined acceptance criteria and aligns with business requirements. If any issues or bugs are discovered during this phase, they are logged in Jira, where they are tracked, updated, and reassigned to developers for resolution. The process continues until the users are satisfied that the system functions correctly and meets their needs, signalling that the story is ready for production.

Note :: The bugs raised on UAT should also be tested in lower environments i.e INT.

Naming Convention for Bug Description (This helps in identifying in which env the bug was raised).

Ex :: UAT_iCARe :: Description of Bug/ UAT_Core :: Description of the bug

UAT_Core :: User unable to log into Core application.

Jira Bug Status and Associated Roles

  • Open/New

    • Role: Reporter (could be a QA Engineer, Developer, or User)

    • Description: A new bug is reported and logged in Jira. The bug is in the queue, awaiting triage or assignment.

  • Triage/Backlog

    • Role: BA, Project Manager (PM), Product Owner (PO), or Lead Developer

    • Description: The bug is reviewed for severity, priority, and assignment. The decision is made whether to work on it immediately or add it to the backlog.

  • In Dev

    • Role: Developer

    • Description: The assigned developer starts working on the bug fix. This stage involves coding and preparing a solution.

  • In Review/Code Review (Optional)

    • Role: Peer Developer or Lead Developer

    • Description: The fix is completed and the code is reviewed by another developer to ensure quality and adherence to standards.

  • Ready For QA

    • Role: Developer / Test team

    • Description: The bug fix is complete and marked as Ready for QA. The resolution is ready for verification, typically by a QA Engineer.

  • IN QA

    • Role: QA Team

    • Description: The fix is tested by the QA team to ensure it works as expected and doesn’t introduce new issues.

  • Closed/Done

    • Role: QA Engineer or Product Owner

    • Description: After successful verification and testing, the bug is closed, marking the end of its lifecycle.

  • Rejected/Won’t Fix

    • Role: Project Manager (PM), Product Owner (PO)

    • Description: The bug is deemed invalid, a duplicate, or is decided not to be fixed. This status is used to close issues that won't be addressed.


Bug Priority :: Low , Medium , High , Critical


Flow Diagram ::



  1. Story Closure: Marks the final step in the development process, where a user story is formally completed and closed in Jira. This occurs after the story has successfully passed all testing phases, including Integration Testing (INT), Product Owner (PO) Testing, and User Acceptance Testing (UAT). The QA team or product owner verifies that all acceptance criteria have been met, all associated bugs have been resolved, and the functionality works as intended in the production environment. The Jira story's status is then updated to "Done" or "Closed," signalling that no further work is required and the feature is ready for release. Story closure also involves ensuring that any related documentation is updated and that the story is archived for future reference.





  • Test Progress Reporting

    • Key Metrics for Test Progress
    • Creating Effective Test Reports
    • Tools for Reporting Test Progress

The best way to get IT support is to use the new Service One Platform.