Get To Know Your Friendly Local Developer
Befriend and bemuse them with your uncanny ability to keep them on their toes.
It should go without saying, but let’s do it anyway in case you’re new here. Your team’s software tester should be generally studied on UX principles, IT basics, platform specifics, project management, development/test tools, and general software engineering. These are the main ancillary areas of “QA” knowledge for any software tester. A solid tester will keep these domain areas in mind while aiming for Expert level in general QA practices. This is pretty typical scope for high functioning testers who will hopefully have an additional specialization of some sort to offer as well. This might sound like a lot but it isn’t. I have worked with many testers functioning at this level and each of them has their area of expertise that compliments their testing skills which are honed by way of design and development knowledge.
There is another aspect that is incredibly valuable but not talked about much in regards to working with an embedded tester on your development team. It’s a combination of observance and collaboration: fostering and honing the interaction between your developers and your testers. Sometimes this looks like pairing and sometimes it’s simply empathetic perception. This stratagem is one of the things you lose when you disconnect your QA from your development team. Don’t do that. If QA is an add-on or optional “evil” to you or your team, you’re simply not functioning on the level I’m talking about. You have someone like me on your team, don’t you? Get it together, man.
What happens in both instances is the most virtuous of circles where the tester has to get better at finding bugs because the developer keeps learning their own blind spots by way of QA and covering the corner cases more thoroughly.
This can happen directly which is the crème de la crème of testing in my humble opinion but we’re not always that lucky. We either pair or run a close facsimile thereof.
If your branching and merging policy requires feature work to be tested before merging to the main branch, this state is perfect for a tester and developer to sit down and review the work before it’s unleashed on the team.
Review what the feature does, what’s expected, what issues the developer is concerned about. Test cases that must pass and other basic functionality. Go through the Happy Path together. Your Tester should write out an exploratory test charter with their basic plan of attack and things like Negative Personas, Worst Case Scenarios and other quick tests, heuristics, and tools of the trade. This should be reviewed with the developer and serve as the other volley to the initial introduction of their work. Now you’re both on the same page of each other’s books.
Time for testing. Before you dig in, figure out how the dev wants to get the info. This could be anything from a Google hangout, a text-dump of the exploratory charter, to a play-by-play in a chat conversation. I’ve found a play by play to be pretty effective as many things could be addressed in the time it took me to find a new thing. This meant we could find and fix a large number of issues on the fly. After your session, let the dust settle and file some bugs. You should have enough ammo to inform further tests or pass along test-cases and update your regression checklist.
Pairing in this way is probably my favorite thing to do and honestly when I’ve felt like I’ve functioned at my highest level. It’s very raw and terrifying.
Why is it scary? Well, the role of QA is in part to hold developers (and designers!) to their own muster. We’re usually the scrutinizers and when you’re doing this one-on-one you’re showing exactly what you are made of. The tables are turned (play nice!). Don’t get too scared though, this is an excellent learning opportunity as your developer will probably mention things they hadn’t yet thought of that were inspired by something you brought up. This is the virtuous circle shimmering.
If you need to convince your developer or QA to afford time for this, simply do the first session and neither of you will be questioning its value in the future. I promise. Well, unless one or both of you suck then I can’t help you but perhaps one of you will help the other until you figure it out.
Testers establish oracles. A lot of times these are things like competing products, PRDs, Apple’s HIG. There is another fleshy oracle and that’s your friendly local developer. Yeah, I know that seems a little creepy. It’s not. When you’re not pairing with them they and their work are still there and can be a passive resource to inform your testing.
Read each commit and the code along with it. If you’re allergic to code, no you’re not, grow up. You don’t have to fully understand each line. You don’t have to know what those APIs do. No one’s going to ask you about subclassing or pointers. Just get a picture of the basic idea and what classes and parts and features the new work touched. Between this and the comments, you should have something to work with. Compare again with the bug tracker (or kanban board or user story or whatever) to further confirm your approach for testing this particular thing.
But before that, there was probably some discussion, in the chatroom, in a status meeting, at a whiteboarding session. You, dear tester, should be monitoring all those channels as well. Not only monitoring but actively participating as much as you can.
Even deeper than reviewing someone’s commits is just being empathetic to where they are as a human and worker. Is the PM asking them to do too much fiddling and it’s taking away from their available time to code? Maybe their partner is sick. Maybe they are just coming on or off another project. Getting a temperature read of the pressures on everyone might not spell out explicit test cases but it can show you where and whom to focus on or back off of. Try to be of assistance and sensitive to your team’s needs.
You’ll be finding and filing bugs all the while. The developer will start to see what you find. Over time you will both see patterns. You will know your team members quirks and idiosyncrasies. And they’ll know yours. You’ll be attuned to their thought processes and should be able to find their ever-shrinking weak spots. A software tester gorges on information, their synthesis skills must be top notch. Put that into play outside of the actual application with our empathetic selves and everything and everyone gets better.