| || |
quality research area
in fact I am about to start my research which is about quality of software development ,, my supervisor asked me to think a bout a way that estimate quality from uml usecases or quality tracing approaches that trace quality backward of forward during the system life cycle. I am not sure if this is possible ,, as most of you have good experience in that field I would be thankful if you just enlighten me with some ideas that could be a possible area of research ..
Re: quality research area
Researching about something as amorphous as "quality" is a big task. Is there a specific area you are targetting or are you going to try and make some sort of broad topic?
I'm not sure you can estimate quality just from use cases, unless you are testing the quality of the use cases themselves, its not something I have tried at that level.
From the life cycle there are ways you could try and determine the "quality of the builds" if that is your goal, and you determine a way to do that is the number of defects opened and closed during each. But I don't really see a value in that, unless that is how you are going to narrow your approach and you say that the quality is judged on these metrics. It's still no guarantee that you will be correct.
I'd try and narrow the focus first before trying to get into something as broad and wide as what you are saying.
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
Now wasting blog space at QAForums Blogs - The Lookout
Re: quality research area
Michael is right on the money when it comes to narrowing down what you want to define as quality. I had recently worked on a project where the only documentation other than the code itself was poorly defined use cases. The project was late by 2.5 months. Between the developers trying to figure out what to design, very little interaction with the users as well as QA being limited it the testing approach. The only reason why I was able to cover more testing was because I was able to read the code. And this is a tedious task, did not allow me to take the time to write up test cases like I would normally.
Use cases are fine for a general idea to start but be prepared for lots of communication between the users/customers/marketing/sales and QA, Dev and QA, project management and QA. Your research right now should be to research what requirements are needed for each use case. Try to define what is expected for each situation. Ex: Use Case - user able to enter customer information into system and that information is required. Define EXACTLY what that customer information is needed and which fields would be required. Hammer away at the right people to define the expectations. This is critical now. Try to take the guess work out of Development's hands.