Shwetank Gaur

Shadow Banking System

2010-06-17T09:37:00.002+05:30

The shadow banking system consists of non-bank financial institutions that play an increasingly critical role in lending businesses the money necessary to operate.

The financial intermediaries involved in facilitating the creation of credit across the global financial system, but whose members are not subject to regulatory oversight. The shadow banking system also refers to unregulated activities by regulated institutions.

Examples of intermediaries not subject to regulation include hedge funds, unlisted derivatives and other unlisted instruments. Examples of unregulated activities by regulated institutions include credit default swaps.

Shadow banking institutions are typically intermediaries between investors and borrowers. For example, an institutional investor like a pension fund may be willing to lend money, while a corporation may be searching for funds to borrow. The shadow banking institution will channel funds from the investor(s) to the corporation, profiting either from fees or from the difference in interest rates between what it pays the investor(s) and what it receives from the borrower.
By definition, shadow institutions do not accept deposits like a depository bank and therefore are not subject to the same regulations. Familiar examples of shadow institutions included Bear Stearns and Lehman Brothers. Other complex legal entities comprising the system include hedge funds, SIVs, conduits, money funds, monolines, investment banks, and other non-bank financial institutions

The shadow banking system has escaped regulation primarily because it did not accept traditional bank deposits. As a result, many of the institutions and instruments were able to employ higher market, credit and liquidity risks, and did not have capital requirements commensurate with those risks. Subsequent to the subprime meltdown in 2008, the activities of the shadow banking system came under increasing scrutiny and regulations.

Kanban

2010-06-09T15:43:00.002+05:30

Kanban is a Japanese word meaning “signboard.” It is a concept related to lean and just-in-time (JIT) production.

A Kanban Board is a visual display in which the movement of objects, in the case of a development project, user story cards, will trigger action. The idea is that there’s continuous flow as the objects are moved across the board to completion.

Kanban is considered an agile methodology, though more adaptive than most. In other words, there aren’t a lot of rules. Kanban was considered the most adaptive with only three rules:

Visualize the Workflow
Limit Work-in-Progress (WIP)
Measure and Optimize Lead Time

Impairment Charge

2010-06-08T08:47:00.001+05:30

A specific reduction on a company's balance sheet that adjusts the value of a company's goodwill. Due to accounting rules, a company must monitor and test the value of its goodwill, to determine if it is overvalued. If it is, the company must issue an impairment charge on its balance sheet, to take into account the reduced value of the goodwill.

For more on Impairment Charge, refer http://www.investopedia.com/articles/analyst/110502.asp

Software Testing Life Cycle - Part 1

2008-07-31T01:08:00.017+05:30

If we talk about STLC in the today's scenario of IT industry, I would like to differentiate it in two parts:

Testing as a part of complete project life cycle.
Testing cycle for a Testing only project (Where testing is outsourced to some some other company)

For Testing as a part of complete project we have V model, W model ideally in place to follow.

But for a Testing Only Project we don't have any such model. Here sometimes companies (vendors for the company who is doing development) are approached lately in the middle of the project or sometimes in the earlier phases.

Here I would like to talk about Testing only projects. I will take a our in brief about what happen behind the scene.

The basic steps of STLC in this case are same:

Test Initiation
Test Planning
Test Environment
Test Design
Test Execution
Defect Reporting
Documentation
Sign-off

1. Test Initiation

BAs (Business Analysts) gather requirements: BAs try to understand the problem of the client and give them a solution in the form of proposal.
Then a contract is signed between client and the company
A BRD/FRD/SRD/UC document is sent from the client side to the test manager of the company.
Test manager made the estimations based on either FP (Calculating Function Points) or UCP (Use Case Points)
Function Points are the logical input and output fields in an application
Estimation is done based on the criticality of the application or by calculating the criticality of the FPs of the modules and summing them.

2. Test planning

After the work estimation and resource estimation, Test Plan and Test Strategies are defined.

Test Strategy document could be a separate document as it can be a part of the Test Plan document.

In the Test Strategy document, Test manager defines the kind of testing that will be performed on the system, who will be the actor for each type of testing, etc…

Test Plan document: It is very formal document and the format of Test Plan document is company specific. The essential content of Test plan document are:

Objective (Summary)
Owners of Key Process Areas (Roles of Members)
Functional description
Hardware and Software Requirement
Feature Test goal and Strategy
Functional test Cases
Tools (Automation / Manual / Test Management / Defect Reporting)
Portability
Related documentation
etc…

Test Manager sends these documents to the client side and client can make request to change the document accordingly.

3. Test Environment or Test-bed

A Test-Bed is a testing environment. It is a execution environment configured for testing. It may consists of specific hardware, OS, Network topology, Configuration of the product, Browsers, Other application or software required, Database, etc…

Test plan for a project should enumerate the test bed to be used.

After setting up the testing environment a kick-off meeting is scheduled.

Kick-Off Meeting: It is a formal meeting in which a PPT is displayed to all the team members. This PPT consists of:

About the client
About Work
Estimations (Time, Resources)
Deadlines
Application
Types of Testing
Deliverables

Then a brain storming session is held in which risks related to the projects are identified and discussed. Team members openly place their ideas.

A defect champion is decided who will analyze the risks involved at any point during the project.

In the meeting, risks and related mitigation and contingency plans are discussed.

Risks

Mitigation

Contingency

Steps to stop Risk A.

If the risk still occur, after applying mitigation plan, then what steps will be followed

(Planning is also done when the contingency plan is executed.)

4. Test Design

From the documents provided (say, FRD / BRD / FS / UC), test scenarios are identified
Test Cases are prepared from the Test scenarios.
RTM is created
Steps for the test cases are written
Test Data is prepared
Test cases review and approval is done
Base-Lining of all the documents is done with sign-off document for each document

5. Test Execution and Defect Tracking

Execution of Test-cases
Capture, review and analysis of results
Raise the defect
Tracking of defects for its closure

6. Defect Reporting

Defects are reported to the client
There could be triage meeting between developers and testers on discussion over the bugs and priority of the bug is defined in that meeting

7. Documentation

Test Summary Report
Test Incident Report
Test matrices
Build Release
Receiving Acceptance

8. Sign-off

Sign-off template provides a checklist format for customers that can be used for reviewing a new system’s functionality and other attributes before accepting and delivering.

Cyclomatic Complexity

2007-10-19T15:47:00.000+05:30

Cyclomatic complexity is a software metric (measurement). It was developed by Thomas McCabe and is used to measure the complexity of a program. It directly measures the number of linearly independent paths through a program's source code. It is computed using a graph that describes the control flow of the program. The nodes of the graph correspond to the commands of a program. A directed edge connects two nodes if the second command might be executed immediately after the first command.

Definition

M = E − N + 2P

where

M = cyclomatic complexity
E = the number of edges of the graph
N = the number of nodes of the graph
P = the number of connected components.

"M" is alternatively defined to be one larger than the number of decision points (if/case-statements, while-statements, etc) in a module (function, procedure, chart node, etc.), or more generally a system.

Separate subroutines are treated as being independent, disconnected components of the program's control flow graph.

Alternative definition

v(G) = e − n + p
G is a program's flowgraph
e is the number of edges (arcs) in the flowgraph
n is the number of nodes in the flowgraph
p is the number of connected components

Alternative way

There is another simple way to determine the cyclomatic number. This is done by counting the number of closed loops in the flow graph, and incrementing that number by one.

i.e.

M = Number of closed loops + 1

where

M = Cyclomatic number.

Implications for Software Testing:

M is a lower bound for the number of possible paths through the control flow graph.
M is an upper bound for the number of test cases that are necessary to achieve a complete branch coverage.

For example, consider a program that consists of two sequential if-then-else statements.

if (c1) {
f1();
} else {
f2();
}

if (c2) {
f3();
} else {
f4();
}

To achieve a complete branch coverage, two test cases are sufficient here.
For a complete path coverage, four test cases are necessary.
The cyclomatic number M is three, falling in the range between these two values, as it does for any program.

Cyclomatic complexity can be applied in several areas, including:

Code development risk analysis: While code is under development, it can be measured for complexity to assess inherent risk or risk buildup.
Change risk analysis in maintenance: Code complexity tends to increase as it is maintained over time. By measuring the complexity before and after a proposed change, this buildup can be monitored and used to help decide how to minimize the risk of the change.
Test Planning: Mathematical analysis has shown that cyclomatic complexity gives the exact number of tests needed to test every decision point in a program for each outcome. Thus, the analysis can be used for test planning. An excessively complex module will require a prohibitive number of test steps; that number can be reduced to a practical size by breaking the module into smaller, less-complex sub-modules.
Re-engineering: Cyclomatic complexity analysis provides knowledge of the structure of the operational code of a system. The risk involved in reengineering a piece of code is related to its complexity. Therefore, cost and risk analysis can benefit from proper application of such an analysis.

Test Coverage Matrix Vs. Traceability Matrix

2007-10-18T12:04:00.000+05:30

Test coverage matrix:

Test coverage matrix is a checklist which ensures that the functionality of the given screen(unit) is checked in all possible combinations (positive and negative) which have not been covered in test cases. Test coverage matrix is usually prepared for a screen having large number of controls (textboxes, dropdowns, buttons etc) usually, test coverage matrix is prepared in a spread sheet having all the controls (textboxes, dropdowns, buttons etc) in the columns and then all possible entries in those fields in the rows with an ''yes'' or ''no'' in the rows against the controls listed in the columns. For example, consider a ''login'' screen wherein we have ''username'' and ''password" textfields.

While preparing test coverage matrix, the first column will be ''s.no'' and the second will be ''username" and ''password" will be the third field followed by ''ok'' and ''cancel'' button. Then, in the first row for s.no 1, enter ''yes'' for both ''user name'' and ''password'' columns, ''yes'' implying that a value is entered in that field. In the second row, enter ''yes'' and ''no'' and in the third row, ''no'' and 'yes'' and so on.

The complexity increases with the number of controls in the screen. Each of the row is considered as one condition and executed while testing. This is how we prepare test coverage matrix. (this is a black box testing technique).

Traceability matrix:

While, Traceability matrix serves in mapping the test cases to the requirements. It serves as a checklist wherein all the requirements (of srs) are listed and the test cases covering the corresponding requirement is listed against each requirement. Every company may have their own template for rtm, but they serve the same purpose as described above.

From V-Model to W-Model

2007-10-18T11:24:00.000+05:30

V-Model:

The V-model promotes the idea that the dynamic test stages (on the right hand side of the model) use the documentation identified on the left hand side as baselines for testing. The V-Model further promotes the notion of early test preparation.

The V-Model of testing

Early test preparation finds faults in baselines and is an effective way of detecting faults early. This approach is fine in principle and the early test preparation approach is always effective. However, there are two problems with the V-Model as normally presented.

The V-Model with early test preparation

There is rarely a perfect, one-to-one relationship between the documents on the left hand side and the test activities on the right. For example, functional specifications don’t usually provide enough information for a system test. System tests must often take account of some aspects of the business requirements as well as physical design issues for example. System testing usually draws on several sources of requirements information to be thoroughly planned.

V-Model has little to say about static testing at all. The V-Model treats testing as a back-door activity on the right hand side of the model. There is no mention of the potentially greater value and effectiveness of static tests such as reviews, inspections, static code analysis and so on. This is a major omission and the V-Model does not support the broader view of testing as a constantly prominent activity throughout the development lifecycle.

W Model:

The W-Model of testing

Paul Herzlich introduced the W-Model approach in 1993. The W-Model attempts to address shortcomings in the V-Model. Rather than focus on specific dynamic test stages, as the V-Model does, the W-Model focuses on the development products themselves. Essentially, every development activity that produces a work product is shadowed by a test activity. The purpose of the test activity specifically is to determine whether the objectives of a development activity have been met and the deliverable meets its requirements. In its most generic form, the W-Model presents a standard development lifecycle with every development stage mirrored by a test activity. On the left hand side, typically, the deliverables of a development activity (for example, write requirements) is accompanied by a test activity test the requirements and so on. If your organization has a different set of development stages, then the W-Model is easily adjusted to your situation. The important thing is this: the W-Model of testing focuses specifically on the product risks of concern at the point where testing can be most effective.

The W-Model and static test techniques.

If we focus on the static test techniques, you can see that there is a wide range of techniques available for evaluating the products of the left hand side. Inspections, reviews, walkthroughs, static analysis, requirements animation as well as early test case preparation can all be used.

The W-Model and dynamic test techniques.

If we consider the dynamic test techniques you can see that there is also a wide range of techniques available for evaluating executable software and systems. The traditional unit, integration, system and acceptance tests can make use of the functional test design and measurement techniques as well as the non-functional test techniques that are all available for use to address specific test objectives.

The W-Model removes the rather artificial constraint of having the same number of dynamic test stages as development stages. If there are five development stages concerned with the definition, design and construction of code in your project, it might be sensible to have only three stages of dynamic testing only. Component, system and acceptance testing might fit your normal way of working. The test objectives for the whole project would be distributed across three stages, not five. There may be practical reasons for doing this and the decision is based on an evaluation of product risks and how best to address them. The W-Model does not enforce a project symmetry that does not (or cannot) exist in reality. The W-model does not impose any rule that later dynamic tests must be based on documents created in specific stages (although earlier documentation products are nearly always used as baselines for dynamic testing. In projects using these methods, requirements and designs might be documented in multiple models so system testing might be based on several of these models (spread over several documents).

We use the W-Model in test strategy as follows. Having identified the specific risks of concern, we specify the products that need to be tested; we then select test techniques (static reviews or dynamic test stages) to be used on those products to address the risks; we then schedule test activities as close as practicable to the development activity that generated the products to be tested.

Cause-Effect Graphing Techniques

2007-10-17T10:36:00.000+05:30

Cause-effect graphing is a technique that provides a concise representation of logical conditions and corresponding actions.

It is a test case design technique that is performed once requirements have been reviewed for ambiguity, followed by a review for content.

Requirements are reviewed for content to insure that they are correct and complete. The Cause-Effect Graphing technique derives the minimum number of test cases to cover 100% of the functional requirements to improve the quality of test coverage.

There are four steps:

Causes (input conditions) and effects (actions) are listed for a module and an identifier is assigned to each.
A cause-effect graph is developed.
The graph is converted to a decision table.
Decision table rules are converted to test cases.

The Cause-Effect Graphing technique was invented by Bill Elmendorf of IBM in 1973. Instead of the test case designer trying to manually determine the right set of test cases, he/she models the problem using a cause-effect graph, and the software that supports the technique, BenderRBT, calculates the right set of test cases to cover 100% of the functionality. The cause-effect graphing technique uses the same algorithms that are used in hardware logic circuit testing. Test case design in hardware insures virtually defect free hardware.

Cause-Effect Graphing also has the ability to detect defects that cancel each other out, and the ability to detect defects hidden by other things going right. These are advanced topics that won’t be discussed in this article.

The starting point for the Cause-Effect Graph is the requirements document. The requirements describe “what” the system is intended to do. The requirements can describe real time systems, events, data driven systems, state transition diagrams, object oriented systems, graphical user interface standards, etc. Any type of logic can be modeled using a Cause-Effect diagram. Each cause (or input) in the requirements is expressed in the cause-effect graph as a condition, which is either true or false. Each effect (or output) is expressed as a condition, which is either true or false.

A Simple Cause-Effect Graphing Example

I have a requirement that says: “If A OR B, then C.” The following rules hold for this requirement:

• If A is true and B is true, then C is true.
• If A is true and B is false, then C is true.
• If A is false and B is true, then C is true.
• If A is false and B is false, then C is false.

The cause-effect graph that represents this requirement is provided in Figure 1. The cause-effect graph shows the relationship between the causes and effects.

In Figure 1, A, B and C are called nodes. Nodes A and B are the causes, while Node C is an effect. Each node can have a true or false condition. The lines, called vectors, connect the cause nodes A and B to the effect node C.

All requirements are translated into nodes and relationships on the cause-effect graph. There are only four possible relationships among nodes, and they are indicated by the following symbols:

Where A always leads to C, a straight line ------------.
Where A or B lead to C, a V at the intersection means “or”.
Where A and B lead to C, an inverted V at the intersection means “and”.
A tilde ~ means “not” as in “If not A, then C”.

The Decision Table
The cause-effect graph is then converted into a decision table or “truth table” representing the logical relationships between the causes and effects. Each column of the decision table is a test case. Each test case corresponds to a unique possible combination of inputs that are either in a true state, a false state, or a masked state (the masked state will be described in Figure 4 below).

Since there are 2 inputs to this example, there are 2 ** 2 = 4 combinations of inputs from which test cases can be selected.

Figure 2 represents the decision table derived for the cause-effect graph in Figure 1.

Notice that there are only three test cases. However, these three test cases cover 100% of the functionality for this example. The fourth combination of inputs (A= true and B =true) does not add any additional functional coverage, and is a redundant test case. Each relation is tested with the right combinations of causes so that all defects are covered for that relation, resulting in 100% coverage.

Smoke Testing vs. Sanity Testing

2007-10-15T17:00:00.000+05:30

S. No.	Smoke	Sanity
1	Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested.	A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.
2	A smoke test is scripted--either using a written set of tests or an automated test	A sanity test is usually unscripted.
3	A Smoke test is designed to touch every part of the application in a cursory way. It's is shallow and wide.	A Sanity test is used to determine a small section of the application is still working after a minor change.
4	Smoke testing will be conducted to ensure whether the most crucial functions of a program work, but not bothering with finer details. (Such as build verification).	Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing.
5	Smoke testing is normal health check up to a build of an application before taking it to testing in depth.	Sanity testing is to verify whether requirements are met or not, checking all features breadth-first.

Sanity Testing

2007-10-15T16:57:00.000+05:30

Sanity testing is cursory testing, and performed whenever cursory testing 'is' sufficient to prove the application is functioning according to specifications. Sanity testing is a subset of regression testing. It normally includes a set of core tests such as basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.

A sanity test or sanity check is a basic test to quickly evaluate the validity of a claim or calculation. In mathematics, for example, when multiplying by three or nine, verifying that the sum of the digits of the result is a multiple of 3 or 9 respectively is a sanity test.

In computer science it is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that the system or methodology works as expected, often prior to a more exhaustive round of testing.

Sanity tests are sometimes mistakenly equated to smoke tests. Where a distinction is made between sanity testing and smoke testing, it's usually in one of two directions. Either sanity testing is a focused but limited form of regression testing – narrow and deep, but cursory; or it's broad and shallow, like a smoke test, but concerned more with the possibility of "insane behavior" such as slowing the entire system to a crawl, or destroying the database, but is not as thorough as a true smoke test.

Generally, a smoke test is scripted (either using a written set of tests or an automated test), whereas a sanity test is usually unscripted.

With the evolution of test methodologies, sanity tests are useful both for initial environment validation and future interactive increments. The process of sanity testing begins with the execution of some online transactions of various modules, batch programs of various modules to see whether the software runs without any hindrance or abnormal termination. This practice can help identify most of the environment related problems. A classic example of this in programming is the hello world program. If a person has just set up a computer and a compiler, a quick sanity test can be performed to see if the compiler actually works: write a program that simply displays the words "hello world".

A sanity test can refer to various order of magnitude and other simple rule of thumb devices applied to cross-check mathematical calculations. For example:

If one were to attempt to square 738 and calculated 53,874, a quick sanity check could show that this cannot be true. Consider that 500 < 5002 =" 521002"> 53874. Since squaring preserves inequality for positive numbers (see inequality), this cannot be true and so the calculation was bad.

In multiplication, 918 x 155 is not 142135 since 918 is divisible by three but 142135 is not (digits add up to 16 the digits of which do not add up to a multiple of three). Moreover, the product of an even and an odd number should be even, whereas 142135 is odd.

When talking about quantities in physics, the power output of a car cannot be 700 kJ since that is a unit of energy, not power (energy per unit time). See dimensional analysis.

Smoke Testing

2007-10-15T16:56:00.000+05:30

Smoke testing is a term used in plumbing, woodwind repair, electronics, and computer software development. It refers to the first test made after repairs or first assembly to provide some assurance that the system under test will not catastrophically fail. After a smoke test proves that the pipes will not leak, the keys seal properly, the circuit will not burn, or the software will not crash outright, the assembly is ready for more stressful testing.

Smoke testing in software development

Smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. In this case, the smoke is metaphorical.

Smoke testing is done by developers before the build is released or by testers before accepting a build for further testing.

In software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection. Next after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software; some even believe that it is the most effective of all.

In software testing, a smoke test is a collection of written tests that are performed on a system prior to being accepted for further testing. This is also known as a build verification test. This is a "shallow and wide" approach to the application. The tester "touches" all areas of the application without getting too deep, looking for answers to basic questions like, "Can I launch the test item at all?", "Does it open to a window?", "Do the buttons on the window do things?". There is no need to get down to field validation or business flows. If you get a "No" answer to basic questions like these, then the application is so badly broken, there's effectively nothing there to allow further testing. These written tests can either be performed manually or using an automated tool. When automated tools are used, the tests are often initiated by the same process that generates the build itself.

Soak Testing or Endurance Testing

2007-10-15T16:12:00.000+05:30

Soak testing is running a system at high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day (or night) than would be expected in a busy day, to identify any performance problems that appear after a large number of transactions have been executed.

Also, it is possible that a system may ‘stop’ working after a certain number of transactions have been processed due to memory leaks or other defects. Soak tests provide an opportunity to identify such defects, whereas load tests and stress tests may not find such problems due to their relatively short duration.

The above diagram shows activity for a certain type of site. Each login results in an average session of 12 minutes duration with and average eight business transactions per session.

A soak test would run for as long as possible, given the limitations of the testing situation. For example, weekends are often an opportune time for a soak test. Soak testing for this application would be at a level of 550 logins per hour, using typical activity for each login.

The average number of logins per day in this example is 4,384 per day, but it would only take 8 hours at 550 per hour to run an entire days activity through the system.

By Starting a 60 hour soak test on Friday evening at 6 pm (to finish at 6am Monday morning), 33,000 logins would be put through the system, representing 7½ days of activity. Only with such a test, will it be possible to observe any degradation of performance under controlled conditions.

Some typical problems identified during soak tests are listed below:

1. Serious memory leaks that would eventually result in a memory crisis,
2. Failure to close connections between tiers of a multi-tiered system under some circumstances which could stall some or all modules of the system.
3. Failure to close database cursors under some conditions which would eventually result in the entire system stalling.
4. Gradual degradation of response time of some functions as internal data-structures become less efficient during a long test.

Apart from monitoring response time, it is also important to measure CPU usage and available memory. If a server process needs to be available for the application to operate, it is often worthwhile to record it's memory usage at the start and end of a soak test. It is also important to monitor internal memory usages of facilities such as Java Virtual Machines, if applicable.

Long Session Soak Testing

When an application is used for long periods of time each day, the above approach should be modified, because the soak test driver is not Logins and transactions per day, but transactions per active user for each user each day.

This type of situation occurs in internal systems, such as ERP and CRM systems, where users login and stay logged in for many hours, executing a number of business transactions during that time. A soak test for such a system should emulate multiple days of activity in a compacted time-frame rather than just pump multiple days worth of transactions through the system.

Long session soak tests should run with realistic user concurrency, but the focus should be on the number of transactions processed. VUGen scripts used in long session soak testing may need to be more sophisticated than short session scripts, as they must be capable of running a long series of business transactions over a prolonged period of time.

Test Duration

The duration of most soak tests is often determined by the available time in the test lab. There are many applications, however, that require extremely long soak tests. Any application that must run, uninterrupted for extended periods of time, may need a soak test to cover all of the activity for a period of time that is agreed to by the stakeholders, such as a month. Most systems have a regular maintenance window, and the time between such windows is usually a key driver for determining the scope of a soak test.

A classic example of a system that requires extensive soak testing is an air traffic control system. A soak test for such a system may have a multi-week or even multi-month duration.

Test Harness

2007-10-15T14:10:00.000+05:30

In software testing, a test harness or automated test framework is a collection of software and test data configured to test a program unit by running it under varying conditions and monitor its behavior and outputs. It has two main parts: the test execution engine and the test script repository.

Test harnesses allow for the automation of tests. They can call functions with supplied parameters and print out and compare the results to the desired value. The test harness is a hook to the developed code, which can be tested using an automation framework.

A test harness should allow specific tests to run (this helps in optimizing), orchestrate a runtime environment, and provide a capability to analyze results.

A test harness should include:
A standard way to specify setup (i.e., creating an artificial runtime environment) and cleanup.
A method for selecting individual tests to run, or all tests.
A means of analyzing output for expected (or unexpected) results.
A standardized form of failure reporting.

The typical objectives of a test harness is to:
Automate the testing process.
Execute test suites of test cases.
Generate associated test reports.

A test harness typically provides the following benefits:
Increased productivity due to automation of the testing process.
Increased probability that regression testing will occur.
Increased quality of software components and application.

TestBed

2007-10-15T14:01:00.000+05:30

The term is used across many disciplines to describe a development environment that is shielded from the hazards of testing in a live or production environment.

In software testing:

Test Bed is an execution environment configured for testing. It consists of specific hardware, Operating Systems, Network Topology, Configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerated the test beds to be used.

In Development Environment:

A testbed is a platform for experimentation for large development projects. Testbeds allow for rigorous, transparent and replicable testing of scientific theories, computational tools, and other new technologies.

Also:

Testbeds are on the internet where the public is given the opportunity to test CSS or HTML they have created and are wanting to see the outcome.

Equivalence partitioning

2007-10-11T17:05:00.000+05:30

Equivalence partitioning is a method for deriving test cases. In this method, classes of input conditions called equivalence classes are identified such that each member of the class causes the same kind of processing and output to occur.

In this method, the tester identifies various equivalence classes for partitioning. A class is a set of input conditions that are is likely to be handled the same way by the system. If the system were to handle one case in the class erroneously, it would handle all cases erroneously.

Equivalence partitioning drastically cuts down the number of test cases required to test a system reasonably. It is an attempt to get a good 'hit rate', to find the most errors with the smallest number of test cases.

To use equivalence partitioning, you will need to perform four steps:

Determining conditions to be Tested
Defining Tests
Designing test cases
Identifying Final set of Test Cases

Defining Tests

A number of items must be considered when determining the tests using the equivalence partitioning method, like:

All valid input data for a given condition are likely to go through the same process.
Invalid data can go through various processes and need to be evaluated more carefully. For example,
a blank entry may be treated differently than an incorrect entry,
a value that is less than a range of values may be treated differently than a value that is greater,
if there is more than one error condition within a particular function, one error may override the other, which means the subordinate error does not get tested unless the other value is valid.

Defining Test Cases

Create test cases that incorporate each of the tests. For valid input, include as many tests as possible in one test case. For invalid input, include only one test in a test case in order to isolate the error. Only the invalid input test condition needs to be evaluated in such tests, because the valid condition has already been tested.

EXAMPLE OF EQUIVALENCE PARTITIONING

1. Conditions to be Tested

The following input conditions will be tested:

For the first three digits of all social insurance (security) numbers, the minimum number is 111 and the maximum number is 222.
For the fourth and fifth digits of all social insurance (security) numbers, the minimum number is 11 and the maximum number is 99.

2. Defining Tests

Identify the input conditions and uniquely identify each test, keeping in mind the items to consider when defining tests for valid and invalid data.

The tests for these conditions are:

The first three digits of the social insurance (security) number are:

= or > 111 and = or <>
<>
> 222, (invalid input, above the range),
blank, (invalid input, below the range, but may be treated differently).

The fourth and fifth digits of the social insurance (security) number are:

= or > 11 and = or <>
<>
> 99, (invalid input, above the range),
blank, (invalid input, below the range, but may be treated differently).

Using equivalence partitioning, only one value that represents each of the eight equivalence classes needs to be tested.

3. Defining Test Cases

After identifying the tests, create test cases to test each equivalence class, (i.e., tests 1 through 8).

Create one test case for the valid input conditions, (i.e., tests 1 and 5), because the two conditions will not affect each other.

Identify separate test cases for each invalid input, (i.e., tests 2 through 4 and tests 6 through 8).

Both conditions specified, (i.e., condition 1 - first three digits, condition 2 - fourth and fifth digits), apply to the social insurance (security) number.

Since equivalence partitioning is a type of black-box testing, the tester does not look at the code and, therefore, the manner in which the programmer has coded the error handling for the social insurance (security) number is not known. Separate tests are used for each invalid input, to avoid masking the result in the event one error takes priority over another.

For example, if only one error message is displayed at one time, and the error message for the first three digits takes priority, then testing invalid inputs for the first three digits and the fourth and fifth digits together, does not result in an error message for the fourth and fifth digits. In tests B through G, only the results for the invalid input need to be evaluated, because the valid input was tested in test case A.

4. Suggested test cases:

Test Case A - Tests 1 and 5, (both are valid, therefore there is no problem with errors),
Test Case B - Tests 2 and 5, (only the first one is invalid, therefore the correct error should be produced),
Test Case C - Tests 3 and 5, (only the first one is invalid, therefore the correct error should be produced),
Test Case D - Tests 4 and 5, (only the first one is invalid, therefore the correct error should be produced),
Test Case E - Tests 1 and 6, (only the second one is invalid, therefore the correct error should be produced),
Test Case F - Tests 1 and 7, (only the second one is invalid, therefore the correct error should be produced),
Test Case G - Tests 1 and 8, (only the second one is invalid, therefore the correct error should be produced).

Testing: Drivers and Stubs

2007-10-05T17:32:00.000+05:30

It is always a good idea to develop and test software in "pieces". But, it may seem impossible because it is hard to imagine how you can test one "piece" if the other "pieces" that it uses have not yet been developed (and vice versa). To solve this kindof diffcult problems we use stubs and drivers.

In white-box testing, we must run the code with predetermined input and check to make sure that the code produces predetermined outputs. Often testers write stubs and drivers for white-box testing.

Driver for Testing:

Driver is a the piece of code that passes test cases to another piece of code. Test Harness or a test driver is supporting code and data used to provide an environment for testing part of a system in isolation. It can be called as as a software module which is used to invoke a module under test and provide test inputs, control and, monitor execution, and report test results or most simplistically a line of code that calls a method and passes that method a value.

For example, if you wanted to move a fighter on the game, the driver code would be
moveFighter(Fighter, LocationX, LocationY);

This driver code would likely be called from the main method. A white-box test case would execute this driver line of code and check "fighter.getPosition()" to make sure the player is now on the expected cell on the board.

Stubs for Testing:

A Stub is a dummy procedure, module or unit that stands in for an unfinished portion of a system.

Four basic types of Stubs for Top-Down Testing are:

1 Display a trace message
2 Display parameter value(s)
3 Return a value from a table
4 Return table value selected by parameter

A stub is a computer program which is used as a substitute for the body of a software module that is or will be defined elsewhere or a dummy component or object used to simulate the behavior of a real component until that component has been developed.

For example, if the movefighter method has not been written yet, a stub such as the one below might be used temporarily – which moves any player to position 1.

public void moveFighter(Fighter player, int LocationX, int LocationY) {
fighter.setPosition(1);
}

Ultimately, the dummy method would be completed with the proper program logic. However, developing the stub allows the programmer to call a method in the code being developed, even if the method does not yet have the desired behavior.

Stubs and drivers are often viewed as throwaway code. However, they do not have to be thrown away: Stubs can be "filled in" to form the actual method. Drivers can become automated test cases.

Too Much Methodology and Project Disaster

2007-10-01T10:37:00.000+05:30

Methodology is a tool for completing a project, not a guarantee that things will go smoothly. Project Management methodologies are documented best practices, and more often than not, the failure of a project can be traced to a lack of best practices. Achieving higher levels of maturity in Capability Maturity Models involves having a methodology as a condition at the initial phases itself. The objective of consistently delivering within budgets and deadlines cannot be achieved without following best practices.

Project Disaster:

There are several important things to do once you realize that you're facing a disaster in the making, but you shouldn't do any of them until you are really sure that it's an impending disaster you're up against. So the first key to disaster recovery is disaster detection.

Too much methodology:

While methodologies are inherently good for projects, getting lost in a flood of them is not the best thing for a project. The damage happens when there is too much methodology - often the 'too much' sneaks up to unsuspecting executives and surprises them. it starts out innocently enough, when some basic methodology is put into place. And as with any tool, it may be employed for its intended use or as a weapon. A team that's over-burdened with methodology is usually either too concerned with the means rather than the end or is using the process as a bludgeon to further political goals.

An article on PM Forum by Tony Crawford says:

"The problem is not the absence of project management methodologies. Indeed, the biggest project failures were with organizations that had the most methodologies. The greater need by project managers and their teams was for easy-to-use methodologies with direct links to recommended tools and templates, and even more importantly, that they also have the insights and understanding of the value of these methodologies to the success of a project and a motivation and desire to apply them."

Test Incident Report

2007-09-28T17:57:00.000+05:30

A document reporting on any event that occurs during testing process which requires further investigation

The purpose of a Test Incident Report is to document any event that occurs during the testing process, which requires investigation. The Problem Resolution procedure defined in the Quality Plan should document the manner in which any Test Incident Reports are to be treated.

The Test Incident Report conforms to ANSI/IEEE Standard 829-1983, IEEE Standards for software test documentation.

A sample Test Incident Report for capturing incidents:

Date: ___________

Project: ____________

Programmer: __________________

Tester: _________________

Program/Module: _______________________

Build/Revision/Release: _______________

Software Environment: _________________

Hardware Environment: _________________

Number of Occurrences: _______

Severity: _________

Priority __________

Detailed Description: ___________________________________________________

___________________________________________________

___________________________________________________

___________________________________________________

___________________________________________________

Assigned To: ___________________

Incident Resolution: ____________________________________________________

Risk Analysis

2007-09-27T14:47:00.001+05:30

A risk is a potential for loss or damage to an Organization from materialized threats. Risk Analysis attempts to identify all the risks and then quantify the severity of the risks. A threat as we have seen is a possible damaging event. If it occurs, it exploits vulnerability in the security of a computer based system.
Risk Identification:

1. Software Risks: Knowledge of the most common risks associated with Software development, and the platform you are working on.

2. Business Risks: Most common risks associated with the business using the Software

3. Testing Risks: Knowledge of the most common risks associated with Software Testing for the platform you are working on, tools being used, and test methods being applied.

4. Premature Release Risk: Ability to determine the risk associated with releasing unsatisfactory or untested Software Predicts.

5. Risk Methods: Strategies and approaches for identifying risks or problems associated with implementing and operating information technology, products and process; assessing their likelihood, and initiating strategies to test those risks.

Sometimes mapping out the risk can be helpful. Risks can be explained in tabular format:

Risk	Probability of occurrence	Risk severity	Exposure	Trigger date	Mitigation plan
Define this in words	How likely is this risk to occur? Use high, medium, low	How severe a problem is this risk if it occurs? Use high, medium, low	Multiply probability and severity together, to derive a joint value	The date by which you will set the mitigation plan in place	What are you going to do about this

Risk Analysis is one of the important concepts in Software Product/Project Life Cycle. Risk analysis is broadly defined to include risk assessment, risk characterization, risk communication, risk management, and policy relating to risk. Risk Assessment is also called as Security risk analysis.

Technical Definitions:

Risk Analysis: A risk analysis involves identifying the most probable threats to an organization and analyzing the related vulnerabilities of the organization to these threats.

Risk Assessment: A risk assessment involves evaluating existing physical and environmental security and controls, and assessing their adequacy relative to the potential threats of the organization.

Business Impact Analysis: A business impact analysis involves identifying the critical business functions within the organization and determining the impact of not performing the business function beyond the maximum acceptable outage. Types of criteria that can be used to evaluate the impact include: customer service, internal operations, legal/statutory and financial.

Types of Risks

Risks for a software product can be categorized into various types. Some of them are:

Product Size Risks:

The following risk item issues identify some generic risks associated with product size:
• Estimated size of the product and confidence in estimated size?
• Estimated size of product?
• Size of database created or used by the product?
• Number of users of the product?
• Number of projected changes to the requirements for the product?

Risk will be high, when a large deviation occurs between expected values and the previous experience. All the expected information must be compared to previous experience for analysis of risk.

Business Impact Risks:

The following risk item issues identify some generic risks associated with business impact:
• Affect of this product on company revenue?
• Reasonableness of delivery deadline?
• Number of customers who will use this product and the consistency of their needs relative to the product?
• Number of other products/systems with which this product must be interoperable?
• Amount and quality of product documentation that must be produced and delivered to the customer?
• Costs associated with late delivery or a defective product?

Customer-Related Risks:

Different Customers have different needs. Customers have different personalities. Some customers accept what is delivered and some others complain about the quality of the product. In some other cases, customers may have very good association with the product and the producer and some other customers may not know. A bad customer represents a significant threat to the project plan and a substantial risk for the project manager.

The following risk item checklist identifies generic risks associated with different customers:
• Have you worked with the customer in the past?
• Does the customer have a solid idea of what is required?
• Will the customer agree to spend time in formal requirements gathering meetings to identify project scope?
• Is the customer willing to participate in reviews?
• Is the customer technically sophisticated in the product area?
• Does the customer understand the software engineering process?

Process Risks:

If the software engineering process is ill-defined or if analysis, design and testing are not conducted in a planned fashion, then risks are high for the product.
• Has your organization developed a written description of the software process to be used on this project?
• Are the team members following the software process as it is documented?
• Are the third party coders following a specific software process and is there any procedure for tracking the performance of them?
• Are formal technical reviews are done regularly at both development and testing teams?
• Are the results of each formal technical review documented, including defects found and resources used?
• Is configuration management used to maintain consistency among system/software requirements, design, code, and test cases?
• Is a mechanism used for controlling changes to customer requirements that impact the software?

Technical Issues:
• Are specific methods used for software analysis?
• Are specific conventions for code documentation defined and used?
• Are any specific methods used for test case design?
• Are software tools used to support planning and tracking activities?
• Are configuration management software tools used to control and track change activity throughout the software process?
• Are tools used to create software prototypes?
• Are software tools used to support the testing process?
• Are software tools used to support the production and management of documentation?
• Are quality metrics collected for all software projects?
• Are productivity metrics collected for all software projects?

Technology Risk:
• Is the technology to be built new to your organization?
• Does the software interface with new hardware configurations?
• Does the software to be built interface with a database system whose function and performance have not been proven in this application area?
• Is a specialized user interface demanded by product requirements?
• Do requirements demand the use of new analysis, design or testing methods?
• Do requirements put excessive performance constraints on the product?

Development Environment Risks:
• Is a software project and process management tool available?
• Are tools for analysis and design available?
• Do analysis and design tools deliver methods that are appropriate for the product to be built? • Are compilers or code generators available and appropriate for the product to be built?
• Are testing tools available and appropriate for the product to be built?
• Are software configuration management tools available?
• Does the environment make use of a database or repository?
• Are all software tools integrated with one another?
• Have members of the project team received training in each of the tools?

Risks Associated with Staff Size and Experience:
• Are the best people available and are they enough for the project?
• Do the people have the right combination of skills?
• Are staffs committed for entire duration of the project?

Risk Analysis and Testing

Metrics Used In Testing

2007-09-27T13:51:00.000+05:30

Software metrics are numerical data related to software development. Metrics strongly support software project management activities. They relate to the four functions of management as follows:
1. Planning - Metrics serve as a basis of cost estimating, training planning, resource planning, scheduling, and budgeting.
2. Organizing - Size and schedule metrics influence a project's organization.
3. Controlling - Metrics are used to status and track software development activities for compliance to plans.
4. Improving - Metrics are used as a tool for process improvement and to identify where improvement efforts should be concentrated and measure the effects of process improvement efforts.

The Product Quality Measures:

Metrics Set
The metrics to be collected provide indicators that track ongoing project progress, software products, and software development processes.

1. Customer satisfaction index
2. Delivered defect quantities
3. Responsiveness (turnaround time) to users
4. Product volatility
5. Defect ratios
6. Defect removal efficiency
7. Complexity of delivered product
8. Test coverage
9. Cost of defects,
10. Costs of quality activities
11. Re-work
12. Reliability and Metrics for Evaluating Application System Testing

1. Customer satisfaction index
This index is surveyed before product delivery and after product delivery
(and on-going on a periodic basis, using standard questionnaires).The following are analyzed:
• Number of system enhancement requests per year
• Number of maintenance fix requests per year
• User friendliness: call volume to customer service hotline
• User friendliness: training time per new user
• Number of product recalls or fix releases (software vendors)
• Number of production re-runs (in-house information systems groups)

2. Delivered defect quantities
They are normalized per function point (or per LOC) at product delivery (first 3 months or first year of operation) or Ongoing (per year of operation) by level of severity, by category or cause, e.g.: requirements defect, design defect, code defect, documentation/on-line help defect, defect introduced by fixes, etc.

3. Responsiveness (turnaround time) to users
• Turnaround time for defect fixes, by level of severity
• Time for minor vs. major enhancements; actual vs. planned elapsed time

4. Product volatility
• Ratio of maintenance fixes (to repair the system & bring it into compliance with specifications), vs. enhancement requests (requests by users to enhance or change functionality)

5. Defect ratios
• Defects found after product delivery per function point.
• Defects found after product delivery per LOC
• Pre-delivery defects: annual post-delivery defects
• Defects per function point of the system modifications

6. Defect removal efficiency
• Number of post-release defects (found by clients in field operation), categorized by level of severity
• Ratio of defects found internally prior to release (via inspections and testing), as a percentage of all defects
• All defects include defects found internally plus externally (by customers) in the first year after product delivery

7. Complexity of delivered product
• McCabe's cyclomatic complexity counts across the system
• Halstead’s measure
• Card's design complexity measures
• Predicted defects and maintenance costs, based on complexity measures

8. Test coverage
• Breadth of functional coverage
• Percentage of paths, branches or conditions that were actually tested
• Percentage by criticality level: perceived level of risk of paths
• The ratio of the number of detected faults to the number of predicted faults.

9. Cost of defects
• Business losses per defect that occurs during operation
• Business interruption costs; costs of work-arounds
• Lost sales and lost goodwill
• Litigation costs resulting from defects
• Annual maintenance cost (per function point)
• Annual operating cost (per function point)
• Measurable damage to your boss's career

10. Costs of quality activities
• Costs of reviews, inspections and preventive measures
• Costs of test planning and preparation
• Costs of test execution, defect tracking, version and change control
• Costs of diagnostics, debugging and fixing
• Costs of tools and tool support
• Costs of test case library maintenance
• Costs of testing & QA education associated with the product
• Costs of monitoring and oversight by the QA organization (if separate from the development and test organizations)

11. Re-work
• Re-work effort (hours, as a percentage of the original coding hours)
• Re-worked LOC (source lines of code, as a percentage of the total delivered LOC)
• Re-worked software components (as a percentage of the total delivered components)

12. Reliability
• Availability (percentage of time a system is available, versus the time the system is needed to be available)
• Mean time between failure (MTBF).
• Man time to repair (MTTR)
• Reliability ratio (MTBF / MTTR)
• Number of product recalls or fix releases
• Number of production re-runs as a ratio of production runs

Metrics for Evaluating Application System Testing:

Metric = Formula
Test Coverage = Number of units (KLOC/FP) tested / total size of the system. (LOC represents Lines of Code)
Number of tests per unit size = Number of test cases per KLOC/FP (LOC represents Lines of Code).
Acceptance criteria tested = Acceptance criteria tested / total acceptance criteria
Defects per size = Defects detected / system size
Test cost (in %) = Cost of testing / total cost *100
Cost to locate defect = Cost of testing / the number of defects located
Achieving Budget = Actual cost of testing / Budgeted cost of testing
Defects detected in testing = Defects detected in testing / total system defects
Defects detected in production = Defects detected in production/system size
Quality of Testing = No of defects found during Testing/(No of defects found during testing + No of acceptance defects found after delivery) *100
Effectiveness of testing to business = Loss due to problems / total resources processed by the system.
System complaints = Number of third party complaints / number of transactions processed
Scale of Ten = Assessment of testing by giving rating in scale of 1 to 10
Source Code Analysis = Number of source code statements changed / total number of tests.
Effort Productivity = Test Planning Productivity = No of Test cases designed / Actual Effort for Design and Documentation
Test Execution Productivity = No of Test cycles executed / Actual Effort for testing

Verification and Validation

2007-09-21T16:15:00.000+05:30

Verification:

The standard definition of Verification is: "Are we building the product RIGHT?"

Verification is a process that makes it sure that the software product is developed the right way. The software should confirm to its predefined specifications, as the product development goes through different stages, an analysis is done to ensure that all required specifications are met.

During the Verification, the work product is reviewed/examined personally by one ore more persons in order to find and point out the defects in it. This process helps in prevention of potential bugs, which may cause in failure of the project.

Validation:

Validation is a process of finding out if the product being built is right?

Whatever the software product is being developed, it should do what the user expects it to do. The software product should functionally do what it is supposed to, it should satisfy all the functional requirements set by the user. Validation is done during or at the end of the development process in order to determine whether the product satisfies specified requirements.

All types of testing methods are basically carried out during the Validation process. Test plan, test suits and test cases are developed, which are used during the various phases of Validation process. The phases involved in Validation process are: Code Validation/Testing, Integration Validation/Integration Testing, Functional Validation/Functional Testing, and System/User Acceptance Testing/Validation.

Activities included in Verification and Validation Process:

The two major V&V activities are reviews, including, inspections and walkthroughs, and testing.

Reviews:
Reviews are conducted during and at the end of each phase of the life cycle to determine whether established requirements, design concepts, and specifications have been met. Reviews consist of the presentation of material to a review board or panel. Reviews are most effective when conducted by personnel who have not been directly involved in the development of the software being reviewed.

Inspection:
Inspection involves a team of about 3-6 people, led by a leader, which formally reviews the documents and work product during various phases of the product development life cycle. The work product and related documents are presented in front of the inspection team, the members of which carry different interpretations of the presentation. The bugs that are detected during the inspection are communicated to the next level in order to take care of them.

Walkthroughs:
Walkthrough can be considered same as inspection without formal preparation (of any presentation or documentations). During the walkthrough meeting, the presenter/author introduces the material to all the participants in order to make them familiar with it. Even when the walkthroughs can help in finding potential bugs, they are used for knowledge sharing or communication purpose.

Testing:
Testing is the operation of the software with real or simulated inputs to demonstrate that a product satisfies its requirements and, if it does not, to identify the specific differences between expected and actual results. There are varied levels of software tests, ranging from unit or element testing through integration testing and performance testing, up to software system and acceptance tests.

White Box Testing

2007-09-14T14:53:00.000+05:30

White Box Testing; also know as glass box testing is a testing method where the tester involves in testing the individual software programs using tools, standards etc.

Using white box testing methods, we can derive test cases that:
1) Guarantee that all independent paths within a module have been exercised at least once,
2) Exercise all logical decisions on their true and false sides,
3) Execute all loops at their boundaries and within their operational bounds, and
4) Exercise internal data structures to ensure their validity.

Advantages of White box testing:
1) Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed.
2) Often, a logical path is not likely to be executed when, in fact, it may be executed on a regular basis.
3) Typographical errors are random.

White Box Testing Types
There are various types of White Box Testing. Here in this framework I will address the most common and important types.

1. Basis Path Testing
Basis path testing is a white box testing technique first proposed by Tom McCabe. The Basis path method enables to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Test Cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.

2. Flow Graph Notation
The flow graph depicts logical control flow using a diagrammatic notation. Each structured construct has a corresponding flow graph symbol.

3. Cyclomatic Complexity
Cyclomatic complexity is software metric that provides a quantitative measure of the logical complexity of a program. When used in the context of a basis path testing method, the value computed for Cyclomatic complexity defines the number for independent paths in the basis set of a program and provides us with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once.
An independent path is any path through the program that introduces at least one new set of processing statements or a new condition.

Computing Cyclomatic Complexity
Cyclomatic complexity has a foundation in graph theory and provides us with extremely useful software metric. Complexity is computed in one of the three ways:

The number of regions of the flow graph corresponds to the Cyclomatic complexity.
Cyclomatic complexity, V(G), for a flow graph, G is defined as V (G) = E-N+2; Where E, is the number of flow graph edges, N is the number of flow graph nodes.
Cyclomatic complexity, V (G) for a flow graph, G is also defined as V (G) = P+1; P is the number of predicate nodes contained in the flow graph G.

4. Graph Matrices
The procedure for deriving the flow graph and even determining a set of basis paths is amenable to mechanization. To develop a software tool that assists in basis path testing, a data structure, called a graph matrix can be quite useful.
A Graph Matrix is a square matrix whose size is equal to the number of nodes on the flow graph. Each row and column corresponds to an identified node, and matrix entries correspond to connections between nodes.

5. Control Structure Testing
Described below are some of the variations of Control Structure Testing.

5.1 Condition Testing
Condition testing is a test case design method that exercises the logical conditions contained in a program module.

5.2 Data Flow Testing
The data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program.

6. Loop Testing
Loop Testing is a white box testing technique that focuses exclusively on the validity of loop constructs. Four classes of loops can be defined: Simple loops, Concatenated loops, nested loops, and unstructured loops.

6.1 Simple Loops
The following sets of tests can be applied to simple loops, where ‘n’ is the maximum number of allowable passes through the loop.

Skip the loop entirely.
Only one pass through the loop.
Two passes through the loop.
‘m’ passes through the loop where m
n-1, n, n+1 passes through the loop.

6.2 Nested Loops
If we extend the test approach for simple loops to nested loops, the number of possible tests would grow geometrically as the level of nesting increases.

Start at the innermost loop. Set all other loops to minimum values.
Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter values. Add other tests for out-of-range or exclude values.
Work outward, conducting tests for the next loop, but keeping all other outer loops at minimum values and other nested loops to “typical” values.
Continue until all loops have been tested.

6.3 Concatenated Loops
Concatenated loops can be tested using the approach defined for simple loops, if each of the loops is independent of the other. However, if two loops are concatenated and the loop counter for loop 1 is used as the initial value for loop 2, then the loops are not independent.

6.4 Unstructured Loops
Whenever possible, this class of loops should be redesigned to reflect the use of the structured programming constructs.

Software Metrics for Testing

2007-09-13T17:18:00.000+05:30

Software metric is a measure of some property of a piece of software or its specifications.
Since quantitative methods have proved so powerful in the other sciences, computer science practitioners and theoreticians have worked hard to bring similar approaches to software development.

Common software metrics include:

Order of growth (See Analysis of algorithms in terms of asymptotic analysis and Big O notation)
Source lines of code
Cyclomatic complexity
Function point analysis
Bugs per line of code
Code coverage
Number of lines of customer requirements
Number of classes and interfaces
Robert Cecil Martin’s software package metrics
Cohesion
Coupling

Types of Metrics for Testing

Base Metrics

Base metrics constitute the raw data gathered by a Test Analyst throughout the testing effort. These metrics are used to provide project status reports to the Test Lead and Project Manager; they also feed into the formulas used to derive Calculated Metrics. Every project should track the following Test Metrics:

Number of Test Cases
Number of Test Cases Executed
Number of Test Cases Passed
Number of Test Cases Failed
Number of Test Cases Under Investigation
Number of Test Cases Blocked
Number of Test Cases Re-executed
Number of First Run Failures
Total Executions
Total Passes
Total Failures
Test Case Execution Time
Test Execution Time

As seen in the ‘Keep It Simple’ section, many of the Base Metrics are simple counts that most Test Analysts already track in one form or another. While there are other Base Metrics that could be tracked, this list is sufficient for most Test Teams that are starting a Test Metrics program.

Use all available information when interpreting the metrics gathered, including other metrics and in-tangible information that may not be quantifiable. Also, when available, compare the metrics across several projects
Calculated Metrics

Calculated Metrics convert the Base Metrics data into more useful information. These types of metrics are generally the responsibility of the Test Lead and can be tracked at many different levels (by module, tester, or project). The following Calculated Metrics are recommended for implementation in all test efforts:

Percentage - Complete
Percentage - Test Coverage
Percentage - Test Cases Passed
Percentage - Test Cases Blocked
Run Fail Rate
Fail Rate
Percentage - Defects Corrected
Percentage - Rework
Percentage - Test Effectiveness
Percentage - Test Efficiency
Discovery Rate
Removal Cost

These metrics provide valuable information that, when used and interpreted, oftentimes leads to significant improvements in the overall SDLC. If a metric like “First Run Fail Rate” has a high value, it may be indicative of a lack of unit testing or code peer review during the coding phase. With this information, as well as any other relevant information available to the Project Team, the Project Team may decide to institute some preventative QA techniques that they believe will improve the process. Of course, in the next project, when the metric is observed it should be noted how it has trended to see if the process change was in fact an improvement.
Calculated metrics use the base data to develop more useful information for doing metrics analysis and identifying potential SDLC process improvements.

TOOL - Lateralus Lyrics

2007-09-06T10:05:00.000+05:30

Black then white are all i see in my infancy.
red and yellow then came to be, reaching out to me.
lets me see.
as below, so above and beyond, I imagine
drawn beyond the lines of reason.
Push the envelope. Watch it bend.

Over thinking, over analyzing separates the body from the mind.
Withering my intuition, missing opportunities and I must
Feed my will to feel my moment drawing way outside the lines.

Black then white are all i see in my infancy.
red and yellow then came to be, reaching out to me.
lets me see there is so much more and
beckons me to look thru to these infinite possibilities.
as below, so above and beyond, I imagine
drawn outside the lines of reason.
Push the envelope. Watch it bend.

over thinking, over analyzing separates the body from the mind.
Withering my intuition leaving opportunities behind.
Feed my will to feel this moment urging me to cross the line.
Reaching out to embrace the random.
Reaching out to embrace whatever may come.

I embrace my desire to
I embrace my desire to
feel the rhythm, to feel connected enough to step aside and weep like a widow
to feel inspired to fathom the power, to witness the beauty,
to bathe in the fountain,
to swing on the spiral
to swing on the spiral
to swing on the spiral of our divinity and still be a human.

With my feet upon the ground I move myself between the sounds and open wide to suck it in.
I feel it move across my skin.
I'm reaching up and reaching out. I'm reaching for the random or what ever will bewilder me.
what ever will bewilder me.
And following our will and wind we may just go where no one's been.
We'll ride the spiral to the end and may just go where no one's been.

Spiral out. Keep going.
Spiral out. Keep going.
Spiral out. Keep going.
Spiral out. Keep going.
Spiral out. Keep going.

TestComplete

2007-08-31T15:41:00.000+05:30

Today automated testing plays a vital role in many software development projects. AutomatedQA's Test Complete is an automated test manager, with project level support for the full range of internal and UI testing. Designed for developers and testers.

It delivers automated functional, unit, regression, manual, data-driven, object-driven, distributed and HTTP load, stress and scalability testing in one easy-to-use.

TestComplete offers systematic, automated, and structured testing, with superior support for .NET, Java, Visual C++, Visual Basic, Delphi, C++Builder and web applications.

First Tank of World War 1

2007-08-31T12:27:00.000+05:30

In 1916 tanks were first introduced into battle - before that armored cars were being used, which had none of the off-road capabilities of the tanks. It was the 15th of September, 1916, that the first British tanks were used in battle. The reasons they were used at this time were basically because of lots of testing, to make sure it would work, and also the fact that attack at the Somme was losing the power to keep going.

The tanks had been successful in the regard that they had scared the Germans, and they had not been disabled immediately, however some were disappointed. Concerns raised included the view slits - they were too thin to be able to see much while moving, and they were targets for enemy gunshot; and the exhaust - it made too much noise and the heat could have set alit the fuel tank. Another issue raised was the amount of mud that got into the treads and blocked them up.

he first French use of tanks was on April 16, 1917, and went much worse than the English attack. While there were more tanks involved, many of them broke down, and those that did reach the enemy lines had no support. This resulted in them having to retreat again. Problems discovered here included the temperature - way too hot for any human to operate safely, as well as the vibrations - guns came out of their holdings. The French tanks also didn't have the ability to cross trenches as the British one could. Another problem (or success from the Germans point of view), was the discovery that the armor piercing bullet could go through the walls of tanks.

During World War I (1914-1918) the British invented and implemented the first working tank. The name tank came when the British shipped them to battle's in crates marked "tanks" trying to cover up what they really were. The first battle in which tanks were implemented was the Battle of the Somme, on September 15, 1916, when the British used 49 tanks with disappointing results. Little more than a year later, however, in November 1917, 400 British tanks penetrated German lines near Cambrai, capturing 8000 of the enemy and 100 guns.

Testing Jokes

2007-08-24T13:34:00.000+05:30

Two software testers at Dinner

Two software testers went into a diner and ordered two drinks. Then they produced sandwiches from their briefcases and started to eat. The owner became quite concerned and marched over and told them, "You can't eat your own sandwiches in here!"

The testers looked at each other, shrugged their shoulders and then exchanged sandwiches.

How Specs Live Forever

The Question

The US Standard railroad gauge (distance between the rails) is 4 feet, 8.5 inches. That's an exceedingly odd number.

o Why was that gauge used?

· Because that's the way they built them in England, and the US railroads were built by English expatriates.

o Why did the English people build them like that?

· Because the first rail lines were built by the same people who built the pre-railroad tramways, and that's the gauge they used.

o Why did "they" use that gauge then?

· Because the people who built the tramways used the same jigs and tools that they used for building wagons, which used that wheel spacing.

o Why did the wagons use that odd wheel spacing?

· Well, if they tried to use any other spacing the wagons would break on some of the old, long distance roads, because that's the spacing of the old wheel ruts.

o So who built these old rutted roads?

· The first long distance roads in Europe were built by Imperial Rome for the benefit of their legions. The roads have been used ever since. And the ruts? The initial ruts, which everyone else had to match for fear of destroying their wagons, were first made by Roman war chariots. Since the chariots were made for or by Imperial Rome they were all alike in the matter of wheel spacing.

The Answer

Thus, we have the answer to the original questions. The United States' standard railroad gauge of 4 feet, 8.5 inches derives from the original specification for an Imperial Roman army war chariot.

Specs and Bureaucracies live forever.

So, the next time you are handed a specification and wonder what horse's ass came up with it, you may be exactly right. Because the Imperial Roman chariots were made to be just wide enough to accommodate the back-ends of two war horses.

TOOL

2007-08-23T09:39:00.000+05:30

Tool is an American rock band, formed during 1990 in Los Angeles, California, that consists of drummer Danny Carey, bassist Justin Chancellor, guitarist Adam Jones, and vocalist Maynard James Keenan.

Emerging with a heavy metal sound on their first release, when the genre was dominated by thrash metal, they were later seen at the top of the alternative metal movement with the release of their second full-length studio album Ænima in 1996.

After an ongoing evolution of their sound and continuous efforts to unify musical experimentation, visual arts, and a message of personal evolution on Lateralus (2001), their most recent album 10,000 Days (2006), as well as respective tours, they are generally described as a style-transgressing act and part of progressive and art rock.

Relatively long and complex releases, controversial song lyrics and cover art, and their unorthodox music videos resulted in a rather ambivalent relationship between the band and today's music industry, at times marked by censorship, and the bandmembers' insistence on privacy.

Nevertheless, Tool receives critical acclaim, has won Grammy Awards, performs worldwide tours, and

produces albums that top the charts in several countries.

Between album releases, the band takes extended breaks that allow for collaboration with other artists to design award-winning album packaging, elaborate light shows and involvement in notable side-projects.

Origin: Los Angeles, California, United States

Genre(s): Progressive metal, Art rock, Alternative metal, Progressive rock

Website: http://www.Toolband.com

Cookies - I love Cookies

2007-08-22T14:00:00.000+05:30

What is a Cookie?
A cookie is a text-only string that gets entered into the memory of your browser. This value of a variable that a website sets; If the lifetime of this value is set to be longer than the time you spend at that site, then this string is saved to file for future reference.

Why do sites use Cookies?
There are many reasons a given site would wish to use cookies. These range from the ability to personalize information (like on My Yahoo or Excite), or to help with on-line sales/services (like on Amazon Books or eBay), or simply for the purposes of collecting demographic information (like DoubleClick). Cookies also provide programmers with a quick and convenient means of keeping site content fresh and relevant to the user's interests. The newest servers use cookies to help with back-end interaction as well, which can improve the utility of a site by being able to securely store any personal data that the user has shared with a site (for example: to help with quick logins on your favorite sites).

How does a cookie really work?
Understanding how cookies really work requires an understanding of how HTTP works. Cookies transport from Server to Client and back as an HTTP header.

When a cookie is sent from the server to the browser, an additional line is added to the HTTP headers (example):
Content-type: text/html
Set-Cookie: foo=bar; path=/; expires Mon, 09-Dec-2002 13:46:00 GMT
This header entry would result in a cookie named foo. The value of foo is bar. In addition, this cookie has a path of /, meaning that it is valid for the entire site, and it has an expiration date of Dec 9, 2002 at 1:46pm Greenwich Mean Time (or Universal Time). Provided the browser can understand this header, the cookie will be set.

When a cookie is sent from the browser to the server, the cookie header is changed slightly:
Content-type: text/html
Cookie: foo=bar
Here, the server is made aware of a cookie called foo, whose value is bar.

Breakdown of Cookie Parameters
As we have just seen, a cookie contains more than simply a name and a value. In fact, a cookie has 6 parameters that can be passed to it:
• The name of the cookie,
• The value of the cookie,
• The expiration date of the cookie,
• The path the cookie is valid for,
• The domain the cookie is valid for,
• The need for a secure connection to exist to use the cookie.

Two of these are mandatory (its name and its value). The other four can be set manually or automatically. Each parameter is separated by a semicolon when set explicitly. Here is a detailed description of each.

Name, Value

The name of a cookie and its value are set simply by pairing them together:
... foo=bar ...
The value of a cookie can also be null, for the purpose of clearing the cookie value:
... foo= ...

Expires
The expires parameter lets you determine the lifetime of the cookie.
... expires=Mon, 01-Jan-2001 00:00:00 GMT ...
If Expires is not set explicitly, then it defaults to end-of-session. The length of a session can vary depending on browsers and servers, but generally a session is the length of time that the browser is open for (even if the user is no longer at that site).

Path
The path parameter is potentially the most useful of the 4 optional cookie settings. It sets the URL path the cookie is valid within. Pages outside of that path cannot read or use the cookie.
... path=/promo ...
If Path is not set explicitly, then it defaults to the URL path of the document creating the cookie.

Netscape has identified a bug for VERY old versions of Navigator where the path must be specified if an expiration is specified. Furthermore, this path must be set to "/". For more information, browse Netscape's Cookie Spec at:
http://www.netscape.com/newsref/std/cookie_spec.html

Domain
The domain parameter takes the flexibility of the path parameter one step further. If a site uses multiple servers within a domain the it is important to make the cookie accessible to pages on any of these servers.
... domain=www.myserver.com ...
Cookies can be assigned to individual machines, or to an entire Internet domain. The only restrictions on this value is that it must contain at least two dots (.myserver.com, not myserver.com) for the normal top-level domains, or three dots for the "extended" domains (.myserver.ny.us, not myserver.ny.us)

IMPORTANT: The server issuing the cookie must be a member of the domain that it tries to set in the cookie. That is, a server called www.myserver.com cannot set a cookie for the domain www.yourserver.com. The security implications should be obvious.

If Domain is not set explicitly, then it defaults to the full domain of the document creating the cookie.

Secure

The secure parameter is a flag indicating that a cookie should only be used under a secure server condition, such as SSL. Since most sites do not require secure connections, this defaults to FALSE.

What are all those entries in my cookies.txt file?
The layout of Netscape's cookies.txt file is such that each line contains one name-value pair. An example cookies.txt file may have an entry that looks like this:
.netscape.com TRUE / FALSE 946684799 NETSCAPE_ID 100103
Each line represents a single piece of stored information. A tab is inserted between each of the fields.

From left-to-right, here is what each field represents:

domain - The domain that created AND that can read the variable.
flag - A TRUE/FALSE value indicating if all machines within a given domain can access the variable. This value is set automatically by the browser, depending on the value you set for domain.
path - The path within the domain that the variable is valid for.
secure - A TRUE/FALSE value indicating if a secure connection with the domain is needed to access the variable.
expiration - The UNIX time that the variable will expire on. UNIX time is defined as the number of seconds since Jan 1, 1970 00:00:00 GMT.
name - The name of the variable.
value - The value of the variable.

Creating a Cookie Value
Creating a cookie generally involves duplicating the HTTP cookie header in some fashion so that the browser will store the name-value pair in memory. Some languages expect an exact HTTP header to be sent, while others will use built-in functions to help you speed the process along.

Cookies can be set from the browser-side or from the server-side. The determining factor will be the language you use to create the cookie. Once the cookie is created, it should flow easily from server to client and back via the HTTP headers.

There are limits on the contents of both the cookie string and the cookie file. These limits are partially imposed by HTTP and partially by arbitrary choice. They are as follows:
You CANNOT set Cookies for domains other than those that your response originates from. That is, a page on www.myserver.com can set a Cookie for myserver.com and www.myserver.com, but NOT www.yourserver.com.
The cookie HTTP header must be no more than 4K in size.
Note that this applies to cookies while they are in memory or stored in the cookies.txt file.

Retrieving a Cookie Value
For the most part, retrieving cookies does not require reading the HTTP Cookie: header. Most languages read this header for you and make it accessible through a variable or object.

Cookies can be read on the browser side or the server side. Again, the determining factor is the language used.

The main limit on retrieving a cookie is that you can only retrieve cookies that are valid for the document your script resides in. That is, a script on www.myserver.com cannot read cookies from www.yourserver.com. This is also true for subdirectories within your site. A cookie valid for /dirOne cannot be read by a script in /dirTwo. This is mainly governed on the browser side, as browsers know the URL that they are accessing, and only transmit cookies for that server across the connection.

Clearing a Cookie Value
When programming a Web site, there are many reasons that you may need to erase a cookie you have created. Often it is because the cookie is no longer needed, or the scheme of your cookie has been altered, and requires resetting.

The two main steps to clearing a cookie you have created are:
Set the cookie's value to null.
Set the cookie's expiration date to some time in the past.
The reason you must do both is that simply setting the expiration to a past time will not change it's value until the browser is closed. That is, all cookie names, values, expirations, etc are resolved once the browser program has been closed. Setting the cookie to null allows you to properly test for the cookie until that resolution.

Differences between Methodology, Techniques, and Tools

2007-08-22T12:35:00.000+05:30

The differences between Methodology, Techniques, and Tools can be explained by using a cooking analogy.

Let's say you want to make Green Curry Chicken. Not being from Thailand, you have no idea how to make Green Curry Chicken, so you go find a recipe for it. Think of the recipe as your methodology. If you follow the methodology, you have a good chance of ending up with Green Curry Chicken. If you don't follow the methodology and you have no prior experience in this, you might just end up with green chicken. In project management terms, this would be a failed project.

Now, as you follow your recipe/methodology, you will no doubt employ some tools. You will need a tool capable of producing enough heat to cook with such as a stove or fire. You will also need a pot and cooking utensils. Think of these things as tools that you employ. Without tools, you can't get the job done.

And as you follow your recipe/methodology and use your tools, you will come across techniques. Such as, you can use 2 cans of coconut milk or alternatively you can use 1 can of coconut cream and 1 can of water. Or another technique might be; reduce the hot chili peppers recipe amount by half when preparing Green Curry Chicken for those who can't take food too spicy. Think of techniques as suggestions that can be useful to help ensure success of the project.

Woh Jiski Deed Mein, Abida Parveen

2006-12-20T12:33:00.000+05:30

Woh jiski deed mein laakhoun masarratein pinhaan
Woh husn jiski tamanna mein jannat pinhaan

Hazaar fitney tah-e-paa-e-naaz khaak-e-nasheen
Har eik nigaah khumar-e-shabaab se rangeen

Shabaab jis se takhaiyul pe bijliyaan barsein
Waqaar jiski rafaqat kou shokhiyaan tarsey

Ada-e-laghzisheiy paa par qyamatein qurbaan
Bayaz-e-rukh sey sahar ki sabahatein qurbaan

Siyaah zulfoun mein badaaon sa nikhatoun ka hujoom
Taweel raatoun ki khwabeedah raahatoun ka hujoom

Vo aankh jiski banaun pe khaliq dey raae
Zabaan shair kou tareef kartey sharmaae

Gudaaz jism qaba jispe saj ke naaz karey
Daraaz qad jisey sarw-e-sahi namaz karey

Kisi zamaney mein is rah-guzar sey guzraa thaa
Ba-sad guroor-o-tajammul idhar sey guzraa thaa

Aur ab ye raah guzar bhi hai dilfareb-o-haseen
Hai uski khaak mein kaife sharab-e-sair makeen

Hawa mein shokhi-e-raftaar ki addaen hain
Faza mein narmi-e-guftaar ki sadaen hain

Garaz vo husn is raah ka juzu-e-manzar hai
Neyaaz-e-ishq kou eik sajda gaah maiyassar hai

Tool

2006-12-19T15:00:00.000+05:30

Someone told me once

that there's a right and wrong,

and that punishment

would come to those

who dare to cross the line.