The Quality Engineering Charter

<curated with love for software quality engineering> and <experience>

The intent of this Quality Engineering (QE) charter is to share insights gleaned from my own journey in Software Quality Engineering.

Processes

The team should focus on the five basics when we talk about processes:

1. Test Planning

• Gather requirements of your project and create a test plan as needed. Ensure that your project has a pre-production environment for you to test the application. Don’t hesitate to ask for it, be vocal!
• Practice Shift Left strategy and get involved in the conversations with the developers and PMs about the future roadmap of the project and your scope of testing.
• Share your thoughts on Test Automation and what tech stack you think would be the best for your project needs.

2. Test Execution

• Write detailed comments. While testing a particular issue, make sure that you add all the relevant details and steps you took to test the issue so that the Developer(s) have clarity on what was tested. Recommended style of comments in Jira or any other issue tracking tool:
  ✅ :<this functionality worked as expected>
  ❎ :<this functionality did not work as expected>
  ℹ️ : <need more clarification>
  Attach screenshots in the comments inline as thumbnail for better readability.
• Advocate strongly that the task/issue should have Acceptance Criteria and/or Testing Instructions(if any needed) before it reaches the ‘Ready for QA’ column.
• Ensure that the relevant documents and Merge Requests are linked.
• Create a new issue to capture the scope of Test Automation so that you can prioritize it soon after and there is no test automation backlog in the long run. You can use the prefix [TA:Test Automation] to differentiate from other tasks on the board.
• If you find a bug/issue, create a new issue(Jira) and make sure to link it to the original one.
• If an issue has been identified by the Test Automation run, you can create and add a label ‘Detected_by_Test_Automation’ to give your test automation suite more visibility.

3. Test Reporting

• Make sure that the test reports are attached to the CI system that your team uses. The link to the test report should be easily accessible from the repository, maybe add a reference to it in the README file.
• The Test reports should be able to give an overview of the test run, the passing and failing tests.
• You can explore integration with ReportPortal for better Test Automation Dashboard.

4. Raising bugs/Defect Tracking

• While raising a bug/issue, it is recommended to include the three sections: Steps to reproduce, Actual results, Expected results.
• If there is a Development task associated with the bug you found, make sure to link it.
• If the issue is high priority, don’t hesitate to tag the PM or any senior developers or senior QEs on the team for better visibility and prioritization.

5. Continuous Improvement

• Continuous Improvement is the essence of QE workflow, make sure to look for the scope of improvement in your current workflow.
• General improvement areas: Test Automation coverage, Detailed Jira comments, Dev: QE communication gap, latest test automation trends and how you can include them in your current workflow.

Tools and Resources

Testing Tools: The QE team to align with the developers and other QEs while selecting a tech stack for their project. If there are more than one testing tools and programming languages being used withing the team, it’s worth having a spreadsheet with all the details. In addition, if you are looking for boiler plate test automation repositories you can find some at The Test Trove and also contribute more. We are looking to build a community.

Documentation

Every team is required to maintain pertinent documentation, encompassing:

• Project overview and objectives
• Stakeholders and use cases
• References to test automation and development code repositories
• Guidelines for executing tests on local machines
• Links to any available demos

Test Automation

Here are a few key points to keep in mind while creating a test automation repository or adding test cases to an existing test automation repository:

• While designing a workflow for a test, try to write independent tests so that a user can run an individual test along with the entire test suite run.
• Think of e2e user scenarios while automating test cases. It is recommended to categorize the test cases using tags such as smoke, e2e, functional, regression.
• Follow the DRY principle ‘Do not Repeat Yourself’, try to modularise the test suite using Page Object Pattern, write reusable functions, avoid sleep commands.
• Use the latest version of packages and dependencies, make sure the test repositories have a package.json or similar with versions specified.
• Design your tests in such a way so that you can run your tests in parallel to save on test execution time. It’s a huge win!
• All test automation repositories must have READMEs. Sample README: https://github.com/redhataccess/cheesecake-ui-tests
• Add a linting tool such as ES Lint or PyLint for each test repository to align with the coding style standards.
• Follow a practice of PR reviews with peer QEs or developers.
• Make a conscious effort to keep the git commit history clean; explore the commands git squash, git rebase, git reset and others.

Releases

Managing releases depends on the team’s workflow and preferences. You may choose to disseminate information about recent releases via email or newsletters, using various formats to effectively communicate the updates.

Communication

It is highly encouraged that the QE team be vocal of their wins and communicate the same to the wider group including PMs and developers. Some examples of minor or major wins can be:

• The test automation run (as a part of your CI/CD pipeline) identified a bug.
• Any major bugs identified.
• Any high complexity tasks you tested and the effort involved.

Always feel free to communicate your thoughts to the team on what you think from an end user’s perspective vs the proposed workflow of an application.

Thank you for reading and I hope this helps. I recently transitioned into a new role expanding my scope beyond Quality Engineering and wanted to publish this story since it has been in my drafts for over 10 months now.

< feel free to reach out for any queries or share your opinion>