Quality Frog Details

Things We Know
2007-08-09 01:00:00
I find it at work. I find it in online forums. I find it in books. I find it in papers. I find it in blogs. I find it at conferences.I hear it from experts. I hear it from freshers. I hear it from friends. I hear it from managers. I sometimes even hear it come out of my own mouth.It influences testers. It influences developers. It influences managers that influence testers and developers. It impacts customers.It wastes time. It wastes money. It frustrates developers. It confuses executives. It demeans testers. It decreases quality in the name of improvement.It permeates the practice of developing and testing software.What is this ubiquitous it?It is testing folklore.It ain’t so much the things we don’t know that gets us in trouble. It’s the things we know that ain’t so.- Artemus WardHere are some examples I pulled off the top of my head:There are best practicesTool vendors know those best practicesThe right tools make good testingTesters are the enemies of ...

Extreme Telecommuting
2007-08-04 20:41:00
"Ten years ago, there's no way this would have worked. Now there are hardly any barriers."- Anthony PageMany of us spend most of our days trapped in a cubical or windowless office. At times I have enjoyed the opportunity to telecommute from home. I've had some good and bad home offices over the years. I've worked with great views and I've worked in basements. I'm a bit envious of James Bach's new digs.I have the pleasure of working from home one day a week. I look forward to this day because I don't have to deal with traffic, I can work in the comfort of my own home, and I can get work done with fewer interruptions.Earlier this week, I came across a CNN story about telecommuters that don't work from home. These telecommuters work from wherever they want to be. They are working globetrotters. Today's technology makes it possible for many people to work from anywhere in the world. I think we are still some time away from this being an option for many employees. Howeve ...

For Better or For Worse
2007-07-26 04:06:00
I just stumbled across a 1986 quote from then-president of now defunct Ashton-Tate. I think it has application to automation in software testing."A computer will not make a good manager out of a bad manager. It makes a good manager better faster and a bad manager worse faster."-Ed EsberAll software is automation. Therefore, all software testing involves some level of automation.Automation has potential to do good or bad faster. And, faster is not necessarily better.Let's be smart about how and what we automate. Ben Simo QualityFrog.com Questioning Software℠ ...

Keys to Innovation
2007-07-26 02:52:00
Lee Copeland's CAST keynote address referenced in a previous post was not only about books. Good books was one of the items on Lee's list of eight recent innovations in software testing. Lee's complete list is shown below.Innovations in Software Testing(Lee Copeland's List)Context-Driven School Testing Specialties Test-First Development Really Good Books Open Source Tools Session-Based Test Management Testing Workshops CertificationI was glad to see most of the items on this list. I am especially happy to see the Context-Driven School and Session-Based Test Management on the list. I believe that these have had a significant impact on software testing and have great potential that has not yet been realized.Tester certification may be an innovation but I don't think its impact has been good. In my opinion, the current certification options are bad. (There was a certification debate hosted by AST at CAST this year. Please take a look at Tim Coulter's review: AST Certification D ...
Innovation

Woodpeckers, Pinatas, and Dead Horses
2007-07-13 04:38:00
Here's some short blurbs of a few things I took away from CAST sessions.From Lee Copeland's keynote address:"It's nonsensical to talk about automated tests as if they were automated human testing."Write or speak about something you're knowledgeable and passionate about.Combine things from multiple disciplines.From Harry Robinson's keynote address:Weinberg's Second Law: If Builders Built Buildings The Way Programmers Write Programs, Then The First Woodpecker That Came Along Would Destroy Civilization.From Esther Derby's keynote:To successfully coach someone, they must want to be coached and want to be coached by you.From James Bach's tutorial:Pinata Heuristic: Keep beating at it until the candy comes out. ... and stop once the candy drops.unless ...Dead Horse Heuristic: You may be beating a dead horse.yet beware ...If it is a pinata, don't stop beating at it until the candy drops; but if it is a dead horse, your beating is bringing no value. It can be a challenge to determin ...

Exploratory Scripted Automated Manual Testing
2007-07-13 03:18:00
Exploratory testing is often said to be the opposite of scripted testing. Automated testing is often said to be the opposite of manual testing. Instead of placing testing on one end of the spectrum or the other, I find it good to look at these as opposite ends of a spectrum. I believe good testing contains components spread throughout the spectrum.I think we get into trouble when we apply these labels to “testing” as a whole. I believe all software testing has some aspects that are exploratory, some scripted, some automated*, and some manual. Hopefully all are driven by sapience.Here are some things I remember about one of the best testing projects in my experience:• Organizational testing processes were well documented• Requirements were well documented• We had enforceable quantitative requirements• Tests were well planed• Test plans were well documented• Test cases were well defined and traceable to requirements• Tests were well scripted• Automation was an in ...
Manual

Read any good books lately?
2007-07-10 22:00:00
"I've never read a book about software testing."- too many testersIn a CAST keynote address about recent innovations in software testing, Lee Copeland relayed a story about asking all the testers at a large respected financial company about their favorite software testing books. Lee said that every one of the testers said they had never read a book about software testing.Lee compared this to a surgeon informing a patient that they've never read a book about surgery, but not to worry because they are a good surgeon.I too have asked a number of testers about their training to be a tester and have often received responses similar to those reported by Lee.I want to pass on Lee's encouragement to read. Lee also heralded the benefits of applying lessons learned outside technology fields to testing (e.g., philosophy and psychology) to software testing.There was a time that there weren't many testing books from which to choose. This has changed. Today, there are many. There are some go ...
Books

Too much testing?
2007-07-08 11:32:00
In a recent blog post, Jason Gorman provides some thoughts about the following question:How much testing is too much?To me, this is like asking "how much cheese would it take to sink a battleship?" There probably is an answer - a real amount of cheese that really would sink a battleship. But very few of us are ever likely to see that amount of cheese in one place in our lifetimes.- Jason Gorman As Jason states, we may never encounter too much testing. However, I believe that we testers often include too much repetition in our testing and miss many bugs that are waiting to be discovered. This becomes especially likely when we limit our testing to scripted testing or put our test plans in freezers. Repeating scripted tests -- whether manual or automated -- is unlikely to find new bugs. To find new bugs, we testers need to step outside the path cleared by previous testing and explore new paths through the subject of our testing.Executing the same tests over and over again is like a grade ...

I'm a user and I just did that
2007-07-07 03:03:00
Michael Bolton just blogged about the sometimes common exchange between testers and developers that often goes something like this:TESTER: I found this really important bug. Look at this. Let me show you ...DEVELOPER: No user would do that.TESTER: But, I'm a user and I just did that.DEVELOPER: But, the real users won't do that.Michael states that what the developer really means is "No user that I've thought of, and that I like, would do that on purpose." This is very true. Michael also points out that we testers are not the real users and may do things that the real users are not expected to do.Thinking of users that the developer did not think of is an important service we testers provide. This becomes especially important when we put applications on the Internet. We need to consider the users and user behavior that the developers did not consider. I believe it is our responsibility as testers to tactfully provide the development team with the information they need to make an infor ...

Ugly Babies: Another Reason Why We Need Testers
2007-06-28 02:20:00
... I got on the train ... And I noticed that the woman across from me in the aisle had her baby with her. Ugly baby. Ugly baby.From the other end of the coach comes this guy and he was very drunk and he was staring at the baby. ... And the guy said, "I'm looking at that ugly baby. That's a horrible looking baby lady. Where'd you get that baby from?"And the woman said, "I don't have to take that!" And she snatched the emergency cord and the train came to a screeching halt, and the conductor came running in.Now this was his moment. At this moment he represented the Pennsylvania Railroad. And he said, "what's going on here?"And the woman said, "This man just insulted me. I don't have to spend my money and ride this railroad and be insulted. I'd rather walk."And the conductor said, "calm down! Calm down! Madame there's nothing, nothing that the Pennsylvania Railroad will not do to avoid having situations such as this. Perhaps it would be more to your convenienc ...
Babies Ugly

Software Development Life Cycle Explained
2007-06-24 08:42:00
A couple weeks back, there was some discussion on the software-testing group about the use of the term "SDLC" on resumes. (Matt Heusser posted some excerpts from this conversation here.) My warning flags go up when people claim to have a "full understanding" of the SDLC. I sometimes see this as an indication that someone may not be as experienced as they claim. The "SDLC" will vary from one company to another and even one project to another. SDLC is a process documentation term -- and there are many differing processes used to develop software. Its not how people talk in the real world.I recently re-stumbled upon a description of the SDLC that seems to be fairly common across many companies and projects. Perhaps this is what people are referring to when they claim full knowledge of the SDLC. :)Software doesn’t just appear on the shelves by magic. That program shrink-wrapped inside the box along with the indecipherable manual and 12-paragraph disclaimer notice actually came to you by ...
Development Life Software Software Development

[First] � Prev 1 2 3 4 Next � [Last]

3806 blogs in our database.
Statistics resets every week.