1. - A discussion of levels of technical skills, knowledge and ability required for systems development.
2. - Technical does not mean 'ability to program" - programming does
3. - When the 'technical people' on the team, don't understand the system, how do we identify technical risks?
4. - Do we understand the technical architecture? If not, why not? Because it helps us test.
5. - Do we keep up to date with the technology we test? If not, why not?

Alan Richardson has over twenty years of professional IT experience: as a programmer, tester and test manager. Author of 3 books and several online training courses to help people learn Java, Technical Web Testing and Selenium WebDriver. He works as an independent consultant, helping companies improve their use of automation, agile, and exploratory technical testing. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.

This talk is paired with UX – What About TX for Test Automation?as part of a conversation track on Automation and People
 

 

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?

 

 

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.