In agile (Scrum) practices, where do I start with making QA (testing) more efficient if the team is transitioning from waterfall to agile?

Question

My team has recently transitioned from the traditional waterfall method to practising Scrum. Being the QA lead, really the only tester on a small team, how can I get the process more aligned with agile?

Right now, it seems as though we're just running a mini waterfall with development in one iteration, then testing in the next (NOT Agile!). After some discussion with programmers, I've come to find we have no Unit tests set up, so we really haven't even done any sort of TDD. We also have yet to implement any sort of automated testing. I'm lost as to where to even start with getting us on the right track.

Answer 1

What you have described so far is something I'd call 'scrummerfall', but given how it often turns out, could be spelt scrummerFAIL instead. I see several issues that need to be addressed. @Aruna covered several in their answer, which gets high marks from me. To what they have said I would add the following.

1. the team doesn't understand what 'DONE' means if things are not in a 'ready to ship' state (e.g. testing still needed, bugs found that require fixes, etc) at the end of the iteration.

2. There does not seem to be an emphasis on good 'craftsmanship' of the code, as evidenced by the lack of TDD and unit tests. In an iterative development environment, you need a pretty robust set of automated tests both at the Unit and Integration/Acceptance level in order to be sure that the stuff that was built and working correctly in earlier iterations is not broken by work done in later iterations. If this testing is not automated, then the amount of regression testing needed at the end of each iteration grows larger and larger until it takes over the entire iteration and no work can be done. As a tester, you need enough time in each iteration to produce automated acceptance tests that can form part of a regression suite for use in following iterations.

3. (in a sense continued from #2) In sort iterations it is crucial to build in quality upfront as there is not enough time to try and 'test in quality' during an iteration. I strongly think developers need to be doing some kind of 'test first' practice in order to be successful in the long run. I know of no other practice that can have as much impact in reducing the defect rate. BDD / ATDD (two terms for pretty much the same thing with a few minor differences) would be preferred, TDD otherwise. All of the *DD's are DESIGN/Development practices, designed to help the developer better understand what they are about to code by looking at the required behaviour, as expressed by tests, FIRST before they write code. While unit tests are produced, they are NOT testing activities, and despite the name 'test' in the name, unit tests are the developer's responsibility.

4. They have not really integrated test into the team, and are basically still 'throwing stuff over the fence' at the end of an iteration, that means you are basically still working in separate silo's and not all part of one team. You need to be testing a story as soon as the developers think it's working, not after they finish a sprint.

5. If you are doing scrum without anyone on the team having had any kind of scrum related training (or prior experience on a high performing team) then it's a recipe for failure, have management invest in at least Scrum Master training for your SM, and I'd strongly recommend Product Owner training for the PO as well.

6. Everyone on the team needs to be clear on how test fits into things, to that end I'd recommend everyone on the team be tasked with reading two very good books that cover this

   • Agile Testing by Crispin & Gregory
   • Bridging the Communications Gap by Gojko Adzic

7. in terms of community, I'd strongly recommend checking out the Agile Testing section of the Skills Matter website where there's a wealth of good free into in the podcasts section. Also, the Agile Testing group in Linked-In is a great place to talk with other agile testers.

Answer 2

1. In an agile environment, the distinction between a tester and a developer is blurred. Testers are not solely responsible or even the primary owner of quality. Quality is a shared responsibility of the whole team. Individuals in an agile team may specialise in a particular role but will take on different roles depending on the context. Testers who are out of their depth reading code or uncomfortable influencing design decisions may require some training (or pair up with DEV) to fit into the agile team. Testing is a key activity that should involve testers, developers and customer representatives. It is not supposed to be done by the testers in isolation. The developers need to write automated unit tests before starting to code. This approach of doing testing before coding is called Test-Driven Development.

2. Change is at the heart of agile projects. The testing team might be expected to follow a plan when a change has happened in the product. The plan should support the change. After a change has been implemented the testers need to test the untouched areas of the changes to ensure the ongoing stability of the product.

3. Conversations and shared understanding will take the place of heavy-weight documentation. Testers should be capable of looking at the big picture from multiple angles and ask good questions that the developers and customers might think of.

4. The agile testing mindset is all about collaborating with customers, looking at the big picture, providing and obtaining feedback. Here the testers collaborate closely with the customers. Working closely with the customers is favoured over becoming a customer proxy. The testers do not merely execute against a negotiated bill of work but have iterative collaboration with the customer. The testers state the user’s point of view in team meetings and bug reports. The testers even fail the release if the quality was unacceptable to protect\defend the customer.

5. Testers need to be on their guard to watch out for any impact of rigid processes on quality. For a long time the focus of testing has been short-sighted with emphasis on functional correctness rather than value to people. This problem in testing is a subset of the bigger problems of rigid processes in place. For example, in company XYZ if the tester logs a defect that lacks the support of requirement specification document, the issue is considered to be a non-issue as per the process. In these situations, there needs to be a careful risk assessment of the issue through shared conversations with the developer and high support from the management if indeed the issue falls into the high risk area.

If you are interested to find more, I have also written an article on "Making a successful transition to agile testing" at http://technologyandleadership.com/making-a-successful-transition-to-agile-testing/

Answer 3

Use your testing skills to help the team define each story more concretely. This shifts your contribution from one of strictly detecting problems to one where also help to prevent them.

As stories are being prepared for the next planning meeting, work with the product owner and developers to clarify the boundary of each feature. Use your well-developed boundary-probing and ambiguity-detection skills to ask "do you mean" questions, and posit "what if" scenarios. Help the team express their growing understanding of concrete, written examples.

It's great if you can automate these examples as automated acceptance tests. But even if you can't, they help the whole team to understand the feature better, to test their own understanding of the feature, and to mark progress during the iteration as the system satisfies more and more of the examples.

Answer 4

In this software development environment, testing should progress with the development.

• As the features are being planned, you should be getting boundaries.
• As the features are being implemented, you should be making scenarios form the boundaries.
• As the features are finished, or at least working, you should be running the scenarios; manually or through automated scripts.

The unit test part should be something that the programmers do, since they shouldn't give testers code that doesn't even run.

If your company has a more "cowboy" approach to programming, and just lets the programmer implement something based on a loose concept, you should have meetings with the programmers to find what boundaries they are intending on using.

Answer 5

I wrote an article sometime for the Agile record magazine (Lessons learnt in agile testing) specifically highlighting some pain points and the learnings we had while transitioning to agile. here is the link. hope it helps

http://agilerecord.com/agilerecord_04.pdf (page 73 – 76)

Answer 6

The core testing practice in agile pethods is automated testing, in order to always have a deliverable software, and to write these tests before coding the features. These are practices from XP and TDD.

Of course, if you are interested by testing in an agile context, you should take a look at Test Driven Development, if you haven't yet.

Answer 7

I would suggest that you need to start by presenting a comprehensive approach to QE to the team so that they can see how it will fit in with Agile Development.

For me a comprehensive approach to QE basically means a comprehensive approach to testing.

For this I start with these four quadrants:

Integrated  |  Performance
--------------------------
Unit        |  Exploratory

You need to be sure that the base code works as intended (Unit Tests), that it integrates correctly with datastores and other dependencies (Integrated Testing), that it performs reasonably (Performance). Finally you want a human to look at how everything works together to achieve the desired business goals (Exploratory).

I then look to talk about how long testing takes - particularly writing automated testing and most particluarly in getting a framework 'off the ground'. I also talk about the testing ratio of the tester/QE person (if broken out separately). If there is 1 tester to 4 developers and some tickets take twice as long to test (a common scenario) then there is an inherent problem. Having laid this out I then suggest the solution: we are a team and everyone does testing. Developers should already be familiar with the value and need for unit tests so this is just building on top of that.

In your case, for the question of where/how/when to start with making QA (testing) more efficient if the team is transitioning from waterfall to agile:

For unit tests by developers

Writing unit tests for code is fundamental to current software development. It didn't exist for me 20 years ago but now it is just a basic requirement. It's not just 'a good practice', it's the accepted basic way to make sure the software keeps working.
So if folks aren't doing unit testing now it's time for more action than just an email or a lunch-and-learn. Folks need to be re-trained. It can be on-site or off-site but we are talking weeks and months here not hours and days. New folks may need to be hired. Existing folks may need to learn to how to balance the value of their experience with the need to continue learning and changing. I am.

For integrated UI testing by developers and QA

Drive change with the common theme of where, how and when QA tests, to emphasize the change in testing close to production - a characteristic of waterfall - to testing as part of development as required by Agile development.

Where:

• Start with production
• move to testing staging
• move to testing locally

How:

• Initially start with QA testing manually to learn the domain and workflows and learn any existing bugs or 'features'.
• Then move to simple UI automation with scripts and gui IDE tools.
• Then move to programmatic solutions using web driver
• Then expand to multi-device and browser testing with both physical devices and remote services.

When:

• Start by testing current production
• Move to also testing a staging environment for code about to be released
• Move to also testing Pull Requests before they are merged into master
• Move to also testing alongside development and planning testing before development starts