Archive for the ‘Agile Development’ Category

Moving to Agile: What the QA team needed to learn.

When my company moved to  Agile, the QA team had to make some adjustments to integrate and fit in with the new process. We’ve been working at it for a good three months now, and I think we are all starting to feel more comfortable with it.

Staying in Step:


Firstly, QA is used to being just a little behind development. We were focused on projects, not features. Although we tried to get in as early as possible, we were usually still an iteration or a milestone behind. It wasn’t terrible, but there were complaints that by the time we had questions about features or stories, the dev team had already moved on and answering our questions meant that they had to switch gears. We had a hard time because it seemed like our bugs stuck around longer and we were just a little out of the loop. Playing catch up on projects when we came in and ramped up was hard and time consuming. We wanted more communication.

Now, we attend each development team’s daily stand up – so we not only are held accountable for our tasks but we hear what the team is working on from day to day. We are part of the sprint planning meeting and we work along side the developers so our questions usually come up early enough to save time and make clarifications right when the feature is being built.

Divide and Conquer:

We have a few teams each working on different projects. Its a lot for one QA to keep up with.  I guess one of the challenges of a small QA team is finding a balance between giving each project the focus and dedication needed, while still getting all the work done on other projects. To handle this,  I split up to cover more. We can each specialize in one specific team, work with them, attend their meetings, and stay up to speed on all their projects. Our own, informal standups just allow the QA team to give eachotehr a quick overview.  It works because each QA gets to be an expert on a few projects and has time to get more indepth when they need, but if they need to switch projects to help out, there is already an expert on that project ramped up and ready to help.

 

Accept Early:

My favorite thing about the switch to Agile is acceptance tests. Once each story is defined, QA works with developers to come up with acceptance steps that become part of our story. This has been great, because I get to talk to the team before they start working to clear up any ambiguities about the feature. I also get a heads up so that when they finish it, I already know what to expect and how I want to test. It has increased our team work and our communication and it helps QA stay out in front of the game.  Once all the features have been looked at individually, we give the whole product a run through, of course. But it gives everyone piece of mind to have the features tested individually first.

Advertisements

Time for QA to fully embrace Agile

My favorite idea from Agile 2010 was that “QA should be the headlights for a project” A quality guide, not a quality police.

We can sit at the end of the schedule, run tests and file bugs. Or, we can jump out in front, help define requirements, learn from the programmers as they work on the project, offer advice and keep the user experience and project quality on everyone’s mind from beginning to end. Which helps the project more? Actually, which is more fun? Because personally I’d much rather get involved and get people excited about turning out a good product in the end, than just force quality on them right before release.

So how do you change your company culture to embrace that? I am presenting at a lunch and learn next week, with the hopes of kicking off this next phase of the QA process. I am so inspired and excited for the change after a week of being surrounded with agile talks… but how will the company take it? I think I have gotten my department on board, but the hard part will be the other departments who have to put up with us a lot more now. No one likes change, and organizations are harder to change than people.

So how do you get everyone excited about it? How do you show everyone how important this will be? I haven’t finished my presentation yet, but I’m trying to think back to those really inspiring sessions at the Agile Conference and give it a go. Heres hoping!

Agile Conference 2010

I arrived in Orlando with my team last night. We are looking forward to a week at the Agile Conference 2010. Our company has been moving more and more into true agile all year, and we are learning as we go, so this conference will be a great chance for us to pick up new ideas.

Finding out a testers place on the team has been an ongoing and ever changing process. Which is why I was so excited when I learned that there is an amazing testing track with classes I can’t wait to take and speakers I am looking forward to hearing. I hope to learn a lot to bring back to the team at home and try out for ourselves!

The “Mythical” QA schedule

I just finished reading The Mythical Man Month by Frederick Brooks. This classic was still amazingly relevant, even thirty some years later.

Some of the tactics he suggests have just been made obsolete by the advances in technology – however, his use of a surgical team as a model for software teams seemed surprisingly agile and modern (not that agile and modern are synonymous). What was most interesting to me was the importance he placed on software testing. In his planning for software schedules, he allots half the project time to testing and bug fixes.

What could you do with that kind of time? Could better fixes be implemented for bugs? Would more bugs be fixed pre-launch? I find that as development schedules get pushed out, it is testing that get shortened.

Squished between milestones that can’t move or running up against a launch date that has already been announced, testing is often a race against time. Sometimes – new projects are hard to estimate for. Sure, you know how long it will take you to run through your test cases, but what about the debugging time? That varies greatly depending on the bugs found. Having half the schedule devoted to testing (or even just a greater percentage) would certainly be a change.

Would such a schedule just stretch things out or get shortened itself? Would it hinder the creativity of the engineers by shortening their time? Or would it work to allow a team with greater importance and visibility placed on testing? A place where quality was not just a “QA” thing, but a collaborative time of testing and bug fixing that could bring the importance of quality at every step of the development process to the forefront.

Maker’s Schedule vs Manager’s Schedule

I just read Maker’s Schedule, Manager’s Schedule by Paul Graham. It got me thinking about how readily it applies to QA and to so many of the projects I have worked on- especially as I get more integrated with the development team. Here is an excerpt, but reading the whole article is well worth it.

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour…

But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.” -Graham

As software testers, we are often makers in a manager’s world. But it is different for us than for engineers, because we need to fill both roles to some extent. We need to produce test cases, comb through documents and create creative and comprehensive test plans. But we also need to sit in on meetings, communicate with other departments, understand release schedules and be focusing not just on our days work- but on following up on a previous releases issues and planning for next releases test cycle. We have to balance needing a maker’s block of time to create and a manager’s hour long shifts to get to meetings and do planning.

What do you do, as testers, to mitigate the clash of schedules and are you happy with how it works in your company?

What I’ve learned about Agile Testing

I started on an agile team last August. In the past few months, I’ve be exposed to a wide range of agile-ness as we have learned to adapt it for different projects and struggled to make it work for us. I have found great worth in some of its practices, and unfinished mess in others. As a team, the company has had to switch practices and courses a few times. The cool thing is that we are able to. No one is so stuck on procedure as to not admit that it could use tweaking. And where procedure was too lax, people have asked for more.

Here is what I’ve learned as the QA department has grown up and around the development teams:

– Agile doesn’t mean “No Processes” it just means flexible processes

Documentation is more a struggle. Shortcuts made in the name of agileness and flexiblity have been huge road blocks in my testing effort. We are still sorting out the right place for them. Something that allows for creativity and adjustments, but still leaves us with a solid document to test against.

– Trying to keep meetings short by cutting out discussion is pointless and unhelpful. Structuring meetings to allow for quick agendas and then discussion time is priceless.

Transparency between departments and code reviews are QA’s best friend, even if it takes more time at first.

– Short iterations mean quick test cycles. This means you need to have as much ready before had as possible – test plans, test suites – both automated an manual, report templates etc can all help keep you on track.

– Managing an agile team means knowing when to step back. The team is responsible to each other, not to you.

– Be flexible. This should be obvious, and maybe it is to some. But in my experience, learning agile meant learning to contort your testing efforts to the time and space available. That doesnt mean you should let your team get pushed around, but it means that you have to be willing to do the agile dance along with everyone else.

– QA needs to make its needs known. Don’t let yourself get deadlines pushed back and back until you are the one left struggling to pick up all the slack. Just because deadlines can change mid cycle now, doesn’t mean that your team has to sacrifice thoroughness in the name of changing requirements and speed.

– Communication is even more important – with things changing and people having so much freedom with their work, if you have a bad communicator, your whole project is at risk.

I am sure this list will grow in the coming months. For those of you who are new to Agile testing- what have you learned? Was it what you expected? Have there been any roadblocks on your project?

Goals

Now that choosing a new team member is complete, it is time to formalize goals for the QA department moving forward. When I started here, QA was a footnote to the development process. The engineers ran unit tests and the production team “clicked through” some functionality at the end. But no one was really focused on what a QA department should look like or what that role should be. I think one of the biggest challenges I faced when I came on was carving out a bigger spot for QA within the existing environment. It is an ongoing process, but in the past six months, I’ve seen vast improvement. It is amazing to see processes start to take shape and make an impact. This position has been incredibly rewarding, in a large part, because I can see improvement every day. The whole team here has been flexible, even when I tried something that didn’t really fit, everyone gave me time to try it and then quickly adapted to something new until we found the processes that worked for us. It is nice to reflect on that progress. But no matter how much further we are now than when I started, there is still so much that can be improved upon.

What I hope to accomplish next is opening up the QA process more to the development team. There is a review process now,  but it is loosely followed. I’d like to finish a test plan and have a round table time for people to review, critique and discuss risk areas and test cases. I think it could help in so many facets. Engineers can think more about risk areas when programming and QA can hear about trouble spots or areas of confusion and revise test cases to be more complete in those areas. The production team will have a more complete picture of what needs to go on before a deploy and most importantly, we all get a chance to sit and talk about quality together. I think its really important for such a discussion to occur before the official testing period.

I keep coming back to where QA teams can add value to the whole process, not just the end product. In an interview, I had one candidate define QA’s role as “Reactionary” to the development process. I have to say, I really don’t want that in this department. I want the QA team to be integrated and active throughout the development process – proactive about reviews, discussions, risk areas and testing. There is no reason to wait until the end of a cycle for that, especially not on an agile team. So here is to a larger team, new goals, and hopefully some more great progress like we have seen in the past six months.