Classic Software Testing mistakes

Classic Software Testing mistakes – An introduction –

Have you ever heard the expression “Been there, done that!”

Well…I have many times and when it comes to mistakes the above expression can be at least a bit annoying, don’t you agree?

This is my point: We human beings are prone to mistakes have the habit of inadequately communicating, and in most cases, we are bad listeners as well.

Add the above flavors to the “Time vs. Budget” recipe, and you end up with a tasteless “This is not what I ordered” meal. So what did go wrong?  Have you come across the “Quality Triangle”? Quality x Time x Money, if you had to select 2 out of the three which would you pick? Generally speaking, the “winners” tend to be Time and Money. What about Quality, you may ask? Well, that is something that we will try to squeeze in with as few resources as possible to execute as many tasks as possible within a incorrect time frame. Furthermore, if you contemplate the fact that the “Quality” element has been damaged, it is plausible to assume that the entire SDLC could be at risk. So if you are a tester like me you are probably saying…”been there, done that!” When I look at the subject “Testing Classic mistakes”, I usually but not always blame the budget restrictions. If you as a company want to save some cash in the project you can within other options 1. Start cutting corners and/ or 2. Reduce overhead costs by hiring “Cheaper” labor.  That in turn could mean you have under skilled stuff. Think about this:  Testing is a skill, it won’t just pop up from somewhere!  You need specific testers for a specific testing effort. You need a unique mindset, attitude, approach, work frame and methodologies that only testers can provide. If not enough hard cash is made available for a suitable Software Development Project (as every project will have its own specific requirements), and as a consequence the project lacks the stuff and skills, maybe it’s time to hold back for a while. Top management must clearly understand about the cost of software defects as a function of time. There is a great article about this topic written by Donald Firesmith at the LinkedIn website.

Obviously, budget restrictions are not the only barrier when it comes to point the finger at the mistakes in the SQA environment, of course not.  There are quite a few that we must consider: “…Most of the classic mistakes have seductive appeal, which is part of the reason they've been made often enough to be considered classics. Do you need to rescue a project that's behind schedule? Add more people. Do you want an earlier delivery date? Just set a more aggressive schedule. Should you keep a key contributor who's aggravating the rest of the team? Yes, the project is too important to let him go…” by Steve McConnel.

I will broadly write and briefly describe a list of mistakes which I think are at the core of the “Classic Mistakes” or as I like to call it “The Immortals”, let’s have a look at them:  All the below examples will be better explained and analyzed on my next article. 1. Testing Tasks and Responsibilities: A first major mistake people make is thinking that the testing team is responsible for assuring quality. Remember this short sentence “ Finding bugs important to customers” 2. Prepare your testing effort correctly: test plans biased toward functional testing – make sure to cover cross functional areas - Insufficient diversity in test strategy - 3. The work force: Make sure you have the right people to the right job! 4. Let’s crack! Testers at work: Paying more attention to running tests than to designing them together with poor bug reporting are both classic mistakes. 5. Test Automation: Attempting to automate all tests is not always cost effective and correct! Apart from the above specific SQA issues, I would like to add a few more: (Why not?J) 6. Bad-mannered Team members: Failure to deal with such problem can undermine the morale and motivation of the rest of the team and potentially increases stuff turnover, product quality and productivity. 7. Abandoning planning under pressure: ran into schedule difficulties? Ditch the plane!  I mean the plan! No mitigation plan means the entire project is now in a chaotic state. 8. Cutting corners: Projects that are in a hurry try to cut out nonessential activities, such as analysis, architecture, and design. From the Quality Assurance point of view the cuts will be executed by eradicating reviews and test planning. The Ax cutting effect: Cuts at the QA activities early in the project means extra QA hours at the end of it. The question now is how much it will cost to get it fixed? 9. Lack of Change Control: How much of the software requirements can or probably will change until release?   10. Location and infrastructure: Too many people! Broken chair? Hard to concentrate? That’s it folks, I hope you have enjoyed reading this article and looking forward to seeing you again soon.