Interview with James Bach for DUMP2015
In March, a conference for Ural developers was held, where one of the sections was devoted to testing. In order to stir up the audience and bring as many people as possible to the dialogue, we gave a speech at which we asked the participants questions. Acquaintance with testers, questions of interest to the local community, the expected answers. With only one exception. The day before, the same questions were asked to a member of the community from another corner of the world, a recognized testing specialist - James Bach. Admittedly, this not only sparked the interest of the audience, but also helped to take a fresh look at some of the usual things in testing.
I present to you the text and video of an interview with James Bach.
James, have you been testing for quite a long time, have you had any desire to change your profession?
')
The beginning of my career was programming. I started programming video games and eventually became disillusioned. I'm tired of doing this all the time. I like programming, but this is not something that I would like to do all the time. For me, testing was a wonderful discovery because it allowed me to use all my communication and thinking skills, as well as programming skills, but there was no need to do the same thing for too long.
Then I discovered that I love to teach, and I became a teacher of testers. Now I do testing, but I also love to teach and advise people. There are many different things that I do, and this variety is enough for me.
But if to answer your question directly, at first I wanted to become a mathematician or physicist. But I didn’t have enough patience to go to school and socialize. Then I wanted to become a military man, but I didn’t have the patience to follow orders. Then I thought that I wanted to be a spy, but I do not know how to keep secrets. I do not like to keep secrets. But obviously, being a spy, you have to do it.
In truth, testing is the only thing left.
What do you find most interesting in testing?
The most interesting thing in testing for me is the psychology of thinking. How people think, how they have ideas, how they manage their thoughts, how people can help each other in finding ideas. This labyrinth is infinitely fascinating - the psychology and science of thinking that underlie testing.
There is one more small thing related to practical activities, which I find most interesting - this is when I can work with very large amounts of data. With many thousands or millions of signs and symbols, this is extremely exciting. I like to select input and output visualization methods, generate them with the help of some tools, for me this is entertainment.
What is the most difficult for you to test?
I am very quickly bored with doing something pedantically and on schedule. I love working with ideas, puzzles, solving them. Being somewhere at a certain time or doing something that in no way can be forgotten is not for me. I would prefer someone to do things for me that require discipline.
I am a puzzle solver.
How do you conduct a retrospective of errors in your projects?
I want to know why every single problem arose, why she slipped away from me, and I want to prevent it from reappearing. I always accept at my own expense the omission of any error.
And if, under the retrospective of defects, you mean trying to understand why the problem happened the first time, and how to prevent re-occurrence - alas, I am not often involved in this kind of investigation. I don’t have so many thoughts on this, but I’m always worried when a problem slips past me.
How often should such investigations be conducted?
I think it depends on the error. When finding some bugs, such as security holes, we have to stop everything and ask what happened? Because there can be one thousand more.
It's like insects in real life. If you see a fly in the kitchen, it means a fly has flown to you. But if you see an ant, it means that soon a colony of ants snuck into your kitchen. That means a thousand or a hundred thousand ants will crawl to you.
When you see a fly or an ant, you react differently. Therefore, I react differently when I see defects that indicate a big problem in the development process and defects that can simply be typos or unintentional errors.
Some testers see professional growth only as a transition to quality assurance - working on processes, creating new tools. What do you think about this?
Why don't you continue on? Why, instead of spending time on quality assurance, you have to devote your time to teaching people how to handle computers, or solve world hunger problems. After all, obviously, hunger is much more important. Or world enlightenment, the creation of the world, the cultivation of the earth.
I think you can say that if you are tired of testing, you can do a lot of things. But it will not be testing, that's the problem! Testing is the study of a product, its research and understanding whether there are any problems in it.
Imagine you're a guard. Imagine that you are a security guard at a military base, and you say: "Instead of guarding the base, in fact, I should try to understand why people want to enter the military base and start studying it at the university." Does this mean that you should not guard a military base? YOU SHOULD PROTECT IT!
Therefore, if someone wants to deal with quality assurance, the prevention of bugs, and the like, which of course is a worthwhile exercise, you should understand that this does not reduce the need to make sure that we have found all those bugs. And I don’t think we should quit testing simply because preventing bugs is also an interesting activity.
And one more thing about this. A reasonable excuse for reducing testing is to reduce the risk of serious bugs. If using the quality assurance process you follow, you can reduce the number of damaging defects and make sure that the technology now contains fewer errors and fewer bugs can occur, then of course you can reduce the testing. You can’t test less until this risk really diminishes, that’s my opinion. You cannot reduce testing, because you HOPE that there will be no bugs in the product. You are cutting back on testing because you have a good reason to BE SURE that there are no bugs.
And then you CAN afford fewer guards.
Many are concerned about the financial side of this approach. So what should a tester do who wants only to test and does not want to deal with quality assurance? Why raise the salary of a person who continues to do the same?
You have to test very difficult things very, very well. You must develop your communication skills, your technical skills. Need to learn more about the various technologies. I think, generally speaking, you should also work on programming skills, although there are alternatives to this.
You do not have to be a coder, you can also be a teacher or a test consultant.
There are also testers, whom I call the test jumper. They are so good at testing that they can jump into a project like a commando, set up testing, help other people, and then go on to the next project. Becoming an internal or external testing consultant is what you can do.
Essentially, this is what I do. I love to test, but what I actually get paid for right now is because of the training of testers. I have to do testing, usually for free, in order to train my skills, only then I can be very good at teaching testing. In fact, the money that I get for teaching testing finances my self-education, my continuous training as a tester. If I were paid for being a tester, I would not be paid enough. I need a lot more money than I can earn as a regular tester to support my family.
I would like to be just a tester who teaches others, but the way I can do this is consulting.
What, in your opinion, is the most important event in the testing world in recent years?
The most significant thing that has happened in my tester community is the discovery of systematic discussion methods and the development of what is called tacit knowledge. This happened thanks to a sociologist whose name is Harry Collins (Harry Collins), whose work influenced me and Michael Bolton (Michael Bolton), as well as some other people from the Context-Driven Testing Community.
Before anyone started talking about implicit knowledge, we did not have a systematic, good way to explain the difference between explicit knowledge and implicit knowledge. And so implicit knowledge remained in some way a mystical thing, about which you can not talk. Now we feel that we have got some pretty good discussion tools. And this means that we can protect implicit knowledge from managers and other people who do not know anything about it.
We received important tools to consciously grab deeper testing skills. And this is the most exciting thing in recent years for me.
Do you continue to conduct free lessons on Skype?
It is very important for me to train testers who knock me on Skype, and I do this quite often in any free time. I love to do this, and even postpone the things for which I pay, for the sake of training sessions.
I did one of these sessions just last night. Although I have scheduled sessions, usually people come to me on Skype and say: "I heard you conduct such lessons." And if I have free time, I suggest spending it right now. Sometimes it is training, sometimes it is instruction, I do both.
And I have to do this, because my skills need to be honed. Only practice allows you to keep yourself in good shape. I improve ideas, and for this I have to communicate with people.
What do you usually teach in these classes?
Sometimes they come to me with a specific problem. Often these are questions about writing reports. On improving test reports for their supervisors. Sometimes this is a specific technique, for example, combinatorial testing, and they want to understand how to test all pairwise combinations.
I also try to engage them in my current research. I often come up with new exercises, rubbing my hands, I say: "I will try my new exercise on teeeeee!". Then I give them some site that they have to test, after which we have a discussion of the work done. So I get new material for my articles and presentations.
What are the most common misconceptions you face in these sessions?
The biggest misconception is that people confuse testing and fact-checking. They think testing is a test of some facts about a product. I show them that testing is much more. It includes such things as fact checking, but this is only a small part of what testers must do. Therefore, I constantly explain this to them.
I also have to explain to people that testing is not quality assurance, and this is not proof of quality. We do not do that. We are looking for problems. This is what we do. And this is acceptable if doing the job well.
Quality assurance is something else. Although testers can also do this.
Automated testing specialists are studying new frameworks and technologies. And what to learn manual tester?
I can not accept the formulation of your question. First of all, there are no automated or manual testers. There are no such things. You want to divide testers into those who write code during their work and those who do not. But they all use the body. Using all sorts of tools is commonplace for the tester.
For example, you can use Excel. If the tester is not a tester writing code, this does not mean that he cannot learn everything about Excel, right? He needs to know how Excel works, and how it can work with data, analyze it, and the like.
Therefore, the study of tools and technologies is the same for all testers, regardless of whether you are writing code or not. Of course, if you are writing code, you should learn more about it. Different things that you can do with the code - of course this is important, not to mention the technology and the study of users.
The main thing that testers should learn is:
• reasoning,
• building models
• and construction of experiments.
And this is what testers should learn, whether they write code or not.
It seems that quite a few testers have a clear idea of how to conduct an experiment. Which is extremely important, because tests are experiments. You need to know how to experiment and how to model a product. Create a mental description of the product, and then turn it into an explicit model with which you work here and now. Explicit it or mental model, testers work with product models and draw conclusions about these models, make experiments in accordance with these models. As well as verify the veracity of these models. This is what testers do. And this is quite important.
At least these two skills we must develop.
I would like to thank Olga Kotkova and Natalia Platonova for help in preparing the article.
I present to you the text and video of an interview with James Bach.
James, have you been testing for quite a long time, have you had any desire to change your profession?
')
The beginning of my career was programming. I started programming video games and eventually became disillusioned. I'm tired of doing this all the time. I like programming, but this is not something that I would like to do all the time. For me, testing was a wonderful discovery because it allowed me to use all my communication and thinking skills, as well as programming skills, but there was no need to do the same thing for too long.
Then I discovered that I love to teach, and I became a teacher of testers. Now I do testing, but I also love to teach and advise people. There are many different things that I do, and this variety is enough for me.
But if to answer your question directly, at first I wanted to become a mathematician or physicist. But I didn’t have enough patience to go to school and socialize. Then I wanted to become a military man, but I didn’t have the patience to follow orders. Then I thought that I wanted to be a spy, but I do not know how to keep secrets. I do not like to keep secrets. But obviously, being a spy, you have to do it.
In truth, testing is the only thing left.
What do you find most interesting in testing?
The most interesting thing in testing for me is the psychology of thinking. How people think, how they have ideas, how they manage their thoughts, how people can help each other in finding ideas. This labyrinth is infinitely fascinating - the psychology and science of thinking that underlie testing.
There is one more small thing related to practical activities, which I find most interesting - this is when I can work with very large amounts of data. With many thousands or millions of signs and symbols, this is extremely exciting. I like to select input and output visualization methods, generate them with the help of some tools, for me this is entertainment.
What is the most difficult for you to test?
I am very quickly bored with doing something pedantically and on schedule. I love working with ideas, puzzles, solving them. Being somewhere at a certain time or doing something that in no way can be forgotten is not for me. I would prefer someone to do things for me that require discipline.
I am a puzzle solver.
How do you conduct a retrospective of errors in your projects?
I want to know why every single problem arose, why she slipped away from me, and I want to prevent it from reappearing. I always accept at my own expense the omission of any error.
And if, under the retrospective of defects, you mean trying to understand why the problem happened the first time, and how to prevent re-occurrence - alas, I am not often involved in this kind of investigation. I don’t have so many thoughts on this, but I’m always worried when a problem slips past me.
How often should such investigations be conducted?
I think it depends on the error. When finding some bugs, such as security holes, we have to stop everything and ask what happened? Because there can be one thousand more.
It's like insects in real life. If you see a fly in the kitchen, it means a fly has flown to you. But if you see an ant, it means that soon a colony of ants snuck into your kitchen. That means a thousand or a hundred thousand ants will crawl to you.
When you see a fly or an ant, you react differently. Therefore, I react differently when I see defects that indicate a big problem in the development process and defects that can simply be typos or unintentional errors.
Some testers see professional growth only as a transition to quality assurance - working on processes, creating new tools. What do you think about this?
Why don't you continue on? Why, instead of spending time on quality assurance, you have to devote your time to teaching people how to handle computers, or solve world hunger problems. After all, obviously, hunger is much more important. Or world enlightenment, the creation of the world, the cultivation of the earth.
I think you can say that if you are tired of testing, you can do a lot of things. But it will not be testing, that's the problem! Testing is the study of a product, its research and understanding whether there are any problems in it.
Imagine you're a guard. Imagine that you are a security guard at a military base, and you say: "Instead of guarding the base, in fact, I should try to understand why people want to enter the military base and start studying it at the university." Does this mean that you should not guard a military base? YOU SHOULD PROTECT IT!
Therefore, if someone wants to deal with quality assurance, the prevention of bugs, and the like, which of course is a worthwhile exercise, you should understand that this does not reduce the need to make sure that we have found all those bugs. And I don’t think we should quit testing simply because preventing bugs is also an interesting activity.
And one more thing about this. A reasonable excuse for reducing testing is to reduce the risk of serious bugs. If using the quality assurance process you follow, you can reduce the number of damaging defects and make sure that the technology now contains fewer errors and fewer bugs can occur, then of course you can reduce the testing. You can’t test less until this risk really diminishes, that’s my opinion. You cannot reduce testing, because you HOPE that there will be no bugs in the product. You are cutting back on testing because you have a good reason to BE SURE that there are no bugs.
And then you CAN afford fewer guards.
Many are concerned about the financial side of this approach. So what should a tester do who wants only to test and does not want to deal with quality assurance? Why raise the salary of a person who continues to do the same?
You have to test very difficult things very, very well. You must develop your communication skills, your technical skills. Need to learn more about the various technologies. I think, generally speaking, you should also work on programming skills, although there are alternatives to this.
You do not have to be a coder, you can also be a teacher or a test consultant.
There are also testers, whom I call the test jumper. They are so good at testing that they can jump into a project like a commando, set up testing, help other people, and then go on to the next project. Becoming an internal or external testing consultant is what you can do.
Essentially, this is what I do. I love to test, but what I actually get paid for right now is because of the training of testers. I have to do testing, usually for free, in order to train my skills, only then I can be very good at teaching testing. In fact, the money that I get for teaching testing finances my self-education, my continuous training as a tester. If I were paid for being a tester, I would not be paid enough. I need a lot more money than I can earn as a regular tester to support my family.
I would like to be just a tester who teaches others, but the way I can do this is consulting.
What, in your opinion, is the most important event in the testing world in recent years?
The most significant thing that has happened in my tester community is the discovery of systematic discussion methods and the development of what is called tacit knowledge. This happened thanks to a sociologist whose name is Harry Collins (Harry Collins), whose work influenced me and Michael Bolton (Michael Bolton), as well as some other people from the Context-Driven Testing Community.
Before anyone started talking about implicit knowledge, we did not have a systematic, good way to explain the difference between explicit knowledge and implicit knowledge. And so implicit knowledge remained in some way a mystical thing, about which you can not talk. Now we feel that we have got some pretty good discussion tools. And this means that we can protect implicit knowledge from managers and other people who do not know anything about it.
We received important tools to consciously grab deeper testing skills. And this is the most exciting thing in recent years for me.
Tacit and Explicit Knowledge by Harry Collins
Do you continue to conduct free lessons on Skype?
It is very important for me to train testers who knock me on Skype, and I do this quite often in any free time. I love to do this, and even postpone the things for which I pay, for the sake of training sessions.
I did one of these sessions just last night. Although I have scheduled sessions, usually people come to me on Skype and say: "I heard you conduct such lessons." And if I have free time, I suggest spending it right now. Sometimes it is training, sometimes it is instruction, I do both.
And I have to do this, because my skills need to be honed. Only practice allows you to keep yourself in good shape. I improve ideas, and for this I have to communicate with people.
What do you usually teach in these classes?
Sometimes they come to me with a specific problem. Often these are questions about writing reports. On improving test reports for their supervisors. Sometimes this is a specific technique, for example, combinatorial testing, and they want to understand how to test all pairwise combinations.
I also try to engage them in my current research. I often come up with new exercises, rubbing my hands, I say: "I will try my new exercise on teeeeee!". Then I give them some site that they have to test, after which we have a discussion of the work done. So I get new material for my articles and presentations.
What are the most common misconceptions you face in these sessions?
The biggest misconception is that people confuse testing and fact-checking. They think testing is a test of some facts about a product. I show them that testing is much more. It includes such things as fact checking, but this is only a small part of what testers must do. Therefore, I constantly explain this to them.
I also have to explain to people that testing is not quality assurance, and this is not proof of quality. We do not do that. We are looking for problems. This is what we do. And this is acceptable if doing the job well.
Quality assurance is something else. Although testers can also do this.
Automated testing specialists are studying new frameworks and technologies. And what to learn manual tester?
I can not accept the formulation of your question. First of all, there are no automated or manual testers. There are no such things. You want to divide testers into those who write code during their work and those who do not. But they all use the body. Using all sorts of tools is commonplace for the tester.
For example, you can use Excel. If the tester is not a tester writing code, this does not mean that he cannot learn everything about Excel, right? He needs to know how Excel works, and how it can work with data, analyze it, and the like.
Therefore, the study of tools and technologies is the same for all testers, regardless of whether you are writing code or not. Of course, if you are writing code, you should learn more about it. Different things that you can do with the code - of course this is important, not to mention the technology and the study of users.
The main thing that testers should learn is:
• reasoning,
• building models
• and construction of experiments.
And this is what testers should learn, whether they write code or not.
It seems that quite a few testers have a clear idea of how to conduct an experiment. Which is extremely important, because tests are experiments. You need to know how to experiment and how to model a product. Create a mental description of the product, and then turn it into an explicit model with which you work here and now. Explicit it or mental model, testers work with product models and draw conclusions about these models, make experiments in accordance with these models. As well as verify the veracity of these models. This is what testers do. And this is quite important.
At least these two skills we must develop.
I would like to thank Olga Kotkova and Natalia Platonova for help in preparing the article.
Source: https://habr.com/ru/post/255747/
All Articles