Agile QA’s concerns about career progression
Recently, I talked with QA members of the group about their future career development and found an interesting thing. Some of them said that they wanted to transfer to BA, some to development, some to PM, and some to consulting in the future. Very few say they want to continue QA on a team. Is QA so unappealing? Why do they all want to transition or go out on their own? After talking to several qAs in the group, I found that the main factor was a concern about career progression in QA and felt that there was not much need for full-time QA in agile teams.
I remember there was an independent test team when I first started working. At that time, the division of labor was very clear. I was responsible for automated testing of applications on Windows Mobile (now called Windows Phone). We have a team of about 10 people, and we report the results to the test manager. Due to the complexity of the product, a large number of test engineers are needed to ensure the smooth release of the product. With the addition of more functions, the number of test team members is also increasing. This is the most valuable time for QA. The release of the product is ultimately controlled by you, and you can choose to work as a performance test engineer, safety test engineer, etc.
But now that more and more companies are choosing agile transformation, adapting to change and delivering working software quickly has become the focus of the team. From the perspective of developers and users, they will welcome the change, customers will see new features constantly, and developers will free up their energy from tedious documentation and processes, and use imagination and creativity to provide better solutions. But what are the benefits of Agile for QA? There was a regular, stable, testable release, and the detailed requirements document was our reference. Now you have to validate a constantly changing object, and you don’t have a long time to design an automation framework. How can we ensure quality?
Test responsibilities for Agile QA
In an Agile team, quality is guaranteed by all of the team members. When I first heard it, it was like an Agile manifesto. I knew it made sense, but how? If quality is the responsibility of the team, what does a full-time QA do?
Let’s start with the TestPyramid that agile teams often use to keep test cases in balance. Simply put, we can put more tests at the unit and service levels because these use cases are easier to maintain, execute, and run more efficiently. See Martin Fowler’s TestPyramid.
Within this framework, it is easy to create such misunderstandings.
1. Development is responsible for unit testing without QA involvement
Have a discussion with the developers on the team about “should QA be involved in reviewing unit test coverage” and developers often find it useless because there are special tools such as Cobertura, Jacoco, Istanbul, etc. The scope of these tools usually includes
- Line coverage: Is every line executed?
- Function coverage: Is every function called?
- Branch Coverage: Is every if block executed?
- Statement coverage: Is every statement executed?
QA checks can compensate for coverage at the pure code level. For example, in the case of exception handling and boundary values, code-level override checks if the statement was executed, but not if the logic was written. Here are some common check methods:
- Equivalence classes: Divide a program’s input field (all possible input data) into parts, and then select a small number of representative data from each part as test cases. Representative data for each category is equivalent to the other values in that category in the test.
- Boundary value: Boundary value analysis is a supplement to equivalence class division, which is a test method for the boundary value of input or output. The “boundary values” we refer to here are special cases that are slightly above or below the boundary of input equivalence classes and output equivalence classes.
- Decision table: In some data processing problems, the implementation of some operations depends on the combination of multiple logical conditions, that is, to perform different operations according to the combination of values of different logical conditions, decision table is very suitable for dealing with this kind of problem.
- Causal diagram: a method of designing test cases by analyzing various combinations of inputs graphically. It is suitable for examining various combinations of program input conditions.
Some QA will find these methods commonly used in black box testing, but implementing these coverage at the unit or service level as much as possible is an efficient, fast feedback approach that can be used directly for regression testing.
In practice, we can see that QA’s involvement in unit test reviews has the following benefits:
- QA can review coverage of unit tests to adjust coverage of unit tests and subsequent interface and regression tests. The previous projects were all about development writing unit tests and interface tests alone, QA writing automated regression tests alone, and later found that there was a lot of duplication of coverage, which was also a waste. It is more efficient to do unit testing in pairs.
- QA can be more aware of the impact of code on each module, so that regression tests can be designed specifically. For example, QA failed to perform regression tests within a short period of time due to a small change in the project, resulting in problems after the product was released. Wouldn’t automation just cover all regression tests? This is true in theory, but in practice there are many limitations and regression testing can only be done through manual validation. In this case, it is important to pinpoint the scope of regression testing.
- QA can have a learning process for system architecture and development language, which is conducive to the establishment of automated regression tests.
2. Developers are more suitable for designing automated test frameworks and interface tests because they write code more efficiently
If the purpose of automated testing and interface testing is to be more efficient than who writes the code, then yes, those things should be done by development, but as QA, the role of involvement is to analyze requirements and design use cases from the customer’s point of view.
Agile teams are increasingly turning to application Behavior Driven development (BDD) to cover service-based and UI-based testing.
QA will work with PO, BA, DEV, UX to analyze the requirements of the software and write these requirements into user stories. The developer is responsible for filling in these stories, and the tester is responsible for verifying the results of these stories. Usually, a story template is used to describe the story.
Story template:
- As a role
- I want characteristics
- So that the interests of
Such as:
As a mobile App user
I want to recharge the Mobile phone number with credit card
so that I can have fee to give a call
2. Each story may have a different scene. The following templates can be used to describe what happened in what environment and what the result was.
- Given [context]
- And [more context]
- When [event]
- Then [result]
- And
Such as:
Scenario: Recharge with Credit card successfully
Given I logged into the Mobile App
When I go to Recharge page
Then I can see the recharge option listed
And I can see the Mobile phone number input box listed
When I input the phone number
And I select the recharge option as “Credit card”
And I input the Credit card number
And I click the Recharge Button
Then I can see the “Recharge successfully” message shows
3. QA will work with DEV to implement automated testing of these stories. Common tools are:
- Cucumber (Ruby framework)
- SpecFlow (.NET framework)
- Behave (Python framework)
- JBehave (Java framework)
- JBehave Web (Java framework with Selenium integration)
- Lettuce (Python framework)
- Concordion (Java framework)
3. Develop interactions for UI-based testing, no need for dedicated QA testing
If UI-based testing is all about executing test cases, then there is no need for full-time QA to do it, but uI-based testing on agile teams is mostly done as exploratory testing. How to design good exploratory test cases is the value of professional QA.
Some say exploratory testing is manual testing, some say it is random testing, and some say it is testing the software as a user.
What is exploratory testing? Here’s the definition from Wikipedia:
Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Cem Kaner, Who coined the term in 1984,[1] provides consistent testing as “a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.
After reading this explanation, I’m even more confused. What exactly is exploratory testing?
Take a simple example, when we dine together, sometimes we will play the game of guessing numbers. The host will write down a number, and everyone will take turns to guess, and the host will remind us whether it is big or small. The next person would follow the cue and keep guessing until someone guessed the number. This is actually the principle of exploring the test. Every time we design the next number based on the previous result, the guess number is defect, and every guess is a test case. If you want to get this number right the least number of times, you need to be efficient, and the same goes for exploratory testing.
The value of agile QA
This is a brief description of QA’s role in testing on an Agile team:
- Review unit test coverage
- Pair with development to build service – and UI-based tests
- Exploratory testing
QA also has many customer-facing responsibilities, such as requirements clarification and product demonstrations, which will be discussed in a future article.
As agile projects become more numerous, QA needs to become more, not less, but more, like a good housewife, able to better balance test design inside and out, within the team, and to better represent product value outside. In an era of rapid change, it is difficult to maintain quality while delivering quickly and consistently, and solving this problem is the value of QA.
For more insights, please follow our wechat official account: Sitvolk
WeChat
Sina Weibo
Evernote
Pocket
Instapaper
Email
LinkedIn
Pinterest
