QA Automator

QA Automator

Do you know what a QA does?

QA, Quality Analyst in English, or quality analyst in Portuguese. This is one of the roles of Thoughtworks consultants most asked by our clients. For this reason, Pat Sarnacke wrote an article to answer this question, originally in English. Given the relevance of this role for teams working with digital products, I decided to translate and share it.

QA must, above all, guarantee quality; that is, the need in any project to ensure that the software we are delivering to the customer is exactly what they want. However, Quality Analysts are the thinkers who specialize and take ownership of the project’s quality. This is challenging because everyone on a team is responsible for quality, and depending on the composition of the team, different aspects of quality can be handled by different people.

QA Tasks and Responsibilities
  • Test Analysis – This includes risk analysis and test design. Risk analysis is about finding out what types of issues are likely to occur – and where and when and how much they affect the software. Test design (and test suite design) is about figuring out how to efficiently cover these risk areas completely, given the time and resources available. QA does test analysis when thinking about exploratory testing, when writing regression test cases, when collaborating on story acceptance criteria, when implementing or maintaining automated tests, or when deciding which regression tests not to do. because you won’t have time.
  • Test Strategy – QAs often collaborate with developers on the team’s overall testing strategy, as many tests, low-level functional tests, service contract tests, UI tests are made by developers. It’s important that test automation efforts between QAs and developers complement each other, because otherwise there can be gaps in coverage that introduce risk or duplication that slows the team down.
  • Business analysis – QAs can (a lot) help business analysts to define success criteria for stories. They help business analysts think about how different users might interact with a proposed solution. Also, by asking “how can we test this story”, QA often changes the way stories are written.
  • Story Verification – As developers finish stories throughout the iteration, someone needs to test them carefully to ensure they meet acceptance criteria and user needs. If a team is big enough to have QAs, that’s part of their role. We trust QAs with their testing skills: rigor and knowledge of efficient techniques to find errors.
  • Manual testing – Before writing an automated test, we need to test things manually to get a feel for how they work and to have a better idea of ​​what to automate. Since automated test suites can be expensive to maintain (see Test Maintenance and Refactoring section below), we may or may not decide to automate manual tests later.
  • Test Automation – Many tests (especially regression testing: see Regression Testing below) involve repeatedly clicking through the software as a user does, and making sure everything works. This is paradoxically error-prone AND a waste of QA: QAs are smart, creative people, and clicking the same pages over and over doesn’t give them much opportunity to exercise that creativity and intelligence. On the other hand, doing these routine tasks manually leaves a high chance of error. It is often best if most important features are tested automatically.
  • Exploratory testing – this is where QA shines. Trying to find cases and combinations that the developers didn’t think of when writing the code. Trying to think like the end user, and imagine how they would use the software. Thinking about things that weren’t described as explicit requirements, but obviously, should be part of the software. Thinking of the system as a whole rather than from the perspective of individual stories. QAs have probably already done some of this thinking when helping to write the stories, but nothing compares to exploring the software and trying various things.
  • Regression Testing – A regression is an unwanted change to existing functionality. When something that used to work correctly stops working trigger, the application “regressed” (or went backwards). A big part of quality assurance has to do with guarding against regressions. On a team building a new application, there is no problem with regression testing until the first story is finished. After that, from the second story onwards, there is a risk of regression that requires regression testing. It’s a constant problem as long as the app is growing and changing. Developers often provide one or more layers of automated regression tests that run on an ongoing basis (unit tests, larger functional tests, service contract tests, etc.) and the QA team often contributes automated functional UI tests. , but because development is often ahead of QA test automation, and because automated testing cannot anticipate every problem that may occur, there are often a lot of manual regression testing to do. This involves more than just passively following test scripts. Much of the effort in manual regression testing is planning and designing tests and suites, and planning and coordinating their execution. Exploratory testing is also key during regression testing.
  • Cross-Functionality Requirements Testing – Many projects will need things like Stress Testing, Immobilization Testing, Load Testing, Disaster Recovery Testing, Performance Testing, Penetration Testing and others system test forms.
  • Creating and Maintaining Test Data – Everyone needs realistic data to test themselves, and it is often dangerous or illegal to use real commercial data. QA can help you find realistic datasets or help you create them and then help you maintain them over the course of a project.
  • DevOps – most testing takes place in a “Test Environment”, which often means the QA is the first person who has a real need for a working deployed application. This sometimes means that the QA becomes a DevOps person for the team as they begin to troubleshoot deployments on their own.
  • Communicating Risks and Defects – People in different roles need different information about risks and problems, presented in different ways. QA needs to be as detailed and accurate as possible when talking to a developer about a defect, but you may need to help a project manager or product manager understand the broader implications for the end user or the software release schedule. . And knowing when to just log an issue, when to raise a red flag about the issue, and when to stop everything until the issue is resolved.
  • Release of decision makingThe QA generally has the responsibility to make, or participate in, go/no-go decision making in English for new features and products.
  • Test maintenance and refactoring – As a project creates a set of automated tests, it becomes increasingly prone to breaking due to small changes. (This is called “fragile”). Someone has to refactor the tests to extract commonly used code (so that it breaks in just one place instead of hundreds), and to combine some tests that are duplicated and delete old tests that are no longer serving their purpose. As the size of the automated test suite grows, the need to maintain this test suite grows proportionately.

Entrar

Cadastrar

Redefinir senha

Digite o seu nome de usuário ou endereço de e-mail, você receberá um link para criar uma nova senha por e-mail.

Membership

An active membership is required for this action, please click on the button below to view the available plans.

pt_BRPortuguese