Power (or not) Point - Presentation

I recently read James Christie's The medium’s PowerPoint, what’s the message?. It was one of those articles that makes you stop doing what ever it is you are working on and start thinking.

I will be the first one to admit that when I started using PowerPoint I thought it was the next best thing after Windows. I fell in love with the application. I used it everywhere and anywhere I could to do presentations. The cool animations, the control that I had on how to share the information, the colors I could play with - well the list just goes on and on for things I loved. Yes I loved the power of PowerPoint. I still like the power but the big question is how much power do I really have if I don't cater to my audience.

Presentation is not about the presenter, it is about the audience and like James says "the message".

Yes power point is still a powerful medium but as presenters we have to find the right balance. Depending on the audience and message the presenter has to modify the presentation. Using power point is a choice and should not be considered as the most important element.

Start with "the message", understand "the audience" and "the medium" will automatically fall into place.

Defect Density - How and why I gather this for my test metrics

When I was asked to calculate defect density for my projects, I wasn't quite sure what it was. I researched it online and found several articles on it. Most of them recommended using lines of code to measure defect density while others suggested using function points.

Defect density is usually calculated per thousand lines of code. As a tester I was struggling with this as I didn't have access to the codes and even if I did get access, I couldn't figure out how I would related the defects found to the code line.

I had to be more creative and decided to try calculating this by builds being tested. I had metrics for defects found by build and test cases executed by build. I also knew the features and changes being delivered in each build and this would help me narrow down areas that testing could focus on. 
So the formal I used to calculate defect density was
Defect Density = Number of defects found per build/number of test cases executed per build

I calculated this for each build and also tracked cumulative metrics to look for trend. Here is a sample of one of the defect density reports I created

Why calculate defect density?
Here are some things that this test metric can help with

• Identifies cluster of issues in an area or feature to narrow down root causes
• Identifies areas that need additional testing focus, re-engineering or redesigning
• Identifying defect dense areas help focus limited resources in those high concentration features
• Measures amount of rework - identifies features or areas where rework needs to occur or has occurred
• Compares relative number of defects in different components of the software application
• Predicts remaining defects when compared to expected defect density based on the trend
• Determines if testing is sufficient
• Creates baselines for standard defect density
• Can be used to measure quality improvement activities for later releases

This is not a perfect method to collect defect density. There are some drawbacks to this method of collecting this metrics

• Not all test cases will be similar. Some may be longer and some smaller. There could be more than one defect associated with each test case or multiple test cases could fail because of one defect. These have to be taken into account when the data is being looked at.
• Some defects may not be related to the test cases at all. And its hard to decide whether to count defects that are found during the execution of the test cases or not.

My Take on CSTE

Yes I am certified. There was a time I said I will never take this test. I put it off for about 4 years. Then finally gave in and said why not get certification in software testing since I don't plan on leaving this industry anytime soon. I mean no harm in trying something at least once. I started preparing in the summer of '09 and decided to write at the end of the year. I wrote the exam Nov 09 (right after thanksgiving) and got my results Feb 2010.

Some things that helped me

1. Group studies - bunch of us from work decided to study together and it helped a lot. It was easier to discuss and understand the content (software testing and testing management as defined in the book) instead of sitting alone and trying to figure it on your own.
2. Index Cards - I wrote almost everything important down on index cards. This was almost everything in the book. Sorted them by chapter and would have them with me at all times. I would go over them when I got a few minutes.  Then every week I would sort them into separate bundles - easy, hard, not sure. Pretty close to the exam the easy bundle was small and hard was small but the not sure pile sure was high.
3. CBOK Made Easy - We think we know testing but the definitions and explanation here in the book are really based on testing as we knew in 80s, 90s and some from the current decade. But remember to pass in this exam you really have to write their definition and also choose multiple choice answers based of the content of the book. We may or may not agree to it but then we are not being tested for agreement, the test is all about how much you know about testing in terms of the CBOK. Found a link to a book which made the CBOK easy. If you google you can find several different versions of this book. It basically defines the CBOK and also makes it easy to understand. I read both the books in parallel and it helped a great deal. When you start studying, you really have to unlearn what you know and learn their definitions at least for the test.
4. My strategy
• Start with chapter 2. If you start with 1 you will loose the motivation to continue. Chapter 1 is the largest, hardest and confusing chapter. So start from 2 and go to 10 then come back to 1.
• Read all chapters at least twice. First round take your own time, write the index cards. Second time do it faster and also use index cards to refresh some definitions, etc.
• The days before the exam only use your notes and index card and go back to the book if you need some examples or are looking for something specific.
• The days before get rid of everything. Get good nights sleep and leave the rest to what you already know. No use trying to get more confused.
5. Actual exam
• For essay questions - write the key words. Don't waste time explaining it all. The computer doesn't care.
• For multiple choices - try to eliminate as many answers as you can and work on the ones that you think fit the most.

Now that the I have the certificate what did I really learn?

1. CSTE is a good refresher - It really is a refresher. There are things you forget over time and studying for this exam gives you an opportunity to refresh your knowledge. 
2. Common language for co-workers - A lot of times we get into discussions with co-workers and having this common language from one book helps reach conclusions. We just grab the latest version of the CBOK and look up topics that we want to discuss.
3. Similar foundation - This really gives a the team a similar foundation. People come from different background, different education level, different experiences, so this really ties them all into one category (good or bad).
4. Substantiate your knowledge - It sometimes help to read about software testing and testing management to substantiate what you already know.
5. Certification - Its now an addition to my resume, my profile, my experience. No one can take it from me.
6. Learn something new - There are things about testing that we either didn't know or knew vaguely. This book really gives us information in various areas that we may not have experience with example I have never worked on mobile application or done security testing. Reading those chapters really gave me some new knowledge.
7. Recertification - for recertification you either take the exam again every 3 years or you read/attend seminars, etc. I think this is good a motivation for education, attending seminars, learning something new etc. I don't think I want to write the test again so I will be focusing on the latter which adds more value and experience than retaking the test.

Book Review: The Buck Stops with You! - John Graci

When Leaders Lead, Employees Become Motivated

Read this book over the weekend. This book has a lot of common sense strategies to help managers motivate their employees. John Graci talks about how managers can really make their employee feel good and want to come to work.

A few of his techniques that really made me think and want to apply:

Listen up - really this shouldn't just be managers we should all be listening to each other at work be it a team member in your project team or a co-worker who may have a suggestion.

Perception is reality - no matter how much we try to deny or justify if someone perceives something to be true then its part of their reality and its hard to change that. If someone things you are rude in your emails even if you don't think so, then its true for them and we cant change that. I think perception management is important for any manager or employee if they want to succeed.

A few other things he talked about were
Involve employees in change
Coach don't lecture
Give recognition
Delegate Authority

Tracking Test Metrics

Tracking test metrics is really an important and integral part of a test lead's job. It helps track testing progress, testing trend and helps with telling a story with data. The data is always there. The leads responsibility really lies in determining what to collect and how to present it so as to tell the testing story to the stakeholders, management, project team, etc.

What to collect?
This question is not as complicated as it looks. It boils down to 3 things

Progress:
What did you plan for the release and where you are in a weekly basis. This is based on two things: Test case creation and test execution. Number of test cases planned versus number of actual test cases created. Number of test cases planned to be executed and number of actual test cases executed with their status (pass/fail).

Some examples of metrics for gathering Progress are

• Planned Test Cases Created versus Actual Test Cases Created
• Planned Test Cases Executed versus Actual Test Cases Executed

Trend:
Trend is more along the lines of the direction testing is taking and what you can predict from the metrics. What does the weekly execution data tell you as a lead? Do you see more failures for a new feature or an existing feature? Do you see more test case execution (productivity) occurring when you get a build early in the week than when you get a build mid week? Its all about letting the data talk to you. At times you wont even see a trend till you see the same data with different context.

Some examples of metrics for gathering Trend are

• Weekly Test Cases Executed
• Weekly Test Cases Created
• Cumulative Defect Density 
• Weekly Defect density
• Open and Closed Defects Per Week
• Defect Age

Quality:
This boils down to the defects that testing team finds. Defect data can be sliced and diced in several different ways and each time it really talks about the quality of the product. Based on the data that is gathered, a lot can be said about the requirements, code, design, product, test cases, testing process, customer, etc. Analysis of defects can really tell the organization a lot about how well we are doing our job and also expose our weakness that can then be easily rectified before the product goes out the door. Finding defects is in no way a negative to any one team or department. Its just a way to judge how we are doing.

Some examples of metrics for gathering Quality are

• New Defects found per week
• Defects closed per week
• Defects found per feature
• Defects found per build
• Defects found by Severity
• Defects found by Priority