James Bach. Software Testing
Open Lecture by James Bach on Software Testing, outline
http://www.youtube.com/watch?v=ILkT_HV9DVU ( http://youtu.be/ILkT_HV9DVU )
Not academic nor doctor, high-school dropper, worst computer seller in Apple in 1982, became programmer, 4 years later bacame a Test Manager. Nobody is reading testbooks. And they are useless.
1000 years there were best practices in medicine, that absolutely did not work. And doctors had a certifications on this bullshit.
Testers are questioning models.
Testers add something that is not in the specifications and schemas explicitely.
Pictures are not the systems that you test. Testers discover the ground truth.
Who calls this? What is this system for? What is happening outside?
You should never trust to the pictures from developers. Be sceptic. Honer what they say, use what they say, but never believe.
"How many tests?" is a silly question is like "How many files will be in your new novel?" Irrelevant.
"How are you going to test?" - learn the product.
I hated being a developer. The same code every day, every week, every month. Testing is very different and interesting, it's like sex. Don't do it right, do it WRONG!
In real industrial life you cannot have all skills, but you should use each skill of every person around you, manipulate to get the problem solved. Everyone in the room is my testing tool, because they posess the information.
My maximum was 12 weeks $35000 each week. I was exciting, but sad, because it will be impossible to beat that maximum.
Seek undeline complexity in simple schemas and systems, it is there.
If you see the small problem, that means that the big problem probably should be there.
Badly tested medical equipment can kill people.
When tester finds a bug, he fills happy, not because he hates developer, but because he is usefull, "today they will not fire me".
I explained what I did in specific technical language, that's what distinguish a professional from amateur.
You must describe your testing. There is no standards in testing terminology, ISTQB is not a standard.
Ask questions before you give your resolution answer as a tester, do not miss a thing.
Everything has a context. Good tester think abount it.
The system should operate at voltage 100-220 V. Good tester does not follow requirements, he brakes requirements. Why? To answer a question, WILL IT KILL somebody or not! This is UNWRITTEN requirement. Is it dangerous? You may not test outside the requirements, but you must test unwritten requirement.
Described, Actual and Imagined worlds intersect, but are not the same.
Developers can achieve the requirements that they do not understand, e.g. due to libraries.
"Try to see if it works" means endless work. It really means "Try to learn how it can work and how it might not to work".
Use audaciousness, imagination, questioning, rapid learning, sensemaking, focusing and defocusing, storytelling and heuristics.
Engineers know that each solution is relative to the context of the problem. There is no best practices in engineering.
Constantly re-analysing risks, its like a detective work, if there is a murder, there are hundreds of murders beneath.
Testing is highly structured activity. Self-management, Testing, Learning and Collaboration.
To write down the test it's economically dangerous and expensive. Try to write down description of what you eat. You probably do a lot of secret eating. Something you can write down, something not.
How many unicorns can be placed in your cubicle? It depends what do you call a unicorn.
Why not automate the testing?
My wife likes me to remind her that I love her. I can write the program that sends her an email every hour saying "I love you". Extremely efficient! What is wrong?
My boss likes me to remind him that old tests still pass. I can write the test that sends him an email every hour saying "Test passed". Extremely efficient! What is wrong?
The test is a terster's thinking at the moment of writing test. Automatic test is not TESTING, it is CHECKING. A human being does not only prescripted test, even if he does it rarely. The tests do not think. They don't use judgement.
Creating a program from the code is called compiling. Why do you distinguish programming and compiling? Why aren't you as excited about "automating" programming as you are about "automating" testing???
Example with Facebok, automating the viewing of performance graph led to serious perf problem.
I do not write bugs, it's you who write bugs. I am not your enemy, I love you, this is customer, who don't like you, not me.
13 commitments of James Bach
----------------------------------------
I provide the service. You are important client of that service. I am not satisfied unless you are satisfied.
I am not the gatekeeper of quality. I don't "own" the quality. Shipping a good product is a goal shared by all of us.
I will test your code as soon as I can after you deliver it to me. I know that you need my test results quickly.
If all I have is partial information or a partial product, I'll nevertheless make every reasonable effort to test.
I will test important things first, and try to fing important problems.
I will try to see product from several points of view, especially the point of view of the user, so that you can be more fully informed.
I will write clear, concise, thoughtful and respectful problem reports. I may make suggestions about design, but I am not a designer.
I will try to test in a way that allows you to work at full speed.
I will let you know how I'm testing, and invite your comments.
I will learn the product quickly, and make use of that knowledge to test more cleverly.
I will try to fulfill special requests, such as if you need me to spot check sommething for you, or run a special kind of test.
I will not carelessly waste your time.Or, if I do, I will learn from that mistake.
I will not FAKE a test project.
----------------------------------------
Because you pay me so much, I will do only my best, not fake.
EXPLANE YOURSELF! TALK AND NAME THE THINGS! Otherwise the world will not know you.
Next item: http://www.youtube.com/watch?v=fNkYz1hB7r0
http://www.youtube.com/watch?v=ILkT_HV9DVU ( http://youtu.be/ILkT_HV9DVU )
Not academic nor doctor, high-school dropper, worst computer seller in Apple in 1982, became programmer, 4 years later bacame a Test Manager. Nobody is reading testbooks. And they are useless.
1000 years there were best practices in medicine, that absolutely did not work. And doctors had a certifications on this bullshit.
Testers are questioning models.
Testers add something that is not in the specifications and schemas explicitely.
Pictures are not the systems that you test. Testers discover the ground truth.
Who calls this? What is this system for? What is happening outside?
You should never trust to the pictures from developers. Be sceptic. Honer what they say, use what they say, but never believe.
"How many tests?" is a silly question is like "How many files will be in your new novel?" Irrelevant.
"How are you going to test?" - learn the product.
I hated being a developer. The same code every day, every week, every month. Testing is very different and interesting, it's like sex. Don't do it right, do it WRONG!
In real industrial life you cannot have all skills, but you should use each skill of every person around you, manipulate to get the problem solved. Everyone in the room is my testing tool, because they posess the information.
My maximum was 12 weeks $35000 each week. I was exciting, but sad, because it will be impossible to beat that maximum.
Seek undeline complexity in simple schemas and systems, it is there.
If you see the small problem, that means that the big problem probably should be there.
Badly tested medical equipment can kill people.
When tester finds a bug, he fills happy, not because he hates developer, but because he is usefull, "today they will not fire me".
I explained what I did in specific technical language, that's what distinguish a professional from amateur.
You must describe your testing. There is no standards in testing terminology, ISTQB is not a standard.
Ask questions before you give your resolution answer as a tester, do not miss a thing.
Everything has a context. Good tester think abount it.
The system should operate at voltage 100-220 V. Good tester does not follow requirements, he brakes requirements. Why? To answer a question, WILL IT KILL somebody or not! This is UNWRITTEN requirement. Is it dangerous? You may not test outside the requirements, but you must test unwritten requirement.
Described, Actual and Imagined worlds intersect, but are not the same.
Developers can achieve the requirements that they do not understand, e.g. due to libraries.
"Try to see if it works" means endless work. It really means "Try to learn how it can work and how it might not to work".
Use audaciousness, imagination, questioning, rapid learning, sensemaking, focusing and defocusing, storytelling and heuristics.
Engineers know that each solution is relative to the context of the problem. There is no best practices in engineering.
Constantly re-analysing risks, its like a detective work, if there is a murder, there are hundreds of murders beneath.
Testing is highly structured activity. Self-management, Testing, Learning and Collaboration.
To write down the test it's economically dangerous and expensive. Try to write down description of what you eat. You probably do a lot of secret eating. Something you can write down, something not.
How many unicorns can be placed in your cubicle? It depends what do you call a unicorn.
Why not automate the testing?
My wife likes me to remind her that I love her. I can write the program that sends her an email every hour saying "I love you". Extremely efficient! What is wrong?
My boss likes me to remind him that old tests still pass. I can write the test that sends him an email every hour saying "Test passed". Extremely efficient! What is wrong?
The test is a terster's thinking at the moment of writing test. Automatic test is not TESTING, it is CHECKING. A human being does not only prescripted test, even if he does it rarely. The tests do not think. They don't use judgement.
Creating a program from the code is called compiling. Why do you distinguish programming and compiling? Why aren't you as excited about "automating" programming as you are about "automating" testing???
Example with Facebok, automating the viewing of performance graph led to serious perf problem.
I do not write bugs, it's you who write bugs. I am not your enemy, I love you, this is customer, who don't like you, not me.
13 commitments of James Bach
----------------------------------------
I provide the service. You are important client of that service. I am not satisfied unless you are satisfied.
I am not the gatekeeper of quality. I don't "own" the quality. Shipping a good product is a goal shared by all of us.
I will test your code as soon as I can after you deliver it to me. I know that you need my test results quickly.
If all I have is partial information or a partial product, I'll nevertheless make every reasonable effort to test.
I will test important things first, and try to fing important problems.
I will try to see product from several points of view, especially the point of view of the user, so that you can be more fully informed.
I will write clear, concise, thoughtful and respectful problem reports. I may make suggestions about design, but I am not a designer.
I will try to test in a way that allows you to work at full speed.
I will let you know how I'm testing, and invite your comments.
I will learn the product quickly, and make use of that knowledge to test more cleverly.
I will try to fulfill special requests, such as if you need me to spot check sommething for you, or run a special kind of test.
I will not carelessly waste your time.Or, if I do, I will learn from that mistake.
I will not FAKE a test project.
----------------------------------------
Because you pay me so much, I will do only my best, not fake.
EXPLANE YOURSELF! TALK AND NAME THE THINGS! Otherwise the world will not know you.
Next item: http://www.youtube.com/watch?v=fNkYz1hB7r0