A Bug’s Life:
A software bug begins its “life” as code or some other artifact of the development process. No one might know the bug really exists until the code or design is excercised by someone, usually a customer, developer or tester
Anatomy of a Bug Report
Ttile
Description
Status
Version Number
Feature Area
Reproduction Steps
Assignment
Severity
Customer Impact
Environment
Resolution
Tuesday, July 21, 2009
Thursday, July 9, 2009
How we test Software at Microsoft
I recently picked up this book called "How we test software at Microsoft". I think every qa person should have 1 copy. It has rich resources, tons of information, different methodologies, baseline studies and tests, case studies and much more.
One amusing fact it talks about is being in a situation where the bugs "wont fix" meaning that a fix was not planned for the current or future release. The reason for these resolutions was simple: The code was "too scary to touch" and apparently the original developer had left the company years earlier. The code was so complex and difficult to comprehend that not a single developer was comfortable fixing bugs for fear that he or she would cause a dozen other failures - Now we all know this doesn’t happen to us "regular" people does it ??
Anytime simplicity isn't a part of the initial design and implementation of the software, there is potential for the code to grow into a nonmaintainable mess. I believe, proper QA Analysts should be involved at the start of the SDLC to ensure to keep it simple. A professor once introduced the term "KISS" - Keep It Simple Stupid :)
The book talks about using Metrics for evaluation and testing. One such metric is Halstead Metrics:
Halstead metrics are an entirely different complexity metric based on 4 measurements of syntax elements in a program:
Number of unique operators
Number of unique operands
Total occurrences of operators
Total occurrences of operands
Eg. To measure the code length. Halstead metics has an formula – (n1/n2) * (N1/N2)
Model-Based Testing Tools at Microsoft
Spec explorer – One powerful tool used for model=based testing at Micosoft. This was created in 2002. It can do impressive analysis and transformation of the model program that generates FSMs(Finite State Machines)
Spec explorer for Visual Studio – 3rd generation spec explorer
One amusing fact it talks about is being in a situation where the bugs "wont fix" meaning that a fix was not planned for the current or future release. The reason for these resolutions was simple: The code was "too scary to touch" and apparently the original developer had left the company years earlier. The code was so complex and difficult to comprehend that not a single developer was comfortable fixing bugs for fear that he or she would cause a dozen other failures - Now we all know this doesn’t happen to us "regular" people does it ??
Anytime simplicity isn't a part of the initial design and implementation of the software, there is potential for the code to grow into a nonmaintainable mess. I believe, proper QA Analysts should be involved at the start of the SDLC to ensure to keep it simple. A professor once introduced the term "KISS" - Keep It Simple Stupid :)
The book talks about using Metrics for evaluation and testing. One such metric is Halstead Metrics:
Halstead metrics are an entirely different complexity metric based on 4 measurements of syntax elements in a program:
Number of unique operators
Number of unique operands
Total occurrences of operators
Total occurrences of operands
Eg. To measure the code length. Halstead metics has an formula – (n1/n2) * (N1/N2)
Model-Based Testing Tools at Microsoft
Spec explorer – One powerful tool used for model=based testing at Micosoft. This was created in 2002. It can do impressive analysis and transformation of the model program that generates FSMs(Finite State Machines)
Spec explorer for Visual Studio – 3rd generation spec explorer