SEVERITY AND PRIORITY

"SEVERITY "         AND          "PRIORITY"

SEVERITY: The impact that a given defect has on the

              system.

PRIORITY: It is defined as how fast a defect should 

              be resolved.

SEVERITY CAN BE OF FOLLOWING TYPES:

Critical: 

The defects which results in the termination of the system and if there is no other way to get the expected results then the severity is taken as critical.

Major: 

The defects which results in the termination of the system but we have an alternative way to get the excepted results, then the severity is stated as major.

Moderate: 

The defect which does not cause the termination of the system but gives the wrong data then the severity is taken as moderate.

Minor: 

The defect which does not cause the termination of the system and we can obtain the required results by just working on the defects such type of severity is stated as minor.

PRIORITY CAN BE OF FOLLOWING TYPES:

High: 

The defects which should be fixed immediately and if the application cannot be further used until we fix it then they are given as high priority.

Medium: 

The defects which can be rectified later in the program.

Low: 

The defects which have less impact then it is taken under low priority.

DIFFERENT SCENARIOS OF SEVERITY AND PRIORITY 

High Priority & High Severity: 

For example if we want to login into an bank application but if it shows an error then we can't move further, since it should be fixed immediately then it is taken as an high priority.

High Priority & Low Severity:

For example if we login into an bank application but the spelling of the bank is misspelled then it does not affect the functionality but it spoils the reputation of the bank.So the priority of fixing it will be high and the severity will be low.

High Severity & Low Priority: 

The scenario in which clicking a certain link in the application and it gets terminated because that link is rarely used by the user, here priority will be less. Clicking that link affects the functionality of the system so the severity will be high.

Low Priority and Low Severity:

It is the scenario in which if there are any spelling mistakes in the text of a paragraph in an application which is rarely read by the users .In this case both severity and priority will be low.


Post by :- Susmitha

Myths of Software Testing

What is a Myth?

Myth is a traditional story concerning the early history of explaining natural or social phenomenon or people.

 Myth 1:

Testing is too expensive:-

Testing is very expensive; it is a myth, whereas the fact is, during software development the cost for testing is less when compared to cost incurred due to maintenance or correction later. Since it is known that early testing in many aspects saves both cost and time. However, cost reduced without testing may lead to improper design of software application and a useless product may be the outcome.

 Myth 2:

Testing is time consuming:-

Testing consumes lot of time, it is a myth, whereas the fact is, during SDLC of testing are never a time consuming process, however fixing the error which are identified during proper testing, consumes more time but it is a productive activity.

Myth 3 :-
Testing starts only after the product is fully developed:-

Testing is started only after the product is fully developed, it is a myth, whereas the fact is, though testing depends on the source code, the reviewing and developing of test cases is independent from development of code. Incremental and Iterative models are examples for reducing dependency of testing on fully developed software.

 Myth 4:-

 Complete Testing is Possible

Exhaustive testing is possible, it is a myth, whereas the fact is, there is possibility of testing all paths by the team but occurrence of exhaustive testing is not possible. During software development life cycle there might be some scenarios that are never executed by test team or the client and may be executed once the project has been deployed.

 Myth 5: -

If software is tested, then it should be bug free:-

If Software is tested, then it must be free from bug, it is a myth, whereas the fact is that even a tester with excellent testing skills has tested the application, there is no one to say with absolute certainty that software application is 100% bug free. It is a common myth which most project managers, clients and management team believe in.

 Hence to become a good tester, he should have a good idea on myths, and how can that be helpful in testing the product successfully, as “quality” is that which matters at the end of the day.

Post by :- Geetanjali 

Debugging Vs Testing

                                         

In previous age of software life cycle, people think that testing is equal to the debugging but it is wrong assumption. Testing is different from Debugging. Before 1979 testing and Debugging are similar in actions, but after 1979 the exact differentiation has started between them. The process of locating a problem and removing that problem is called Debugging.

Testing--> Testing is defined as process of finding bugs.

Debugging -->Debugging is after the bug is found, correction of that bug is called as debugging.

Debugging-->Debugging is a systematic process. Using debugging we can identify the logical errors and syntactical errors in an application.

Testing-->Testing is a abnormal process.

Debugging-->Debugging activity is done by developers.

Testing -->Testing activity is done by testing team .

Testing team run their tests on the piece of software. If they are finding any bugs in that they report it to the development team. After getting the test report from the testers , developers tries to find that bug. After finding the bug they tries to modify the portion of code and then he re-checks if the bug is fixed or not. After fixing the bug ,developers send it to the testers.

Post by :- Madhavi

Life is All About Choices ....!!!!

  

“Destiny is no matter of chance. It is a matter of choice. It is not a thing to be waited for; it is a thing to be achieved.”           

                                                                                         - "William Jennings Bryan."

Life is all about making a right choice and a right decision at suitable Situation.

One has to move ahead based on the choice he opted. Wherever he goes, Choice is left behind him, which indeed makes the person a successful.

The complete universe is running on these two Boolean values. "Right or wrong", "True or False", "Yes.or .No"  "If... Else"...etc.

Testing is what which makes the choice clear to the End User. In the sense

"The software is working in Right or wrong way”.

Let me explain this with an example.

Consider, a person who goes to a bike showroom, he sees different bikes with large variety of models.

In spite of that, he finally ends up in making a choice between two bikes, "Pulsar" Or “Discover"

There can be many factors involved, in taking the right decision?

Condition: - # which one is good? Pulsar or Discover?

Cases:-

 a) Mileage:-

        

                 If (mileage >45km h) then

                             Take "Pulsar"

                Else

                             Take "discover"

b) Comfort:-

                  If (Comfort = Awesome)   

                               Take "Pulsar"

                  Else

                              Take "discover"  

c) Engine :-       

                    if ( Engine = 150cc DTSI) then

                          take “Pulsar"

                    Else

                           Take “Discover"

d) Cost or Budget:-       

                  if ( Cost <Rs.60,000)

                         Take "Discover"

                   Else

                               Take "Pulsar"

e) Speed or H.P:-            

             If (Speed > 80km h)

                      Take "Pulsar"   

            Else

                     Take "Discover"

The Choice mainly depends on the requirements of a person and his ability to afford.

Based on the above factors, a person can make his choice better.

Testing indeed is nothing but making up the right choice or else we can say that

Right decision whether the product that is to be delivered is functioning properly or not? ,

Is this the right time to deliver the product or not. ?  What so ever the choice that is taken, "Satisfaction" is what it matters at the end of the day.

One has to take the deliverable steps in order make his choice better and indeed a
“Successful Tester “(referring to the context).

“Make the right Choice to be a Successful Person

Make the right decision to be a Successful Tester for the better way ahead! “ 

 CHEERS!!!

Post by :- Pardha Saradhi . Boddupalli

Why Integration testing is Vital for software components?

Hi Sprinters….!! Have you ever thought, why integration testing of software components is needed, even though those components are tested individually as part of Unit testing?

Following are the reasons behind the need of integration testing:

• A Module in general is designed by an individual software developer whose understanding and programming logic may differ from other programmers. Integration testing becomes necessary to verify the software modules work in unity.
  
  
• At the time of module development, there are wide chances of change in requirements by the clients. These new requirements may not be unit tested and hence integration testing becomes necessary.
  
  
• Interfaces of the software modules with the database could be erroneous.

Now let’s take a look at the different approaches in performing integration testing.

Integration testing can be mainly classified into four categories:

1. Top-down approach
2. Bottom up approach 
3. Sandwich approach
4. Big-bang approach

Let’s discuss about each type.

1. Top-down approach: In this type of approach, top integrated modules are tested first and the branches of the modules are tested step by step until the end of the related module.

      But what should we do when come across a situation where sub 

                  modules are still under construction??? Need to stop the testing,

                  until those are fully implemented?? Not at all required..!!

In this type of scenario, we will use dummy sub-modules, which can be referred as “Stub”, to go ahead with our testing.

2. Bottom-up approach: In this type of approach, lowest level 
   components are tested first, and then used to facilitate the 
   testing of higher level components. The process is repeated 
   until the component at the top of the hierarchy is tested.

But similar to the hurdle just we faced in top-down approach, what should we do when come across a situation where main modules are still under construction??? Need to stop the testing, until those are fully implemented?? No…!!

In this type of scenario, we will use dummy main-module, which can be referred as “driver”, to proceed with our testing.

3. Sand-wich testing: It is the combination of top-down & bottom-up approaches where both the testing techniques are started simultaneously and meet somewhere in the middle. Suitable for large programs such as operating systems.

4. Big-bang testing: It is a bit different from the above three approaches, in which software elements, hardware elements, are combined all at once into overall system, rather than stages.

So friends..!! This is the technical story behind the integration testing.

Hey…do you know the other names for Integration testing!!? 

This can be also called as “String Testing” and sometimes 

”Thread Testing”.

Post By:- Deepthi

Test Case on a Bottle

I have a bottle,  

if I fill it with water then it is call as water bottle

if I fill it with milk then it is call as milk bottle

and constituency theory written was Aristotle

finally now I am going write test cases on this bottle

Test Cases on Water Bottle

***************************

1.Check the dimension of the bottle.

        2.See if the cap fits well with the bottle.

3.Test if the mouth of the bottle is not too small to pour water.

        4.Fill the bottle with water and keep it on a smooth dry surface.

        Watch for any leaks if any.

5.Fill the bottle with water, seal it with the cap and see if water leaks

when the bottle is tilted.

        6.Take water in the bottle and keep it in the refrigerator for cooling  
        normal temp.

        See what happens.

        7.Keep a filled-water bottle in the freezer for a very long time .
         See what happens to the water and/or bottle.

8.Keep a filled-water bottle under freezing condition. See if the bottle expands or breaks.

9.Try to heat (boil!) water by keeping the bottle in a microwave oven

10.Pour some hot boiling water into the bottle and see what happens

        11.Keep a dry bottle for a very long time. See what happens. See if
        any physical or chemical deformation occurs to the bottle.

        12.Test the water after keeping it in the bottle and see if there is

        any chemical change.

        13.Keep water in the bottle for sometime. And see if the smell of      
        waterchanges.

14.Try using the bottle with different types of water

15.Try to drink water directly from the bottle and see if it is

comfortable to use.

        16.Test if the bottle is designed and if it is comfortable to hold. Also
         see if the center of gravity of the bottle and it does not topple     
         down easily.

        17.Drop the bottle from a reasonable height and see if it breaks.If it
        is a glass bottle then in most cases it may break. See if it breaks into  small pieces or breaks into nice large pieces.

18.Test the bottle with empty bottles and bottles filled with water.

19.Test if the bottle is made up of material, which is recyclable. In

case of plastic made bottle test if it is easily crushable.

20.Test the bottle can also be used to hold other common household

things like honey, fruit juice, fuel, paint.

Post by :- Srikanth 

WHY TESTING IS NECESSARY BEFORE DEPLOYMENT

Deploying a software without testing is equal to riding a bicycle without brakes

Example :

If a person is riding a bicycle with maximum speed suddenly he saw a big tree in front of him then he applied the brakes but brakes are not working then what’s the condition of the person

In the same way a company developed a software according to client’s requirement in a company’s environment I do not know whether software is working as client’s need but I know software works.

Now company deployed a software to the client after reaching the software to the client. Now Client started using it in hospital. but because of change in environment my software works in different way .

Now software should work like this :

Software should stop working for every 20 seconds and after 10 seconds again software should start working but because of change of some code and change in the environment software is not getting stopped for every 20 seconds its working continuously

Software is working like this :

If the patient is sent to a automatic machine for a treatment to cure some disease at that time machine is using the software which our company was developed and it was the first time the doctor is using our software in his hospital then what’s the situation of the person who went inside the machine is ?

Example :

So deploying software without doing testing some time causes to death. And the bicycle incident shows without testing starting the work some time gives us a bad result so start testing when something is going to do

Developing software may takes only some years but testing that developed software can take impractical amount of time

Post by :-  Hariteja .

“Convivial way to understand software testing”

Who is Software tester…..???

Officially a person who conducts prescribed tests on software programs and applications prior to their implementation to ensure quality, design integrity and proper functionality. They apply rigorous testing methods including extensive end-user simulations to uncover program "bugs" which are then eliminated by the software programmers.”

But how people other than testers understand it??

A person who always criticise the work done and always brings a bad news and to do so officially is called software test engineer.

Tester’s perspective!!!

A glass is half filled then

To an optimist, the glass is half full.

To a pessimist, the glass is half empty.

To a good tester, the glass is twice as big as it needs to be.

Who drives a testing process???

“A drunken driver is very dangerous. So is a drunken backseat driver, if he’s persuasive!
'Dude, make a left.'
'But those are trees…!'
'Trust me...'“

Essential operational decisions are made by someone else (project manager, product owner, whatever you call him). But if we are not the drivers, our position is certainly close to this of a backseat driver, we have our maps, good knowledge of the area and our experience, and we give advice that is used to take real decisions. So don’t be a drunken backseat driver, its dangerous! If you are inebriated by an obsessive desire to fix a bug, or by any thing else you’ll be taking your company directly into the trees. And, as with any drunk person… Whenever your judgment isn’t objective… At least recognize that you may be drunk! Will make it easier for everyone else.

Where to find a bug?

Under a streetlight, on a very dark night, a software tester was looking for a set of lost keys.A policeman came by, asked him about the object of his search, and joined him to help. After the two had searched for some time, the policeman asked,

“Are you sure you lost them here?”

“Oh, no,” said the software tester. “I lost the keys somewhere else.”

“Then why are you looking for them over here?” the policeman asked.

“Because this is where the light is!” the software tester replied.

Moral: Do not be so stupid that you search for bugs only at the obvious places.

What is software testing intended to?

To deduct number of bugs possible and build confidence on the product….but testers tends to loose confidence if they don’t find bugs in the project…!!!

Suggested easier way ……..but understood as a wrong way !!!

A group of managers were given the assignment of measuring the height of a flagpole. So they go out to the flagpole with ladders and tape measures and they’re struggling to get the correct measurement dropping the tape measures and falling off the ladders.

A tester comes along and sees what they’re trying to do, walks over, pulls down the flagpole, lays it flat, measures it from end to end, gives the measurement to one of the managers and walks away. After the tester is gone, one manager turns to another and laughs,

“Isn’t that just like a tester?

We’re looking for the height and he gives us the length.”

Will certification make you an expert!!!

“I used to play sports... Then I realized you can buy trophies. Now I'm good at everything!“

A plaque, a crown, a card, a trophy… They prove you’ve mastered a skill. Trophies are nice and great, but only if they are accompanied by skills and real world practice. Trophies that can be attained without these traits are just empty cups.

One should beware when dealing with “achievement symbols”. At times, acquiring the symbol does not mean acquiring the achievement or skill too!

For example, just as buying the trophy doesn’t make you good at sports,

Similarly getting a testing certification won’t make a tester good at testing… The certifications syllabi try to teach only specific lexicon and terms definition, but not the real practice of testing, because they don’t/can’t cover the interactions between persons and players.
For some people, the joke could be read as “I used to practice and study... Then I realized you can pass a certification. Now I can prove mastership - without the effort of gaining it!” Be sure to be from the ones who keep learning and carrying the skill.

Understand how much to test….!!

In a car manufacturing company a person with no formal experience was appointed as an observer on the production line. His work was to check whether the painted doors have an even coat on it. The next day there is a knock at the Personnel Manager’s door. The Foreman throws open the door and begins to rant about the new employee. He complains that he is incredibly slow and the whole line is delayed, putting the entire production line behind schedule.

The Personnel Manager decides he should see this for himself, so the two men march down to the factory floor. When they get there the line is so backed up that there are doors all piling up. At the end of the line stands a nervous new employee.

The personnel manager observed the he was examining each door inch by inch by slowly gliding the tool all over the door…..

Summary:

A software test engineer must have a clear idea about what is testing, the role of a tester, the need/purpose of the testing, how to test and how much to test, what to test and where to test.

“The business of the company depends on the quality of their product….and for the quality the company depends on the TESTER”….so be proud to be a tester.

Post by :- Surya Prakash Goske

Published By :- Pardha Saradhi

-