Tester's Musings: Motivation to Test?

Our organization like a lot out there are going through a lot of change. Recession, doing more with less, hiring freeze, no raises, etc are just a few reasons as to why organization cant do better with motivating people. The traditional trends used to be give a bonus, provide, raises, give lots of time off, not ask people to work overtime or pay when people have to work overtime. With this new face of economic pressure there are very few options left.

I feel I am getting caught up in this where I am demotivated from doing my job. To pull myself out of feeling the misery I started looking for things that motivate me. Here is a list of few things that helped me

• Good Team: Working with a project team that is motivating really helps. I feel that if my project team can support me and have my back that I will do anything to support them. Creating a good team is key to having engaged employees. The trend with spread of agile shows that companies have recognized this.
• Rewards: yes I just said companies don't have the money to give rewards but then its not always about money. For me getting an unexpected half day off or not having to take personal time off when I need an hour or two to go visit a doctor speaks louder and tells me that my company cares about me. Working from home is another reward that I feel helps with in this economy and motivates me to give my best to my company.
• Customer voice - we hear a lot from customers when things go bad and we get their issues as defects that we have to fix immediately. Our company asks us to look at why we missed a defect. Recently our product owner shared a letter from a customer who thanked us for the work we do. They said they depend on us to do their job. This letter motivated me to make sure I do everything I can so I will have a few more happy customers. I am glad they shared the positive note from customers. I needed that to get through a few long days that I had to put.
• Employee Voice - President of our division met with each and every employee. I have been with this company for over 6 years. We had a lot of good years and this past year has been hard with all the financial changes (we are a lending based software company). When our president sat down for half hour with every one of us I felt like someone was there to hear my voice. He sat down and asked me what was working, what was not working and how can he help? Just the fact that he listened to my voice made a difference. I came out of the room feeling like the burden from my shoulders were taken. I don't expect miracles because I vented to the president. But just knowing that someone was there and can be reached if needed makes a big difference.

Every time I feel like giving up because I don't see immediate results or feel the work burden is going to kill me I am going to look back at my motivators. I have this listed printed out and posted in my office cube. I will not let this economy demotivate me. I am looking forward to better days but for now I am happy with what I can get.  

Automation - Magic Robot

Do you have any test automation for your project? If so does your management think its a magic robot that can pretty much do anything and that too on its own?

We have been asked to automate our project. It has to test everything, catch all defects and need no manual over site time. We try to explain that creating and maintaining test scripts is really important and project will have to scope in time for this every release.

A fellow blogger in the post Automation: Oh! What A Lovely Burden! talks about automation being a lovely burden.

What are some automation myths and how to manage them?

• Automation will test everything!
• Automating every single test is not a good investment. There are some features of the product that might never be used or used very little. Spending time on automating them may not give good return on investment.
• The more complex a test, the harder it is to automate it and the harder it is to maintain the test. If it takes a hour to manually test it during regression then just manually test it.
• Automation will catch all defects!
• Again this is a misconception. If something changes in areas that are already automated the automation test will catch it. If its in features that automation does not cover then we wont be catching it via automation. For example an automation test might check a box and continue with the test. A defect occurs when the box is checked and then unchecked. This defect was caught my a customer because its not a standard step that customers follow. It was a one off scenario.
• Automation will not catch defects in new features since they have not been automated yet.
• Once automation is complete no more time will be needed for maintaining those tests.
• Any change in future releases can impact automated tests. Time has to be spent in maintaining these scripts. It wont take as much time as it takes when creating new tests but its still time that testers have to spend and this time has to be planned into the project plan.

Yes automation is great but its not a robot and it wont do everything we would like it to do. It makes manual testing effort easier and also gives time to explore and test other features that are new or need our attention.

SOP - Its Really About Quality

Most dictionaries define Standard Operating Procedure as

• Established procedure to be followed in carrying out a given operation or in a given situation.
• A specific procedure or set of procedures so established.

What does SOP mean?

SOP is a written document detailing steps or activities for a certain process. SOP can be created for any existing or new process. This document helps standardize the process. The goal is to really do the job same way every time we do it.

Why create SOP?

• It details the activities that need to be performed and so there is a common understanding of the process among the people involved.
• Someone new to the position will perform the same task the same way as someone who has been in the job.
• It ensures the process is performed the same way on a continuous basis.

How to create SOP?

• Start with the team who is involved in the process. Include people who will be performing the job to gain insight and details that might get missed.
• Document current state of the process in the sequence it occurs.
• Document terminologies and define them so there is no ambiguity.
• Review the document with the team and get sign off.
• Maintain the document and review on a continuous basis.
• Establish a system for distribution and sign off when changes occur.

Bottom line: SOP are an integral part of creating quality systems. It provides information to perform a job consistently and properly. To get to a good quality output we have to have inputs that are predictable. For example I asked 10 non-testing people at work "What is regression testing?

Each one had a different understanding. One person said its "100% testing of everything" Another individual said "its automated testing". We have a Software Quality Control Handbook that defines our testing terminology but that is a document that we use internally. We also have explained regression testing to some extend in our Test Plan. This test plan is reviewed before every release. So then why is there a lack of understanding?

Well we haven't spent the time with the team to go over the process steps. We didn't define terms with context to the process steps involved within testing group. With a Lean Six Sigma project I am currently working on I am hoping to define the testing process and create an SOP that would make our lives a lot easier than it is today.

What this will then do is help with setting the right expectations from our testing processes and we can deliver a product that is tested and meets the expectations of the project team. Right now they expect us to test everything and catch all defects. Sure we did love to do that and then we would never have a release for any of our products.

The Test Story - My First Online Publication

I am really excited because one of my goals for 2011 has come true. In this blog "Welcome 2011" I talked about wanting to get published.
My white paper has been published in STP "Test &QA Report" You can read a summary at their site and also download the whole white paper.

Link to article - click here. One goal down, four more to go.

Ask or Answer and Get Paid

I am really excited about the latest badge earnings that IT Knowledge Exchange is offering. ITKE gives you points for every questions you ask, for every answer you provide and for approving answers. The details on earning points can be found here.

Here is my previous blog on ITKE.

This is a summary view of the points

• Ask a Question: 5 Knowledge Points
• Answering a Question: 15 Knowledge Points
• Discussing a Question: 10 Knowledge Points
• Accepting an Answer: 10 Knowledge Points - approve an answer a fellow member has give to your question

The more you exchange knowledge the more you earn. Their new rewarding system pays going forward and also retrospective. So if you have been active look for emails from them. If you have not been active this is the time to really look at how you can participate. More information can be found at

Earning Badges Pays Off - Literally!

Earning badges pays off - Today!

From here on out, prizes will be as follows:

• Bronze Member Badge: Sticker and ITKnowledgeExchange t-shirt
• Silver Member Badge: $25 Amazon.com Gift Card
• Gold Member Badge: $50 Amazon.com Gift Card
• Platinum Member Badge: $100 Amazon.com Gift Card
• Nerd Cog: $10 Amazon.com Gift Card
• Genius Cog: $25 Amazon.com Gift Card
• Brainiac Cog: $50 Amazon.com Gift Card
• Certified Nerd Cog: $10 Amazon.com Gift Card
• Certified Genius Cog: $25 Amazon.com Gift Card
• Certified Brainiac Cog: $50 Amazon.com Gift Card

If you have not checked out IT Knowledge Exchange the time to start getting active in asking or answering questions.

Mistake Proofing - Poka Yoke

"Your ability to mistake-proof of a process is only limited by your own lack of imagination." Shigeo Shingo

Last week I was at week 2 lean six sigma training and learnt a concept that really made me think of my job differently. In testing we at times look for bugs and we also do activities that are risk based. For risk based activities we look at the risks that can occur and how we can test or plan for it during testing.
The other side to a defect is how to mistake proof it in such a way that if the defect does occur how do we prevent or detect it. Its a back up of a back up - Poka Yoke.

Poka Yoke is Japanese for mistake proofing. It is the creation of devices that either prevent special causes that result in defects or inexpensively inspect each item produced to determine whether it is acceptable or defective.

When this topic was introduced in class I was thinking oh this is hard. I didn't understand it. Then the instructor gave examples. Automobile air bags - yes this is poka yoke. If the customer does have an accident then the car is helping reduce the impact. Another good example is auto door lock, seat belt warning, etc.

What is really happening in these cases are that a tester is being sent with every product. He or she warns the customer when a defect is occurring or going to occur. There are some cases where the customer can override it. Example of this is where you get a spell check error and you can still choose to over write it and use the different spelling than what is being recommended. When closing a word file a message is displayed do you want to save the file before closing and its up to the customer or end user to choose one option or the other.

After the class was completed we were given an assignment to come up with as many poka yoke's we can see around us. We all went home thinking this is hard we don't see as many of these mistake proofing as we think. Next morning we all came up with 200 poke yoke's between 11 class participants.

Its really everywhere....My favorites from the class

1. Garages have car clearance limits and have a height check before the cars go into the garage
2. Dryer/washer switch off when the doors are open
3. Garage doors do not close if there is an object that obstructs its closing path
4. Drop downs for most online applications have a state drop down
5. You have to enter email addresses twice when signing up online
6. ABS (anti lock braking system)
7. Bathroom sink have a little hole at the top of the sink to prevent overflows
8. Iron's auto switch off
9. Auto sensor lights/flushes
10. Keys enter the key hole only certain way

I love this concept and will be thinking of how to use this in our day to day activities be it how I write test plans, test cases or do my testing. After all I have to think of our customers everyday and add value for them.

Updates and TFS WIT - Pilot Project

My projects at work have been keeping me away from blogging. This project that I was helping with during the month of Jan is finally wrapped up and I have caught up with my other project work that were on the back burner.
The thing that I am most excited about right now is the implementation and roll out of TFS Visual Studio Work Item Tracking (WIT). Yes we are going to pilot our new tracking system. Our goal with TFS is that it will eventually be a one stop show for all our software development activities (code, builds, work items, requirements, test cases).
Right now we are only moving our work item tracking (defects and change requests) to this system. We already have our code in TFS. Eventually we will be using it for requirements and test management. We are not there yet but moving WIT is like being one step closer.

This project is special to me because this has a lot of "firsts" for me. My first project

1. I am leading the documentation process. I have a great team who is helping me put all the pieces together.
2. We are doing a pilot for a process roll out. I will get a chance to learn pilot project processes including but not limited to gathering feedback, training and supporting users, gathering metrics, etc.
3. I will be training teams outside of our core business unit. Its a great opportunity for me to learn about our other business units and their current/future processes.

I cant wait for the first pilot project to kick off. I will be back with more on pilot project implementation and process.

Risks and Mitigations in Cloud Testing

Here is a link to my post on Cloud Testing: Risks and Mitigation
http://solutions.wolterskluwer.com/blog/2011/01/cloud-testing-risks-and-mitigation/

ITKE - The IT Files Series - Yusuf Salwait

Read the whole interview here

http://itknowledgeexchange.techtarget.com/software-testing-big-picture/the-it-files-yusuf-salwati-part-i/
http://itknowledgeexchange.techtarget.com/software-testing-big-picture/the-it-files-yusuf-salwati-part-ii/

Help with an Article I am Working on

I am doing a survey for an article I am working on. If you would like to participate please reply to the following question and add your name and occupation at the end. Send the reply to shillu13@gmail.com or post it as a comment here.


Name one technology/trend that you adopted in 2010? (IPad, ITouch, Ebook reader, touch screen phone, cloud services, agile process etc) Do you love or hate it? Would it be hard to give it up? What other tool or technology did it replace? (old flip phone, desk top, books, waterfall etc)

Your help is much appreciated.

My Take: Test Manager (TFS Visual Studio 2010)

I was at the Microsoft Event - The Full Testing Experience - Quality Assurance with Visual Studio 2010. I am pretty excited about this tool and the demo I saw. There are some cool features that I wouldn't mind using to test my application. The one thing that was preventing me from using this tool so long (even though I have access to it) was that the test manager piece didn't support silver light 4 and our application was on that technology.
The latest update for Test Manager now has this support. So yes I am looking forward to using this to test.

Some pieces that I am really excited about

1. Manual test cases - video recording. Really if I can have a witness to all my testing I would not have to waste my time battling, answering, writing clearer notes, etc. I would have it all in my recordings.
2. Fast forwarding - I can fast forward my test cases. Super cool.
3. Lab Management - If I can get the same test environment that takes 6-8 weeks to build in hours, I would be testing so much more than fighting paper work to get the lab machines.
4. Use manual test cases to create automated test cases - really that just makes my life a lot easier. Automation and manual testing wont be in two different tool/technology. They will be based of each other.
5. Dashboard - Requirements, test cases, execution, defects - when everything is in the same system, my metrics would mean so much more real time. I wont have to massage my data to co relate the different elements together.

I will be playing with this tool for the next several months. I will add more information as I learn more. But this is one technology I am excited about.


For more information visit
http://www.teamsystemcafe.net/Resources.aspx
http://msdn.microsoft.com/en-us/events/bb944781.aspx

My Take - TCQAA Meeting - Cloud Computing

Paul Selway from redpath talked about cloud computing last night at the TCQAA meeting. Very technical but informative presentation. He started with a high level picture of what cloud computing is and narrowed his focus to Iaas (Infrastructure as a Service). He used some good analogy to explain the concept of cloud computing. He compared the growth and evolution of cloud services similar to generating and distributing electricity.
He explained the cloud in real easy day to day terms. He asked us to stay away from cloud washing (like brain washing). He gave us good pointers on when to start thinking about the cloud and when to absolutely stay away from it.


I also had a good discussion with Barry Dietrich on how cloud will tie in well with lean and agile. We also talked about how we can take it back to our work plays to see how best to jump into the cloud.

Bonus for members who are still thinking about attending these meetings: There were several recruiters there looking for Test Leads and testers. Also there were couple of company representative's who were looking for people. The test market is opening and if you are looking for a job feel free to attend TCQAA meetings.

My Take: Agile Comes to You (Minneapolis Seminar)

I was at the Agile Comes to You conference on Oct 19th 2010. It was a good place to learn about agile if you have not heard about it yet. A place to learn more if you are just learning about agile or are in the initial stages of implementing agile. Its also a good place for people who are already into agile and just want tips and tricks. The session was from 9 am to about 2:30 pm and included breakfast and lunch.

The keynote speaker David Hussman from DevJam was really good. His dude's law on value/how/why was simple thinking. He could as well call it common sense law or people's law and really it applies to IT or software development in general. You don't have to be agile to follow it. He focused on test driven development and talked about how agile and test driven development go hand in hand. His theory on simple-complicated-complex was really interesting. If you do get a chance to listen to him, please do so. You can find more about him at DevJam.

Michael Johnson from Make Music Inc spoke about how his company adopted agile successfully. He talked about how not everyone was into agile but once they saw the value it was easy to get them all to be as excited as others.

James Talbott from AccuRev talked about Agile Workflow Economic Management - his focus was on what is the outcome instead of the how or efficiency. His analogy using football was really good - end of the day its the score not the yardage that counts. So true.

Jeffrey Fredrick from AnthillPro talked about The Co-Evolution of Continuous Integration and Agile. His checklist manifesto was really interesting. He talked about having simple processes in complex environments. He talked about how people matter more than anything.

There were product demos in the end. It was nice to see some tools that support Agile: Rally, AccuRev and AnthillPro.

Cloud Computing 101

For weeks now I receive at least one email everyday mentioning cloud computing. I was curious but not motivated to find out more. Finally seeing a flurry of tweets I decided to look this up. I went into it thinking its a product that is being marketed hard and fast.

I was so wrong (ya a true duh moment) and not alone in the "I don't know what cloud computing is?".  VerizonOne survey IT professional in 2009 and revealed that 41% of senior IT professionals admitted they didn't know about cloud computing. I am sure this number has decreased since then. Compute world predicts this as one of the trends with the most promise in 2011.

What is cloud computing?
Cloud computing from what I understand is Internet based computing technology that uses Internet and remote servers for data and applications. Users (consumers and businesses) can use applications from any computer through the Internet on demand. This is the new buzz and is being forecast as the next big thing in the technology industry. Cloud gives the opportunity for collaboration without boundaries. Companies can increase capacity without investing a lot in infrastructure. More and more companies will jump into this bandwagon and will promote integration of services across borders. Services can be offered as software (SaaS - software as service), platform (PaaS - platform as service) or as infrastructure (IaaS - Infrastructure as a service).
 

Who is in the cloud?

Google
Microsoft
Hewlett Packard
IBM
Salesforce
Amazon

Why it works?

• User really does not have to know the technology behind the services
• Can be used by anyone over the Internet from anywhere
• Low cost when compared to owning the infrastructure in house
• Maintenance is easier since its not installed locally in each user's computer.

What are some concerns?

• Dependency on the Internet
• Loss of privacy (providers can monitor or control the services)
• Compliance to regulations (more expenses involved when trying to be compliant with regulations)
• Security when its being managed over the network or outside infrastructure

Where can I get more information?
Bird-watching in the cloud
What is cloud computing?
InfoWorld
IBM

(Please note this is based on what I learnt in the last few days out of curisoity. This is not everything about cloud ... just a short intro.)

IT Knowledge Exchange

A great site for getting answers to your technical and non- technical questions.
http://itknowledgeexchange.techtarget.com

You can ask questions or answer questions. Its for both learning and sharing knowledge.

Its Complicated!

Its complicated! Nope not the movie but everything else I guess.

I was talking to a lady at the bus stop this morning about how even simple things like the cell phone is now complicated. How some people over-complicate even the simplest processes and how we like to add arms and legs to something that probably is like a one cell organism or simpler.

Is it the curse of the new technology? Is it the expectations that people have from things? Does complexity add value?

Stanton Champion recently wrote We Really, Really Like Feature Bloat (UTest) where he talks about how we want the coolest features over simplicity. When a customer is out there looking to buy a computer, laptop, phone, Internet connection, cable TV, phone services, they really are looking for what all can they get for the money they pay. What are the coolest features out there, what is the latest model, will I get more if I spend a more.

Technology is getting outdated at a faster rate than it used to a decade or so ago. Couple of years ago when you buy a phone, computer or even take television, you would think of long term use of that product, something that lasted forever (well almost forever). But today its not about long term, its about what all is available (features, uses, how latest is the technology) and how fast or cool it is. People buy it with the notion of replacing it a few years or even months down the line.

Don Norman talks about this in his article on Simplicity is Highly Overrated. He talks about how people want more (complex) features for more money. If we look at this closer it does make a lot of sense. Customers pay more when they think they are getting more: more as in more features, complex features, latest technology, more settings, more applications, etc.

Or is complexity really a perception. Do some people really find latest technology to be less complicated than others? My 10 year old son knows more about my cell phone than I do. I go to him for help with settings or to learn about the new features and applications. So for one its real simple and to the other its real complicated. Who defines complexity? Does the 80-20 rule apply here? If 80% of people use a feature then that feature is simple. If less than 20% people use a feature does it mean its harder or more complex?

I think complexity can be attributed to perception to some extend. Once my son shows me how to use a feature in my phone and once I start using it I am more comfortable with it. My perception of how complex it used to be changes. Does familiarity breed simplicity?

Joel Spolsky on the other end talks about how simplicity actually complicates product development and creates ambiguity. People want simple but with everything else along with it. When designing a product we like to think we are making a simple and easy solution, then we add to it all the features that we think the customers want, then add everything that the competition has, then add something extra to make it cool or stand out. What do we have here? I don't think its simple for sure.

What does all this mean to software development and marketing? Well it means managing perception and adding value so we have happy customers. Happy customers make happy companies and happy employees.

Web-Based Applications - Emerging Trends and Challenges for Testing

With the rise of Internet, there is a rise of web applications. Applications that were previously installed in personal computers or specialized labs are now accessible through the Internet. With this emerging trend, testers also have to keep up with the changes and learn to adapt to work with the challenges of web application testing. The end result of testing for traditional application or web application may be similar (the application meets the requirements, has no critical bugs and meets the business and customer needs) but the means to get there may not be the same. The traditional testing methodologies have to be modified and adapted to the new technological demands.
Some reasons as to why web application are more challenging

1. More concurrent users than traditional client servers or standalone (load testing and performance comes into play)
2. Users spread all around the world (cannot test from every country or even states in US)
3. Users may have a different platform or environment that they are using to access the web application (may not be possible to test all the permutations and combinations)
4. More components and technologies are involved when developing these applications, third party tools, COTS or in house built from scratch tools (more things happening in the back end that are not always in control when testing these environments)
5. Less control over the test environment (its no long something that is installed on my computer where I can control most things happening in the environment)

What should testers do?

1. Keep up with technology, learn as much as they can about the technology that is being adopted for their applications be it third party tools or something that is built in house from scratch.
2. Be ready to adapt to the technology - traditional methods may not work as successfully and testers have to be open to work with technology.
3. Talk to developers about technology and try to understand the back end/UI/Network, etc as best as possible.
4. Focus on the weaknesses of web applications and try to capture issues in those areas as early as possible e.g. security, network, connectivity, firewalls, etc.

Steps for testing web applications

1. Understand the design - its important to understand all the components involved here like where is the application hosted, how is it connected, is it thin or thick client, are any of the components installed in the local machines, etc. Understanding how the components work with each other will also help with planning.
2. Test Planning - Document the plan well and involve developers, architects and security team so that the appropriate risks can be documented and discussed well in advance. Also planning for test environments that mirror production is important. Talk to customers if necessary to see if there are additional network firewalls or settings that you would need to work with during testing.
3. Testing - Test as close to how the customers would be using the system. Get customers involved if its possible or else plan for user acceptance testing. Define the level of testing ahead of time and get your team involved in this.

Testing web application is challenging and test leads have to be well prepared to face technology and its challenges.

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.

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.