Archive for the ‘Mindset’ 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.


Become a Better QA

What do you do to become a better QA?

It is easy to get distracted by the rush of every day work as a tester. Over time, you get practice and your skills develop and you progress. But it seems such a passive way to go about improving yourself and your career. There are numerous books and blogs and communities out there, not to mention whatever is available locally in your area. So how do you chose?

When I started at my current job, I made it an ongoing personal goal to learn as much as I could about testing and related technologies that will make my job easier, make my team stronger and help our testing efforts go further.

In the last year, I have met a lot of mini-goals along that path- becoming  more comfortable with shell scripting, starting to learn ruby, reading at least two testing books per quarter – but I still feel like I have a lot to do! It is both exciting and overwhelming to dive into open-ended self education.

I frequent blogs that put out fresh new ideas and share experiences, I follow groups online and attended an awesome conference. I’ve considered taking evening classes at a community college (I loved my evening ruby class last spring) and trying to get more involved with the local community. I think both of those may come into play next year. My focus for the next year is both on strengthening my agile testing skills as we have teams switching over to SCRUM, as well as to continue learning Ruby and of course, reading about new QA techniques and approaches.

But where do you turn to become a better tester? How do you decide what to work on and where to improve your skills?

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 Tester’s Scientific Method

We all remember the scientific method from jr. high science labs.  But as a tester, we still use it every day. The steps may entail different things, but the underlying philosophy remains the same. Testing is an interesting blend between scientific and creative, between destructing and constructing. It requires a flexible yet ordered mind and, as with any scientific approach, it requires curiosity.

1. Ask a Question: The most valuable thing a QA can do is to ask the right questions. Is this feature supposed to work this way? Could this functionality be broken if I do this?  How will this affect existing functionality? What does this mean for the user experience?

2. Do research: Talk to the engineers, look at the documentation, discuss with your fellow testers. Stand up meetings are a great time to hear what developers are up to and to ask any questions you have run into on those features.

3. Construct Hypothesis: Determine how the feature should work and all the ways you need to verify that it passes when it is supposed to pass and fails when it is supposed to fail. Write your automated and manual test cases

4. Test: Run test cases

5. Analyze Results: Evaluate what is failing and why. It is not enough to know that a feature has an issue, you need to know what exactly reproduces it? If you spend a moment looking at it, perhaps you will find related issues or other ways it can be reproduced.

6. Report results:  Carefully fill out your bug report. Stick to a bug filing standard. Spell check. Make sure that anyone could understand your bug and the information you have gathered from it.

7. Be prepared to test again. Bug fixes always bring with them the risk of inserting more bugs. Don’t just verify a bug fix, test the bug fix. It should get the same attention that the original feature did. Be aware that you may have uncovered a cluster of bugs or a series of new bugs that have appeared since the fix, so look at it with fresh eyes.

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.

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.

Developers: A Ray of Sunshine

Developers may be the most blatantly, unashamedly  optimistic group of people I have ever known. In the face of all evidence to the contrary, they believe that this time, software will work, deadlines will be met, solutions will be easy and testing will find no bugs.  It doesn’t matter how quickly something was put together or how shaky the requirements, or how new the system – developers feel completely confident that things will be fine. This never ceases to amaze me. I hate being the rain cloud on their bright day, but at the same time, I do enjoy injecting a little realism.

Code freeze just two days before launch? No problem.

Late requirements? We can squeeze them in!

last minute fixes? It shouldn’t be too hard/ (and my favorite) This will just take a minute.

They deploy their hard work off to staging, crack open a beer, and sit in the sun while testing begins. Even before you start that first test, you know it is too early for that beer. You remember last release, and the one before that. You remember that “quick bug fix” that took two days of testing and reworking to straighten out. You know this time is not different. You know they have deployed code that is broken, and that in a matter of time and tests, you will find the first broken spot- and then the next. You know that no matter how long or how hard you work, when testing is over and the project goes live, there will still be more bugs uncovered days, weeks or months later. You can only hope that if you work really hard, you will catch all the big issues. But that is your job- to remember all the ways things have broken before.

Developers spend their days creating new systems and solving problems. They get instant gratification when they do little fixes and get their unit tests to pass. They thought up their own solution, and so are somewhat blinded to potential issues  by their very involvement. Software testers spend their days slogging through broken programs, early releases, and failed bug fixes. Once something is fixed, we stop using it. We read countless bug reports and user issues and spend our days writing test cases trying to find broken spots. We aren’t involved in that creative burst of fixing something or designing something. Our creativity comes from all the ways we find to break it.

So when you file that first bug of the testing cycle, remember… their optimism will come in handy when it is time to fix all the issues you find. Besides, we are optimistic in our own way. We fully believe that their are bugs out there to find, and each day, we are proved blissfully right. Each issue we file a little victory, because that is one less issue for there to be in production, which helps the developers, QA and project managers to feel more optimistic about the release as a whole.