Posts Tagged ‘management’

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

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?