UKStar 2017

I spoke at the UKStar 2017 London, 27th - 28th February 2017.

This was a ‘conversation’ session. A new type of session that UKStar are trying out. Basically - take two speakers who submitted complimentary sessions. Let them talk for 15 minutes each and have a conversation amongst each other and the audience to discuss the topic.

The topic I submitted was “What does technical enough mean?” and the conversation is titled “Automation and people”

About the Session

“Automation and people” combines some of the fundament from my submission and some from Isabel Evans’ submission.

The UKStar site lists the individual submissions that Isabel and I entered. The following is the combined description that we agreed upon to describe the conversation session:

Are we technical enough? Do we need for a better User Experience (UX) for Test Automation: that is, the TX (Testers’ Experience) related to automating within a testing and monitoring process? Are over emphasising the technical and ignoring the personal?

Join the conversation with Alan and Isabel where we’ll talk about stuff like:

What levels of technical skills, knowledge and ability are required for systems development, and specifically for testing activities?.

What do we mean by “Technical”? – just Technical (IT) or also Technical (Domain)?

What types of technical knowledge support our testing (for example technical architecture, hardware as well as software, code, etc).

How do we keep up to date with the technology we test? If not, why not?

If the ‘technical people’ on the team don’t understand the system, how do we identify technical risks?

As the toolset we use matures, can we rely on it to support people better, or are the people driven by the technology they use?

How do we improve the Tester’s Experience of automating and working with more technical systems.

Original Blurb

Isabel’s original description is online on UKstar, as is my original submission.

I have also added my original blurb below:

I worry that I’m not technical enough.

I know how to code in multiple languages. I understand some of the protocols in use by web applications. I can debug in the browser. Using tools I can bend most systems to my will. I’m more technical than many testers.

But I worry that I’m not technical enough, and that neither are most of the people on the project. So there is a massive risk that serious technical defects will slip through and when found, will not be easy fixes.

I was using an application a few days ago. And simply by ‘using’ the application I managed to bring the entire web site offline. The root cause that was mentioned was a corruption in the JSON serialisation caused by concurrent access. I know what that means, I could test for that. But the project team had managed to architect a system where that could happen – but no-one spotted that technical flaw (which is architecture based) early. I worry that so many of our technologies are hard to test because no-one on the project is technical enough. Particularly not testers.

I work hard to increase my technical understanding. I know many people don’t. I don’t understand why not.

So what does “technical enough” mean for testing?

Takeaways:

A discussion of levels of technical skills, knowledge and ability required for systems development.

Technical does not mean ‘ability to program” – programming does

Do we understand the technical architecture? If not, why not? Because it helps us test.

Do we keep up to date with the technology we test? If not, why not?

When the ‘technical people’ on the team, don’t understand the system, how do we identify technical risks?

I submitted two conversations - one didn’t make it, so I’ll probably release that as a series of YouTube videos instead. Stay tuned for “Every system has a unique shape and none look like Pyramids”.