Ep 39 – I Can Teach You, But I’d Have To Charge

Okay, a few things before we get started:

I am going to be at the pre- and post- testbash meetups, come at me testing folks!
I will be bringing my mic along to testbash, if people want to be on the show! I can do full interviews or shorter vox-pop style segments, so hit me up if you want in on it! I’m also talking to Mark Tomlinson and others regarding a podcast mashup, so I’ll keep you upto date on things in the works there!
I finally got selenium (both webdriver and IDE) installed, so going to start playing around with that and get started on my 2016 goal of getting some automation under my belt. I’m armed with some resources from Richard Bradshaw12 and I am ready to go!

And now, on to the show!

At the moment I’m doing some brief preparation to have a couple of apprentice developers shadow me for a while as part of their training. It’s hard to know what to show them, and I want to make sure that I’ve got both planning and testing work I can do to show them the breadth of work the QA/test team do, and this will give them an overview of how we use jira.

But they’re very new to all this stuff, so I want to make this more broadly useful for them – not just showing them what I do and what tools I use, but how and why, and therefore help them to become good developers who do some of this themselves and also understand the worth of QA/test beyond breaking shit. Though I will also show them how I apply the knowledge I have to the system to try and break it.

My first port of call was Katrina’s pathway for non testers3. I’ll send this link to the department head in charge of their training, but for my session, I’ll use two or three specific parts, depending on how much time I have/how long we spend discussing these ideas.

The first thing I want to use is a blog post around the concept of testing being a team responsibility1. At our place, the devs own the automated checks – they add acceptance checks (based on AC) for all stories, and run those before it comes to me. If they don’t pass, they fix, then it’s ready for me to test. This means there are very few circumstances where I reject a story based on AC – either something has been missed because people are human after all, or there’s something in the AC that is 1) too complex to write automated checks for or 2) the automated checks can’t cover (visual stuff, or really custom things).

This means that the devs have some ownership and investment in their code and the tests.

The next thing I’m going to use is a pdf that covers sources for test ideas5, because ‘where do you even start testing?’ is something I’ve heard. This document is a list of things to consider when starting testing a feature, and covers everything from the obvious (the capabilities and purpose of the system) to the more obscure (rumours around what’s causing the dev team issues, domain knowledge etc).

This will also help explain why I’m involved in planning sessions, and scrums that have no relevance to me – the first few scrums of a sprint I have nothing constructive to add, more often than not, because it’s rare stories have come to me by then. But I’m still part of a team, and I’m still involved, and I learn a lot. Knowing what’s causing devs issues means I know what work might need extra testing, and may be risky. Its both a way for me to plan my work based on when I’m told to expect to get stuff sent to me, and recon for what I might face come testing.

The last thing I want to talk to them about is about testing in an agile environment6, which is useful, I think to all members of an agile team, especially for people new to agile. It covers how agile applies to a tester specifically, but the idea of agile is to promote team cross-functionality, and so knowing this stuff is useful. Its also good to know what to expect from working with testers outside of bugs, like being proxies for stakeholders and users, which will be useful.

I don’t think I’ll get through all of it, and it may be slightly overwhelming, but I’m hoping it will be mostly useful, and I can give them resources to learn from and help them become good developers, and that’s what we’re here for.

I think that’s a decent enough intro for people who aren’t testers and presumably have little interest in becoming testers, but I’d be interesting in hearing what people with more experience of this kind of thing think. Do you teach people differently? Have I missed anything?

Footnotes

[1]https://dojo.ministryoftesting.com/lessons/podcast-richard-bradshaw-test-automation
[2]http://www.thefriendlytester.co.uk/search/label/automation
[3]http://katrinatester.blogspot.co.uk/2015/11/testing-for-non-testers-pathway.html
[4]http://testobsessed.com/2011/09/testing-as-a-whole-team-activity/
[5]http://thetesteye.com/posters/TheTestEye_SourcesForTestIdeas.pdf
[6]https://dzone.com/articles/agile-testing-principles

Ep 15: So Cunning You Could Pin A Tail On It And Call It A Fox

Test plans, cases, charters, etc.

I honestly kind of thought all these were kind of different things in some way? It was surprising to find out that they are all basically the same thing.

I generally do a mix of planning tests out when writing AC and using how I’d test the feature to make sure I’d hit most of the edge cases. As I’ve said before, I also use this time to strive to figure out how the client would use this feature, so we can deliver a good product to the client.

So this is where I make any notes for that specific feature, if I need to get anything from the devs on deployment, if I need any test data from the client, things like that go in at the start.

When the feature comes to me, I will have more context – depending on where it is in the build I may have more context about the project, and the client, I may have more features that will interact with each other to consider, I’ve got information from testing other parts of the system, so all this information comes into play when sitting down to test.

I follow the AC as I test, to make sure the basics are covered, but then I test for the best solution we can offer – this can be testing for accessibility, usability, how it looks, if the flow makes sense.

Then there’s making sure it fits with the client, and with the rest of the product.

This also works as a vague form of prioritisation:

  • Does it work as we have planned it to?
  • If I can’t use it at all, can I tell if it’s fit for purpose?
  • Does it fit the need we’ve made it for?
  • Regardless of if it passes AC, does it actually work as needed? Is rework needed?
  • Can it be used by users with different devices and software?
  • Can it be used easily by all users?
  • Does it look right?
  • Per designs/wireframes
  • Subjectively (tricky, but there can be consensus if something’s obviously off, or it’s a good opportunity to get UX/Design/client feedback

And I think being able to prioritise, even vaguely helps. The issue with testing, when you test and not check, is that there’s very rarely a single right answer. This means you have to figure out what the best option is, taking into account all sorts of things like budget (time/money), how complex the issue is, what the client wants vs what I think is the best option vs what the devs think. Then you have to formulate the best option or solution from there. Sometimes you can push it back to the client – if there is no obvious better answer, and there’s no real effort needed to change it, we may just talk to the client and give them options and see what they come back with.

So you have to engage with the product to test it, and I think this on the fly method of planning and testing bringing all the experience and context you’ve got over the course of the project works really well. I think having AC gives me a framework to work around, and I can test outwards from that core functionality.

I think it helps that I test manually. I think or assume that if I did more automated testing I’d probably do a bit more planning out in the ‘how I’m going to build/code/modify tests’ in order to hit all the cases. Maybe. Feel free to tell me I’m wrong.

I’ve started going through the Black Box Software Testing course1, which is supplemental to the Rapid Software Testing course that James Back puts on2, which is something I definitely want to go on (I can’t go to the one in the UK in October, unfortunately. Next time he hits somewhere close, maybe!).

As an aside, reading those slides makes me glad for my biochem degree, I’ve got some decent experimental and scientific thinking background to apply to testing.

As an aside to that aside, I did a lab based dissertation, and despite writing out all my lab protocols and following them to the letter, my experiment didn’t work. We tried various different things and made changes to the protocol; still wouldn’t work. Eventually my supervisor shrugged and said it was too close to the deadline to try again, and he had no clue why the bacteria weren’t playing nice, they just weren’t. So I had to write a dissertation on why my project failed.

I am used to planning things out and it going wrong for no discernible reason.

I can see how rapid software testing would be a bit worrying though. If you don’t write it down, or plan it out, how do you know you’ve not missed anything? Which is why I like having AC, and I make notes about what works (and what doesn’t), so there’s a paper trail of what I’ve done. I just think that being able to have that flexibility can be useful.

Footnote

[1]http://www.testingeducation.org/BBST/
[2]http://www.satisfice.com/rst.pdf/