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

Question

My team has recently transitioned from the traditional waterfall method to practicing 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 spelled 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 up front 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 behavior, 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 highly performing team) then it's a recipe for failure, have management invest in at least ScrumMaster 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 a) Agile Testing by Crispin & Gregory b) 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

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 with 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 3

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 4

1. In agile environment the distinction between a tester and a developer is blurred. Testers are not the 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 mind-set 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 favored 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 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 5

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 6

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)