Fan - Marcus Buckingham

Yes I love the term Facebook uses. I mean really Fan I cannot find a better word for it. So here goes this section is for people, places, things that have inspired me over the years. And I am starting this with Marcus Buckingham, a speaker, an author and a lot more.

Marcus Buckingham has inspired me to look at my strengths. Yes its not easy for me especially having grown up in India where the focus is over all growth and if there is a subject that we are not good in then the whole family and community focus on that one weakness instead of the million other strength we have.

Going back to Marcus, his books and seminar have inspired me a lot. I feel more confident in using my strengths and also have learned to deal with my weakness.

I was lucky to have been able to hear him in 2009 in Alexandria, Minnesota. Here is a picture I took with him.

*Yes he is as cute face to face as he is in pictures.

Seminar: Presenting Data and Information - Edward Tufte

Recently I had a chance to attend Edward Tufte's seminar in Minneapolis, Minnesota. From what I hear Mr Tufte presents this couple of times a week. The seminar was held in the Minneapolis Marriott City Center. This was the first time for me at this hotel. The actual seminar was from 10 am to 4 pm. You could go in early to gather your package and also have some one one one time with Mr. Tufte. He even signs your books.

So I went in, got my package and agenda. There were some recommended readings before the seminar started. I was pretty impressed with the check in process. Show the bar codes, get checkin and gather the package. How easy.

Well I gather my stuff and sit down to read the books. It was a little hard to focus on the readings with trying to keep an eye on whether Mr. Tufte will come to you to sign the books since he was walking around and signing them at random. The package had 4 books written by Edward Tufte.

The Visual Display of Quantitative Information
Envisioning Information
Visual Explanation
Beautiful Evidence

Anyways I was lucky enough that he stopped by and talked to me for a couple of minutes and signed my books. We got into a discussion about presenting data and audience. Without going into the actual details I will give you a gist of what I learned from him in those 10 minutes that helped me understand the rest of the presentation.

Its all about the content. Know your content.
Be brief but precise and intense.
Do "what ever it takes" to present data.
Get a good template and stick to it.
Use super graphics.
Simple.

I really enjoyed the presentation though it takes a while before you really connect the dots. I don't necessarily agree with everything he had to say but all in all I took several pages of notes and think that I will be applying a few when presenting data in the future.

I will probably talk more about his seminar in my future blogs Also the 4 books we got totally worth attending the seminar for.

Metrics - A Tester's True Friend, Not A Foe

Metrics Oh Metrics it took me a while to understand you. Now that I know you I appreciate your help with presenting status or talking to the project team.

Yes its true I love metrics and I will give you ample reasons so you would love them too. Well maybe not love but atleast start appreciating them better.

1. Metrics helps tell stories with data. "Story" lets start with defining it. Story really is what you are trying to achieve example a new release for your product, hot fix, user acceptance testing for a product that interfaces with your application, or a mini regression cycle for production release. So the goal of the metric here is to tell your story - where you are, where you should be and how much is left.
• Where are you? Really that is your actual work say how many test cases did you write so far, how many test cases did you execute and what is the status of those tests.
• Where should you be? - say today is the last day of your test case creation phase you should be at 100% test case creation complete but if you are in 90% then your data should show where you are and you should be able to explain why you are not at 100%.
• How much is left? - this is very important information - what is left to do, how many test cases do we have to execute or how many defects have to be retested. Imagine if your project manager comes to you and says "Sorry to say but we have release one week early and since testing team will be affected the most, can you tell me how many more resources would you need to complete your release?" You should be able to pull these numbers from your metrics that you have been maintaining. You should be able to tell exactly how many people you need to get this done in the time frame you have.
2. Metrics helps predict trend. Trend is important. It helps replace words like my gut feeling says this is not a good build or my gut feeling says we have a lot of defects. No your data should tell you if you have higher than unusual defect density or if a certain build has more defects for a certain feature that in turns shows the high risk area that needs regression testing. Really let the data support your gut feeling. Next time you have a one on one with you manager or a team meeting talk with numbers and you will see a huge difference in how they perceive your gut feeling when you tell them the product is not ready for release.  
3. Numbers or data have the same meaning. It cannot be misinterpreted. If you have executed 100 tests and 50 fail then your failure rate is 50% there is no two meanings to it. Well ya you can say 50% pass rate. Either way it means the same. So when we bring numbers to the table, there are fewer arguments over what the data means.
4. Metrics shows quality. Metrics really shows the quality of the product and tracks the quality too. How many defects were logged, how many of those defects were fixed, how many are critical? For test exection it shows how many test have failed and how many test cases have yet to be executed. Metrics speaks volume for the quality of your work, your teams work and shows the readiness for the release.

Takeaway - If you create good metrics it will help you make your life easy. It helps you manage your testing project better and also get the rest of the product team off your back when they worry about status or progress.

Why Testing?

Over the past several years people and interviewer's have asked me this question a lot. Why are you in testing? Or why did you choose testing? And I have always replied with "Why not testing"? I didn't grow up saying I want to be in testing, I didn't think about it when I was in college. I was offered an opportunity long ago by a friend. He said try it out and don't do it if you don't like it. So I gave it a try and never looked back.

I believe there are two sets of people. People who understand testing and people who don't understand testing. No I don't mean definition wise or theoretically. I mean more in terms of concept. You can learn as much as you want about testing and claim to apply things you have learned. The real understanding comes from how you handle it in real time.

Lets take for example the definition as stated in the CSTE CBOK
"Testing is the process of evaluating a deliverable with the intent of finding errors."

This sums up the testing process. The greater problem lies in understanding errors, how to find them, and also what deliverable we are talking about. Its really the thinking behind the actual job that counts. You can dive in deep and test or you can float in the job of trying to test to come out on the other side really not knowing what you have to do.

Testing is an art and a science. And you have to understand both to really understand testing.
Definition of Art (Merriam-Webster)

• skill acquired by experience, study, or observation
• the conscious use of skill and creative imagination especially in the production of aesthetic objects; also : works so produced

It really drives down to the fact that testers have to be open to a lot, should be willing to learn, be a good observer and willing to learn from experience. These things that we learn over time are skills that have to be applied to the job to be a successful tester. It is very important to use your skills and imagination. There are no limits or boundaries to testing. One does not stop at just testing, testing involves learning the system, putting on different thinking hats (Business Analyst, Developers, customers, end users, support line, etc). Its about being able to switch gears and roles to really bring the best of the product forward and identifying the risk (weaknesses) to help our organization to mitigate these risks. Its about the big picture - release of the product to the customer and to meet their requirements with as few risks as possible.

Definition of Science (Merriam-Webster)

• the state of knowing : knowledge as distinguished from ignorance or misunderstanding
• a : a department of systematized knowledge as an object of study b : something (as a sport or technique) that may be studied or learned like systematized knowledge
• knowledge or a system of knowledge covering general truths or the operation of general laws especially as obtained and tested through scientific method b : such knowledge or such a system of knowledge concerned with the physical world and its phenomena

There are a number of processes and functions that can be used for testing. The goal that the testers are trying to achieve are finding as many risks (defects or bugs) before the product goes to production. There are a large number of scientific processes that testers can apply to get this done. CSTE CBOK get into a lot of them in detail and I don't want to get into the actual process here.
 
The point I am trying to get to is between being an art and science, Testing often the most misunderstood job in the technology industry. Its not about breaking anything. No its not breaking software. Testers simply bring out the risk (defect, bugs, weakness - each one defines it differently ) of the software. And this job is no less no more than any other technology job that is out there.
 
So why testing? Because its art and science and needs skills. I have the skills and am a successful tester. So any tester who still doubts their role please don't.

Why "Today's Big Picture"?

I have been meaning to start a blog for a long time. I debated on the topics, the name and the purpose. In the end I decided I just have to start it and depending on the day I could bring what is important to me to the table here in my blog. As a full time working mom, when I have a lot of things going on, I always remind myself that the most important piece is the big picture. Technically big picture is my goal. Sometimes its as simple as get a document out before end of the day or it can be a month long project where I need my team to help. When a lot goes on I try to break things down into smaller chunks and this helps with positively marching towards my big picture.