Roles: Test-Engineer

"Area Path" and "Iteration Path" are standard fields in Azure DevOps (ADO), and they are used to organize work items by product classification, team, and time period.

This guide describes how bugs – when they are created in Azure DevOps (ADO) – also are classified to ensure that they are handled with regards to their severity and potential impact.

This guide provides a quick overview of component tests and when and how they should be used.

This is the overall description of how to handle configuration release management within ABB PCP.

The "Definition of Ready" (DoR) are the checks performed when a system epic, epic, feature, story, or bug is defined and ready to start work on. The "Definition of Done" (DoD) is the checks performed when the work items are completed before it is closed.

The Development Team process manages the planning, prioritization, and visualization of all activities related to the development of software and hardware components. There are multiple development teams in each development stream.

Division testing (DT) is an optional testing stage carried out with ABB divisions (e.g., PAEN, PAPI, PADI) during the project if it is relevant to the respective product or system release.

The purpose of this guide is to provide handson support to the roles involved in setting up a test plan and test suites in Azure DevOps (ADO), demonstrating the product's test coverage.

This guide describes how to use Markdown to document technical information using the Azure DevOps (ADO) wiki. The Markdown files can be reviewed, approved, and baselined with the code. The code and technical documentation can be restored from the same baseline when a released product needs to be updated.

This guide provides handson support for the roles involved in executing test cases and reviewing test results.

Introduction

During the development of a release, if a bug is found but the CCB decides to fix it in a later version, the bug is deferred. After the official release, it will then be a known bug in the product or system.

A work item of type "Bug" can be used to suggest an enhancement, something that is not a real defect, but an idea for improvement. This guide describes how to handle enhancements as bugs.

A bug is an unexpected problem in the software or hardware which can be reported for any issue in a product by e.g. product managers, product owners, test engineers, or customers (via L3 or L4 Support).

For a new epic, feature, or user story, there may be a need to write new test cases or modify existing test cases. The purpose of this guide is to provide handson support to the roles involved in writing, updating, or reviewing test cases of a product.

This guide provides an overview of Kanban and its application to software development teams.

This guides includes general information about performance testing and a brief description of different types of performance testing.

The product test verifies that the product to be released has acceptable quality. It applies to new products and maintenance/updates of existing products.

A regression bug is a bug that causes a completed feature that worked correctly to stop working after updates (e.g., system upgrade, system patching, or bug fixes). This definition applies both before and after releasing the feature to customers.

This guide describes how Scrum can be used by teams to manage their work. Scrum is a framework that implements the principles of Agile as a concrete set of artifacts, practices, and roles.

This guideline describes the custom standard fields used in bug templates. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guideline describes the Document Update work item type and the custom standard fields used in its template. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guideline describes the custom standard fields used in the Epic template. For a more general picture of the standard work item template change process in Azure DevOps, see the ADO standard work item template change management process.

This guideline describes the custom standard fields used in the Feature template. For a more general picture of the standard work item template change process in Azure DevOps, see the ADO standard work item template change management process.

This guideline describes the fields used in the system epic template.

This guideline describes the custom standard fields used in the Test Case template. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guideline describes the custom standard fields used in the User Story template. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guide describes what system interfaces are, how they are documented, and how they are managed.

The system test is a crucial step in the development process as it integrates and tests deliverables from the various development streams.

The system and products are integrated and tested to provide stakeholders with information about the quality of potential deliverables or releases.

Test case audit checklist.

The test engineer develops tests (test cases, test methods, test applications), performs the tests, reports the test result, and verifies the symptoms of reported defects.

This guide gives an overall view of the test performed before a component, container, product, or system is released.

The test phase checklist is a general guide for users to gauge the quality of product build delivery before starting tests in system test (ST) or RAT. Further, tailoring can be done to align the checklist with any specific product.

This guideline briefly describes test techniques used at the different test levels. Each project defines the test levels and when to use the various test techniques.

This guide gives an overview of what a unit test is, and when and how it should be used.

This guide provides valuable tips to anyone involved in creating unit tests. A good unit test should be easy to understand, reliable, quick to run, and without dependencies.