Tuesday, January 31, 2012

Exhaustive Testing


Exhaustive Testing as the name suggests ‘Performed comprehensively and completely’ and remember that 100 % Testing is not possible, you may have a greater confidence on your application but 100 % Tested Application can only be found in Pluto; just take it for the understanding don’t get into it.

Let’s come to the actual point. Assume you are testing an application that has a Textbox (accepts min 1 and max of 26 chars length) that accepts characters from a-z, if the user is a novice tester then it will first enters a, b … z individually then will group them as aa, ab, … az, then will increase the order and combinations and then finally come up at the point where he has to enter all characters as abcde…z in that Textbox. This kind of testing is exhaustive testing which is extremely undesirable.

The solution for the Exhaustive testing appears to be resolved by boundary values as follows:

If I am going to test that Textbox in my application I will create following test cases to get the same degree confidence that required by Exhaustive Testing.

1. Enter nothing (leave the textbox blank) application remains intact error/warning is displayed depending on requirement.
2. Enter a or any other SINGLE character only
3. Enter ab or any other TWO character only
4. Enter abc..y or any combination of 25 characters only
5. Enter abc…z or any combination of 26 characters only
6. Enter abc…za or any combination of 27 characters only, error/warning is displayed depending on requirement.

I anticipate, the idea is a bit clear about Exhaustive Testing by considering above two examples and it is very obvious which way is more effective and efficient.

Let’s look at the scientific part of the Exhaustive Testing. You know that English alphabets composed of 26 letters and the Textbox above is also a maximum of 26 length, therefore there are “6.1561195802071573107966742884002 e+36” that many combination that you have to test for that single Textbox which is impossible. If you are thinking to automate this textbox then you are fooling yourself, the amount of logic required to test this textbox will also be cumbersome. Once you try to find the solution for this then you will say test case 1 to test case 6 is the better solution.




Monday, January 30, 2012

Test Strategy versus Test Plans


Test Strategy is part of the Test Plans. Test Plans describes who will do what? Describes roles and responsibilities of test team, resources required any risks associated, major functions to be tested. Test Strategy is a very important part of the test plan. When requirements analysis phase is finished and requirements are somewhat mature then testing team starts preparing test plans, how to carry on testing and what strategy to be followed.

In very simple precise terms there are two basic testing strategies:

 To test the software in its entirety, once the completed package is available; otherwise know as “big bang testing”
 To test the software piecemeal, in modules, as they are completed (unit test); then to test groups of tested modules integrated with newly completed modules (integration tests). This process continues until all the package modules have been tested. Once this phase is completed, the entire package is tested as a whole (system test). This testing strategy is usually termed “Incremental Testing”

Incremental Testing is further divided into two classes Bottom-up Testing Strategy and Top-Down Testing Strategy.


What is Test Scenario?


Test Scenario

Test Scenarios, as it little obvious with its phrase. Scenario is something which is meaningful. Let’s take an example of routine life – as in submitting a utility bill in queuing in front of the local bank or via your cell phones. Doing that scenario you have to meet some conditions (i.e. by date available for the bill) and some valid documents (utility bill). Available Date and Utility bill itself meaningless in someway until it is submitted/cleared. Therefore, all the steps you will take to submit your utility bill will become a SCENARIO. Thinking all these steps in computer software context is a Test Scenario if an automated systems is put into place in the bank and you are testing the utility bill scenario in that software application.

Technically, test scenario is group of test cases to achieve/complete desired goal (objective) with the software application.

Let’s take the other example step-wise.

How do you check your emails? Checking emails is Test Scenario… How?

1. Launch browser or tab
2. Enter mail.google.com
3. Provide user-id password
4. Press Login

Step 1 to 4 as a whole represent a Test Scenario, if you successfully managed to see your emails the Test Scenario is passed otherwise it will be considered as failed

Formally, “steps required to complete a meaningful activity is a test scenario”

In the above example steps 1 to 4 are individual test cases in order to test individual steps.

Test Scenarios are the cornerstone of Scenario Based testing.



Saturday, January 28, 2012

Are You/We Confucius At Work?


Confucius at work

Confucius, the Chinese philosopher (551-479 BC), is widely quoted for his succinct counsel. On the occasion of Chinese New Year which has began a few days back, and coincides with the post-appraisal period for most companies, lets take heed of his words to shape the coming year at work.

Confucius advice, “Real knowledge is to know the extent of one’s ignorance,” is particularly relevant in this context. It suggests that we ought to be aware of how much we know. And, more importantly, how much we don’t know, which is to say that we ought to be aware of the limitations of our knowledge.

In the terms of what Confucius advises, the acquisition of knowledge is to widen one’s own perspective in order to see a broader truth. As they say, the more you know, the more you realize how much you don’t know. In the word of Albert Einstein, “As the circle of light increases so does its circumference of darkness.

To have knowledge enables one to be acutely aware of oneself and the world around us, to the extent of recognizing how far you can go (for instance) to the edge of a cliff without being ignorant to the possibility of falling over. Another quote by Confucius that shed more light to be one above is, “He that would perfect his work must first sharpen his tools”

Steven Covey calls it ‘Sharpening the Saw’, the habit of self-renewal. It suggests examining the extent of your knowledge; a blunt saw is far less efficient. It calls for planning and preparation and constantly revisiting what you know in order to add to it, because the minute we decide that we are an expert in any field, we stop being innovative and seeking new ways of doing things.

Questioning what we know and what we don’t know is the principle and the process that empowers us to move in an upward spiral of growth, change and continuous improvement.







Saturday, January 21, 2012

How To Help Employees Dealing With Winter Blues?


While many of us go into a sort of ‘natural hibernation mode’ in winter and grumble and complain as the days turn shorter, a lot of people suffer from a condition called Seasonal Affective Disorder -  SAD, popularly know as the ‘Winter Blues’

People suffering from SAD typically feel lethargic, depressed and withdrawn. They sleep more, eat more and crave carbohydrates and sweets. They also become irritable and impatient, have trouble thinking clearly and quickly, and tend to make more mistakes. Usually, symptoms cease after winter is over; for people suffering from severe cases of SAD, light therapy and counseling are advised.

Research indicates that SAD is caused by inadequate light during winter, which creates an imbalance in brain chemistry. In his book, Winter Blues: Everything You Need To Know To Beat Seasonal Disorder, Norman E. Rosenthal states that even people living in cities that are sunny during the winter suffer from Seasonal Affective Disorder. He attributes this due to decreased exposure to direct sunlight. Additionally, some researchers and psychologist point out that December is also a nostalgic month for many people, and as a result, they are prone to being depressed.

There are a number of initiatives that employers can implement to help arm employees against Seasonal Affective Disorder:

ü      Position Desks near windows or install sufficient lighting.
ü      Encourage employees to exercise daily and eat healthy
ü      Organize Lunch ‘n’ Learn seminars or provide written information on how better to deal with Seasonal Affective Disorder
ü      Provide counseling services.

Perhaps the last word about SAD goes to Stephan Covey, who in The 7 Habits of Highly Effective People writes that proactive people carry their weather with them. He suggest that people should concentrate on the things they have control over and can change, rather than being counterproductive and wasting energy complaining about the Cold and Dark.



Monday, January 16, 2012

Software Testing Briefly Re-visited...


This post at the Software Quality Geeks is 3rd of a series of how to be Software Quality Professional. This post will talk about the basics of software testing. This is one of the core areas of Software Quality and also stands for one of the major responsibility of the Software Quality Professionals as we discussed in the “Does Your Organization Have A Well Defined Software Quality Process?”

Software Testing

Software Testing can be very simply defined as “the process of executing/running the software application in order to find visible and/or hidden defects (non-conformance to requirements)”. The defects are not only non-conformance to requirement this can be unusual behavior of controls of the application which is not usually and explicitly elaborated by clients.

“Good testers are masters at noticing ‘something funny’ and acting on it.”  
-Brian Marick

Practical implication of the Brian Marick can be felt when you trying to scroll down from the keyboard on Microsoft Word file and MS Word does not allow you to scroll down via keyboard navigation keys and suddenly moves up where you have dragged the scroll bar from.

Software Testing can be performed in either of the following two ways depending upon the Software Development Life Cycle chosen for the software being developed.

Conventional: In conventional ways testing is started after the coding is finished.

Unconventional: In unconventional ways testing is ongoing process and started from the initial phase. This is widely accepted as compared to conventional testing because it helps identifying defects as early as possible.

In order to achieve a great level of confidence on the software application great effort required to put on the application. But this is not the case in today’s world of software development. Effective and efficient use of software testing can help achieve a required confidence. In order to achieve a greater confidence on software application any organization can use mixed combination of testing techniques provided by Black-Box testing and White-Box testing.

Black-Box (Functional) Software Testing

Identifies bugs only according to software malfunctioning as they are revealed in its erroneous outputs. In cases that the outputs are found to be correct, black box testing disregards the internal path of calculations and process performed. This is also known as the Functional or Functionality testing.

White-Box (Structural) Software Testing

White box testing strategy deals with the internal logic and structure of the code. White box testing is also called as glass, structural, open box or clear box testing. The tests written based on the white box testing strategy incorporate coverage of the code written, branches, paths, statements and internal logic of the code etc.

The following table illustrates the testing techniques belong to what specific type of testing whether Black-Box or White-Box.
  

The above are the most common testing techniques most widely acceptable and can be adapted for most of the software projects undergoing in any organization. There can be hundreds of software testing techniques that can be elaborated by different prominent software quality geeks around the globe. Each of the above testing techniques will be discussed in the coming post at Software Quality Geeks. 


Wednesday, January 11, 2012

Does Your Organization Have Well Defined and Strong Quality Assurance Process?


What motivates an organization to have an independent Software Quality Assurance department/process?

What value Software Quality Assurance process brings to an organization?


The answer of above two questions and many such questions lies here

  • Malaysia Air Jetliner, August 2005
Flight between Perth, Australia and Kuala Lumpur, Malaysia zoomed 3000 feet upwards. A defective software program had provided incorrect data about the aircraft’s speed and acceleration, confusing the flight computers.

  • NASA Mars Polar Lander, 1999
On 3rd December 1999 MARS Polar Lander disappeared during its landing attempt. Failure Review Board concludes the likely failure reason was unexpected setting of single data bit.

  • The Lion King Animated Storybook
Disney’s first multimedia CD-ROM game for kids, released in Christmas season.26th December was the nightmare for the customer support. The CD was tested only for specific PC platform. It failed on many popular PC and operating systems.

Organizations are becoming more quality conscious as the customer is getting aware of the technologies, its pros and cons, the risk involved in it etc. When it comes to meeting and/or exceeding the customer’s expectations in Software Development Industry the need of well defined and well matured Software Quality Assurance process arise.

Quality

Quality is defined by American Heritage Dictionary very precisely and comprehensively it says “Quality is the characteristics or attribute of something”

The following equation summarizes the quality that can best be fit in to the software development industry.

User Satisfaction = Compliant product + good quality
    + Delivery within budget and schedule

             “People forget how fast you did a job—but they always remember how well you did it.”
                                                                                      -Howard Newton.


There exist many software quality standards (see software quality standard in upcoming posts) and procedure around the globe to conduct business by meeting or exceeding the customer’s expectations. The block diagram below generalizes the Software Quality Assurance process that comprises two major activities:
         
  • Formal Technical Reviews (aka. FTRs)
  • Software Application Testing
Software Quality Assurance Process

Formal Technical Review

A formal technical review is a quality control activity performed by dominantly Software Quality Assurance Engineers (SQAEs) and/or Software Engineers themselves in rare cases. The primary purpose of this activity is walkthroughs, inspections, round-robin reviews and other small group technical assessments of software.

The most common and widely used activity is inspection; in which SQA Engineer execute the checklist on the document produced in the Requirement Gathering (i.e. FS, SRS and CRF) and Design (i.e. ERD, Class Diagram and DFD) phase. There are many objectives of and FTR or inspection:

  1. To uncover errors what customer actually wanted and what is described by the business analyst (BA) in the document (e.g. functional specification –FS)
  2. To verify that software under review and/or development will meet its requirement.
  3. To make projects more manageable.

Software Application Testing

“Like death and taxes, testing is both unpleasant and inevitable.”
                                                                               –Ed Yourdon

This is the very important and critical activity in the software quality assurance process that guarantees the software application quality mainly. This phase usually takes the output of formal technical reviews activities (i.e. inspected FS, SRS or CRF) and makes use of it in the following core activities; that includes:

  1. Test case writing
  2. Test data preparation (done usually for large, complex and critical applications)
  3. Test environment setup
  4. Test case execution
  5. Defect summary report

You will be the happiest and luckiest person on this earth if you do not have to compile defect summary report for the application being tested or have been tested.


What Requires To Be A Software Quality Professional?



Software Quality professionals are highly in demand worldwide. Therefore, organizations are developing separate department for Quality Assurance and ensuring the independence of that department in order to provide great values and quality products to their clientele.

To be a successful and competent Software Quality Professional one must exhibit and have some or all of the following skills and capabilities.
                   

  1. Good understanding of software quality process and concepts
  2. Good understanding of software testing concepts and their application.
  3. Reasonable Understanding of Quality Improvement standards like CMMI and ISO series.
  4. Good communication skills
  5. Good hands on databases, RDBMS concepts and above all at least know how to write queries in SQL.
  6. Reasonable knowledge of UML of any version
  7. Good Intelligence Quotient – IQ, greater the IQ then greater the chances of grabbing any position and job in this world.

The above skills are blueprints to be a successful and competent Software Quality Professional, there could be more than that. The order is kept with respect to the importance that organizations give to their prospects employees, but this is not the case in general, great organizations give value to the persons have high IQ; that in some way suggests that the person is a Quick Learner which is considered as a triumph card for the organization during talent hunting. Organization prefers Quick Learner because he/she can adjust and mold himself/herself according to organization needs and can perform various flavors of tasks which help in both learning and career growth.

IQ can be increased by reading and listening to people have experience and have spent most of their lives no matter whether they went to high school or some sort of universities.


Intelligence Quotient = (Person’s Mental Age / Person’s Age) X 100

Let’s assume a sixty year old man writes his Autobiography and twenty years old high school fellow reads that biography than we can roughly estimate the guy’s intelligence quotient by the formula appeared earlier which will result in 300.

More accurate IQ is more complex to calculate and there exist so many other parameters to take care of that.

Skim around Software Quality Geeks blog to find out more on the above skills which will give an insight into ‘How to be a successful Software Quality Professional?”. The blog will later provide some mock interviews questions in forthcoming posts.
All the skills require to be a Software Quality professional that will be posted in future to Software Quality Geeks will be marked with the same number exist above.

Good luck!!!