Below are the some categories in which testing tools are broadly classified:

• Web Site Management Tools
• Requirements-Based Testing Tools
• Test Management Tools
• Regression Testing Tools
• Coverage Analysis Tools
• Dynamic Testing Tools
• Static Testing Tools
• Load Testing Tools
• Comparators

Web Site Management Tools

Web site management tools are designed to help the Webmaster or business manager manage every aspect of a rapidly changing site. It helps detect and repair defects in the structural integrity of their sites, e.g., broken links, orphaned pages, potential performance problems on Websites, etc.

Requirements-Based Testing Tools

A requirements-based testing tool, or functional test case design tool, drives clarification of application requirements and uses the “requirements” as the basis for test design. Such tools validate requirements by identifying all functional variations and logical inconsistencies, and they determine the minimal number of test cases needed to maximize coverage of the functional requirements.

Test Management Tools

A test management tool keeps track of all the testing assets through a common repository of information and contains such information as test plans, test cases, and test scripts. It helps quality assurance plan, manage, and analyze the testing progress and enhances the communication of the de velopment team, including testers, developers, project leaders, and QA managers. Using a test management tool, testers report defects and track progress, developers correct defects and update the defect status, project leaders extract information about the progress of the testing process. Quality assurance managers generate reports and create graphical analysis for management.

Regression Testing Tools

Each code change, enhancement, bug fix, and platform port necessitates retesting the entire application to ensure a quality release. Manual testing can no longer keep pace in this rapid developing environment. A regression testing tool helps automate the testing process, from test development to execution. Reusable test scripts are created which test the systemís functionality. Prior to a release, one can execute these tests in an unattended mode, which fosters the detection of defects and ensures quality deliverables.

Coverage Analysis Tools

The purpose of coverage analysis tools is to monitor the system while a dynamic testing tool is executing. They are a form of white-box testing in which there is knowledge about the internal structure of the program of the system is necessary. Information is provided on how thorough the test was. Graphic analysis displays how much the system was covered during the test, such as the percent of code executed and in which locations. This will provide the tester with information on weaknesses in the test design, which can be solved with additional test cases.

Dynamic Testing Tools

Dynamic testing techniques are time dependent and involve executing a specific sequence of instructions by the computer. The purpose of dynamic testing tools is to examine a program of systems behavior and performance while it is executing to verify whether it operated as expected. Examples include regression testing capture/playback and load/stress testing tools.

Static Testing Tools

The purpose of static testing tools is to uncover defects by examining the software itself rather than executing it, as with dynamic testing. They are a form of white-box testing in which there is knowledge about the internal structure of the program of the system and can be thought of as automated code inspectors.

Typical defects reported by the static testing tools include:

 

• Overly complex code
• Misspellings
• Incorrect punctuation
• Path analysis
• Improper statement sequencing
• Inconsistency of parameters
• Redundant code
• Unreachable code
• Overly complex system structure
• Faults
• Initialized variables
• Coding standard violations
• Inconsistent data attributes.

Load Testing Tools

The purpose of load testing tools is to simulate a production environment to determine that normal or above-normal volumes of transactions can be completed successfully in an expected time frame. These tools test the availability and capacity of system resources, such as CPU, disk, memory, channel, and communication lines.

Comparators

A comparator is a program used to compare two versions of source data to determine whether the two versions are identical or to specifically identify where any differences in the versions occur. Comparators are most effective during software testing and maintenance when periodic modifications to the software are anticipated.

Q) Define Critical Success Factors

This step tells whether the software package will be successful in meeting your business needs. Critical Success Factors (CSFs) are those criteria or factors that must be present in the acquired software for it to be successful.

Use some of these more common CSFs when testing a software:

Ease of use – the software is understandable and usable by the average person.

Expandability – the vendor plans to add additional features in the future.

Maintainability – the vendor will provide support/assistance to help utilize the package in the event of problems.

Cost-effectiveness – the software package makes money for your business by reducing costs, and so on.

Transferability – if you change your computer equipment the vendor indicates that they will support new models or hardware.

Reliability – in computer language, the system is friendly, meaning that it will help you get your transactions entered into the system so that you can produce your results readily.

Security – the system has adequate safeguards to protect the data against damage (for example, power failures, operator errors, or other goofs that could cause you to lose your data).

Wikipedia defines QA as given below…

“Quality assurance, or QA for short, refers to planned and systematic production processes that provide confidence in a product’s suitability for its intended purpose. It is a set of activities intended to ensure that products (goods and/or services) satisfy customer requirements in a systematic, reliable fashion.”

The entire software development process of examining and improving the process and making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with constitutes the Software QA.

Quality Assurance refers to the process used to create the deliverables, and can be performed by a manager, client, or even a third-party reviewer like QC Boss.

Are Software QA processes needed in an organization?

• A lot depends on the size of the organization and the risks involved. For large organizations with high-risk (in terms of lives or property) projects, serious management buy-in is required and a formalized QA process is necessary.
• Where the risk is lower, management and organizational buy-in and QA implementation may be a slower, step-at-a-time process. QA processes should be balanced with productivity so as to keep bureaucracy from getting out of hand.
• For small groups or projects, a more ad-hoc process may be appropriate, depending on the type of customers and projects. A lot will depend on team leads or managers, feedback to developers, and ensuring adequate communications among customers, managers, developers, and testers.
• The most value for effort will often be in (a) requirements management processes, with a goal of clear, complete, testable requirement specifications embodied in requirements or design documentation, or in ‘agile’-type environments extensive continuous coordination with end-users, (b) design inspections and code inspections, and (c) post-mortems/retrospectives.
• Other possibilities include incremental self-managed team approaches such as ‘Kaizen’ methods of continuous process improvement, the Deming-Shewhart Plan-Do-Check-Act cycle, and others.

If you still find it difficult to maintain the standards of your websites, then it is the time to send your requirements to QC Boss.

To know more visit www.qcboss.com

Our independent software testing services provide validation and verification for websites, portals, and web applications. We offer highly professional testing expertise coupled with personalised service that translates into value for money for you, as our client.  

We Offer

A complete range of testing – system testing, integration testing, functional testing, regression testing, gorilla testing, heuristic evaluations, user acceptance testing, conformance testing, interoperability testing, design check, content check, cross browser/OS testing and performance testing.

Flexible resources – develop a testing solution for your needs, both at our facility or in-house at your office.

So you like what you’ve seen about the services we offer and want to get a closer look at what we can do for you and your business. We are happy to show you the difference that QC BOSS can make and we are sure that you will be pleased by what you see.

Our dedicated team of skilled software testers, Offshore QA Lab, provides a full range of quality assurance services (QA), including software quality consulting, test planning, test execution and reporting, control of software development processes.

It is known that software quality and its conformation to requirements, standards and objectives underlies the effectiveness of such product. Our Offshore QA support software QA both for small and large development projects.

What we do          

Offshore QA Lab is engaged in the software development process at each stage to assure the quality of a software product and processes involved. Our QA services encompass:

          Review of

          Software Requirements / System Specifications / Project Plan / Software Architecture / Databases Structure / SRS / FSD / BRD

          Software Testing

          System testing, integration testing, functional testing, regression testing, gorilla testing, heuristic evaluations, user acceptance testing, conformance testing, interoperability testing, design check, content check, cross browser/OS testing and performance testing.        

You are free to discuss and choose all or any of the software quality assurance services upon your needs and requirements.

There are numerous testing tools, each with specific capabilities and test objectives. The selection of the best testing tool for a particular development environment is a critical success factor for the testing activities. However, if the right testing tool is not selected and/or the organization is not positioned for a testing tool, it can easily become “shelfware,” as testing tools require a learning curve, skills, standards, and must be integrated into the development methodology.

When to Consider Using a Testing Tool?

A testing tool should be considered based on the test objectives. As a general guideline, one should investigate the appropriateness of a testing tool when the human manual process is inadequate. For example, if a system needs to be stress tested, a group of testers could simultaneously logon to the system and attempt to simulate peak loads using stopwatches. However, this approach has limitations. One cannot systematically measure the performance precisely or repeatably. For this case, a load testing tool can simulate several virtual users under controlled stress conditions.

A regression testing tool might be needed under the following circumstances:

• Tests need to be run at every build of an application, e.g., time consuming, unreliable and inconsistent use of human resources
• Tests are required using multiple data values for the same actions
• Tests require detailed information from system internals such as SQL, GUI attributes
• There is a need to stress a system to see how it performs

• Speedy and much faster then their human counterpart
• Run unattended without human intervention
• Provide code coverage analysis after a test run
• Precisely repeatable
• Reusable, just as programming subroutines
• Programmable

When to Not Consider Using a Testing Tool?

Contrary to popular belief, it is not always wise to purchase a testing tool. Some factors that limit a testing tool include:

Cost

A testing tool may not be affordable to the organization, e.g., the cost/performance tradeoff.

 

Culture

The development culture may not be ready for a testing tool, because it requires the proper skills and commitment to long-term quality.

 

Usability testing

There are no automated testing tools that can test usability.

 

One-time testing

If the test is going to be performed only once, a testing tool may not be worth the required time and expense.

 

Time crunch

If there is pressure to complete testing within a fixed time frame, a testing tool may not be feasible, because it takes time to learn, set up, and integrate a testing tool to the development methodology.

 

Ad hoc testing

If there is no formal test design and test cases, a regression testing tool will be useless

 

Predictable results

If tests do not have predictable results, a regression testing tool will be useless

 

Instability

If the system is changing rapidly during each testing spiral, more time will be spent maintaining a regression testing tool than it is worth.

 

Nobody knows how many bugs will be found, but a 5% functionality change in a 1000 suite test will create at least 5-25 new defects.

Regression testing is also a most important part of the entire testing effort. Always take time to plan and manage your regression testing effort. Investigate the tools that are available to help you automate your regression tests and manage your suites. In an industry where time and skilled staff always seem to be scarce, it makes sense to work smarter by outsourcing your Testing jobs to us.

For more info visit www.qcboss.com.

Q) The differences in testing software developed in-house and software developed by a contractor include the following:

Quality factors may not be specified

There are many factors such as reliability and ease of use which are frequently not included as part of the contractual criteria. Thus, when the software is delivered it may not be as easy to use or as reliable as desired by the contractor.

Non-testable requirements and criteria

If the requirements or contractual criteria are in measurable and testable terms then the delivered result may not meet the intent of the contractor.

Customer’s standards may not be met

Unless the contract specifies the operational standards and documentation standards the delivered product may be more complex to use than desired by the contractor.

Missing requirements

Unless detailed analysis and contractual specifications work is complete the contractor may realize during the development of the software that requirements are missing and thus the cost of the contract could escalate significantly.

Overlooked changes in standards in technology

If changes in standards that the organization must meet, or the introduction of new desirable technology is incorporated into the contract there may be significant cost to modify the software for those new standards in technology.

Training and deployment may be difficult

If software is developed by another organization there may be inadequate knowledge in the contracted organization to provide the appropriate training for staff and to ensure that deployment is effective and efficient.

Additional Differences with Contractors in another Country (Offshore):

Cultural differences

There may be a significant difference in the culture and values between the contractor and the offshore organization.

Communication barriers

The language of the offshore organization may be different or difficult to comprehend which causes difficulty in communicating the needs and desires of the contractor.

Loss of employee morale and support

Employees who would like to have developed the software may resent the software being developed offshore and thus make it difficult for the offshore-developed software to be successful.

Root cause of the contractor IT organization not addressed

Frequently, an offshore organization is chosen because there are problems in the contracting organization that executives do not want to address. For example, the problems might include a lack of training for the employees in the contracting organization or other perhaps better options for software development were not explored.

Manual testing is defined as the oldest and most rigorous type of software testing by http://www.wikipedia.com/. Here’s more on Manual testing described by them. Manual testing helps discover and record any software bugs or discrepancies related to the functionality of the product.

Despite the proliferation of automated solutions, manual testing still accounts for at least 80% of all testing. Automation can only be justified where repeatable consistent tests can be run over a stable environment. When this isn’t the case (i.e. during the early stages of the test cycle), testing teams almost always revert back to manual testing. So manual testing is here to stay! Here are some reasons why:

Business critical / Heavily tested software: With constantly changing applications, automation can simply be too daunting.

Script based automation tools not living up to their hype: Many people still find that despite investing in script based automation solutions this only covers 10-20% of their total testing. The rest is still carried out manually.

Full automation is simply not appropriate: You may be testing new functionality, new platforms/OS, or there maybe insufficient time and/or skills to develop test scripts.

Manual testing helps discover defects related to the usability testing and GUI testing area. While performing manual tests the software application can be validated whether it meets the various standards defined for effective and efficient usage and accessibility.

There is no complete substitute for manual testing. Manual testing is crucial for testing software applications more thoroughly.

To get fully professional manual testing services visit http://www.qcboss.com/

This metric gives the variation of actual effort vs. the estimated effort. This is calculated for each project Stage wise

Formula

EV = [(Actual person hours – Estimated person hours) / Estimated person hours] * 100

Calculated at

Stage completion as identified in SPP

Calculated from

Estimation sheets for estimated values in person hours, for each activity within a given stage and Actual Worked Hours values in person hours.

This metric gives the variation of actual cost Vs the estimated cost. This is calculated for each project Stage wise

Formula

CV = [(Actual Cost – Estimated Cost) / Estimated Cost] * 100

Calculated at

Stage completion

Calculated from

Estimation sheets for estimated values in dollars or rupees, for each activity within a given stage

Actual cost incurred