Testing Test Cases

Getting test cases completed can be a big challenge.  You need to identify what should be tested, how those tests will be run, who will run them and how you'll track it all.  Each step is important, but ensuring it's actually done can be the hardest part.

There's a number of ways to do this, and each had it's own pros and cons.

Testing on your own

This is a very common approach.  Just send out the test cases with some instructions and ask folks to run the test.  The big advantage is this is entirely asynchronous.  Testers can do their testing on their own time.  A big trade off, however, is that since it's asynchronous it's hard to track and plan… you never know when someone will get it done.

Regular syncs, independent testing

This approach blends in regular meetings with testers while still allowing them test on their own.  These regular syncs are useful as they give the y am a touch point for help, and let you more easily see progress. The check-ins help mitigate the risks Of asynchronous testing, but allowing testers to choose their own time to test still presents a risk that things won't get done in a timely fashion.

Scheduled testing sessions

The next step up is the schedule specific times for the entire team to connect and test together.  This involves getting the testers, and the technical team, in a conference room (virtual or otherwise) and running tests together.  This presents the best opportunity to solve challenges and get updates since everyone's in it together.  Depending on the size of your group it can be challenging to find time/space for everyone.

One on one testing

This option involves scheduling one on one time for testers to connect with the technical team and test together.  This provides the highest touch experience as each tester gets personalized support.  This is a good option if specific users are new to testing or if they have a need for elevated support.  It doesn't, however, scale well if the group is big as each tester needs their own session(s).  It can also be very taxing on the project team as they'll have to sit on all those calls.

Rolling out an intake process

There's tons of ideas for work and projects floating around, and there's certainly no argument that there's tons of work to do, or that a lot of that is important and should get done. That said, this doesn’t mean that it ALL should be done.  Frequently teams end up getting bombarded with different requests from multiple angles.  Individuals will approach random team members and ask for some work, or executives will plan something out and assume it'll get done. 

The challenge in the tech team is to figure out how to setup an intake process to streamline, filter and accept work. This process should include a way to evaluate the value of the work (e.g. what the business gets out of it), as well as the relative effort of the work (is it possible to accomplish with current resources).  A good intake process results in several changes in how work is sourced, how it's accepted and how a team decides what to accept.  

While there certainly is a lot to it, one of the biggest impacts I've seen is for the business side; they now have to follow a process instead of just flinging ideas at you. This makes getting buy-in from the business critical to any intake process.  Not only are you changing things up for them, but you're adding process, which means things take longer.  There's a few things I've found that help reduce this impact;

Start early

Once you've determined a basic I take process start socializing it with your business partners.  This means letting them know what the plan is, and more importantly, how it helps them.   Giving the team loads of time to get used to the change will help blunt the surprise when it goes online. You can start early be constantly bringing it up in meetings, reminding folks when it’s going to go online, and providing documentation on how it works.

Talk to the top

Like any process change, be sure you're getting buy-in from the leadership of your business partners.  Ensuring the VP or Director is onboard will both get you an ally who will spread the word, but also give you a backstop.  This makes it much harder for someone to not follow the process since their leadership is onboard.  It also helps demonstrate you want to collaborate with the entire team instead of just pushing new processes onto specific individuals.

Be consistent

Once the process is in place ALWAYS use it.  Nothing will undo it more quickly than one person or project getting to skip the line.  This isn’t to say the process can’t or won’t be changed, just that it should be consistently applied across all requests / projects.  

Collaborate

Once you've created your basic process, share it with the business.  Explain to them why you started here, but ask them for their input.  At the very least this gets more buy in, but it's also likely you'll get some good ideas from it.  As the process matures, feedback from your business partners will also be a great source of ideas.  After all, they’re the ones who have to deal with it on a regular basis.

All hands on deck

Most of the time our work fits into the (insert your normal working hours here).  This means we may or may not see the whole team we work with at any given time, and we can reasonably expect to be unavailable when we go home to do things like not work.  There are, however, times when we need everyone to be available outside those hours.  These situations tend to be big deployments, massive outages and other (thankfully!) non-standard events.  While everyone knows they come up, they do frequently cause a lot of friction… after all, who wants to be dragged into the (virtual) office on a Sunday?

I’ve found a number of things help at least easy the pain of these events:

Plan it out in advance

When possible these events should be planned out in advance.  This is easier to do on bigger projects where you can predict when major events (like a go-live) occur, but to some extent this can also be performed through risk planning.  For example if you know a holiday is coming up and your system may be stressed, have more folks placed on call.  

Planning it in advance helps everyone plan for it; now they can not take holiday and they can move other personal things out of the way.  Planning it out also helps everyone see it’s an important part of the project/etc. And sets an expectation that its a required action vs. an optional event.

EVERYONE shows up

I usually serve as the project manager, so I’m rarely the one actually performing the go-live.  This means my presence isn’t as critical as the developers, but I still make a point of being in the room as things unfold.  This extends beyond my own personal sense of ownership of the project and into a sense of camaraderie.  If everyone knows that everyone else will be there during crunch time, it’s more likely they’ll show up.  Experiencing this stressful event together will help the team bond, and make it feel more like, well, a team.

Loosen protocol

Depending on the office culture this may or may not be a good tip, but loosening protocol (e.g. dress codes, eating at your desk, whatever) during these events helps to ease folks into it.  It also helps deflate arguments about people being available as they can be more comfortable… or at the very least makes it more palatable (well at least I can wear my jeans).

Clearly define what needs doing

This goes with the “plan it in advance”, but you should (ideally) have a plan in place for what needs to happen during crunch time.  This helps reinforce the “this is important” aspect of things, but also signals to your team that they aren’t going to be wasting their time.  It also gives you a finish line to point at and keep driving towards.