Archive for the ‘roles’ Category

Test Escape Reports

We just had a big launch at work, which of course leaves me thinking about test escape reports.

I have mixed feelings on test escape reports, and for a long time I didn’t want to use them here. My reason being that if you have a small test team, and you know everyone is really dedicated and working hard, then the occasional test escape is to be excepted and we shouldn’t harp on them.

However, I think over time I’ve seen the other side of this issue. Test Escape reports ensure stakeholders that you are on top of any issues both before launch and after. They hold the team accountable, not just for the issue but also for the resolution and prevention of it in the future.


The format we use is simple:



Reason missed:

Steps taken to cover functionality:

Test cases numbers for verification:


The point being not to look backward, or to blame someone for missing a bug- but to look forward into how we can test that in the future and how we can avoid over looking similar areas on other projects. The goal is to improve visibility- we admit our mistakes, take steps to correct them and let everyone take comfort in/participate in the improved coverage.

How do you handle missed bugs? Are test escapes’ a whole team problem or an individual tester’s problem? Is there a formal process surrounding them?


Having interns on the QA team

Internships are good for the interns, right? As an intern, you get a chance to learn, to be in a professional environment, sometimes- class credit and of course, some of your first professional references.  Interns get to be around the processes they are learning about first hand, they get to attend daily standups, read through requirements and work on project deadlines. It can be a great experience, but not just for the interns. The whole department can benefit from having some amazing interns around.

Having interns on the team has brought a different point of view. While they don’t have as much professional work experience they do know about the process and are used to learning new things quickly. I’ve been impressed with the quality of interns we have gotten. It is also great to have people with a little more programming knowledge who can help us make adjustments and revisions to tools.

Managing interns provides many of the same complications that managing a regular team of full time people does, but with some added quirks. The biggest quirk is that you have to realize that this job is not their focus. Sure, you spend 40 hours a week at it and it is your career. It is really important to you. But for them, at best this is part of their education, and at worst, it is an after school job. School comes first. Finals week, family vacations, homework- all of that is higher priority. Which is as it should be.

Also, they aren’t used to the office. It can be overwhelming. I personally think this is one of the best advantages an internships can provide, because they can become more comfortable with a professional setting early. Usually this isn’t a problem, but when assigning out projects or attending meetings, it is a good thing to remember.

Lets be honest, for some reason, not many people go to college to be a software QA. There aren’t really any programs and a lot of computer science programs don’t even include it as a required class. Want to get people excited about QA? Why not include it as part of the process while you are studying in college.

I like to think that I’m helping out future QAs by teaching future devs that the QA department does work hard. We experiment with new tools and new languages until we find the right mix for the project, we know how to get around the command line and can read and write some code, we pour over requirements documents and offer suggestions and ask questions. We act as user advocates, we clarify stories, keep long suites of tests debugged and running. We know there is limited time and so we test quickly, doing our best to squeeze out as much testing as we can in what little extra time there is in a project. I jokingly tell them (but not so jokingly) to remember all that when they are leading a Dev team some day.

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.

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.

High Heels in High Tech part 2: Becoming One of the Boys.

You move into your new office space (which you share with a guy named George) and start to unpack and set up your computer.  Your boss seems nice, your office has a window, and the lunchroom fridge is stocked with soda. You’ve made a mental note to request diet coke.

George is friendly, but a little awkward as he clears off his collection of army men that seem to have been launching a full scale attack on the corner of your desk. He offers to show you around and introduce you. Somewhere between introducing you to Mark, Brian, Greg and Dan, he leans over and says “I’ve always wanted to walk around the office with a girl on my arm.” It is right then that you realize you are in strange territory. This isn’t an ordinary office- this is a tech office and until you started – this was a place for jeans ,“that’s what she said” jokes and hot wings lunches.  While you are introduced to Dan, you can tell people are looking at you, and it isn’t because you are the new person- its because you are the first woman on their team and everyone wants to know what that means.

You are the new dynamic. Your coworkers might be a little worried that you will radically change the office culture. They might be uncomfortable making jokes like they used to. You might be uncomfortable wearing feminine (office appropriate) clothes. Nylons, necklaces, and necklines are all new.

They have lots of questions, but so do you. How do you act around these men? Are you supposed to fit in and be one of the boys or are we supposed to step up the professionalism? What do you wear? Is a knee length skirt too short when no one else is wearing them? There may be no HR policy about open toed shoes. When the guys wear shorts in the summer – is it ok if we do? How sensitive should people be about professionalism? Will there be a women’s bathroom or will you all share? Most of that depends on the culture of the office- but a lot of it you will define yourself as you find your spot on the team.

I read an article about women in the work place and how if there are more men, women will actually subconsciously speak in a lower voice and stand with their arms crossed more often in an attempt to fit in with the men.  We don’t need to be one of the boys to be one of the team. It is important to remember that even though we are all coworkers- women and men are still wired a little differently- but that’s a good thing! If we think differently, work together differently or test differently, that just makes us a valuable asset to team.

At some point, you end up managing men. Sometimes much older men. When I was 23, I found myself – as the youngest team member and the only women in the group– in charge of men old enough to be my father. Age is a factor, but so is gender. There were a few rocky releases for us, but eventually, we were all up together on late nights testing, we learned to work together and over look the generational and gender gaps to make a great team.

It feels strange to talk about it, but gender is defiantly a factor- at my company, a new female engineer came on to lead one of our development teams and said one of the biggest challenges was coming on and taking over a man’s role on a team with all men. She had to work to find her place- both as a new employee, and the only female engineering lead.  It can be uncomfortable for you and the people you have been assigned to manage. There are different boundaries, It can be intimidating to stand up and take charge in that situation, but as a leader, it is important address the issues and face them so that your team does not suffer.

Once you find a comfortable fit though- the joys of being one of a few is apparent. I have found the offices to often be more laid back and less cliquish. After few late releases together, (or after you win your first chicken wing eating contest) you are suddenly part of a team that can use its differences- in age, gender or background- to its advantage and work together.


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.