Last minute issues...

You may read many articles and books about Testing and many of them said that the earlier you find issues, the better overall.

Is that really true? well, based on my experience, Yes, it is true. However it is always possible for all issues? No it is not.

There are some issues which we may find only when the product and QA are mature and ready.

I'm not trying to say that QA doesn't have to be part of early planning and reviewing to find out issues. Yes it is very important to find out design level defects. it will help to improve the productivity of overall process and it will reduce the issues later.  However, even with all efforts, you will encounter the last minute issues when product is mature and fully integrated, also QA(team or person) have enough knowledge about the product in user's perspective. (it is different topic to talk about why QA can't understand everything at the beginning. so I'll talk about this later.)

Why? in my opinion, it is very obvious that the problem was not there at early stage of product or it was hidden some way and waits until the time comes. it may sound strange. but in my opinion, it is true. 

if so, how can we reduce these last minute issues? Well, I don't think that there is gold bullet for these. but I think that there are some things that we can consider the below for improvement.

- Keep in mind the integration at the beginning at design level and QA should look at the level of each individual tree and also the big forest. not just your component integration, but also at the final product level. it doesn't have to be done by everyone. but some one in the org should look into this as early as possible.

- Have better communication channel between teams. modern S/W is very complicated and has complex dependency between components. so if you don't understand the changes and progress of depending components, you can do properly QA work at all. so the information should be delivered appropriately.

- Education on the base technology of the product for QA. why? the more you know, the wider and deeper you can see.

- Have various types of user scenarios in various level. you need to have feature level user scenario, component level, and integration level and real world user level scenarios. just doing feature level unit test will not let you avoid the issues.

-  Nothing is wrong. you just need to validate what you are assuming... Generally we assume how the product will be used. and QA team is directed to focus on main line scenario all times. Yes, I agree that it is important and proper way to do approach to product with limited resource. However, we need to validate our assumption in someways like beta feedback and news group monitoring or userability study. Well when you see the result, you will be supprised by the result. there are many different ways for our customers to do their work with product.

There are many things to consider besides these. Anyway, important thing is that we need to understand the process and stage of product and we need to prepared for coming stage and do proper testing.

Comments

• Anonymous
  April 15, 2004
  The next worst issues for QA and the entire team are probably the so called 'firefighting issues', i.e. urgent issues reported by customer after release. Wonder if you can share some of your experience here. Or ask some folks on the Security Patch team to share their experience.
• Anonymous
  April 16, 2004
  Yeah.. it can be good topic... I'll consider it.
  
  thanks,
  Min
• Anonymous
  July 06, 2004
  Yeah, I feel exactly the same way.