POC and POO

Point of Control (POC): Point of control is the point at which test objects are supplied with test data.

Point of Observation (POO): Point of observation is the point at which test objects are logged and investigated.

In Black box testing the Point of observation is outside the test object, and Point of control is also situated at outside the test object. Here test object it can be your module/component, System .In Black box testing as you know you can’t see internal behaviour of the test object. So that why the POC and POO situated outside the test object. In black box testing the Point of control are appropriate test input data, appropriate test precondition. The Point of Observation is output, result.

In white box testing the Point of observation and Point of control is situated inside the test object. Here Test object can be source code, design, and requirements. In white box testing as you know that you can see internal working of code. Here internal processing of test object as well as output is analysed that’s nothing but Point of observation .and Point of control is also located inside the test object .The POO and POC is one of the white box testing technique.

Difference between Top-Down Testing and Bottom-UP Testing

NO	Top- Down Testing	Bottom-UP Testing
1	Top-Down testing conducted from main-module to sub module.	Bottom-Up testing conducted from sub module to main module.
2	If sub module is not developed a temporary program called Stub is used for simulate the submodule.	If main module is not developed a temporary program called Driver is used to simulate the main module.
3	Top -Down testing good if major flaws occur toward the top of the program.	Bottom-Up Testing good if major flaws occur toward the bottom of the program.
4	In this test condition difficult to create.	In this test condition easy to create.
5	Observation of test output is more difficult.	Observation of test output is easier.

Top Down & Bottom UP Testing

Top-Down Testing:

Top –Down Testing take place from Top to bottom In this testing Stubs used. “Stub” it’s special purpose software component . If sub module is not developed a temporary program called that is Stub. A stub is called from software component to be tested.

During Testing X  call the Stub A or Stub B.

1.       X calls Stub A  , If error occurs then will come to know that problem is in A or problem in interface between Component X and Stub A

2.       X calls Stub B  , If error occurs then will come to know that problem is in B or problem in interface between Component X and Stub B

Important Note: Remember that here we are testing the component X using Stubs A and B. Stubs are used to simulate the activity of the components that are not currently tested.

Bottom-Up Testing:

 Bottom-Up Testing take place from Bottom to Top.  If main module is not developed  a temporary program used  that is Driver. “Driver” its Software component which calls a component to be tested.

During testing Driver X calls Component A or Component B

1.       Driver X calls component  A, If error occurs then will come to know that problem is in  Driver X or problem in interface between  X and component  A

2.       Driver X calls component  B, If error occurs then will come to know that problem is in  Driver X or problem in interface between  X and component  B

Important Note:

Remember that here we are testing component B and C using Driver X

Example:

Cab Service :  Unit Testing of “Customer order Decline” Program , Here a driver will have code which will create customer order records using hardcoded data and then calls Customer order decline program. Program customer order decline uses another unit which Check how many customer raise the request for cab on same time, check that cab is available or not some complex thing. For checking and calculation call to this unit will be replaced by Stub.

Difference between Static Testing and Dynamic Testing

NO	Static Testing	Dynamic Testing
1	It's testing of without executing of the Software.	It's testing that involves the execution of the Software.
2	In Static Testing software are examined manually and some Static analysis tool used.	In Dynamic Testing software executed by giving set of inputs,examined  it's output and compared what is expected.
3	Static Testing can start early in the life cycle.Eg: By Verifying User Requirements.	Dynamic testing can start after development of software components.
4	Types of defect find in Static testing are : Missing requirements, Desgin defect ,Syntax Error etc.	Types of defect find in dynamic testing are : Variables not constant ,checking if output from the expected values.
5	Types of Static Testing : Review ,Inspection , Walk-through.	Types of Dynamic Testing: Unit testing,Integartion testing, System Testing, Acceptance Testing.
6	Static Testing find bug before you compile.	Dynamic testing find bug after compilation, linking.
7	Static Testing is about prevention.	Dynamic Testing is about cure.
8	Static Testing is most cost effective than Dynamic Testing.	Dynamic Testing not Cost effective as compare to Static Testing
9	Static Testing done in the verification stage.	Dynamic Testing done in validation stage.
10	Static Testing gives 100% statement coverage.	Dynamic Testing does not give 100% statement coverage.

What’s Specification and Requirement mean?

So many times we read, hear that requirement should be clear, understandable but what exactly requirement is it? Does requirement and specification are equivalent?

Requirements are what program and system should do, Specifications are how you are going to do it.

Requirement represents the application from the perspective of the user or business. Specification represents the application from the perspective of technical team.

Specifications are outcome of the conversations, discussion of group of people on the requirements.

Tester need to be work on the specification because it specific ,It’s help you out to do testing activity because requirements might be unclear ,messy sometimes. And “Yes” Requirements and Specifications are not equivalent.

How much testing should we do ?

There are question people asked that can you test the software fully? Can you test everything ?then quick response  of some people that -"yes", Everything should be tested. But is it possible to test everything (All combination of inputs and conditions)?

As Tester we need to give confidence to the software/product, The software is good to be  release whether you test completely or you do exhausting testing but it’s very important what customer and project manager expecting from you what they ask for.

when we say how much testing is enough we need to take care of level of risk in product/project then that risk can be business risk, technical risk etc. we need to consider time and budget. That mean in what time we need to complete our testing activity by given budget.

Now the question come over here can we test everything ?Suppose we need to test one text box field which can take only a character,so here can you going to check all upper and lower character ,special character for valid values and for invalid values are you going to check all digits and blank space. Here we are talking about only one text box but when more than one text box will come so can you imagine how much combination and inputs require, does it possible to test everything in give time ? No, it's not possible .In that case you need to do testing with smart way using various type of technique ,understanding the customer requirements, risk and of course you need to do all those thing  by given time frame.

What is root cause analysis?(RCA)

Testing is activity to find defect, prevent defect and gain the confidence of the software but when we detect the defect, failures we need to find out real reason why that happened? what‘s the root cause of that failure? for that we need to analysis the root cause. When we say the root cause that mean when you fix it, when it get resolved and prevent the recurrence of the problem.


Root cause Analysis is the a systematic way to know actual root cause of our problem. There are server ways to analysis the root cause and different techniques too .Every organizations has different techniques and different method to do root cause activity.Understanding the root cause of defect is an important aspect.Many time (RCA) done once event has occurred. But we may make it useful as pro-active method.

Example of Dish washer:
“Machine is 1 week old (Serial no: 123456) After few minutes of loading utensils I see the foam outside the dishwasher”
Now what will be next? The technician check the dish washer operation to test procedure.Technicians determines the cause or investigate why that happened.
Some of the obvious causes technician discover might be:

Liquid dishwashing soap used instead of automatic dishwasher detergent.

Too much automatic dishwasher detergent.

Examine the drain hose to make sure it isn’t kinked.

There are several tool used for the root cause analysis:

Brainstorming:
It's a process where people get together to examine the problem, where the group quickly generate many ideas for the particular problem.
It's a very useful technique because it uses collective brainpower to generate many ideas in a short period of time.

Fishbone diagram:
It is also known as cause –effect diagram, it's a technique to graphically identify and organize many possible causes of a problem
It's help to identify the most likely root cause of the problem.This tool can help focus problem solving and reduce subjective decision making

As tester , we want not to just detect the defect and report it but we need to think about any potential causes of failures.