Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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.

share|improve this question
5  
Be very careful of falling into the "OMG WE HAVE TO BE AGILE" trap. Being agile isn't about confirming to some set of rules that some blogger spewed out, or following a book to the letter. It's about allowing your process to be more adaptive. I wouldn't say that a dev iteration, followed by a test iteration, couldn't be agile. For a small team it's hard to have dedicated resources for anything; you might have a dev/sales, you might have a dev/marketing, maybe a receptionist/graphics/logistics manager/sysadmin (one heck of a resource!) Agile (IMO) is more a philosophy than anything else. –  corsiKa Jun 3 '11 at 21:52
    
+1 Having waterfall practices is not an issue until the team delivers product to the customer delight. You don't have to be 100% agile as glowcoder says –  Aruna Jun 3 '11 at 23:55
add comment

6 Answers

up vote 7 down vote accepted

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.

share|improve this answer
    
+1 for all of the recommendations that I wish I would have known a year ago on my last team. –  Lyndon Vrooman Jun 6 '11 at 10:07
    
As a matter of fact, I'm halfway through Agile Testing by Crispin & Gregory... Excellent Read... Thanks for the awesome post +1 –  Jason M Jun 6 '11 at 14:20
    
I'm humbled that you felt this was an awsome post, especially in light of the other good advice being given in the majority of the answers below. It is interesting that few if any conflict with what I've said or other answers, and that they tend to dovetail to create a pretty good set of comprehensive advice. –  Chuck van der Linden Jun 6 '11 at 23:45
add comment

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.

share|improve this answer
    
Another issue is that we haven't gotten buy-in on the user story format yet. Excellent response though, a good way to think about it. –  Jason M Jun 3 '11 at 19:08
1  
It's hard to know what formats will work for you until you try some stuff and gain experience. For now, take an experimental attitude. I wouldn't worry about nailing down a format yet (if ever). That may become more important as you select tools for automating your examples. But for now, focus on making the examples really clear, without delving into incidental details. That's hard enough. The format will follow. –  Dale Emery Jun 3 '11 at 19:15
add comment

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.

share|improve this answer
    
They do like to sling cowboy code... So it's really about defining the boundaries –  Jason M Jun 3 '11 at 19:24
add comment
  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/

share|improve this answer
2  
I strongly feel that " Quality is a shared responsibility of the whole team." should be true of all development teams. Not just agile ones. –  sean_robbins Jun 6 '11 at 21:00
add comment

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.

share|improve this answer
add comment

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)

share|improve this answer
    
The content is not accessible. The document requires authentication. –  dzieciou Oct 8 '12 at 19:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.