The Blog - Expert Thoughts & Opinions

9 Vital Attributes to Excel in Quality Assurance (QA)

The Role of Quality Assurance in Agile methodology

To start let's take a look at a Quality Assurance role. I work as an Engagement Manager here with Pexlify and recently had the opportunity to work as a QA on a major software project for one of our customers. Over the years I have acquired a QA knowledge through different roles throughout my career. My recent experience acting as QA reinforced an often misunderstood role in the world of agile development: how critically important this role is to the successful implementation of a solution.

When I started out in project delivery, projects mainly used the Waterfall delivery methodology. The QA role was usually referred to as the testing role and it consisted of 2 types of positions. 

1. A senior position that created the test strategy and the test plan.
2. A junior role of creating the test cases and executing the test cases.

This was usually quite monotonous and after a few months, many people moved on to other roles and areas. As more and more projects start adopting agile project delivery methodologies, the role of the QA shifted and morphed into one of the most important roles on the team with a very high level of responsibility.

Within a Scrum team, the QA is the person responsible for putting the rubber stamp that “guarantees this functionality meets the business need” on a piece of functionality that was developed. This means that the QA is the person standing between the developer and the deployment of their piece of functionality. They act as gatekeepers to ensure that whatever is being developed is developed to the highest standards and the customer's needs are met. 

For many QA’s out there, this requires a shift in mindset. From only understanding and testing what the developer has developed to understand how the piece of functionality that the developer developed fits into the overall solution. The reason that this functionality has been developed for the business and identifying any gaps within the functionality that need to be rectified to meet the customer requirement. This is a big responsibility.

To succeed with this role, I have put together 9 attributes that I believe are vital to excel in
their careers: 

1. The End-User needs and experience.

The QA needs to know why and how the end-users will use the system once it is deployed so that when they are validating the functionality that was developed, they can ensure that they test all the different scenarios. On bigger projects, there can be UI and UX resources available to advise on the end-user experience, but the QA is still a vital person to guarantee what is being developed will work for the end-user. 

2. Understand the business needs inside out.

Although similar to point 1, this is more focused on the overall business understanding, the direction that the business is going and why the business is going in that direction. The QA needs to understand the features that are being developed and where they fit into the overall business strategy. This again will guarantee that when functionality is being
validated, all the scenarios are captured and there is nothing missed (where possible). Having this understanding will also benefit the QA in any refinement meetings that the scrum
the team have and they will be able to verify that the business need is being captured in every user story.

3. Understand the software that you are testing.

As a QA you should have a technical understanding of the software that you are testing. If you do not then there will be big gaps when trying to validate the solution and you will not be able to confidently verify that the functionality developed meets the highest standard.

4. Work very closely with all the members of the team.

Although obvious, a QA should remind themselves of this every day. To get close with the team the skill that they need to master is communication, communication, communication. Similar to the BA on a project, the QA can be seen as the person on the team with both business and technical understanding. Often the QA will find themselves on a call with the Business Analyst (BA) or Product Owner (PO) of the project to get a complete understanding of the business requirements and then jumping onto a call with the developer to understand what they are developing so that they can create complete test scenarios for to test their functionality. Usually, developers are not as aware of the business need and the QA often is the person to explain the business significance regarding the functionality they are Developing.

5. Do not just test the “Happy Path”.

Business processes are never linear and there are always edge cases or places where a process splits from the happy path. A QA needs to make sure the system works and
behaves the right way for every scenario. Although it is nearly impossible for a QA to find and test all of the edge cases, they should always try their best to make sure the system
works as expected, especially if the edge cases were discussed by the business owner but also cases that were not thought of by the business.

6. Bugs and defects need to be raised as early as possible and with all the information the developer requires to fix the issue.

Although seemingly obvious, raising bugs and defects as early as possible is crucial. These bugs and defects need to be detailed enough so that a developer understands immediately the steps to reproduce the error, the expected result, the actual result, the environment the bug was found and evidence of the bug in the form of a screenshot/video/error log/etc. If this information is not provided in a timely manner to the developer, then there is a delay in the resolving of the bug.

7. Do not become the bottleneck when it comes to completing a Sprint.

The QA cannot be the reason the User Stories assigned to a Sprint are not delivered. Organisation and focus are critical for the QA to make sure that this does not happen. Let's
take a typical Sprint for me, 2 weeks. Once the Sprint starts there is nothing to test in the system and the QA needs to utilise this period of time to prepare all of the test scenarios, test cases and test cycles so that when a User Story is ready to be tested the QA is ready to complete the test. If the QA is not organised, then the User Story is waiting to be tested as the QA is creating their artefacts and this will slow the whole project. 

8. Start learning about automated testing.

Automation used to be scary for some not-as-technical QA resources and it was left to developers or automation engineers to worry about. However, this is changing. There is a growing marketplace of production that provides configurable creation of automation test cases and these will only become more and more popular as the technology gets better. Do yourself a favour and start upskilling in one of these. One software I have personally used was Tosca by Tricentis and I know that UI Path is currently developing a solution themselves.

9. Stay informed with any changes in the QA world

Always keep one eye on what is happening in the QA world. It is a role that is changing rapidly and with the development of new automation technologies and the adoption of agile delivery. The role will continue to be changed and the more you know, the better opportunities you will have in your career.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Today's post is by one of our Engagement Managers, Conor Daly.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

As always, thanks for reading, if you enjoyed this post please feel free to share it and tag us @Pexlify

If you’re interested in Salesforce Solutions, contact us today to set up a hassle-free consultation.