Test Management with QaTraq Pro

The Software and Hardware Test Management Solution

QaTraq Professional is one of the leading test case management tools available today. QaTraq Professional provides test teams all over the world with the tools they need to ensure they make the most of their test resources. By encouraging a structured approach to test management QaTraq Professional will help you increase productivity, improve visibility of your test progress and, ultimately, help you improve the quality of your product releases.

Centralised Test Information, Accessible Anywhere at Anytime

QaTraq Professional provides a single, central repository for critical test information and data for your whole team. With QaTraq Professional, remote and office based users can access, update and share centralised data in real time through a web browser (removing the need for the deployment of client software throughout an organisation).



Key QaTraq Professional Features QaTraq Professional provides you with extensive control over your test process. When you purchase the QaTraq Professional licences just some of the capabilities you gain are:

Test Scripts:
One of the key challenges for any test team is controlling and tracking the development of test scripts. How, for example, do you know when a test script is complete, reviewed and ready to run? Test Scripts and Test Script Templates allow you to divide your scripts into those that are still being developed and those that are ready to run. Furthermore you can even implement a test script review process for your team. All of this adds up to far more control and increased repeatability across your test process. Control and repeatability that is essential to the success of any test project.

Sets:
With QaTraq Professional regression test sets you can quickly create sets of regression test scripts that can be, quickly and easily, distributed across your team. Sets are neatly linked in with Template Test Scripts so that only Templates that are ready for execution are distributed. Regression sets of test scripts can be built up from existing test scripts or created with links to templates. Either way you get complete control over who’s running which scripts, on which platforms for which versions of your software or hardware.

Reports:
Professional Reports provide you with graphical reporting capabilities covering everything from identifying test coverage to tracking test completion status. This gives you the visibility needed to see exactly how your test projects are progressing.


Collating your Test Data to Pin Point Progress If you are searching for answers to some of the questions set out below, then perhaps now is the time to consider the capabilities and benefits of QaTraq Professional.

• How are we progressing with the development of our test scripts/cases?
• What does our current test case coverage look like?
• Which high priority test cases should we be running first?
• How do the test results, from the previous and current builds, compare?
• Who wrote and who reviewed each test script?
• How are we dealing with our regression testing responsibilities?
• Are we prepared for compliance audits (e.g. Sarbanes-Oxley)?

Managing the Test Process with QaTraq Professional

QaTraq Professional provides the foundation for test teams to create and update test scripts, test cases and test results. QaTraq Professional provides you with instant access to graphical reports, test script templating and other key functions. This all improves visibility of your testing and helps pin-point test case execution progress. Simple server installation, along with the web based user interface, means that your test team members have access to a central repository of test data wherever they might be working.


Key Benefits

• Improve repeatability of test runs
• Implement a test script review process
• Create a formal release mechanism
• Create reusable regression test script sets
• Create and release multiple test scripts in one easy step
• Import and Export Excel, Pdf or XML formated test cases
• Use advanced Html editing facilities to edit documents
• Over 30 key graphical test management reports

QaTraq Professional Capability List:

• Create and manage thousands of test cases.
• Link test cases to products and components under test.
• Create test scripts from test cases along with their associated result records.
• Define priorities for individual test cases within test scripts.
• Group test scripts along with test design information.
• Link all test scripts to your centrally stored Test Plans.
• Assign test scripts to multiple users for test runs.
• Attach results files, such as screen shots and test result data, to test result records.
• Track linked document versions with ease.
• Divide test scripts into those still under development, those ready for review and those ready for execution.
  
• Where necessary enforce a test script review process.
  
• Neatly link marked templates in Sets ready for execution.
  
• Group test scripts into Sets for ease of management.
  
• Deploy multiple test scripts across your team for different platforms and versions of your software/hardware.
  
• View over 30 graphical test management reports
  
• Advanced Html editing.
  
• Import test cases in XML or Excel format.
  
• Export test plans in XML, Excel or Pdf format.
  
• Report on actual and estimated time to complete test runs
  

SQL FAQs

Questions & Answers

1. What do you understand by client-server concept?

A. A software component that services requests from another software component is called a server. The component making the requests is the client.

The idea of client/server programming is to maximize the benefits of the desktop. The client and server can be present on the same computer or on geographically distant computer connected over a network . Some of the benefits of C/s computing are :

Flexibility, scalability and cost savings in terms of resource utilization and centralized control.

2. What is meant by 3-Tier architecture?

A. 3 Tier architecture is a method of deploying the client/server technology in real –world situations. The 3 tiers are :

· GUI front-end - Takes care of the end-user interaction and validation of input

data

· Business logic layer - It encapsulates the business processing logic for the data

entered by the user or the data to be processed and given as output to the user. It can be implemented as a collection of reusable and upgradable software components .

· Data-processing layer - It takes care of the data processing , storage and

retrieval of the stored data.

3. What are the advantages of 3-Tier architecture over 2-Tier architecture?

A. In 2-tier architecture we only have the application layer and the data-processing layer.

The application layer is a combination of the GUI front-end and the business logic.

The following are the disadvantages of the 2-tier architecture (which in turn are the advantages of 3-tier over 2-tier ) :

· The application is not easily upgradable.

· The size of the application is large.

3-tier arch. Provides :

· Maximum performance

· Security

· Ease of maintenance.

4. What do normalization and Denormalization mean?

Normalization is the process of simplifying the relationship between data elements in a data structure .

OR

The task of the database designer is to structure the data in a way that eliminates unnecessary duplication and provides a rapid search path to all necessary information. The process of dividing the information into separate tables that meet these goals is called Normalization.

Denormalization is the reverse process of normalization wherein the normalized data is merged to form a larger data structure that might have redundant data.

5. What are the different degrees of normalization?

A. A relation is in 1st Normal form if and only if all underlying domains contain atomic values only.

A relation is in 2nd normal form if and only if it is in 1NF and every nonkey attribute is fully dependent on the primary key.

A relation is in 3rd Normal form if and only if it is in 2NF and every nonkey attribute is nontransitively dependent on the primary key.

A relation R in 4th normal form if and only if , whenever there exists a multi-valued dependency in R, say A ->-> B (attribute B is multi-dependant on attribute A), then all attributes of R are also functionally dependent on A .

A relation R is said to be in fifth normal form also called Projection Join Normal form (PJNF) if and only if every join dependency in R is implied by the candidate keys of R.

6. Do you know ODBC?

A. ODBC is Open-database Connectivity. It provides access to any database which has a

ODBC database driver .

The database can be a client/server database that conform to ODBC standards

eg. SQL Server , Oracle etc.

An ODBC driver-manager provides an interface from the host language to the specific

Back-end data source driver. The driver manager is responsible for :

· Loading the remote database drivers specified in the DSN entry

· Initializing the interface

· Providing entry points to driver entry points

· Validating parameters and managing serialization of ODBC functions

ODBC driver is a DLL that can interface with a specific back-end database engine

Eg. MS-SQL server , Oracle , sybase etc.

An ODBC driver takes advantage of specific back-end features such as cursors or parameterized queries . It can also implement some other features not supported by the back-end. If the driver doesn’t support a specific feature it returns an error stating that it doesn’t support the feature .

7. What are the factors that influence ODBC response time ?

A. The main factors that influence the ODBC response time are :

· Network load

· The complexity of the SQL queries

· The speed of the machine on which the server executes

· The RAM of the machine on which the server executes

· The number of records that are likely to be returned as result of the query.

· The physical location of the database and number of connections to database

8. In how many ways can VB implement ODBC ?

A. VB can implement ODBC in the following ways :

· Using Data control and connecting to a database like SQL Server , Oracle

· Using DAO objects and using the dbUseODBC parameter in the CreateWorkspace methods ie. Using ODBC Direct

· Using Remote Data Control

· Using Remote Data Objects

· Using ODBC API calls

9. What is OOPS ?

A. OOPS is Object Oriented Programming. The main features of OOPS are :

Data hiding & encapsulation

Polymorphism

Inheritance

Data Abstraction

The advantages of OOPS over structured programming are :

· Data hiding

· Code reusability

· Lower costs in building systems

· Flexibility

10. How VB 5.0 implements OOPS ?

A. VB implements OOPS concepts in the following ways :

· Data hiding is implemented using the “Public , Private scoping keywords “

· Polymorphism is implemented using the “Implements “ , ParamArray , Optional keywords

· Inheritance is implemented in the sense of interface inheritance and not implementation inheritance (ie. Not like C++ inheritance)

Aptitude Questions Answers Vol - 1

Q. If 2x-y=4 then 6x-3y=?
(a)15
(b)12
(c)18
(d)10
Ans. (b)


Q. If x=y=2z and xyz=256 then what is the value of x?
(a)12
(b)8
(c)16
(d)6
Ans. (b)


Q. (1/10)18 - (1/10)20 = ?
(a) 99/1020
(b) 99/10
(c) 0.9
(d) none of these
Ans. (a)


Q. Pipe A can fill in 20 minutes and Pipe B in 30 mins and Pipe C can empty the same in 40 mins.If all of them work together, find the time taken to fill the tank
(a) 17 1/7 mins
(b) 20 mins
(c) 8 mins
(d) none of these
Ans. (a)


Q. Thirty men take 20 days to complete a job working 9 hours a day. How many hour a day should 40 men work to complete the job?
(a) 8 hrs
(b) 7 1/2 hrs
(c) 7 hrs
(d) 9 hrs
Ans. (b)


Q. Find the smallest number in a GP whose sum is 38 and product 1728
(a) 12
(b) 20
(c) 8
(d) none of these
Ans. (c)


Q. A boat travels 20 kms upstream in 6 hrs and 18 kms downstream in 4 hrs. Find the speed of the boat in still water and the speed of the water current?
(a) 1/2 kmph
(b) 7/12 kmph
(c) 5 kmph
(d) none of these
Ans. (b)


Q. A goat is tied to one corner of a square plot of side 12m by a rope 7m long. Find the area it can graze?
(a) 38.5 sq.m
(b) 155 sq.m
(c) 144 sq.m
(d) 19.25 sq.m
Ans. (a)


Q. Mr. Shah decided to walk down the escalator of a tube station. He found that if he walks down 26 steps, he requires 30 seconds to reach the bottom. However, if he steps down 34 stairs he would only require 18 seconds to get to the bottom. If the time is measured from the moment the top step begins to descend to the time he steps off the last step at the bottom, find out the height of the stair way in steps?
Ans.46 steps.


Q. The average age of 10 members of a committee is the same as it was 4 years ago, because an old member has been replaced by a young member. Find how much younger is the new member ?
Ans.40 years.

Organisational Approaches for Unit Testing

Introduction

Unit testing is the testing of individual components (units) of the software. Unit testing is
usually conducted as part of a combined code and unit test phase of the software lifecycle, although it is not uncommon for coding and unit testing to be conducted as two distinct phases. The basic units of design and code in Ada, C and C++ programs are individual subprograms (procedures, functions, member functions). Ada and C++ provide capabilities for grouping basic units together into packages (Ada) and classes (C++).
Unit testing for Ada and C++ usually tests units in the context of the containing package or class.
When developing a strategy for unit testing, there are three basic organisational approaches that can be taken. These are top down, bottom up and isolation. These three approaches are described and their advantages and disadvantages discussed in sections 2, 3, and 4 of this paper.
The concepts of test drivers and stubs are used throughout this paper. A test driver is software which executes software in order to test it, providing a framework for setting input parameters, executing the unit, and reading the output parameters. A stub is an imitation of a unit, used in place of the real unit to facilitate testing.
An AdaTEST or Cantata test script comprises a test driver and an (optional) collection of stubs. Using AdaTEST or Cantata to implement the organisational approaches to unit testing presented in this paper is discussed in section 5.

2. Top Down Testing

2.1. Description
In top down unit testing, individual units are tested by using them from the units which call them, but in isolation from the units called. The unit at the top of a hierarchy is tested first, with all called units replaced by stubs. Testing continues by replacing the stubs with the actual called units, with lower level units being stubbed. This process is repeated until the lowest level units have been tested.
Top down testing requires test stubs, but not test drivers.
Figure 2.1 illustrates the test stubs and tested units needed to test unit D, assuming that units A, B and C have already been tested in a top down approach. A unit test plan for the program shown in figure 2.1, using a strategy based on the top down organisational approach, could read as follows:
Step (1)
Test unit A, using stubs for units B, C and D.
Step (2)
Test unit B, by calling it from tested unit A, using stubs for units C and D.
Step (3)
Test unit C, by calling it from tested unit A, using tested units B and a stub for unit D.
Step (4)
Test unit D, by calling it from tested unit A, using tested unit B and C, and stubs for units E, F and G. (Shown in figure 2.1).
Step (5)
Test unit E, by calling it from tested unit D, which is called from tested unit A, using tested units B and C, and stubs for units F, G, H, I and J.
Step (6)
Test unit F, by calling it from tested unit D, which is called from tested unit A, using tested units B, C and E, and stubs for units G, H, I and J.
Step (7)
Test unit G, by calling it from tested unit D, which is called from tested unit A, using tested units B, C, E and F, and stubs for units H, I and J.
Step (8)
Test unit H, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F and G, and stubs for units I and J.
Step (9)
Test unit I, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F, G and H, and a stub for units J.
Step (10)
Test unit J, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F, G, H and I.







2.2 Advantages
Top down unit testing provides an early integration of units before the software integration phase. In fact, top down unit testing is really a combined unit test and software integration strategy.
The detailed design of units is top down, and top down unit testing implements tests in the sequence units are designed, so development time can be shortened by overlapping unit testing with the detailed design and code phases of the software lifecycle. In a conventionally structured design, where units at the top of the hierarchy provide high level functions, with units at the bottom of the hierarchy implementing details, top down unit testing will provide an early integration of 'visible' functionality. This gives a very requirements oriented approach to unit testing. Redundant functionality in lower level units will be identified by top down unit testing, because there will be no route to test it. (However, there can be some difficulty in distinguishing between redundant functionality and untested functionality).

2.3. Disadvantages
Top down unit testing is controlled by stubs, with test cases often spread across many stubs. With each unit tested, testing becomes more complicated, and consequently more expensive to develop and maintain. As testing progresses down the unit hierarchy, it also becomes more difficult to achieve
the good structural coverage which is essential for high integrity and safety critical applications, and which are required by many standards. Difficulty in achieving structural coverage can also lead to a confusion between genuinely redundant functionality and untested functionality. Testing some low level functionality, especially error handling code, can be totally impractical. Changes to a unit often impact the testing of sibling units and units below it in the hierarchy. For example, consider a change to unit D. Obviously, the unit test for unit D would have to change and be repeated. In addition, unit tests for units E, F, G, H, I and J, which use the tested unit D, would also have to be repeated. These tests may also have to change themselves, as a consequence of the change to unit D, even though units E, F, G, H, I and J had not actually changed. This leads to a high cost associated with retesting when changes are made, and a high maintenance and overall lifecycle cost.
The design of test cases for top down unit testing requires structural knowledge of when the unit under test calls other units. The sequence in which units can be tested is constrained by the hierarchy of units, with lower units having to wait for higher units to be tested, forcing a 'long and thin' unit test phase. (However, this can overlap substantially with the detailed design and code phases of the software lifecycle).
The relationships between units in the example program in figure 2.1 is much simpler than would be encountered in a real program, where units could be referenced from more than one other unit in the hierarchy. All of the disadvantages of a top down approach to unit testing are compounded by a unit being referenced from more than one other unit.

2.4. Overall
A top down strategy will cost more than an isolation based strategy, due to complexity of testing units below the top of the unit hierarchy, and the high impact of changes. The top down ganisational approach is not a good choice for unit testing. However, a top down approach to the integration of units, where the units have already been tested in isolation, can be viable.

Why Bother to Unit Testing?

1. Introduction
The quality and reliability of software is often seen as the weak link in industry's attempts to develop new products and services. The last decade has seen the issue of software quality and reliability addressed through a growing adoption of design methodologies and supporting CASE tools, to the extent that most software designers have had some training and experience in the use of
formalised software design methods. Unfortunately, the same cannot be said of software testing. Many developments applying such design methodologies are still failing to bring the quality and reliability of software under control. It is not unusual for 50% of software maintenance costs to be
attributed to fixing bugs left by the initial software development; bugs which should have been eliminated by thorough and effective software testing.
This paper addresses a question often posed by developers who are new to the concept of thorough testing: Why bother to unit test? The question is answered by adopting the position of devil's advocate, presenting some of the common arguments made against unit testing, then proceeding to show how these arguments are worthless. The case for unit testing is supported by published data.

2. What is Unit Testing?
The unit test is the lowest level of testing performed during software development, where individual units of software are tested in isolation from other parts of a program. In a conventional structured programming language, such as C, the unit to be tested is traditionally the function or sub-routine. In object oriented languages such as C++, the basic unit to be tested is the class. With Ada, developers have the choice of unit testing individual procedures and functions, or unit testing at the Ada package level. The principle of unit testing also extends to 4GL development, where the basic unit would typically be a menu or display.
Unit level testing is not just intended for one-off development use, to aid bug free coding. Unit tests have to be repeated whenever software is modified or used in a new environment. Consequently, all tests have to be maintained throughout the life of a software system. Other activities which are often associated with unit testing are code reviews, static analysis and dynamic analysis. Static analysis investigates the textual source of software, looking for problems and gathering metrics without actually compiling or executing it. Dynamic analysis looks at the behaviour of software while it is executing, to provide information such as execution traces, timing profiles, and test coverage information.

3. Some Popular Misconceptions
Having established what unit testing is, we can now proceed to play the devil's advocate. In the following subsections, some of the common arguments made against unit testing are presented, together with reasoned cases showing how these arguments are worthless.

3.1. It Consumes Too Much Time
Once code has been written, developers are often keen to get on with integrating the software, so that they can see the actual system starting to work. Activities such as unit testing may be seen to get in the way of this apparent progress, delaying the time when the real fun of debugging the overall system can start. What really happens with this approach to development is that real progress is traded for apparent progress. There is little point in having a system which “sort of” works, but
happens to be full of bugs. In practice, such an approach to development will often result
in software which will not even run. The net result is that a lot of time will be spent tracking down relatively simple bugs which are wholly contained within particular units.
Individually, such bugs may be trivial, but collectively they result in an excessive period of time integrating the software to produce a system which is unlikely to be reliable when it enters use.
In practice, properly planned unit tests consume approximately as much effort as writing the actual code. Once completed, many bugs will have been corrected and developers can proceed to a much more efficient integration, knowing that they have reliable components to begin with. Real progress has been made, so properly planned unit testing is a much more efficient use of time. Uncontrolled rambling with a debugger consumes a lot more time for less benefit. Tool support using tools such as AdaTEST and Cantata can make unit testing more efficient and effective, but is not essential. Unit testing is a worthwhile activity even without tool support.

3.2. It Only Proves That the Code Does What the Code Does
This is a common complaint of developers who jump straight into writing code, without first writing a specification for the unit. Having written the code and confronted with the task of testing it, they read the code to find out what it actually does and base their tests upon the code they have written. Of course they will prove nothing. All that such a test will show is that the compiler works. Yes, they will catch the (hopefully) rare compiler bug; but they could be achieving so much more.
If they had first written a specification, then tests could be based upon the specification.
The code could then be tested against its specification, not against itself. Such a test will
continue to catch compiler bugs. It will also find a lot more coding errors and even some
errors in the specification. Better specifications enable better testing, and the corollary is
that better testing requires better specifications.
In practice, there will be situations where a developer is faced with the thankless task of testing a unit given only the code for the unit and no specification. How can you do more than just find compiler bugs? The first step is to understand what the unit is supposed to do - not what it actually does. In effect, reverse engineer an outline specification. The main input to this process is to read the code and the comments, for the unit, and the units which call it or it calls. This can be supported by drawing flowgraphs, either by hand or using a tool. The outline specification can then be reviewed, to make sure that there are no fundamental flaws in the unit, and then used to design unit tests, with minimal further reference to the code.

3.3. “I'm too Good a Programmer to Need Unit Tests”
There is at least one developer in every organisation who is so good at programming that their software always works first time and consequently does not need to be tested. How often have you heard this excuse? In the real world, everyone makes mistakes. Even if a developer can muddle through with this attitude for a few simple programs, real software systems are much more
complex. Real software systems do not have a hope of working without extensive testing and consequent bug fixing.
Coding is not a one pass process. In the real world software has to be maintained to reflect changes in operational requirements and fix bugs left by the original development. Do you want to be dependent upon the original author to make these changes? The chances are that the “expert” programmer who hacked out the original code without testing it will have moved on to hacking out code elsewhere. With a repeatable unit test the developer making changes will be able to check that there are no undesirable side effects.

3.4. Integration Tests will Catch all the Bugs Anyway
We have already addressed this argument in part as a side issue from some of the receding iscussion. The reason why this will not work is that larger integrations of code are more complex. If units have not been tested first, a developer could easily spend a lot of time just getting the software to run, without actually executing any test cases.
Once the software is running, the developer is then faced with the problem of thoroughly testing each unit within the overall complexity of the software. It can be quite difficult to even create a situation where a unit is called, let alone thoroughly exercised once it is called. Thorough testing of unit level functionality during integration is much more complex than testing units in isolation.
The consequence is that testing will not be as thorough as it should be. Gaps will be left and bugs will slip through.
To create an analogy, try cleaning a fully assembled food processor! No matter how much water and detergent is sprayed around, little scraps of food will remain stuck in awkward corners, only to go rotten and surface in a later recipe. On the other hand, if it is disassembled, the awkward corners either disappear or become much more accessible, and each part can be cleaned without too much trouble.

3.5. It is not Cost Effective

The level of testing appropriate to a particular organisation and software application depends on the potential consequences of undetected bugs. Such consequences can range from a minor inconvenience of having to find a work-round for a bug to multiple deaths. Often overlooked by software developers (but not by customers), is the long term damage to the credibility of an organisation which delivers software to users with bugs in it, and the resulting negative impact on future business. Conversely, a reputation for reliable software will help an organisation to obtain future business.
Many studies have shown that efficiency and quality are best served by testing software as early in the life cycle as practical, with full regression testing whenever changes are made. The later a bug is found, the higher the cost of fixing it, so it is sound economics to identify and fix bugs as early as possible. Unit testing is an opportunity to catch bugs early, before the cost of correction escalates too far.
Unit tests are simpler to create, easier to maintain and more convenient to repeat than later stages of testing. When all costs are considered, unit tests are cheap compared to the alternative of complex and drawn out integration testing, or unreliable software.

4. Some Figures

Figures from “Applied Software Measurement”, (Capers Jones, McGraw-Hill 1991), for the time taken to prepare tests, execute tests, and fix defects (normalised to one function point), show that unit testing is about twice as cost effective as integration testing and more than three times as cost effective as system testing.
This does not mean that developers should not perform the latter stages of testing, they are still necessary. What it does mean is that the expense of later stages of testing can be reduced by eliminating as many bugs as possible as early as possible. Other figures show that up to 50% of maintenance effort is spent fixing bugs which have always been there. This effort could be saved if the bugs were eliminated during development. When it is considered that software maintenance costs can be many times the initial development cost, a potential saving of 50% on software maintenance can make a sizeable impact on overall lifecycle costs.

5. Conclusion
Experience has shown that a conscientious approach to unit testing will detect many bugs at a stage of the software development where they can be corrected economically. In later stages of software development, detection and correction of bugs is much more difficult, time consuming and costly. Efficiency and quality are best served by testing software as early in the lifecycle as practical, with full regression testing whenever changes are made. Given units which have been tested, the integration process is greatly simplified. Developers will be able to concentrate upon the interactions between units and the overall functionality without being swamped by lots of little bugs within the units. The effectiveness of testing effort can be maximised by selection of a testing strategy
which includes thorough unit testing, good management of the testing process, and appropriate use of tools such as AdaTEST or Cantata to support the testing process. The result will be more reliable software at a lower development cost, and there will be further benefits in simplified maintenance and reduced lifecycle costs. Effective unit testing is all part of developing an overall “quality” culture, which can only be beneficial to a software developers business.