Company: Compendium Developments Ltd
Role in Company:
Country: United Kingdom
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?
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.