Archive for November, 2010

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.

Advertisements

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.