April & May 2010: Testing in Agile, Part 1 of Our Series on Agile Testing

Agile‘s impact on software development teams is huge. For test teams it can be even more pronounced — and good, especially if your existing projects have been problematic.

There are many positive things about the move to be more Agile and responsive in software development, but like so many things the devil is in the details! What Agile actually means in your organization and what practices will be implemented vary dramatically from company to company. There is a rush to be Agile these days and I see it mis-implemented more than well implemented. I believe “Agile” itself needs to be reunderstood, if not reconceived.

Here is what I mean: Agile does not equal faster. It is not Scrum, it is not XP, nor is it Lean. Agile is not an SDLC or how to manage a project or how developers write code. Agile means too many different things to many people. This series of articles in not meant to be an Intro to Agile. The discussion here centers not on what Agile is or is not. It focuses only on those aspects which directly impact software testing and how traditional testers need to be prepared to be Agile.

Most of the white papers and speakers you find these days on Agile, Scrum and XP focus on its practices. There is more than enough written about things like test-driven development, sprint retrospectives, and estimating user stories. My focus is different.

First, I will focus on software testing. And by this I mean testing in the traditional sense, not in the unit testing/user story acceptance testing sense. Secondly, I will focus on the areas of Agile development that are most overlooked but quite important to successful implementation of Agile, such as team dynamics, self-forming or self-directing teams, and tools.

Let me layout some overview themes that guide my views on agile and are critical points to be made about this movement.

1- These ideas are not new. In 1987, deMarco and Lister famously wrote about software development teams in their groundbreaking book, Peopleware:

Here is what I mean: Agile does not equal faster. It is not Scrum, it is not XP, nor is it Lean. Agile is not an SDLC or how to manage a project or how developers write code. Agile means too many different things to many people. This series of articles in not meant to be an Intro to Agile. The discussion here centers not on what Agile is or is not. It focuses only on those aspects which directly impact software testing and how traditional testers need to be prepared to be Agile.

Most of the white papers and speakers you find these days on Agile, Scrum and XP focus on its practices. There is more than enough written about things like test-driven development, sprint retrospectives, and estimating user stories. My focus is different.

First, I will focus on software testing. And by this I mean testing in the traditional sense, not in the unit testing/user story acceptance testing sense. Secondly, I will focus on the areas of Agile development that are most overlooked but quite important to successful implementation of Agile, such as team dynamics, self-forming or self-directing teams, and tools.

Let me layout some overview themes that guide my views on agile and are critical points to be made about this movement.

Things that have a strong positive effect:

    • Fellow team member interactions

    • Workplace physical layout

    • Protection from interruptions

Things that have a negative effect:

  • Overtime
  • Lack of closure

Agile addresses these issues like no other set of ideas in software development or project management before it. There is no Agile, whatever project management mechanism you choose, that is not based upon teams sitting together and focusing on one set of tasks with excellent, full-team, daily communication.

2- Agile is not about getting faster!

Agile is about people and interactions being more important than processes and tools, working at a sustainable pace, and self-directed teams!

People working on Agile projects should be more satisfied with their work, do it at a more sustainable pace and feel better about the quality of the released product. If not, your company has really missed the boat. If Agile at your company is about a tool, or set of tools implemented, something is very wrong.

3- Testers have recommended many Agile ideals and practices for a long time.

    • “Unit testing is really good- we should do more!” How long have testers been saying that?

    • “Accept the fact that we always accept late changes rather than pretend we don’t.”

    • “I [formerly known as QA] don’t own quality- we all do!”

    • “You are going to stop calling my team QA.”

    • “We need to automate more”

    • “We need to design the code for testability.”

The fact is that test teams have known many good Agile practices for a long, long time. In some cases, using more Agile development practices may not change the job of a traditional tester; the focus of testing may not change very much. But how the projects are managed will be a change.

The following series of topic discussions on aspects of Agile development will explore how implementing Agile development practices and values can dramatically change your job satisfaction, level of respect, and work situation for the better — if practices are implemented and not just given lip service.

The series:
1- Testing in Agile
2- Team and People issues
3- Practices and processes specific to testing
4- New skills and training for traditional testers
5- Tools

NEXT, PART 2- TEAM AND PEOPLE ISSUES

Take our quick survey on Testing in an Agile Development Team!

Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

One of the challenges with building an application these days is the number of dependencies that application will actually have on other applications. Ideally in order to know how that application will actually perform, application developers would be able to test their application against the application it depends on running in production. The odds of ...
One of the features of using Agile methods is the opportunity for continuous improvement within a project. There are a number of improvement opportunities throughout a typical iteration or sprint─over the next few weeks I’m going to walk through a few, starting this week with the Retrospective. Retrospectives are one of the many tools in ...
Over the years many Agile proponents have come out strongly against offshoring some of the development team, and in particular against having a remote testing team. We made use of not one, but two separate outsourcing providers located in two distant locations. While we had many challenges, what we found was that by starting with ...
Agile, in terms of software development, has incorrectly and for too long come to mean fast and “getting product out the door quicker.” But Agile is not about speed; it is about being flexible. I always begin my discussions on Agile development by getting a definition for the word Agile. Agile, in terms of software development, ...
Author of The Agile Warrior, Rasmusson answers questions from LogiGear’s testing staff about test automation in agile projects.
Team collaboration is essential for testing embedded systems. Developing software for an embedded system often carries more risk than for general purpose computers, so testing is extremely critical. However, there still has to be a good balance between time spent on testing and time spent on development to keep the project on track. As consultants ...
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part Four of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile”   LogiGear Corporation  LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and ...
Agile stresses instant and easy communication and is built on teams working efficiently together. This necessitates an open work space environment. A characteristic of an effective team is a high level of collaboration, making the physical work environment an important factor. Cubicles should be eliminated in favor of an open work space in an effort ...
Agile is a philosophy focused on delivering constant value to customers incrementally and frequently, based on communication and feedback. These two ingredients are vital to a successful Agile recipe. Agile is no longer a buzzword or an unknown territory in the industry. Agile has progressed leaps and bounds the last few years and has matured to ...
Maximize the function of your teams The Modern Agile philosophy created by the folks at Industrial Logic is one of the most exciting ideas I’ve encountered in a while. Moving beyond the pre-canned “You must do X to be Agile” mindset that I’ve seen becoming more and more prevalent.
Agile methods were developed as a response to the issues that waterfall and V-model methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed. From www.agiletesting.com.au A software tester’s role in traditional software development methodology, a.k.a waterfall & the V-model can be ...
“Agile is to software development what poetry is to literature. It is very difficult to do well, very easy to do poorly, and most people don’t understand why a good poem is good and a bad poem isn’t…” – from the web

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe