Michael Ambrose - Teach them to Fish
As I implement my plans to upskill my testers in development capabilities to allow us to reach ever more clever ways of testing, there will be a risk in us becoming a speed bump on the team velocity as we try and juggle old and new ways of testing. I'll be discussing my plans to help mitigate this risk by also upskilling the developers in testing, so they can help pick up any slack, and looking at the possible consequences that can come of this - both good and bad...James Coombes - who should do testing and what can they test?
People test for a variety of different reasons, but mainly it is to prove a hypothesis that something either works or doesn’t. When used in an iterative manner (fixing bugs then retesting) this can be used to improve quality. Indeed without testing it is practically impossible to say whether something works or not.
For me QA is a form of risk management, we test to ensure that our reputation as a company and organization is well respected for producing high quality software. We (the company) all own quality. This talk will focus on the reason for test and who should do the testing. A series of short examples will give insights into who should be doing testing and the key areas a stakeholder can contribute to the overall task of testing. It may or may not be obvious, but a multitude of other people apart from QA can undertake testing, and we will explore who they are.
These are great, don't get me wrong. I like them. But they are also a bit clinical, rational, purposeful. And if I'm being honest, at the end of the day, these might not exactly be the reasons why /I/ test, or what keeps /me/ in testing.
So I'd like to explore what other reasons there might be. I'll be reflecting on which (personal, subjective) value testing brings to me rather than what value it might bring to my team or company. And being true to my craft, I'll be wondering if this experiment will reveal any new information and if yes, what I could be doing with it.
In this talk, I'll instead view testing as a number of different instruments that can be used in an arbitrary number of dimensions. Further, I'll suggest that testing can be applied not only to a system, but to descriptions of that system, to models of that system, to abstractions of that system, to a system which is testing that system, and to a system which is testing the system which is testing that system. And so on. It's testing all the way round.
I'll finish by proposing a definition of testing that I think might capture this wide applicability. (slides)
For me QA is a form of risk management, we test to ensure that our reputation as a company and organization is well respected for producing high quality software. We (the company) all own quality. This talk will focus on the reason for test and who should do the testing. A series of short examples will give insights into who should be doing testing and the key areas a stakeholder can contribute to the overall task of testing. It may or may not be obvious, but a multitude of other people apart from QA can undertake testing, and we will explore who they are.
Lee Hawkins – What is Testing? It depends ...
There are many definitions of what “testing” is – they can come from many sources, such as certification glossaries or the school of testing you align yourself with. But maybe we focus too much on the idea of a definition and focus too little on the wide range of perspectives of what testing means to different stakeholders. Let’s explore a few different perspectives together. (slides)Aleksandar Simic - Testing is ...
An attempt to explain what is testing by telling a two days testing story - a story that can be shared in various ways.Karo Stoltzenburg - I test, therefore I am
When you go on a lookout for answers to why we test, and what testing is (anyway), you often come across very similar explanations. Explanations that managers likely like and that contain terms such as "information", "quality", "state", "decisions", "risk" and similar.These are great, don't get me wrong. I like them. But they are also a bit clinical, rational, purposeful. And if I'm being honest, at the end of the day, these might not exactly be the reasons why /I/ test, or what keeps /me/ in testing.
So I'd like to explore what other reasons there might be. I'll be reflecting on which (personal, subjective) value testing brings to me rather than what value it might bring to my team or company. And being true to my craft, I'll be wondering if this experiment will reveal any new information and if yes, what I could be doing with it.
James Thomas - Testing All the Way Down, and Other Directions
The idea that testing is or can be a recursive activity - or even fractal - has some currency. In that view, a test or experiment generates some data, which suggests new experiments, which generate some data, which suggest new experiments and so on. The kinds of activities being done at each stage will be self-similar and testing is used as a kind of microscope to focus in on some aspect of the system under test. Testing all the way down.In this talk, I'll instead view testing as a number of different instruments that can be used in an arbitrary number of dimensions. Further, I'll suggest that testing can be applied not only to a system, but to descriptions of that system, to models of that system, to abstractions of that system, to a system which is testing that system, and to a system which is testing the system which is testing that system. And so on. It's testing all the way round.
I'll finish by proposing a definition of testing that I think might capture this wide applicability. (slides)