Weightage for Foundation level ISTQB Exam

Hi folks,
The information below will surely help you guys to clear the ISTQB foundation level Exam.

The most important aspect of preparation is knowing the weightage for different chapters involved.

Here is goes :-

1. Fundamentals of testing -                                                   7 Questions

2.Testing through out the life cycle-                                       6 Questions

3.Static analysis-                                                                   3 Questions 

4.Dynamic test design techniques-                                         12 Questions

  

5.Test Management -                                                            8 Questions

6.Tools for test design                                                           4 Questions

Concentrate on chapters 4,5,and 1 to get a  good score.

Hope this information could  be helpful  to get ISTQB Certified 

All the Best Team Testers. 

Regards

Vijaya Lakshmi

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 .

Tester & Developer

  Relationship between developers and testers in software world.


Developer:
                  software developers are the people who prepare the software that can perform some operations or to run some applications or products.

Tester:
                  software testers function is to test the developed software whether  is it working  as per the user requirement or not


History of testing:

               During 1960 testing had done in ad hoc manner.Adhoc testing is nothing but developers tested their codes on their own.After few days this could be changed as developers done testing by exchanging their codes during 1970 "Glenford Myers"  done some research about  different techniques they could be useful for testing and wrote the “science of quality assurance  and control”.

     A misunderstanding of what the testers’ job is creates constant conflict at the place of employment. Many developers do not realize how difficult system testing can be. It takes patience and flexibility. It requires an eye for detail   and an understanding of the big picture. Many testers are frustrated working with developers who think testing is easy. At the same time, I have not yet met one tester who was not fascinated with code writing work. Hence , do the testing with passion , be attracted to whatever work  you do , then one can surely enjoy the wealth behind it .

Post by :- Sravani 

Test Case in Software Testing .

WHAT IS TEST CASE?

“A test case has components that describes an input, action or event and an expected response, to determine if a feature of an application is working correctly.”

A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly.

Why do we write test cases?

The basic objective of writing test cases is to validate the testing coverage of the application. If you are working in any CMMi company then you will strictly follow test cases standards. So writing test cases brings some sort of standardization and minimizes the ad-hoc approach in testing.

Writing effective test cases is a skill and that can be achieved by some experience and in-depth study of the application on which test cases are being written.

There are levels in which each test case will fall in order to avoid duplication efforts. 
Level 1:In this level you will write the basic test cases from the available specification and user documentation.

Level 2:This is the practical stage in which writing test cases depend on actual functional and system flow of the application.

Level 3:This is the stage in which you will group some test cases and write a test procedure. Test procedure is nothing but a group of small test cases maximum of 10.

Level 4:Automation of the project.This will minimize human interaction with system and thus QA can focus on current updated functionalities to test rather than remaining busy with regression testing.

Fields in test cases:

Test case id Input

Expected output

Actual output

pass/Fail

Well written test cases can make the testing cycle smooth and efficient. A good test case is easy to determine if a feature of an application is working correctly.

Post by :- Madhavi.

Published by :- Pardha Saradhi