Do Software companies deliberately ship products with bugs?

Almost all of the software companies ships their products with a known bug list. It is important to understand what forces these companies are forced to follow this practice on regular basis. Also most of the companies have their own defined criteria to determine which bugs they can defer and deliver with the product release. Some of the possible criteria can be:

1. Bugs which are low severity and low priority

2. Bugs that may not cause any business impact

3. Bugs which have some level of workaround possible

4. Bugs which are existing (since old release) in the product

5. Bugs which are not high Priority and requires high level of efforts to fix them

These are some of the reasons that may allow some of the bugs to be deferred for a release. For any organization it is very important to determine good enough testing. Testing is good enough (This is also referred as Test Stop Criteria) if:

1. Requirements are correct and each of them are covered with at least one test scenario

2. All required functional and non-functional test scenarios are identified and are executed

3. All logical paths and conditions are exercised

4. All failed requirements are revalidated with respective regression test

5. All Identified issues planned for fix are fixed and validated

It is important to think on how as a tester you can help, contribute and voice over these areas and help improve quality within your Team and line of business:

1. Determine appropriate test strategy that maximizes the probability of finding defect

2. Try to build a Bug Deferral Criteria with your LOB, BU or product suite teams that is agreed upon by all stakeholders

3. If a defect is logged then try your best that the defect is fixed. you may not be able to do alone yourself, so use mechanisms like status reports, escalation and proper communication involving your superiors

4. If a bug is marked as deferred analyze if the bug not severe and has possible workaround. If you suspect that this bug can raise concerns from customers or decreases competitiveness in the market then raise your voice and escalate immediately. I'm sure if the alarm is genuine then it will be heard out

5. Ensure that the possible workaround is published in appropriate customer facing documents e.g. release notes, user guides, online help etc

6. Identify the means on how you can minimize the number of backlog issues. You will certainly need support from your superior and management for this.

7. Become game changers and identify measures on how you can contribute your best.

How to reduce number of tests using test techniques

Many a times we are required to perform validation with a large number of test scenarios that will require significant time and effort to cover the complete coverage. Most of us face this challlenge on a day to day basis due to following reasons:
1. Large number of Permutation and Combination of tests
2. Lack of resource and time available for testing
3. History data is not available that will help identify prioritization of test 

To tackle this problem we may use test techniques that may help in reducing the number of tests and at the same time provide high level of coverage. This will ensure that we are using our resources effectively and optimally. one of the techniques that was used extensively in manufacturing domain and now used in software testing is Design Of Experiment (DOE).

DOE allows statistical analysis by experimenting behavior of different combinations of data. When you have large number of combinations then you can design your test data with Orthogonal Array (All Pair) techniques to reduce your number of tests. In this case instead of testing all n * n-1 combinations we create all possible pairs of data and test them.  Let's take an example:

Suppose you have following parameters to test:

O/S
Win 2008
Red Hat Linux
Mac

Browser
IE
Mozilla

Print size
A4
A5

In this case if you take all combinations then you will get a total of 3*2*2 = 12 combinations, with all pair technique you can get this validated in only 6 combinations:

TEST CASES
Case	O/S	Browser	Print
1	Win	IE	A4
2	Win	Mozilla	A5
3	Linux	IE	A5
4	Linux	Mozilla	A4
5	Mac	IE	A4
6	Mac	Mozilla	A5

As the number of test combinations increased you will see lot of difference between all nth combination test and all pair test.

There are tools also available but I have found tool provided by James Bach site as very effective and easy to use. There is a document inside the zip file that illustrates on how to execute the tool.

http://www.satisfice.com/tools.shtml

I would be more than happy to answer any related question on this.

Qualities you should evaluate while taking Interview for a tester position.

Interviewing is an art and it just like other arts comes by practice. While interviewing you are required to judge a candidate, based on only few questions, whether he/she is fit enough to work in your team and your organization. I'm outlining some of the important aspects that will help you in evaluating a candidate for testing role. These are not the only aspects you should consider rather you should observe a candidate based on your specific requirements for the open position: 

1. Plan the interview - Just like anything other activity you should plan your interview. You should go through the resume and understand different level of information e.g. Education, Type of exp, Type of project done, Domains candidate has worked, Knowledge of tools etc. Identify what are the key skills you need for specific role and position. Each position may require different level of skills and should be evaluated accordingly.
2. Type of questions - are very important and should depend on the candidates total experience. E.g. for the junior position you should ask objective questions (What is BVA?) and should expect objective answers. For senior positions in addition you should also ask subjective questions (like explain test plan and test strategy), this will help you understand the comprehensive knowledge of the candidate. Similarly you would like to ask different set of questions to a database tester, a functional tester and a performance tester. If you have doubts about the answer that is no harm in asking a counter or related question to check the depth of candidate skills.
3. Communication skills - This is one of the important aspect as the candidate will require to communicate a lot with different groups e.g. testers, developers, managers, customers etc. Candidate should have good written and speaking skills.
4. Faking the skills - Many a time you will observe a resume that mentions lot of tools and project around them. At a first look you will find the resume very impressive, but when you ask few questions you will realize that lot of information is not real and fake. You should spend first 5-10 minutes to understand if someone is faking the skill, if it is true there is no point in proceeding with interview.
5. Attention to Details - Try to judge candidate based on his attention during the interview. Observe how he/she is able to understand the questions in details and giving appropriate answers to the questions you have asked. If you have to explain same question multiple times then it may create trouble for you later.
6. Technical Skills - This is the most important aspect of the evaluation. You need someone in your team who has good technical skills on the specific areas you are looking. Evaluate candidate skills based on the requirement for your project. Also evaluate candidate skills for the specific role you are looking into. e.g. if you are looking for a security tester and he/she doesn't have a clue on buffer overflow or SQL injection then that may not be the worth.
7. Ability to learn new things - Identify the aptitude of candidates towards new aspects. If a candidate doesn't know the specific area you are planning to work, then evaluate if the candidate is curious, quick learner, shows interest in learning and exploring new things he/she doesn't know.
8. Knowledge of Test methodologies, techniques and approaches - If the candidate possess good knowledge on various test methods and techniques then he might prove effective when he/she is assigned tasks on the project. You may ask few questions to start with and see how effectively candidate defines test data for the problems or defines test approach for a particular case study.
9. Giving respect to the candidate - We should give respect to the candidate even if the candidate is rejected. If possible explain the kind of work and profile you are looking for. Also try to see if the person suits some other open requirements in your organization. A rejected candidate for security testing may be a prospective candidate for functional testing if he/she posses related skills.
10. Collation of feedback - Collate all the inputs you receive and make a call on where the candidate stands as per your expectations. You can prepare a skill assessment sheet where you have defined skills and rating against each of the skill area. This will help you make a go/no-go decision. Also based on your organizational setup try to analyze the candidate skills in respect to the organizational vision. Many a time technical teams pass the candidates but they are rejected in later stages of interviews for senior management and HR. You should also keep these things in mind. 

Myths and Facts about Software Testing...

Even though software testing is a complete software engineering role. There is lack of information available at acedamic level about software testing (at least in India). Due to this not many of the computer science graduates think about Software testing as a full fledged career and rather more attracted towards a programmer role. With this blog I'm trying to clear some of the myths that exists in people minds:

Myth 1 – Testers are non technical bunch of people who can test applications without using any technical skills

Fact – Testing is a Software Engineering job and Testers are software engineers who are equally qualified for any software engineering role

Myth 2 – Testing is a routine job and do not require techniques and thinking

Fact – Testing is a very challenging, innovative and creative skill that requires significant level of analytical thinking, system level thinking and lateral thinking

Myth 3 – Testing is a relative easy job and can be done very quickly as comparison to coding

Fact – Testing is equally (and more) tough and strategic as coding and also requires significant time in planning, designing and execution of tests

Myth 4 – There are not many and better career opportunities available in software testing field as compared to programming
Fact - Today testing is one of the best career available with career levels equals to any other software engineering role. Most of the organizations recognizes testing as a responsible and innovative role. 

I believe that being tester everyone should educate other people about these facts and make software testing as a respectful career choice.

Feel Pride in you and you being a TESTER...

Qualities a Tester must Strive for...

Software testing is a profession and like any profession that existed, software testing also requires tremendous level of abilities, skills and qualities. I'm trying to list some of the qualities that a Tester must strive for...

1. Passion for Quality – If you have this… then well…Rest will follow
2. Five Senses for Quality - Speak, See, Hear, Smell and Feel Quality  
3. Understand Technology – Learn & Earn Technological Advances 
4. Continuously Improve Technical Skills – Focused and Strategic learning 
5. Understand Product Domain - You can Break ONLY IF you know How It Works 
6. Think, Think and Think – Its all about thinking 
1. System Level Thinking 
2. Analytical Problem Solving  
3. Problem Decomposition Skills 
4. Lateral Thinking 
5. Survival mechanism – The fittest to survive 
6. Don’t restrict your thinking 
7. Think Smart, Do Smart, Be Smart – Curiosity and Improvisation 
8. Innovate with the ideas – Believe ‘Things can be better if done differently’ 
9. Be a Team player - Collaborate with others...Share and Learn
10. Be a Differentiator - Develop competencies and differentiate Outstanding work from Typical work
11. Be a Motivator - Motivate yourself and motivate others
12. Self Management and Discipline – ‘Don’t lose to your inner self’

How to Solve customer problems by identifying Critical to Quality (CTQ) approach.

Many a times we are faced with situations with problems being reports from customers. If we do not look into the problems quickly and handle them carefully then we may end up with unwanted escalations and loss of business opportunities.

To manage customer problems there are many frameworks available that helps understand the problem areas and then work towards correcting them. One of such technique is Voice of Customer (VOC) to Critical to Quality (CTQ) mapping techniques in Six Sigma. This is a very effective methodology to understand and solve customer problems very quickly and effectively. Some of the elements that we need to consider for this are listed below:

1. Identify Voice of Customer (VOC) - It is very important to understand the customer problems clearly. This may include carefully examine feedback provided by customer, talking directly to customers or getting details from customer issue base etc.
2. Service/Quality Affected - Once you identify the problem customer is reporting then try to map this to a specific Service/Quality Area. This will help in alignment of identifying team and other resources needed to resolve the problem.
3. Customer Expectations - Try to understand what exactly customer needs. If the need is understood correctly then you can target the corrective measures effectively.
4. Critical to Quality (CTQ) measurement - Identify the CTQ data measurement that will help you evaluate whether the exact problem is solved or not with the suggested corrective actions. This will also define benchmark for tracking and identification of improvement in future.
5. Action Items - This will help tracking of various action items that are identified while solving the problem. 

I'm giving an example for your easier understanding of this methodology:

Voice of Customer (VOC)	Service/Quality Area Affected	Customer Expectations	Critical To Quality (CTQ)
Customers complains that bills are either not provided to them or not delivered timely	Inconsistency of Billing cycle	Bill needs to be delivered consistently  and on time	Bill needs to be delivered on 10th of every month with a exception of +/- 1 day

Risk Based Regression Testing approach

One of the goals of Regression testing is 'To ensure defects in existing functionalities are not introduced while making changes or adding new features in a module'.


Regression testing is a strategic mechanism of selection of tests that needs to be exercised and performed in a release to uncover any defect which is introduced while fixing something or adding a new feature in the product or an application. One of the very effective and optimized mechanism to meet this goal is Risk Based Regression Testing approach.

Following are the steps to plan the approach:

1. First of all your need to organize your product into various modules and sub modules

2. Once the modularization is done then do Risk assessment for each module/sub-module from business perspective

3. Next step is to identify Impact on design and level of code changes done on each module/sub-module

4. You may also consider past Stability of each modules based on assessment from some of the metrics like ‘Total Issues reported against each Module’, ‘Severity of issues reported for each modules’ etc

5. Once you complete this assessment then you can identify easily the level of regression you need to perform.

Module	Sub-Module	Risk	Impact	Stability	Regression Needed
M1	S1M1	High	High	Fragile	Extensive
M1	S2M1	Medium	Medium	Stable	Medium
M2	S1M2	Low	Low	Stable	Low
M3	S1M3	Low	None	Stable	None

After each release you can review the data again and then you can redefine some of the parameters to make it more realistic and accurate for future references. This approach can help you define your regression strategy easily and ensure you focus exactly where you need to focus on impacted areas.

अक्स से एक मुलाकात...

आइना देखा तो... दूधला सा एक अक्स नज़र आया...
पेहेचानने की कोशिश मे... लम्बा समय बिताया...

कभी सोचा ये हे...कभी सोचा वोह हे...
कभी लगा हे कोई पहचाना...कभी लगा हे कोई अनजाना...
जुगत लगायी बड़ी... पर सम्जः कुछ न आया...
आइना देखा तो... दूधला सा एक अक्स नज़र आया...

इन्तेज़ार किया शायद कुछ बोलेगा...कुछ तो अपने बारे मे बताएगा...
कुछ सुराग मिला न मुझको... अधर से मै निकल न पाया...
एक छोटी सी उलझन ने मेरा.. रक्त चाप बढाया...
आइना देखा तो... दूधला सा एक अक्स नज़र आया...

कभी घबराया मै...कभी खुद को संभलवाया॥
सुलझेगी कभी गुत्थी ...धीरज दिया खुद को ये दिलासा दिलवाया॥
अपनी ही गलती को...अपना गर्व बनवाया...
आइना देखा तो... दूधला सा एक अक्स नज़र आया...

मेरी लाचारी देख कर अक्स ही.... खुद आइने से बाहर आया...
बोला इस भीड़ भाड़ भरी दुनिया मे...खुद को ही भूल गया तू...
क्या अब समजह मे आया?
आइना देखा तो... दूधला सा एक अक्स नज़र आया...

वक़्त के पीछा जाकर... अरसा पहले फिर से खुद से मुलाकात कर के आया॥
खुद को भीड़ मे भी... अंजना, अकेला और भागता हुआ पाया...
दिखावे मे दुनिया के...खुद को ही एक अक्स बनाया...
आइना देखा तो...खुद का चेहरा मुझको अक्स मे नज़र आया...
आइना देखा तो... दूधला सा एक अक्स नज़र आया...

Time to go back home..

Finally I will be heading back to my home place after much of travelling, work and spending time away from family (Will miss the thanksgiving weekend though). Hope to spend some good time at home and yes some good food. lol :)

Its a nice feeling going back to one's own nation...missing the winters in Delhi and Vishu!!!
Going back with 2 things in mind i.e. PMP cert and much awaited trip to Kerala ... Lets see.

I deserve a break..Isn't it? :)

क्या चाहता हे तू मन?

हर लम्हा हर छण
खुद से ये कैसी अन-बन।
अनजाने मौसम के ही जैसा
क्योँ पल मे बदलता हे ये मन.

कभी उम्मीदे जगाता
कभी तकलीफे देता।
एक अकेली कश्ती के जैसा
क्यौं होले होले बहता हे ये मन.

अँधेरे मे सहारा देता
रौशनी मे कही छुप्प जाता।
मोम की बत्ती जैसा
क्योँ जलता हे ये मन.

खुशियों मे दर्द को
दर्द मे खुशियों को
और दूरियों मे नजदीकियों को।
कैसे महसूस कर लेता हे ये मन.

कभी सी++, कभी सी#
कभी बीओ सीओ, कभी एअस्पी जावा,
नयी नयी टेक्नोलॉजी के जैसा
कैसे खुद को कॉन्फिगर करता हे ये मन.

कभी सुलझ जाना
कभी उलझ जाना
क्या कभी तुझे समज पाउँगा
क्या चाहता हे तू मन?
क्या चाहता हे तू मन?