Archive for May, 2010

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?

When Low Priority Bugs Should be Fixed

So you file a UI issue. No functionality is broken, the site looks ok. The deadline is close, and it makes sense to launch it. No one wants to delay a deploy because of a few pixels. When do you put your foot down? Maybe it isn’t worth fixing the color on a banner that only shows up for 5% of people using the application, or optimizing for an outdated browser that few people use. But not all issues that are marked as low priority should be ignored.

Low priority issues should be fixed when they make you look sloppy. Sure, everything works, but if your alignment is off, your headlines are the wrong font size, or spelling / grammar could be improved – the overall look of the application is sloppy. People will not remember that the log in process worked just fine, they will remember that your news story hung halfway off the page, that they had to scroll down the page to get to information or that your content blocks were not lined up.

low priority defect on Facebook

Low priority issues should also be fixed if they they add frustration (now or in the future). If your page can only be viewed well in one or two browsers, you may lose users who don’t want to download and use an unfamiliar browser.  Anything that can cause frustration to your users or waste the customer service department’s time helping people find work around is better off fixed.

Your site should be polished- functionality, and look and feel. If adjusting a low priority defect gives a more professional overall appearance, or saves you from having to have a detailed troubleshooting page- they should be fixed before launch. And it is worth the QA departments’ time to make a stand for them.

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?