Numerous articles, blog posts, and videos have been written on the subject of QA (Quality Assurance or Quality Analysts) vs QE (Quality Engineers) and the many other Quality roles that exist. However, many of our clients and prospects find the overlap and differences between these roles confusing or unclear. We share the CodeScience Quality journey to help explain them.
The most common roles we utilize at CodeScience are the QA and QE. Although some may consider these roles similar or even the same, we implement them as two separate but complementary roles. Before we dive in, let us define QA and QE per Codescience’s standards.
QA: Quality Analyst – one who ensures/maintains the quality of a product by executing on CodeScience’s quality procedures.
QE: Quality Engineer – one who automates quality procedures to minimize manual testing efforts.
How Agile Has Transformed the Role of a QA
The traditional waterfall methodology implemented the QA role as reactive — detecting bugs, measuring, documenting, and reporting findings and presenting the impact to the development team. The Agile framework transformed the focus of this role, in concert with the new QE role, into defect prevention — making the role more proactive and instilling quality into software development process from the beginning of the product development lifecycle.
The work of QA and QE may vary from client to client, between projects and project phases.
Same Goal, Different Focus
While the end goal of a quality product is the same for both roles, the focus of the QA and QE are different. The QA role focuses on delivering a quality solution through planning and executing on the quality standards. Where the QE focuses on automating manual, repeatable tasks to make the process more efficient and less error-prone.
In the Agile development process, the role of the QA starts when planning starts. The QA role is needed in every phase of the product development lifecycle and is responsible for:
- Creating test plans, sprint planning, release planning, and participating in ceremonies as the testing subject matter expert.
- Backlog Management — creating and grooming stories by identifying missing Acceptance Criteria and edge cases.
- Communicating the testing status during daily stand-ups and executing functional tests when a story is developed.
- Testing both functionality and behavior as well as continuously documenting bugs and working closely with developers during retest and issues finding phases.
- Identifying regression test cases for the application, browser related test cases, mobile test cases, UX, performance, and security test cases.
- Working with the client team — providing test steps for acceptance testing, analyzing and coordinating issues found through testing, and classifying them as bugs or enhancements.
- Manually setting up environments.
The QE role, on the other hand, works closely with the QA or the Product Owner (PO) to:
- Identify the test cases that are executed repeatedly.
- Identify the tests that involve multiple browsers, devices, and different versions of operating systems.
- Identify end-to-end test cases.
- Automate the identified test cases with the help of the automation testing frameworks/tools.
- Address most of the challenges of manual testing.
- Automate the tests to be executed in the continuous integration (CI) process when builds are deployed in various environments.
- Identify bugs as a result of automation test failures and re-run tests after resolution of failures.
A QE is needed in every project where there is continuous implementation of functionality, where the previous implementation is regularly regression tested, and where automated test scripts are included in the “definition of done”.
The Challenges of Manual-Only Testing
If you’re curious as to why you would automate your testing, we’ve discussed the challenges around manual-only testing and why automation is important for your project in our post — How Automated Testing Can Streamline Your Build.
Here are 3 points for your consideration.
- Time: Comprehensive tests take days — if not weeks — depending on the size of the test suite and complexity of tests. Time is the constraint.
- Repetitiveness: Repetitive smoke tests and regression tests — which sometimes occur up to 2 or 3 times during the release/delivery process — can take a significant amount of time when timelines are critical.
- Speed: Test automation increases speed in the delivery process. This is especially true when a hotfix is needed. If it’s not possible to do a full manual regression in the shorter timeline, automation can make it possible.
Working Together Builds Quality Products
Traditional waterfall development used the QA role as a mere detection mechanism for defects prior to deployment. In the Agile world and at CodeScience, the QA and QE roles work hand in hand from the start of the development lifecycle to embed quality into the development process. This ultimately transforms the end product’s quality and shortens the user acceptance testing (UAT) cycle.
It is critical to understand the difference between the QA and QE roles in order to effectively implement them on projects. Each role should be compared with the goals of a project for best fit. The key to success when implementing a QA and QE together is that they support each other by adhering to the highest quality standards, with the delivery of a quality product.
Thank you so much to Carla Kossally of our Expert Services team for reviewing the post and for the valuable suggestions!
CodeScience has the experience to get your app to market fast. Learn more at www.codescience.com/services.
