Tuesday, June 26, 2018

What testers should perform to stay relevant in agile teams | Supreme Agile

Let's put it on the table, traditional software testers must step up if they want to remain relevant as testers in agile teams. You cannot run from it, agile is here and most probably will continue to be the leading SDLC methodology that will lead the industry in the upcoming years.

Testers must step up and add more skills to their arsenal to meet the new challenging environment of an agile team. Testing in an agile team has much more than what testers have used to have in traditional testing. It's no longer about working in one bug QA team that testing features once development phase is done.

Agile testing means more communication with different stakeholders (External/Internal), Faster testing with more advanced test methods (Exploratory and Risk-based testing are the classic once) and many other challenges that demand testers to develop themselves to really be able to contribute to the team and stay relevant.

The classic scenario

It usually starts when the organization understands the Hugh benefits that agile has to offer and decide to move forward and make the agile transition in the organization. Once the announcement arrives at the different departments, many questions are a raised and uncertainty becomes the employees worst enemy.

Now, if you’re a tester in a testing team the uncertainty becomes even hire and some of the most classic questions are thrown into the air:
  • How this transition will affect the testing team?
  • What should we do in the new agile teams?
  • How can testers and developers will work in one small team?
  • Who is responsible to ensure that the quality will not affect? 
This is just a narrow list of questions that I see in almost any agile transition, and we can understand why moving from traditional testing to agile testing is not obvious to testers that used to own the responsibility on testing the product that now spreads to the all agile team.

The expectations from testers on an agile team

So now it’s a fact, your organization started the transition to agile and as a tester you have a great amount of uncertainty of what does it really means to be tester in agile team, in the following paragraphs, I will review some of the mandatory tasks that any tester is expected to perform as part of the team.

Collaborate with other team members

Collaboration is one of the key principles of agile, as such, we can expect to see it from any team member and testers are not different. Testers should have the personal capabilities to communicate with other team members inside the team and also with external stockholders that are part of the project.

  • Help other team members to write tests on all level of the application (Starting from unit, component and integration tests that will make the testing process more efficient and reduce the manual testing effort).
  • Conduct test review, create test designs and reduce duplicate tests on the different testing layers.
  • Work together with the team developers to report on design issues that may raise major quality issues. 
  • Help other team members to complete a user story that hasn't progress as planned (It can be testing, writing code, and set-up the test environment). 

Help with Testability

Testability is one of the most important items that testers are expected to contribute to an agile team. Testability will help the team to increase the software quality but no less, it also helps to improve the discipline and communications.

Testability is a major part of any user story that the team will want to deliver and known as one of the five pars of the commonly used "INVEST" model for writing user stories (Each PBI should be independent, negotiable, valuable, estimable and testable).

Testers must be involved in all parts of this model but especially on the testability side, they must help the team to understand how and what they need to be able to test this story, which will increase the contribution of the other team members to the testing effort.

Another aspect of testability is that testers are now working closely with the team developers to ensure and advice on all testability aspects. As part of this discussion, the team will decide the test design, strategy (Automate/Manual) and who execute which tests.

learning is not an option

I think that it not really matters what you do in the software industry or in any other job, but just to be on the safe side I will say that for any member in agile teams and especially for testers learning is not an option it must do. Testers have just too many areas that they must contumely improve at, including testing methods, tools, coding skills, technologies, agile itself and to keep up with the production they are testing. 

Take an active part in defining "Done"

This is just a classic example of how the world of testers has changed when moving to agile teams. In traditional testing, testers had to wait for some time to the completion of the first phase (Requirements Analysis) before they even can start thinking on the test plan, Strategy and ensure all requirements are covered (It's just easier when you get one SRS document containing all the application requirements).

Now, once testers are integrated into agile team that follow the basic values and principles of the agile manifesto, any team members (including testers) are part of the all process of defining user stories, adding them to the project backlog and helping the product owner (the business owner of the product) and the rest of the team to define the relevant criteria that must be fulfilled prior the team can mark user story as "Done."

Definition of done from testers perspective is not so different from any other testing project, if they have the most experience and knowledge among all team members in this medium, they will need to ensure that the DoD will include all quality aspects that guarantee that the user story is delivered at the highest quality

From a quality perspective, a DoD of a user story may include the following:
  • All functional and nonfunctional tests with priority X, Y are executed and approved.
  • All bugs are fixed and verified (Product owner approval is needed for all bugs that are differed in future sprints).
  • All tests are automated to reduce future technical debt.
  • All major flows of the software are tested on production environment
  • The code is covered with 90%+ unit tests.
  • All major risks are mitigated with corresponding tests  

Estimate work

Same as other team members, testers will have to have the skills that should be allowing them to estimate the scope and size of the testing effort of each user story that the team will need to deliver in an upcoming sprint.

The testing effort should be estimated by the testers and the other team members in a way that the team will agree, this is crucial aspect of any estimation in agile team because it is part of the overall estimation of the size of the user story which also includes different activities such as coding, design and sometimes even research.

Provide fast feedback 

One of the most important advantages of agile software development is being able to deliver in short iterations that will allow the organization to face the increased challenges of the software industry. to be able to work in an environment of quick releases, the team must have the ability to get quick feedback on each one of their deliverables and make the necessary changes accordingly.

Again although the entire team is responsible for the quality of the product, in most cases testers will be the one that will deliver the quick feedback about the quality of the written code, testers must have the ability to  test fast and to determine the real health of the application (As fast as defects are reported, the faster the fix can be made).

Testers can share their feedback with the team while using different forms such as:
  • Bug reports. 
  • Code and Test reviews.
  • quick sessions of exploratory testing. 
  • Design and monitor quality KPI's.
  • Pair Programming. 

Fail as long as you learn

One of the biggest advantages in agile teams is that you can fail and that's just fine as long as you use it as another step for continued growth for both the individual and the rest of the team. In traditional development, the room for mistakes Is almost not exists due to the nature of the separate phases of the traditional SDLC that increase the impact of each mistake made by the involved engineers. 

Help the team to automate

When it comes to automation, Agile testing is not different from traditional testing. Automation has a major part in the team able to run a more rebuts and efficient test process while keeping future technical debt to the minimum.

In agile development environment that runs on short iterations, automation is the main option to test all the small increments functionalities that added per spring, these small changes that added per sprint will not allow the team to run the same manual tests over and over again (The software is continually changing) and regression test will become a Hugh risk to the team able to deliver in time.

The only way that an agile team can confront this issue is by using automated frameworks on all layers of the application including unit, Component and system tests and do it as much as possible (Manual tests should reduce to the minimum).

As a tester in the team, you must have the capability to write these types of tests and to contribute to the overall testing effort. That does not mean that the tester will write the automated frameworks (Again, depends on his coding skills) but he most defiantly assists in writing the test scenarios, writing them in code (It is more than accepted that the team developers will assist and educate their testers to do it).

Due to the importance of this item, I will add a real example from one of my consultant activities, and the story goes like this; I once invited to organization with more than 40 working agile teams, 35 from these teams were able to deliver on time but the remaining 5 continually fail to do so. After a week that I was reviewed how these teams have worked, I found many failures in different aspects including many HR issues among the members of the team. But the one thing that was really critical is that in all of these teams there were only two testers on a group of 10 engineers.

The bigger problem was that these testers were expected to write and execute tests without any real knowledge in automated (in-house) framework and as a result, all tests were executed manually and in the good case automated by the team developers.

To overcome this problem, I used this situation as a leverage to resolve many other HR issues that were affecting the team; First, we raised this issue in retrospective and let the testers to share their technical issues in addition to their feeling of lack of help of the rest of the team members.

Second, we let the team decide how they can help their testers to become more professional in the company automated frameworks (Per sprint, a new user story was added for this purpose, to provide the team the necessary time to help their testers).

The result of these two simple items was the trigger to major success in future sprints, after four sprints of investment in the team testers, they gain the respect of other team members, the team started to meet the stories DoD and from delivery of 40% they started to deliver in almost 90% per sprint.

  • As a tester, you will help the team to search and acquire the most suitable testing tools.
  • As a tester, you will help the team to minimize the execution of manual tests.
  • As a tester, you will help the team to reduce regression tests and technical debt.
  • As a tester, you will help the team to create different automated metrics. 
  • As a tester, you will help the team to write, execute and analyze the results of the automated tests.
  • As a tester, you will help the team to decide which tests should be automated (per testing layer).

Help the team to determine different metrics

There is one quote about metrics that I love to use in my teams, the quote is "if you cannot measure it you cannot improve it – William Thomson, Lord Kelvin". This short quote can explain why metrics are so important to any project and especially to agile projects that based on continues improvement of the process, Quality and the team itself.

In traditional testing, the metrics were very important from an organization perspective, such as the number of reported bugs, Number of executed tests etc. Now in agile, we are looking at a new world of metrics that the team must track as part of an agile working environment.

The classic metrics:
  • Sprint Burndown.
  • Release Backlog.
  • Velocity.
  • The frequency of changes once the sprint has started.
  • Team happiness 

Open and Verify defects

It's the bread and butter of any tester to report on new defects and verify them once the bug was fixed. Now, although it doesn't sound new, there are some major differences between traditional and agile testing I summarized in this table:

Traditional Testing
Agile Testing
Fix time
defect fixes might be made by the dev department days, weeks and even months ago
Bugs are fixed during the sprint (Max of 4 weeks, Min of 1 week)
Similar to bug fixes, verifications are made department days, weeks and even months after the fix was made
Verifications are made based on the PBI definition of done (So almost all bugs should be verified within the sprint)

In some cases, defects are moved to a future iteration.
Usually by the project manager/Dev Manager
Prioritization is made by the product owner and the team
Build for verifications
Verifications are made on formal builds that are created every few days.
With a good CI system, builds are available within the hour and there is no need to wait for a formal build

Be ready to handle the frequent changes

One of the biggest differences between agile and traditional testing is the frequency of the changes that the development team and especially their testers should face during the sprint. if you remember the 4 agile values than you know that it’s something that is expected from the team "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."   

In traditional testing, the room for changes in the testing phase are very narrowed and almost does not exists (Each disruption can severely affect the project and jeopardize the whole project) which allow the testers to work on their test strategy without the need to change it once they start to test.

As a tester in an agile team, you must be able to work in an environment that will arise many disruptions and new challenges during development that arrive from new customer requirements, changes in prioritization and many other streams that will increase the risks but without affecting the whole project (Remember that we are talking about short iterations and contuse refrainment of the product backlog that based on the exact demands of the customer). 

1 comment:

  1. Hi,

    What do you mean by "I will say that for any member in agile teams and especially for testers learning is not an option it must do"?

    1. There is no time for testers to learn as others activities are far too time consuming.

    2. Learning is essential for all members of agile teams to keep pace with evolution of technologies, methods and the project they are working on.



My Presentations