Hi, My name is David Burns I am a Software test Engineer for a shop in Redmond Washington. If you know me in our area you might have heard me referred to as “The Kaner story”. But it wasn’t always so, let me explain.
For 14 years I assisted surgeons in the operating room, doing shock trauma surgery. I traveled across the country and worked in the biggest and busiest operating rooms in the USA. Eventually I ended up in Seattle, looking to move up in the field of Surgical Technology (after doing over 30,000 trauma cases as well as orthopedic specialties like total hip and knee replacement, it was time to impart my knowledge.)so, I became a teacher in Bellevue and developed and ran the surgical technology program with a classroom as well as Laboratory activities. In 2007, the school I was teaching in closed down, and I got a gig with a small company as a corporate trainer. This particular company had me teaching technicians how to use a PDA with some pages added to the UI by a developer ,the company hired to write code. Of course, they needed the pages tested so I was briefly trained on how to do this. Mostly UI testing with some bug reporting, both verbal and written. Shortly thereafter, my contract ran out with them and I was once again faced with the challenge of finding work in an economy that was quickly taking a nose dive right into the shitter. On unemployment and going nowhere fast I wanted to try and keep the meager testing skills I possessed sharp as well as develop them into a meaningful career. I really enjoyed testing the small project I was on before, it was like surgery, deconstructing something and finding the cancerous areas, only no blood and guts. My wife gave me a book to read that she said was imperative for me to develop my career as a test engineer, Testing Computer Software by Kaner,Falk and Ngeyen. I dove right into the book ,even though I had no idea what half the stuff in there was talking about, I asked questions to anyone I knew in the industry about the book and took it everywhere I went .I put my resume out on the market but received very few hits as I was so green and stumbled through the few interviews , scaring the interviewee with my answers ( but at one of the interviews I was asked to test a triangle, the first input I entered broke their testing program and 2 developers appeared like CIA to stand over me and watch me repro what I had done so they could fix it! I have to say I was elated that I had successfully broken their testing program used for interviews! I was later told by friends in the industry that I should have gotten the job just for that fact. But much bigger and better things awaited me and my fate lay elsewhere in the industry) desperate to develop my newly honed skills I took a job making minimum wage at a game test lab. I have coined the term “nerd heard” for this job, as hundreds of unwashed youth would pour into the secure labs each day and sit with headphones on “testing” games in a semi-conscience state. I quickly found out that the Kaner book DID apply to this lowly position that did not even come close to supplementing my unemployment. I COULD test, I was testing, and using my kaner book as a guide or How to, I began writing bug reports on the back of pieces of scrap paper. After a month I found myself slipping into my teaching shoes and showing those around me who were interested, how to write a bug, reading straight from my trusty Kaner book. I was hardly an expert, but figured sharing what I knew could be a start for anyone. I would come in to the game test lab on days I was not scheduled to work and hope someone would not show up, so I could get another crack at breaking one of the games. I was sitting in the cafeteria when I noticed 2 gentlemen talking over the proverbial water cooler. I noticed looking over my Kaner book that one of them kept looking my way as if he knew me. After a bit , he came over and stuck a meaty hand out that looked like it had seen the better side of a river paddle more than once. “HI, I’m a test manager in another department “he said as he shook my hand, “and I have a question for you. That book your reading, why are you reading it?” I was little surprised at his question but answered back without hesitation,” because I want to be a great tester and I was told this book would help”. Well, that was the beginning to the current position I now hold as a Software Test Engineer. After the story had been passed around the “campfire” a bit, I simply began to be known as The Kaner Story. Thanks to the patience, instruction and belief in me by my Practice area leader and my team, I am one of the leading experts in our shop on Persona Development and User Stories. I manage our test cases, write them, and execute them along side my co-workers. I have been given the opportunity to Lead a test project and teach my team some of the things I have learned. I am not there yet, but am surely developing into the great Software tester I seek to become. I am …. The Kaner Story.
Tuesday, February 24, 2009
Wednesday, February 18, 2009
5 easy things every Test Engineer can do at the start of the project
It’s a common problem I face as a software Test engineer, ramping-up quickly on new projects. Here’s what usually happens.
My practice area leader gives my team a heads up about our next project when he can. We are usually at the end of a project or had just completed one. So, those who can, will jump on the web and do a search for the new project coming up. It usually does not take long until we were looking at an older version of our next assignment. At first it seems very awkward to navigate, but after about 20 minutes or so we have a general sense of what the application is supposed to do and how to navigate through it. This early exploration slices off some of the team’s ramp up time when the project begins. It also helps the team become subject matter proficient from the very beginning of the project. Even if only one team member can accomplish this, it is still a bonus to the overall team as they have a reference point to spring board questions.
This is a win win situation for the team and the customer. The customer sees results from testing sooner and the team’s ramp up time is cut down considerably, giving us the ability to quickly focus our attention on finding bugs and decomposing the application. I think there are 5 steps to accomplish this 1) Familiarization of the Application. 2) Gaining access to the application. 3) Searching the bug database. 4) Exploration. 5) Being ready for anything.
1. Familiarization with the Application. Being Familiar with an application can significantly reduce the ramp up time to almost nothing. It can mean the difference between fishing all over a lake, trying different kinds of lures and catching small blue gills (nothing wrong with that, blue gills are small but good to eat) or being familiar with the lake, knowing which lure to use and going right to the lily pads where you know the big fish are lurking. Becoming familiar with the application before the ramp up will help the test cases go more smoothly and efficiently and could lead you to some nice sev 1 bugs.
2. Gain Access to the Application. Gain access to the application in whatever form is available, you will need to get a hold of this as soon as possible! If you cannot get the latest version because it’s not quite ready, No problem, and older versions will work just fine. I have gained access to applications from a thumb drive in the past, whatever it takes!
3. Search the bug database. Search the bug database for older applications with a known history. This is a great way to see where the problem areas have been in the past. Reading the repro steps is another way to familiarize the logical steps for how bugs were found. What if no bugs are logged in on this application yet? No problem, simply look for a similar application and dig through those bugs looking for possible similarities. Try searching by severity to get a look at past show stoppers, these could be located in the prime test areas.
4. Explore the Application. At this stage in the game, test cases may still be “under construction”. Cool! Explore the application. Try everything, fear nothing. Clicking and typing information wherever you can. Ask yourself questions like, how deep can I get in this App? What’s this app supposed to be doing? You are seeing the application through unscripted eyes, so decompose it as your mind sees fit.
5. Be ready for anything! Do not be surprised if bugs start appearing right away, like they were patiently waiting your arrival. How exciting! You don’t even have test cases and seem to be wading waist deep in bugs! On the other hand, no need for disappointment if you do not find bugs initially. It’s like the kitchen lights are turned on or something, you know as soon as you turn the lights out, the bugs will appear. But you just cannot find the switch, no worries, try using a different light! The important aspect is you are familiarizing yourself with the application, the bugs are a bonus! Reproduce them and write them up, assigning them to yourself. This way they will not get lost or forgotten.
My practice area leader gives my team a heads up about our next project when he can. We are usually at the end of a project or had just completed one. So, those who can, will jump on the web and do a search for the new project coming up. It usually does not take long until we were looking at an older version of our next assignment. At first it seems very awkward to navigate, but after about 20 minutes or so we have a general sense of what the application is supposed to do and how to navigate through it. This early exploration slices off some of the team’s ramp up time when the project begins. It also helps the team become subject matter proficient from the very beginning of the project. Even if only one team member can accomplish this, it is still a bonus to the overall team as they have a reference point to spring board questions.
This is a win win situation for the team and the customer. The customer sees results from testing sooner and the team’s ramp up time is cut down considerably, giving us the ability to quickly focus our attention on finding bugs and decomposing the application. I think there are 5 steps to accomplish this 1) Familiarization of the Application. 2) Gaining access to the application. 3) Searching the bug database. 4) Exploration. 5) Being ready for anything.
1. Familiarization with the Application. Being Familiar with an application can significantly reduce the ramp up time to almost nothing. It can mean the difference between fishing all over a lake, trying different kinds of lures and catching small blue gills (nothing wrong with that, blue gills are small but good to eat) or being familiar with the lake, knowing which lure to use and going right to the lily pads where you know the big fish are lurking. Becoming familiar with the application before the ramp up will help the test cases go more smoothly and efficiently and could lead you to some nice sev 1 bugs.
2. Gain Access to the Application. Gain access to the application in whatever form is available, you will need to get a hold of this as soon as possible! If you cannot get the latest version because it’s not quite ready, No problem, and older versions will work just fine. I have gained access to applications from a thumb drive in the past, whatever it takes!
3. Search the bug database. Search the bug database for older applications with a known history. This is a great way to see where the problem areas have been in the past. Reading the repro steps is another way to familiarize the logical steps for how bugs were found. What if no bugs are logged in on this application yet? No problem, simply look for a similar application and dig through those bugs looking for possible similarities. Try searching by severity to get a look at past show stoppers, these could be located in the prime test areas.
4. Explore the Application. At this stage in the game, test cases may still be “under construction”. Cool! Explore the application. Try everything, fear nothing. Clicking and typing information wherever you can. Ask yourself questions like, how deep can I get in this App? What’s this app supposed to be doing? You are seeing the application through unscripted eyes, so decompose it as your mind sees fit.
5. Be ready for anything! Do not be surprised if bugs start appearing right away, like they were patiently waiting your arrival. How exciting! You don’t even have test cases and seem to be wading waist deep in bugs! On the other hand, no need for disappointment if you do not find bugs initially. It’s like the kitchen lights are turned on or something, you know as soon as you turn the lights out, the bugs will appear. But you just cannot find the switch, no worries, try using a different light! The important aspect is you are familiarizing yourself with the application, the bugs are a bonus! Reproduce them and write them up, assigning them to yourself. This way they will not get lost or forgotten.
The Importance of writing good bug reports
The Importance of writing good bug reports
I was copying over some old bug reports into our new database the other day, It would have been nice to just import them all in, but if that was the case I would have missed out on the first hand realization of good bug reporting. As I was copying them over I noticed the difference in the bugs that were written before we were put on the project. Now I am not slinging mud at anyone nor tooting my own horn. But the difference was painfully obvious. The bugs that were poorly written had tons of notes added to them like, “Cannot repro” What do you mean by this abbreviation” “Please explain” and on and on. I also noticed the poorly written bugs took almost twice as long to come to a decision about and close.
If you have been writing bug reports for years and years, you’re probably thinking, I don’t need to read any further, I KNOW how to write a GREAT bug report! If that’s true I have a challenge for you!
Knowing how to do it and DOING it correctly are two separate issues. I have found in the Software industry , the longer test engineers write bug reports, the more the information in the reports tends to get muddled in speak that only makes sense to those directly on the project. Or shortened down to a brief description that leaves out the “Obvious” steps. I have even seen bug reports that are simply the Description line.
And how is this helpful to the Developer in another state or Country? She may not know what your acronym means, she may need the “obvious” steps you left out in order to correctly repro the bug, and using the description line as your bug report is, well, that’s just sad. (You need to shape up or ship out mister!)
It takes allot of time for information to get interpreted and dealt in a cost effective manner, add in language barriers, distance and the ongoing trend of outsourcing and a poorly written bug report can suddenly add up to allot of unnecessary time, money and effort!
How can I tell if my bug reports are written properly? Well, in my opinion, the correct answer is, Do your bug reports reflect the teachings of the Great Master Jedi Kaner in his manuscript testing computer software? If you’re still not sure then here’s a sure fire answer, Can your Mom or Dad repro your bug report? I guess you could say your dad invented the computer or something and totally can, but what I mean is, can someone NOT on the project with limited technical skills pick up your bug report and repro it. If the answer is no, Then it’s time to dust off that Kaner book. If the answer is yes, then congratulations! Now show someone else what you are doing, maybe your good habits will rub off on them!
I was copying over some old bug reports into our new database the other day, It would have been nice to just import them all in, but if that was the case I would have missed out on the first hand realization of good bug reporting. As I was copying them over I noticed the difference in the bugs that were written before we were put on the project. Now I am not slinging mud at anyone nor tooting my own horn. But the difference was painfully obvious. The bugs that were poorly written had tons of notes added to them like, “Cannot repro” What do you mean by this abbreviation” “Please explain” and on and on. I also noticed the poorly written bugs took almost twice as long to come to a decision about and close.
If you have been writing bug reports for years and years, you’re probably thinking, I don’t need to read any further, I KNOW how to write a GREAT bug report! If that’s true I have a challenge for you!
Knowing how to do it and DOING it correctly are two separate issues. I have found in the Software industry , the longer test engineers write bug reports, the more the information in the reports tends to get muddled in speak that only makes sense to those directly on the project. Or shortened down to a brief description that leaves out the “Obvious” steps. I have even seen bug reports that are simply the Description line.
And how is this helpful to the Developer in another state or Country? She may not know what your acronym means, she may need the “obvious” steps you left out in order to correctly repro the bug, and using the description line as your bug report is, well, that’s just sad. (You need to shape up or ship out mister!)
It takes allot of time for information to get interpreted and dealt in a cost effective manner, add in language barriers, distance and the ongoing trend of outsourcing and a poorly written bug report can suddenly add up to allot of unnecessary time, money and effort!
How can I tell if my bug reports are written properly? Well, in my opinion, the correct answer is, Do your bug reports reflect the teachings of the Great Master Jedi Kaner in his manuscript testing computer software? If you’re still not sure then here’s a sure fire answer, Can your Mom or Dad repro your bug report? I guess you could say your dad invented the computer or something and totally can, but what I mean is, can someone NOT on the project with limited technical skills pick up your bug report and repro it. If the answer is no, Then it’s time to dust off that Kaner book. If the answer is yes, then congratulations! Now show someone else what you are doing, maybe your good habits will rub off on them!
Subscribe to:
Posts (Atom)
