Archive for the ‘Manual Testing’ Category

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!

Advertisements

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?

Manual Testing Tips

Mindset:

There are always more bugs to find.

Don’t assume that you are trying to “break” the software- you aren’t. You are just trying to find out where it is already broken- and trust me, it is already broken, or you aren’t looking hard enough. You are literally hunting for bugs – so dont forget to be active in your pursuit of them.

Planning

Consider what isn’t being tested elsewhere. What is the most common user flow? Where will people most likely run into problems or where would problems be the biggest deal?

Test UI- really read through the text, even if you know what it should say. Is it clear? Edited? Understandable? Look at the pictures/images and alignment as though you were looking at them for the first time.

What are your blind spots? Are there pieces of functionality that depend on other pieces? Could bugs be hidden one layer down in the functionality and simply be masked?

Execution

Don’t test on autopilot. Really think about what you are doing. Really look, don’t just click around. Dont zone out while pages load or queries are returned, watch what is happening. Your eyes should always be evaluating the page.

Limit Distractions – Turn off your music, Step away from the TV (if you are testing at home), Don’t chat with your coworker. Give your self concentrated bursts of time to really focus and test. (and take breaks between so that you don’t zone out).

Test like a user. – You know how to work this page. You have read the documentation. Users haven’t (always). So assume you don’t know how to use it. In the end, you are responsible to the user- to ensure that they get a quality product.

Take Breaks

The first week of my first QA job out of college, the guy training me, Steve, told me “remember to take breaks when doing manual tests.” I nodded, figuring it must be some kind of trick. Why would you take breaks when you are on deadline?  It took me a few development cycles to realize the value of what he had said, and to this day, it remains one of the best pieces of advice I’ve gotten. We are in the middle of testing right now, and in the middle of a full day of manual tests, I was reminded of Steve’s advice.

Take breaks because your mind can only focus like that for so long before your eyes start to glaze over and you make silly mistakes: like starting to go on autopilot instead of evaluating every interaction, or ignoring a possible bug as a usual web glitch -when it might be something bigger. So this is my reminder for the day… go take a break. Go play tetris, or bubble shooter (my favorite), take a walk, close your eyes and listen to pandora for a full song. Give yourself five or ten minutes to reset and refocus. Go look at something that is not a computer screen, or talk to a coworker, or get up and stretch. The deadline will still be there, but you will be a more useful tool in meeting that deadline if you remember to take breaks.