Tuesday, 25 July 2017

How to successfully submit to a Software Testing Conference - lessons learned the hard way

TLDR; Identify why you should be the one talking about a topic and hold that Why at your core as you build a short sales pitch for the conference organizers.

Regardless of how long you have until a conference submission deadline: 1 month, 1 week, 1 day, 1 hour. You still have time to submit.

And if you submit a passionate sales pitch with good benefits and features then you can submit successfully. Read on to learn how.

You can submit

I’m on the programme committee for UKSTar 2018. The closing date for submissions for this conference is 30th July 2017 - at the time of writing (25th July) you still have plenty of time to submit a talk.

People spend too long on submissions:

  • they often outline the entire talk prior to submitting
  • they write slides
  • they make sure they have enough material for the 25, 30, 40 minute slot
  • they work out where they are going to get the art work
  • they procrastinate in ever more creative ways.
What they should do is:

  • find a topic that they feel strongly about
  • identify their unique slant on that topic - their experience, “Why does no-one else talk about…”, “people don’t seem to realise that…”
  • focus that unique slant and that strength of feeling into a pinpoint burning flame of righteous passion
Then sell that passion in the form of a conference submission.

You need the motivation to:

  • have your point of view told
  • submit a talk
Everything else comes after you are accepted, and if you have any doubts about ability to speak, or creating good slides then allow the pinpoint burning flame of righteous passion to overrule them because everything you need to do, you will have time to do, after you are accepted to talk.

Some Written Guidance

I wrote a lot of notes on ‘how to submit for a conference’, but after writing a few pages, I realised that most of what I was writing was already covered by Rob Lambert’s Blazingly Simple Guide To Submitting To Conferences. I recommend you read this as Rob covers idea generation, overcoming common doubts, and guidance for submission.

I’ve added my outline at the bottom of this post in case it helps.


  • Read the call for papers - understand what the conference want
  • Copy paste the submission form to a text file
  • fill in the text file, never write directly to the submission form (browsers crash, forms fail)
  • find your “Why?”
  • create a boring title to guide you
  • Rant passionately, record it, transcribe it - that is your first draft blurb
  • Edit your blurb for clarity, to add more examples
  • When you edit, do not remove the passion, do not “corporate speak it up”
  • work on the title to make it a sales headline
  • avoid cute headlines
  • don’t tease with questions and promises - provide some actual tips, solutions and examples that you will cover
  • always be ready to paste it into the submission form, keep it in a ‘ready to go’ state
  • you are not writing the blurb for the web site, you are writing a sales pitch for the organisers
  • the blurb can be edited prior to going on the conference web site - you can make that clear in the blurb if you want to
  • focus on the submission, not the talk
  • you can do this if you want to
The UKStar call for speakers ends on 30th July 2017. You can submit if you want to.

Free Bonus Video

I created a video covering this material, with a small ‘case study’ and analysis of some older submissions and talks that I’ve put in to conferences - including failed submissions so you can see where I didn’t live up to my tips.

Free Bonus Notes

  • Intro

    • The point of this is to help people submit to and speak at conferences.
    • Conferences used to be the place where you went to hear ‘new’ and cutting edge material.
    • the internet does that now
    • Conferences are still relevant, but we have to use them differently
    • Selfishly
      • build your profile
      • gain new skills
      • improve your confidence
      • good for your CV or linkedin profile
      • free entrance to the conference
    • Philanthropically
      • share your experiences
      • share your lessons learned so that others don’t have to learn the hard way
  • What is a CFP/CFS

    • call for papers, call for speakers, call for speaking, call for submissions
    • conferences need people to talk at them
    • they create a call for papers CFP to encourage people to submit talks
    • the CFP describes any theme or topics they want to encourage
    • often describes the types of talks you can submit - conferences usually have mutiple types short talks, track talks, workshops, tutorials, keynotes
    • you can submit for all of these but tutorials and keynotes are more likely to be invited
    • the most important thing on the CFP is the deadline
    • why is the deadline so far before the conf e.g. 6 - 8 months ahead
      • review
      • decide on programme
      • balance programme
      • marketing and sales process for the conf
    • CFP is a call to action, and an opportunity for you
  • Finding the Motivation to speak

    • this is the most important step - figuring out Why you are going to speak, what is your purpose?
    • if you don’t have the motivation then you’ll never submit and the stuff you submit will be flat
    • this is going to vary between people, I’m going to describe some possible motivations see which drives you
      • motivated by the rewards and benefits provided by a conference - free entrance, free hotel, etc.
      • motivated by the rewards and benefits provided by speaking - more practice, improve skills
    • i don’t think they really work for me
      • for me, the reason I started, was that I was angry. I was sick of going to conferences and hearing case studies and presentations about how you ‘should’ do it one way, but that didn’t match my experience. And I wanted to make sure that there was a balance.
        • that’s one of the things that still drives me now
        • and its also one of the ways of overcoming resistance - your unique story, no-one else can inhabit that space
    • another reason I spoke was that certain topics I was interested in were under-represented, or not discussed at all
      • my early talks were about Model Based Testing, ways of improving as a tester, psychology and psychotherapy, free and cheap tools
      • and all of these were experience based, so in reality it was ‘my experience’ that was not being represented
    • diversity - it seems odd now but one reason I started speaking was diversity
      • yeah, an old white man with beard talking about diversity
      • but I was younger when I started, and I felt that many of the people I was seeing at conferences were ‘older and out of touch’
        • they were talking about theory instead of practice
      • if you are concerned that your gender, ethnicity, creed, belief systems… whatever - are not represented at conferences, then be part of the change for that by submitting to speak.
    • if you feel in any way under-represented or marginalised by conference programmes then make a difference
    • you have to find what works for you

      • I need something strong enough to give me a push
      • and I need to believe in the message that I want to deliver enough in the talk so that it carries me through the weeks it takes to go though the submission process, and then the months it takes to go through the talk preparation and preparation phase.
    • Case Study

  • Overcoming your resistance to speaking

    • after deciding on your motivation we then have to overcome the resistance that your brain is going to throw up
    • particularly if you haven’t spoken at a conference before
    • and you have to commit to a decision to speak, to overcome this resistance
    • typical phrases that bounce into your head
      • why would anyone want to hear me speak?
      • i don’t have the experience to talk about this
      • there is nothing new in what I have to say
      • but this will just bore people
    • doubts and impostor system
      • generally people will call this impostor system and you can look it up but that would be procrastination
      • you get over that by just doing it
      • if you want evidence then go online, look at conference programmes, look at videos and consider
        • most of what you saw wasn’t new
        • the speaker might not have been particularly experienced
      • the only way to gain experience is to do it, and unfortunately with public speaking we learn in public
      • good speakers, are simply more experienced, there are ways of getting ready for a talk that we will cover later
      • if you use “I haven’t done it before” as an excuse to not do it, then you will never do it
      • fall back on your motivation, if it is strong enough then it will carry you through, if it isn’t then revisit your motivation because that will push you over this hurdle
    • every conference has people who have never been at a conference before and people who have never heard the subject before
    • and in your talk you will present your view, your experience, your lessons learned, in your unique style and that has never been presented before, that will be new and is worth putting out there
    • you overcome resistence by taking action and doing it, either because you know the rewards are worth it, or because your motivation is strong enough
    • you can procrastinate and do a lot of research and reading but the step that will make a difference is committing to action
    • that’s it. do it, commit to taking the step of submitting and you overcome your resistance
  • Case Study

  • Planning for the submission

    • once you know why you are going to speak you build a plan
    • this isn’t procrastination
    • this is making sure you don’t have any excuses
      • if you don’t do this then your subconscious can give you a get out clause for not speaking “oh I forgot about it and missed the deadline” “oh dear”
      • many conferences will accept submissions after the call for papers has closed so you don’t get to use that excuse, but we want to avoid that happening in the first place
    • so we are going to build a set of dates
    • look at call for papers page
    • make a note of the important details
    • make a list of the dates
      • check that you are free when the conference takes place
      • add the date of the conference as a ‘possibly attend conf X” in you calendar
      • find the deadline for submissions
      • add a calendar entry for the deadline (create some reminders)
    • make a list of the requirements
      • what do they need? a photo, description?
      • add a calendar entry for gathering these a week or so before the deadline
    • create a checklist
      • you can already tick off a few items
      • [] add conference CFP deadline into calendar
      • [] add conference dates into calendar
      • [] add conference material prep dates into calendar
      • now add
        • create ideas for talk
        • draft talk description
        • review talk description
        • write submission
        • review submission against CFP
        • add a todo for each item on the submission (find head photo, write bio)
        • submit talk
      • it doesn’t have to be detailed at this point because we can add items later
      • schedule some time in you calendar for working on the submission, it doesn’t have to be anything more than “work on conf submission” because you are going to work from your checklist
      • don’t write down anything about creating slides, or looking for images, because at this point we are working on a submission, not the talk
  • Creating an idea

    • hopefully your purpose will lead you to an idea if you are speaking because a certain topic or viewpoint is under-represented
    • but if you need to generate ideas for a talk then draw on your experience
    • think “back”
      • what was hard when you started, how did you learn to make it easier, what is it like now?
      • how have your views changed? what did you believe? why? what changed your mind? what do you believe now? how does that help you?
    • think “now”
      • what cool tool are you using that you don’t see people talking about? how does it work? what does it do? can you demo it? how does it help you?
      • what did you learn recently? how are you improving that? how will you learn more? how does that help you? what has learning it changed?
    • think “success”
      • what did you and your team do recently that worked really well? what did you do? what problems did you face? what did you learn?
    • think “annoyed”
      • what in the test community annoys you because it doesn’t match your experience? use of technology? approaches to testing? a viewpoint that is getting attention that misses the point? expert pontification that you have counterexamples for?
      • what were you told, that was just plain wrong? mandates? methodology? approach? tool choice? how did the wrongness manifest? how did you make it right?
    • think - why does no-one talk about this?
    • think - I wish people would stop saying…
    • think
    • always draw on your experience, it means that when you come to do your talk you will have strong basis and bedrock to talk from.
  • Case Study

    • create some from scratch
  • Testing an Idea

    • this is not about ‘resistance’ and saying ‘not sure’, this is about focus and building more passion into it
    • when you have a bunch of ideas you need to hone in one (or two) to create a submission
    • It might be easy, you might have one that you are so passionate about that it swamps all others, in which case you can jump to fleshing it out
    • In order to decide between multiple ideas you might have to flesh it out, map it to the CFP submission types
    • CFP often have multiple submission types - lightning talks, short 8 - 10 minute overviews, 30 minute talks, 4560 minute talks with Q&A, 90 minute workshops, half day tutorials
      • which format does your idea best map on to?
      • then you will know how much information you need to build and if you can pull off
    • Why? What? Who? When? Where? How
  • Creating a Submission

    • A submission is more than an Idea, it is a sales pitch Sales pitch
      • stress benefits, rather than features
      • sell your passion and experience on the talk - why should it be you talking about it, rather than someone else?
    • A way of refining your talk
      • don’t write your talk at this point #1 mistake people make - writing the talk at this point Identify why this is important and what is your driving purpose, what is the essence Main points that you want to get across
    • what I usually do - rant, record, transcribe
    • Title
      • start with a plain old boring title
      • create multiple titles
      • make it scannable rather than ‘cute’
      • your title is your marketing department - it is there to get attention
      • your description is your sales department - it is there to close the deal
  • Reviewing your submission

    • who for, why
    • description
  • Practical tips for submissions

    • always cut and paste into submission form
Resources to help you with submitting

Monday, 17 July 2017

Use your malevolent powers for good

TLDR; I can fool myself into comfortable complacency about code when programming. I can use testing to banish this false glamor.

“Why might we be villainous? First, because we can be… that’s a big deal…”

Thursday, 13 July 2017

Using Browser Dev tools to investigate and bypass GUI error reporting bugs

TLDR; Learning to use browser dev tools can help you investigate defects that have no visible output on the Web GUI, and they can help you bypass problems in the real world.

One common bug that I find a lot with web applications are errors that do not get reported to the user.

Monday, 10 July 2017

Are you stable, or complacent? Is it time to experiment yet?

TLDR; If you are not sure that you should experiment with new techniques then find ways to monitor the domain first, you might be able to learn from someone else’s experience.

When things are stable, and they are going well, a hard question to answer is “Is it time to experiment?”.

Friday, 7 July 2017

How to improve your software testing skills by following Isaac Newton's strategies

How to improve your software testing skills, by following these strategies, that’s how. Based on a quick book recommendation - Isaac Newton by James Gleick I want to explain how we can learn lessons from his approach to his work and career.

Isaac Newton didn’t just work from contemporary materials. He did, as he was starting out, and when he entered officialdom, but he mainly worked from his own research and from older texts. We can do this. Keep going back to the source for any contemporary material, then look at the source for that and find older material that you can mine for goodness.

Monday, 3 July 2017

New ebook version of "Automating and Testing a REST API" released

TLDR; Updated my “Automating and Testing a REST API ebook to have 50 more pages and now covers JSON and XML

For the last week or so I’ve been fixing up the editing todos on “Automating and Testing a REST API” that I collated back in January.

Thursday, 29 June 2017

How to use your testing skills to bag a SNES Classic Mini Pre-Order

TLDR; Identify Oracles, automate observation of changes, understand GUI/Mobile differences, harness tool support.

At the moment Nintendo have initiated a voluntary viral distributed denial of service attack which hits retailers on demand.

Wednesday, 24 May 2017

Quaere, Heuristics, Mnemonics, and Acronyms

Don’t limit yourself to a set of attributes and words, seek more, develop strategies for identifying new concepts and ways of exploring them for then you have manifested the spirit of Quaere.

How might I describe the process of model building?

I was writing some notes on ‘Testing’ and trying to think through how I might describe the process of model building.

And I wrote down a few words:

  • Questioning,
  • Exploration,
  • Experimentation,
  • Analysis.
Useful words methinks.

Friday, 19 May 2017

How to use JavaScript Bookmarklets to Amend Web Page Example [Tutorial Text and Video]

TLDR; When you learn to manipulate the DOM with JavaScript you can create simple tools and automate from within the browser and use bookmarklets to make the code easy to execute and sync across different machines.

Wednesday, 10 May 2017

Resolutions and Trends in Software Testing Xebia Meetup

TLDR; Map resolutions every day. Evaluate if you are living the purpose you set. Go deep with your current knowledge and it will allow you to adopt the trends when they become strong influences on your work.

I gave a short 20 minute talk (including Q&A) at Xebia in Hilversum in January 2017, the evening before TestBash Netherlands.

The aim was to discuss New Year’s Resolutions and Trends for Software Testing. I filmed the talk on my mobile phone (hence the strange angle).
  • How to keep resolutions
  • Figure out your ‘slogan’
  • Own your definitions
  • Build on what you know
  • Weak Signals and Strong Signals
  • Responsibility
  • Implement

Monday, 8 May 2017

TOTE Model For Testers - Test, Operate, Test, Exit

TLDR; Map the TOTE (Test, Operate, Test, Exit) model on to TDD, Exploratory Testing, Design processes, Analysis, Learning, Decision Making and Problem Solving.


In 1960, George Miller, presented a model of problem solving which he called the T.O.T.E model
  • Test, Operate, Test, Exit
The notion being that you loop around a [Test, Operate]* cycle and when your Test is complete, then you have done enough Operations and you can Exit.

It was a model of problem solving, or decision making.

I wrote about it a while back on the blog and in my NLP papers

You can find George Miller’s book Plans and the Structure of Behavior on archive.org. He describes the TOTE model in that book.

TOTE in Action

Showing T.O.T.E in action. I drew this dynamically to make the point that it is a cyclical process and we Test to decide if we continue to Operate, to Exit the process, and to change what we will operate.

You can see the 9 second version on Instagram

Test to build a model.

And sometimes we exit because things are Good Enough, but we still need criteria to determine what Good Enough means. And sometimes we Operate to learn if something is Good Enough.

TOTE for learning

At the time that I explored the TOTE model previously I didn’t make the connection that arc from Operate -> Test was also a feedback process.

In the TOTE model the Test learns from Operate, which we can easily map on to Exploratory Testing.
  • we come up with an idea to explore (Test)
  • we explore (Operate)
  • we learn from that (Operate -> Test)
  • we derive new things to explore (Test)
  • etc.
And we Exit when our time has finished or we have covered our ideas or whatever other ‘exit’ criteria we started our testing with.


I’ve also written a lot more code using TDD. And I know that my TDD process very often resembles a TOTE process.
  • write some @Test code (Test)
  • see if fail and write some code to make the test pass (Operate)
  • write more @Test code to flesh out the design (Test)
  • and repeat
Until our design is complete, or our review of our @Test and code can’t come up with anything new, and we have compared it with our statement of intent, etc.

TOTE Learning

We could view this as a completely well defined process of evaluation where at every ‘Test’ point we know exactly what we are deciding upon and use the pre-defined evaluation criteria.

We could also view the Operate process as a learning process which feeds into the Test process and explains the cycle. Each time we ‘do’ something (operate), we learn something which we feed into the Test process.

I missed the learning process inherent in the Operate -> Test arc first time around.

I won’t do that again, and that makes TOTE an even better model for the type of work I do.

A model worth investigating.

See also
PS. If you want your own T.O.T.E model diagram then feed this into Graphviz or WebGraphviz

digraph G { 
  node [shape = "rectangle"];
  Test -> {Operate Exit}
  Operate -> Test

  subgraph { rank = same; Test; Exit}

  Exit [shape = "ellipse"];

Thursday, 27 April 2017

Notes on Structured Analysis and System Specification by Tom Demarco

TLDR; Time unfortunately has not been kind to this - it still has moments of well worth reading but it also has sections where you hope no-one follows the instructions lest they doom the project, but the chapter on estimation is well worth reading.

I haven’t read this book since University but I vaguely remembered it as one of the books that taught me system modelling, a skill that I still rely on to this day.

Wednesday, 26 April 2017

Do you know what your framework is doing? A quick use of WebPageTest.

TLDR; Frameworks implement an abstraction layer so we don’t have to bother about it. But, what if the implementation is doing stuff you don’t want? How do you know? Find tools that let you observe inside. WebPageTest.org does that for web pages.

Tuesday, 25 April 2017

Notes from Glenford Myers Advances in Computer Architecture

TLDR; Abstractions are not new, have never been easy, and have always been important when architecting our Systems.

Monday, 24 April 2017

A Quick Intro To BookMarkLets

TLDR; Bookmarklets are an easy way to have custom javascript to support your testing that sync across browsers.

It took me quite a while to start using Bookmarklets but now that I’ve started… ooh, just try and stop me.

Friday, 21 April 2017

Lessons from the making of "Are you Experienced"

TLDR; Learn your skills and techniques. Then learn your tools. Mastery of tooling can lead to new techniques and new ideas. Continue to learn your theory, skills and techniques. Continue to master your tools.

I’m not exactly sure what I was hoping to learn when I started reading “Not necessarily stoned, but beautiful” subtitled “The making of Are You Experienced” by Sean Egan - a book which chronicles the making of the debut album by the Jimi Hendrix Experience.

But I pulled out information about Hendrix guitar playing that I didn’t know.

Thursday, 20 April 2017

Lessons from "Platoon Leader" by James McDonough

TLDR; war is horrible. Lessons can be learned from it. Would a distinction between defensive measures and pursuit, help your testing? I often see many test strategies that are highly defensive, but low on pursuit.

I do turn to books written by people who have fought in the army for lessons on tactics and leadership. I read “Platoon Leader” by James McDonough because it was a first hand account of a rookie leader in the Vietnam war.

Tuesday, 18 April 2017

Normal is the rarest of all states

TLDR; if you blindly copy an expert you do not learn context, you replicate mannerisms and lose their subtlety. Consciously analyse their actions, learn their skills, and apply them individually in a coordinated fashion.

When you learn about ‘context’ what disciplines do you learn from?

Thursday, 13 April 2017

That moment where you should have automated but didn't

TLDR; I migrated blogs over to Hugo and I didn’t automate because I was only doing it once, I should have automated because I actually migrated 450+ times (at least once per post. Find results at testerhq.com

Thursday, 30 March 2017

How do you interview testers?

TLDR; I received an email asking if I have any good interview questions and the short answer is "No". slightly longer is "I don't know, I do not know the person you are interviewing, or why you are interviewing." and since that could come across as arrogant and unhelpful, I thought I'd explain in a blog post that I audition, rather than interview based on a set of questions.

Friday, 17 March 2017

Top Ten Books For Testers for Huib Schoots

Huib Schoots recently asked for a top 10 books list for testers. I had to think hard when I wrote my list.

Bulleted below you can read the list I created. I added amazon links to the book so you can find them easily.
Only one of my titles had other people listing it as a shared title - Boris Beizer's book. Sadly,
it didn't make the top ten, so if you do read the above books then you'll be joining an exclusive club of Testers in the know.

And if you read the other books you'll be initiating yourself into an even more exclusive group. The group of people who have read all those books.

I think I added some of these books into the related reading section of "Dear Evil Tester", which has additional notes on why the books are important to me.

(This post was originally written around May/June 2013, but for some reason never left draft until 17/3/2017)

Sunday, 12 March 2017

Representation and Meaning: relating Programming, Testing, Coding and Checking

TLDR; older computing books and papers have a lot of really useful information - read them. Programming has an ‘easy to automate’ level called ‘coding’, with a similar relationship to ‘testing’ that ‘checking’ has. Assert as well as Check. Developing includes Testing and Programing and other stuff.

Some quick notes from a reading of the book “Representation and Meaning”, published in 1972, compiles various academic papers from 1960 - 1965.

The first paper in the book “The Heuristic Compiler” by Herbert A. Simon contains the following quote at the start of section 2.2
‘One distinction between the restricted, relatively simple tasks we call “coding”, and the broader, more difficult tasks we call “programming,” is that the latter may encompass the selection or design of an appropriate problem representation, while the former do not.’
Which made me think of the various discussion about “Testing” vs “Checking” and “Automation”, specifically:
  • we can’t automate ‘testing’, we can automate ‘checking’
  • why don’t we talk about “programming automation”?

We can’t automate ‘testing’ we can automate ‘checking’

The quoted statement about coding and programming seems to have a similar relationship to statements about checking and testing.
  • Programming and Testing
    • broader and more difficult than coding and checking
    • selection and design of appropriate problem representations
  • Coding and Checking
    • a representation of the work done when ‘programming’ or ‘testing’

Why don’t we talk about “programming automation”?

We don’t talk about “programming automation” because we automate coding.
  • code completion
  • macro systems
  • annotations for code generation e.g. projectlombok
  • transcompilers
It almost seems abnormal to consider the act of coding without thinking of how we can automate it, we have been doing this to coding since we started coding.

My first major project was the generation of program code from JSP diagrams. In the course of that project I automatically generated ‘C’ and ‘Cobol’ code.

The paper by Herbert A Simon, referenced above describes an exploration of automating the ‘programming’ tasks by treating it as a problem solving exercise. The automating of ‘coding’ was already a given and taken for granted.

A Diagram

I drew a diagram in my notes from reading the book.

I added some extra information to my diagram:
  • “…” to represent the fact that ‘developing’ does not consist of only programming and testing
  • both programming and testing have levels of representation - the stuff we can easily automate and the stuff that humans do (which we find harder to automate)
  • we automate at the ‘easy’ level
And for public consumption I have tidied the diagram, and I added additional information:

  • “-” to represent the fact that every named ‘high level set tasks’ has a lower level (which may or may not have a name) of easy to automate tasks
  • I added ‘asserting’ into the ‘checking’ representation because…
    • we check that a particular condition is met e.g. if(x==2){return false;}
      • we can report on the check in reports and monitoring
    • we assert on it to ‘halt’ execution of an automated process


I try to develop a model of ‘automating’ as part of the Software Development. This means I avoid thinking of “test automation” or “automation” and I think that allows me to think broadly about tool support in the development process than limiting it to ‘testing’ or ‘testers’.

I think this makes it easier to communicate to people who identify with the role of ‘programmer’. Because we no longer talk about ‘automating testing’ we talk about extending the normal process of automating our development approach to include:
  • executing code flows in the application
  • checking results
  • asserting on those checks
And… much value exists in the documentation trail of computing history, seek it out, do not ignore it.


Wednesday, 8 March 2017

Ambiguity Detection and Weaponisation for Software Testers

TLDR; You can learn to detect ambiguity and then weaponize it for your testing. Do you think I meant that? What else could I mean?


Can you identify ambiguity in written, verbal and visual communication? If so then you can apply that skill during your testing to give you ideas of where in an application to test.

In the places that you perceive ambiguity, when you test there, you might find an easy win due to different expectations between project staff e.g.:
  • stakeholders believe they asked for Y
  • development team thought they X
  • managers push for Z
  • etc.


You can also use your skill to improve your own communication and avoid ambiguity:
  • make any issue or defect reporting clearer
  • have concise statements of risk that become harder to ignore
  • avoid ‘triggering’ development staff when you talk about potential system malfeasance
  • etc.
And you can expand on the identification of ambiguity to the harnessing of ambiguity in your testing:
  • Do you perceive the validation rules as ambiguous? Can you create data that validates but should not?
  • Could you traverse the entity states ambiguously? Can you move the entity into states that it should not validly enter ‘yet’?
  • etc.
And if you feel particularly brave then you can harness this in your test process:
  • Write your ‘test strategy’ and ‘test plan’ such that it gives you more flexibility than ‘they’ want you to have.
  • Communicate ‘risks’ and ‘issues’ in such a way that you generate increased fear and concern about the fellow to achieve your aim of having it worked on.
  • etc.

Development & Homework

I estimate that there exist well over 3, and possibly over 11 million, different ways to develop your ambiguity detection and utilization skills.

On the assumption that you read this at home, relaxing in your easy chair, and reflecting on your testing skill development, I suggest that you could:
  • find some politician speeches on the YouTube and listen for ambiguities
    • in speeches, politicians often provide high level generalizations which sound specific in intent, but lack clarity of end results and have no implementation details
  • find some politician interviews on the same or similar video platforms and listen for ambiguities
    • do they answer specific (Yes/No) questions with long answers? Do you think they tried to avoid the question? Did they they avoid ambiguities in the question? What can you read into their answers? What intent might stand behind their answer?
Look for multiple interpretations - when you find something that they ‘might’ have meant, look again at what else they might have meant, and then again, and then again. I suggest you stop when your answer reveals to you that they form part of an alien lizard race conspiring with the Illuminati to achieve world domination, because that model probably does not match reality.

If you want to antagonize your family then play the “did you mean?” game. For their every utterance where you detect ambiguity you reply “Did you mean …?” and supply an outlandish alternative meaning. Advanced players might consider not waiting for a response and instead chain “Or did you mean…?” with additional alternative interpretations in rapid fire. For maximum effect, you should continue to play the game even when faced with slammed and locked doors, in the modern world, you can continue to contact your family via up to date communication channels such as WhatsApp, FaceBook and SMS messaging.

I harbor no doubt that you can find your own ways to practice these skills.

Find your own ways to practice these skills.

Friday, 17 February 2017

Harness Your Ruthless Efficiency as MVP in testing and development

TLDR; Ruthlessly look at your process and incrementally improve your efficiency. Take the same attitude when testing and developing and harness MVP as often as you can.

In this post I’m going to describe focus and how you can apply that in your work, not just for testing but for software development in general with examples.

On the morning of 17th Feb 2017, I created an Instagram video on ‘focus’ and it was about… how ruthlessly efficient we can be if we focus.

The Monty Python Test Tactics

And it was partly inspired by Monty Python with their Spanish Inquisition sketch. They have three main weapons, four or five, but it’s surprise, fear, and ruthless efficiency.

Wednesday, 15 February 2017

Should I test at the GUI Level or the API Level?

TLDR; Where to test? Can you isolate the functionality? If so, test the isolation most heavily. Then look to see what integrates, and how it integrates. Then test the integration as heavily as the ‘how’ requires.

Question: Is there a rule of thumb when deciding to test at the GUI level or API level? Are any rules to help decide when to test at one level over the other?
Answer: I don’t think I use a simple rule of thumb. But I will try and explore some of the thought processes I use to make the decision.

When I am trying to decide whether to test at the GUI or the API I have to figure out:
  • what am I trying to test?
  • can I isolate the functionality I’m testing to a specific ‘level’?

Tuesday, 31 January 2017

How to test a text adventure game - some notes on Testing RestMud

TLDR; RestMud has JUnit Unit @Test coverage, functional integration testing, REST API testing with Jsoup and Gson, Bots for multi-user and model based testing, Postman and GUI based exploratory testing.

I’m getting RestMud ready for some workshops later in the year and this means:
  • making sure a player can complete the maps I have created
    • I’m OK with some bugs (because they are for testers), but I need them to complete because they are games
  • making sure they can handle enough players
    • I imagine that we will have a max of 20 or so people playing at a time
  • making sure I don’t break existing games
    • with last minute engine changes
    • with new game maps
    • with new game commands and script commands
As most of you reading this will realise - that means as well as developing it, I need to test it.

RestMud Text Adventure Game for Testers Walkthrough

I have created a walkthrough for the RestMud game I released last year.

Why? Because I have had a few people email me asking for tips.

  • This is a full walkthrough
  • Start to finish, every command
  • It will not improve your technical skills
  • If you don’t play the game with dev tools on then it might not be obvious why you use some of these commands
  • there is a full map at the end of the walkthrough, I put it at the back because you should only use it in an emergency
I recommend:
  • use this sparingly
  • go as far as you can, and only if you get stuck to you use it
  • search for your location id if you are stuck to jump to the correct hint
  • make your own map
You can find the walkthrough and a hand drawn map on the RestMud game page.

PS. The walkthrough was generated by an automated script that played the game to check that it completes.

Thursday, 12 January 2017

What do you do? As a Tester, when you are asked for ROI calculation

TLDR; push back, ask questions, and if all else fails - plan it as a manageable set of tasks

At the Test Automation Guild I was asked a question about how we calculate ROI for Test Automation. And its a hard question for me to answer in 30 seconds when I don’t know enough about the situation the person asking the question finds themselves in.

Because testers are often asked by managers for information that the manager should really be dealing with and which does not seem to add value to the process and which we are concerned trivializes or views the process from the wrong perspective.

I know this is a difficult position for testers.

And I know testers are asked to do this.

I empathize. I’ve been there.

And I want you to be able to take this less seriously - consider that your only warning for what you are about to receive.

So I will attempt to provide tactics to help with the situation.

Monday, 2 January 2017

Hack the JavaScript Evil Tester Sloganizer to Generate Random New Year's Resolutions

I wrote a blog post for the new year:
And in there I noted that if you go off to the Evil Tester Sloganizer
and type this code

for(var x=0;x<100;x++){
console.log("-" + process_sentence(sentences[30]));}

Then you’ll get a bunch of New Year’s Resolutions printed out to the console:

Lessons Learned from Arnold Schwarzenegger Applied to Software Testing

Lessons Learned from Arnold Schwarzenegger Applied to Software Testing

TLDR; Start emulating people, use your job to learn, keep training,  identify other people's strategies, experiment to see what works for you, make your own tools, harness your uniqueness.

Everyone that is successful in their discipline and is prepared to tell their story, we can probably learn lessons from. Particularly if they are someone who’s really driven toward certain goals.

With Arnold Schwarzenegger, you’ve got the benefit that he has had multiple careers or multiple things that he has done throughout his life, and each one of them he has had to work for and practise hard to achieve.

I read Arnold Schwarzenegger Autobiography “Total Recall” and I made some notes, and I’m going to turn these into applied notes for learning how to improve our testing.