S/w fAQ's
S.No   Category views Poted On
1 SQA and testing frequently asked definitions

TESTING

999 01/01/08
2 Load testing interview questions

TESTING

2547 01/01/08
3 Performance Testing Considerations

TESTING

525 01/01/08
4 what is testing?

TESTING

658 01/01/08
5 blackbox testing tips

TESTING

4254 01/01/08
6 Tester Tips

TESTING

6589 01/01/08
7 Interview with Brian Marick on How to do Good Test..

TESTING

254 01/01/08
8

WEB Testing Interview Questions For software teste...

TESTING

5846 02/02/08
9 General interview questions

TESTING

5554 02/02/08
10 Latest Questions in Testing Definations

TESTING

5885 02/02/08
11 Software Testing Interview Questions

TESTING

556 02/02/08
12 Interview Questions for Software Testers.

TESTING

658 02/02/08
13 Testing Interview Questions

TESTING

2135 02/02/08
14 Testing Tools Interview Questions

TESTING

245 02/02/08
15 TESTING TOOLS INTERVIEW QUESTIONS-Part2

TESTING

546 02/02/08
16 TESTING TOOLS INTERVIEW QUESTIONS-Part1

TESTING

879 02/02/08
17 Fuzz testing

TESTING

1245 02/02/08
18 Defect Tracking & Formal Verification

TESTING

471 02/02/08
19 Test Cases, Suits, Scripts

TESTING

501 02/02/08
20 Compatibility Testing

TESTING

2456 02/02/08
21 System Testing & Regression Testing

TESTING

4511 02/02/08
22 Beta Testing & Product Testing

TESTING

6548 02/02/08
23 Installation Testing & Alpha Testing

TESTING

235 02/02/08
24 Stability Testing & Acceptance Testing

TESTING

546 02/02/08
25 Usability Testing

TESTING

546 02/02/08
26 Stress Testing & Security Testing

TESTING

856 02/02/08
27 Performance Testing

TESTING

214 02/02/08
28 Unit Testing & Integration Testing

TESTING

568 02/02/08
29 White Box & Black Box Testing

TESTING

546 02/02/08
30 Interview questions on WinRunner TESTING 125 03/02/08
31 Testing Tools Interview Questions TESTING 658 03/02/08
32 Testing Tools Interview Questions-2 TESTING 5488 03/02/08
33 Testing Tools Interview Questions-3 TESTING 254 03/02/08
34 Testing Tools Interview Questions-4 TESTING 987 03/02/08
35 Testing Tools Interview Questions TESTING 2456 03/02/08
36 Testing Tools Interview Questions TESTING 2145 03/02/08
37 Software Testing 10 Rules-Bugs and fixes TESTING 985 03/02/08
38 How to Write a Fully Effective Bug Report TESTING 357 03/02/08
39 Testing Reviews--methodology and techniques TESTING 159 03/02/08
40 Load and Performance Test Tools TESTING 658 03/02/08
41 TESTING 856 03/02/08
42 Debugging Strategies, Tips, and Gotchas TESTING 2145 03/02/08
43 Web services programming tips and tricks: Stress t... TESTING 84754 03/02/08
44 Web services programming tips and tricks: improve ... TESTING 2358 03/02/08
45 WinRunner Interview Questions TESTING 3569 03/02/08
46 LoadRunner Interview Questions TESTING 1245 03/02/08
47 SilkTest Interview Question TESTING 845 03/02/08
48 Software QA and Testing Frequently-Asked-Questions... TESTING 21 03/02/08
49 Systematic Software Testing TESTING 254 03/02/08
50 Software Testing-Introduction TESTING 2586 03/02/08
51 Tips for Releasing Software for Customer Testing TESTING 358 03/02/08
52 Software Regression Testing TESTING 951 03/02/08
53 TestComplete 4 - Automate the Non-Automatable. TESTING 32558 03/02/08
54 webtest tools TESTING 245 03/02/08
55 webtest tools TESTING 956 03/02/08
56 Applying Patterns to Software Testing TESTING 845 03/02/08
57 The Software Testing Automation Framework TESTING 326 03/02/08
58 Testing Tools Interview Questions and Faqs-unanswe... TESTING 745 03/02/08
53 latest and unanswered Questions in Rational Robot ... TESTING 5125 03/02/08
54 Buttons TESTING 648 03/02/08
55 XPLANNER TESTING 213 03/02/08
56 Testing Tools Interview Questions TESTING 9547 03/02/08
57 Web services programming tips and tricks: TESTING 852 03/02/08
         

Error Handling Testing

Error handling refers to the anticipation, detection, and resolution of programming, application, and communications errors. Specialized programs, called error handlers, are available for some applications. The best programs of this type forestall errors if possible, recover from them when they occur without terminating the application, or (if all else fails) gracefully terminate an affected application and save the error information to a log file.

In programming, a development error is one that can be prevented. Such an error can occur in syntax or logic. Syntax errors, which are typographical mistakes or improper use of special characters, are handled by rigorous proofreading. Logic errors, also called bugs, occur when executed code does not produce the expected or desired result. Logic errors are best handled by meticulous program debugging. This can be an ongoing process that involves, in addition to the traditional debugging routine, beta testing prior to official release and customer feedback after official release.

A run-time error takes place during the execution of a program, and usually happens because of adverse system parameters or invalid input data. An example is the lack of sufficient memory to run an application or a memory conflict with another program. On the Internet, run-time errors can result from electrical noise, various forms of malware or an exceptionally heavy demand on a server. Run-time errors can be resolved, or their impact minimized, by the use of error handler programs, by vigilance on the part of network and server administrators, and by reasonable security countermeasures on the part of Internet users.

----

Usage


  • It determines the ability of applications system to process the incorrect transactions properly

  • Errors encompass all unexpected conditions.

  • In some system approx. 50% of programming effort will be devoted to handling error condition.
----

Objective


  • Determine Application system recognizes all expected error conditions.

  • Determine Accountability of processing errors has been assigned and procedures provide a high probability that errors will be properly corrected.

  • Determine During correction process reasonable control is maintained over errors.
-----

How to Use?


  • A group of knowledgeable people is required to anticipate what can go wrong in the application system.

  • It is needed that all the application knowledgeable people assemble to integrate their knowledge of user area, auditing and error tracking.

  • Then logical test error conditions should be created based on this assimilated information.
----

When to Use?


  • Throughout SDLC.

  • Impact from errors should be identified and should be corrected to reduce the errors to acceptable level.

  • Used to assist in error management process of system development and maintenance.
------

Example


  • Create a set of erroneous transactions and enter them into the application system then find out whether the system is able to identify the problems.

  • Using iterative testing enters transactions and trap errors. Correct them. Then enter transactions with errors, which were not present in the system earlier.




Risk Analysis

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 Prodicts.

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.

----

What is Schedule Risk?

In your project, you have to estimate how long it takes to complete a certain task.

You estimate that it usually takes 15 days to complete. If things go well it may take 12 days but if things go badly it may take 20 days.

In your project plan you enter 15 days against the task.

The other information, the best case estimate of 12 days and the worst case estimate of 20 days, is not entered into the project at all.

If this seems familiar, then you already go through the process of identifying uncertainty or risk. By entering only the most likely duration a great deal of additional information is lost. But with Schedule Risk this extra information is used to help produce a much more realistic project.

And you are not just limited to durations. Uncertainty in resources and costs can also be modeled in your project to produce an even greater depth and accuracy to the information available to you.


Who should use Schedule Risk Analysis?

The simple answer is - anyone who manages a project! If you are running projects that are time and/or cost critical, risk analysis will help you manage your projects more effectively and help reduce the chances of your project being late and over budget.

Pertmaster is used by project planners of all levels, from those just entering into the Schedule Risk arena to the world's leading risk experts.


How easy is it to use?

Very easy. You do not need to be an expert in risk and statistics to be able to use schedule risk. With normal project planning, the level of detail and complexity that you build into the project is up to you and your requirements. This is the same with Schedule Risk. Very little extra information is required as a minimum but you have the ability to provide a great deal of very specific additional information if you require it.

Pertmaster is acclaimed as being very easy to use. By simply following the tutorials and examples you will be able to incorporate risk into your project with ease. Pertmaster includes a Quick Risk (link) facility that lets you add risk to your project in seconds.

-----

What is Schedule Risk?

In your project, you have to estimate how long it takes to complete a certain task.

You estimate that it usually takes 15 days to complete. If things go well it may take 12 days but if things go badly it may take 20 days.

In your project plan you enter 15 days against the task.

The other information, the best case estimate of 12 days and the worst case estimate of 20 days, is not entered into the project at all.

If this seems familiar, then you already go through the process of identifying uncertainty or risk. By entering only the most likely duration a great deal of additional information is lost. But with Schedule Risk this extra information is used to help produce a much more realistic project.

And you are not just limited to durations. Uncertainty in resources and costs can also be modeled in your project to produce an even greater depth and accuracy to the information available to you.


Who should use Schedule Risk Analysis?

The simple answer is - anyone who manages a project! If you are running projects that are time and/or cost critical, risk analysis will help you manage your projects more effectively and help reduce the chances of your project being late and over budget.

Pertmaster is used by project planners of all levels, from those just entering into the Schedule Risk arena to the world's leading risk experts.


How easy is it to use?

Very easy. You do not need to be an expert in risk and statistics to be able to use schedule risk. With normal project planning, the level of detail and complexity that you build into the project is up to you and your requirements. This is the same with Schedule Risk. Very little extra information is required as a minimum but you have the ability to provide a great deal of very specific additional information if you require it.

Pertmaster is acclaimed as being very easy to use. By simply following the tutorials and examples you will be able to incorporate risk into your project with ease. Pertmaster includes a Quick Risk (link) facility that lets you add risk to your project in seconds.

--------

Risk Assessment

Risk assessment may be the most important step in the risk management process, and may also be the most difficult and prone to error. Once risks have been identified and assessed, the steps to properly deal with them are much more programmatical.

Part of the difficulty of risk management is that measurement of both of the quantities in which risk assessment is concerned can be very difficult itself. Uncertainty in the measurement is often large in both cases. Also, risk management would be simpler if a single metric could embody all of the information in the measurement. However, since two quantities are being measured, this is not possible. A risk with a large potential loss and a low probability of occurring must be treated differently than one with a low potential loss but a high likelihood of occurring. In theory both are of nearly equal priority in dealing with first, but in practice it can be very difficult to manage when faced with the scarcity of resources, especially time, in which to conduct the risk management process. Expressed mathematically,



R_{total}=\sum_i L_i p(L_i)\,\!

Financial decisions, such as insurance, often express loss terms in dollars. When risk assessment is used for public health or environmental decisions, there are differences of opinions as to whether the loss can be quantified in a common metric such as dollar values or some numerical measure of quality of life. Often for public health and environmental decisions, the loss term is simply a verbal description of the outcome, such as increased cancer incidence or incidence of birth defects. In that case, the "risk" is expressed as:



R_i= p(L_i)\,\!

If the risk estimate takes into account information on the number of individuals exposed, it is termed a "population risk" and is in units of expected increased cases per a time period. If the risk estimate does not take into account the number of individuals exposed, it is termed an "individual risk" and is in units of incidence rate per a time period. Population risks are of more use for cost/benefit analysis; individual risks are of more use for evaluating whether risks to individuals are "acceptable".

----

Risk assessment in public health

In the context of public health, risk assessment is the process of quantifying the probability of a harmful effect to individuals or populations from certain human activities. In most countries, the use of specific chemicals, or the operations of specific facilities (e.g. power plants, manufacturing plants) is not allowed unless it can be shown that they do not increase the risk of death or illness above a specific threshold. For example, the American Food and Drug Administration (FDA) regulates food safety through risk assessment. The FDA required in 1973 that cancer-causing compounds must not be present in meat at concentrations that would cause a cancer risk greater than 1 in a million lifetimes.

--------

Risk assessment in auditing

In auditing, risk assessment is a very crucial stage before accepting an audit engagement. According to ISA315 Understanding the Entity and its Environment and Assessing the Risks of Material Misstatement, "the auditor should perform risk assessment procedures to obtain an understanding of the entity and its environment, including its internal control."

The main purpose of risk assessment procedures is to help the auditor understand the audit client. Aspects like client's business nature, management structure and internal control system are good examples. The procedures will provide audit evidence relating to the auditor’s risk assessment of a material misstatement in the client’s financial statements. Then, auditor obtains initial evidence regarding the classes of transactions at the client and the operating effectiveness of the client’s internal controls.

In auditing, audit risk includes inherent risk, control risk and detection risk

--

Criticisms of quantitative risk assessment

Barry Commoner and other critics have expressed concerns that risk assessment tends to be overly quantitative and reductive. For example, they argue that risk assessments ignore qualitative differences among risks. Some charge that assessments may drop out important non-quantifiable or inaccessible information, such as variations among the classes of people exposed to hazards. O'Brien further claims that quantitative approaches divert attention from precautionary or preventative measures.

---

Risk Management

Risk management is a structured approach to managing uncertainty through, risk assessment, developing strategies to manage it, and mitigation of risk using managerial resources.

The strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk.

Some traditional risk managements are focused on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments.

Objective of risk management is to reduce different risks related to a preselected domain to the level accepted by society. It may refer to numerous types of threats caused by environment, technology, humans, organizations and politics. On the other hand it involves all means available for humans, or in particular, for a risk management entity (person, staff, organization).

---

Create a risk management plan

Select appropriate controls or countermeasures to measure each risk. Risk mitigation needs to be approved by the appropriate level of management. For example, a risk concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks.

The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing antivirus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions.

According to ISO/IEC 27001, the stage immediately after completion of the Risk Assessment phase consists of preparing a Risk Treatment Plan, which should document the decisions about how each of the identified risks should be handled. Mitigation of risks often means selection of Security Controls, which should be documented in a Statement of Applicability, which identifies which particular control objectives and controls from the standard have been selected, and why.

-----

Implementation
Follow all of the planned methods for mitigating the effect of the risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer, avoid all risks that can be avoided without sacrificing the entity's goals, reduce others

---

Review and evaluation of the plan

Initial risk management plans will never be perfect. Practice, experience, and actual loss results will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced.

Risk analysis results and management plans should be updated periodically. There are two primary reasons for this:

  • to evaluate whether the previously selected security controls are still applicable and effective, and

  • to evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment
------
Risk management and business continuity

Risk management is simply a practice of systematically selecting cost effective approaches for minimising the effect of threat realization to the organization. All risks can never be fully avoided or mitigated simply because of financial and practical limitations. Therefore all organizations have to accept some level of residual risks. Whereas risk management tends to be preemptive, business continuity planning (BCP) was invented to deal with the consequences of realised residual risks. The necessity to have BCP in place arises because even very unlikely events will occur if given enough time. Risk management and BCP are often mistakenly seen as rivals or overlapping practices. In fact these processes are so tightly tied together that such separation seems artificial. For example, the risk management process creates important inputs for the BCP (assets, impact assessments, cost estimates etc). Risk management also proposes applicable controls for the observed risks. Therefore, risk management covers several areas that are vital for the BCP process. However, the BCP process goes beyond risk management's preemptive approach and moves on from the assumption that the disaster will realize at some point.

---

Areas of risk management

As applied to corporate finance, risk management is the technique for measuring, monitoring and controlling the financial or operational risk on a firm's balance sheet.

The Basel II framework breaks risks into market risk (price risk), credit risk and operational risk and also specifies methods for calculating capital requirements for each of these components.


Enterprise risk management

In enterprise risk management, a risk is defined as a possible event or circumstance that can have negative influences on the Enterprise in question. Its impact can be on the very existence, the resources (human and capital), the products and services, or the customers of the enterprise, as well as external impacts on society, markets, or the environment. In a financial institution, enterprise risk management is normally thought of as the combination of credit risk, interest rate risk or asset liability management, market risk, and operational risk.

In the more general case, every probable risk can have a preformulated plan to deal with its possible consequences (to ensure contingency if the risk becomes a liability).

From the information above and the average cost per employee over time, or cost accrual ratio, a project manager can estimate

  • the cost associated with the risk if it arises, estimated by multiplying employee costs per unit time by the estimated time lost (cost impact, C where C = cost accrual ratio * S).
  • the probable increase in time associated with a risk (schedule variance due to risk, Rs where Rs = P * S):
    • Sorting on this value puts the highest risks to the schedule first. This is intended to cause the greatest risks to the project to be attempted first so that risk is minimized as quickly as possible.
    • This is slightly misleading as schedule variances with a large P and small S and vice versa are not equivalent. (The risk of the RMS Titanic sinking vs. the passengers' meals being served at slightly the wrong time).
  • the probable increase in cost associated with a risk (cost variance due to risk, Rc where Rc = P*C = P*CAR*S = P*S*CAR)
    • sorting on this value puts the highest risks to the budget first.
    • see concerns about schedule variance as this is a function of it, as illustrated in the equation above.

Risk in a project or process can be due either to Special Cause Variation or Common Cause Variation and requires appropriate treatment. That is to re-iterate the concern about extremal cases not being equivalent in the list immediately above.

Risk management activities as applied to project management

In project management, risk management includes the following activities:

  • Planning how risk management will be held in the particular project. Plan should include risk management tasks, responsibilities, activities and budget.
  • Assigning a risk officer - a team member other than a project manager who is responsible for foreseeing potential project problems. Typical characteristic of risk officer is a healthy skepticism.
  • Maintaining live project risk database. Each risk should have the following attributes: opening date, title, short description, probability and importance. Optionally a risk may have an assigned person responsible for its resolution and a date by which the risk must be resolved.
  • Creating anonymous risk reporting channel. Each team member should have possibility to report risk that he foresees in the project.
  • Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the mitigation plan is to describe how this particular risk will be handled – what, when, by who and how will it be done to avoid it or minimize consequences if it becomes a liability.
  • Summarizing planned and faced risks, effectiveness of mitigation activities, and effort spent for the risk management.
-------
Areas of risk management

As applied to corporate finance, risk management is the technique for measuring, monitoring and controlling the financial or operational risk on a firm's balance sheet.

The Basel II framework breaks risks into market risk (price risk), credit risk and operational risk and also specifies methods for calculating capital requirements for each of these components.


Enterprise risk management

In enterprise risk management, a risk is defined as a possible event or circumstance that can have negative influences on the Enterprise in question. Its impact can be on the very existence, the resources (human and capital), the products and services, or the customers of the enterprise, as well as external impacts on society, markets, or the environment. In a financial institution, enterprise risk management is normally thought of as the combination of credit risk, interest rate risk or asset liability management, market risk, and operational risk.

In the more general case, every probable risk can have a preformulated plan to deal with its possible consequences (to ensure contingency if the risk becomes a liability).

From the information above and the average cost per employee over time, or cost accrual ratio, a project manager can estimate

  • the cost associated with the risk if it arises, estimated by multiplying employee costs per unit time by the estimated time lost (cost impact, C where C = cost accrual ratio * S).
  • the probable increase in time associated with a risk (schedule variance due to risk, Rs where Rs = P * S):
    • Sorting on this value puts the highest risks to the schedule first. This is intended to cause the greatest risks to the project to be attempted first so that risk is minimized as quickly as possible.
    • This is slightly misleading as schedule variances with a large P and small S and vice versa are not equivalent. (The risk of the RMS Titanic sinking vs. the passengers' meals being served at slightly the wrong time).
  • the probable increase in cost associated with a risk (cost variance due to risk, Rc where Rc = P*C = P*CAR*S = P*S*CAR)
    • sorting on this value puts the highest risks to the budget first.
    • see concerns about schedule variance as this is a function of it, as illustrated in the equation above.

Risk in a project or process can be due either to Special Cause Variation or Common Cause Variation and requires appropriate treatment. That is to re-iterate the concern about extremal cases not being equivalent in the list immediately above.

Risk management activities as applied to project management

In project management, risk management includes the following activities:

  • Planning how risk management will be held in the particular project. Plan should include risk management tasks, responsibilities, activities and budget.
  • Assigning a risk officer - a team member other than a project manager who is responsible for foreseeing potential project problems. Typical characteristic of risk officer is a healthy skepticism.
  • Maintaining live project risk database. Each risk should have the following attributes: opening date, title, short description, probability and importance. Optionally a risk may have an assigned person responsible for its resolution and a date by which the risk must be resolved.
  • Creating anonymous risk reporting channel. Each team member should have possibility to report risk that he foresees in the project.
  • Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the mitigation plan is to describe how this particular risk will be handled – what, when, by who and how will it be done to avoid it or minimize consequences if it becomes a liability.
  • Summarizing planned and faced risks, effectiveness of mitigation activities, and effort spent for the risk management.
------
Limitations

If risks are improperly assessed and prioritized, time can be wasted in dealing with risk of losses that are not likely to occur. Spending too much time assessing and managing unlikely risks can divert resources that could be used more profitably. Unlikely events do occur but if the risk is unlikely enough to occur it may be better to simply retain the risk and deal with the result if the loss does in fact occur.

Prioritizing too highly the risk management processes could keep an organization from ever completing a project or even getting started. This is especially true if other work is suspended until the risk management process is considered complete.

It is also important to keep in mind the distinction between risk and uncertainty. Risk can be measured by impacts x probability.




Test Plan

A test plan is a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be.

In software testing, a test plan gives detailed testing information regarding an upcoming testing effort, including

  • Scope of testing.

  • Schedule.

  • Test Deliverables.

  • Release Criteria.

  • Risks and Contingencies.

Test Strategy

How we plan to cover the product so as to develop an adequate assessment of quality.

A good test strategy is:

  • Specific

  • Practical

  • Justified

The purpose of a test strategy is to clarify the major tasks and challenges of the test project.

Test Approach and Test Architecture are other terms commonly used to describe what I’m calling test strategy.

Example of a poorly stated (and probably poorly conceived) test strategy:

"We will use black box testing, cause-effect graphing, boundary testing, and white box testing to test this product against its specification."

Creating a Test Strategy


The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.

Inputs for this process:
  • A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.
  • A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.
  • Testing methodology. This is based on known standards.
  • Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.
  • Requirements that the system can not provide, e.g. system limitations.
Outputs for this process:
  • An approved and signed off test strategy document, test plan, including test cases.
  • Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.
-------

Defining a Test Strategy


A solid testing strategy provides the framework necessary to implement your testing methodology. A separate strategy should be developed for each system being developed taking into account the development methodology being used and the specific application architecture.

The heart of any testing strategy is the master testing strategy document. It aggregates all the information from the requirements, system design and acceptance criteria into a detailed plan for testing. A detailed master strategy should cover the following:

Project Scope

Restate the business objective of the application and define the scope of the testing. The statement should be a list of activities that will be in scope or out of scope. A sample list would include:

* List of software to be tested
* Software configurations to be tested
* Documentation to be validated
* Hardware to be tested

Test Objectives

The system under test should be measured by its compliance to the requirements and the user acceptance criteria. Each requirement and acceptance criteria must be mapped to specific test plans that validate and measure the expected results for each test being performed. The objectives should be listed in order of importance and weighted by Risk.

Features and Functions to be Tested

Every feature and function must be listed for test inclusion or exclusion, along with a description of the exceptions. Some features may not be testable due to a lack of hardware or lack of control etc. The list should be grouped by functional area to add clarity. The following is a basic list of functional areas:

* Backup and recovery
* Workflow
* Interface design
* Installation
* Procedures (users, operational, installation)
* Requirements and design
* Messaging
* Notifications
* Error handling
* System exceptions and third-party application faults

Testing Approach

The approach provides the detail necessary to describe the levels and types of testing. The basic V-Model shows what types of testing are needed to validate the system.
More specific test types include functionality, performance testing, backup and recovery, security testing, environmental testing, conversion testing, usability testing, installation and regression testing. The specific testing methodology should be described and the entry/exit criteria for each phase noted in a matrix by phase. A project plan that list the resources and schedule for each testing cycle should also be created that maps the specific testing task to the overall development project plan.

Testing Process and Procedures

The order of test execution and the steps necessary to perform each type of test should be described in sufficient detail to provide clear input into the creation of test plans and test cases. Procedures should include how test data is created, managed and loaded. Test cycles should be planned and scheduled based on system availability and deliverable dates from development. All application and environmental dependencies should be identified along with the procedures necessary to gain access to all the dependent systems.

Test Compliance

Every level of testing must have a defined set of entry/exit criteria which is used to validate that all prerequisites for a valid test have been met. All mainstream software testing methodologies provide an extensive list of entry/exit criteria and checklist. In addition to the standard list, additional items should be added based on specific testing needs. Some common additions are, environmental availability, data availability, and validated code which is ready to be tested.

Each level of testing should define specific pass/fail acceptance criteria, to ensure to ensure that all quality gates have been validated and that the test plan focuses on developing test that validate the specific criteria defined by the user acceptance plan.

Testing Tools

All testing tools should be identified and their use, ownership and dependencies defined. The tools category includes manual tools, such as templates in spreadsheets and documents as well as automated tools for test management, defect tracking, regression testing and performance/load testing. Any specific skill sets should be identified and compared against the existing skills identified for the project to highlight any training needs.

Defect Resolution

A plan to address the resolution of failed tests needs to be created that lists the escalation procedures to seek correction and retest of the failed tests along with a risk mitigation plan for high-risk test. Defect tracking should include basic metrics for compliance based on number and type of defect found.

Roles and Responsibilities

A matrix listing the roles and responsibilities of everyone involved in the testing activities, along with the anticipated amount of their time allocated to the project, must be prepared.

Process Improvement

The entire testing process should be focused on process improvement. The strategy should list ways to monitor progress and provide constant feedback. This feedback can serve to enhance the process, deliverables and metrics used in the testing. Root cause analysis should be performed on all reported defects to help isolate the true nature of the problem and prevent unnecessary repeat offenses.

Deliverables

All deliverables should be defined and their location specified. Common deliverables are test plans, test cases, test scripts, test matrix and a defect log.

Schedule

All testing activities should be combined into one master testing schedule. The schedule should include an estimate of time for each task and the dependences for each. Testing resources should be assigned to each task and quality gates should be listed to insure oversight of the entire process.

Environmental Needs

All the requirements of the testing environment need to be listed. Common ones include a description of the environment's use, management, hardware and software, specific tools needed, data loading and security requirements.

Resource Management

The skills of all personnel involved in the testing effort need to be assessed and the gaps noted so that a comprehensive training program can be designed. Specialty skills that will not be filled with in-house staff will require job descriptions and budgeting.

Risk and Contingencies

Planning for risk in advance and ways to mitigate it are essential for a robust strategy. A risk assessment that is prioritized by severity of risk and covers technology, resource, schedule and environmental issues should feed a detailed plan to mitigate each red flag.

Approvals and Workflow

All items on the critical path must go through an approval cycle. The procedures for approval and escalation must be well defined and assigned to resources prior to the start of the testing.

The above covers the main sections of a well-drafted and documented testing strategy. The more detail that you include in the strategy document, the less ambiguity and chance for deviation there will be throughout the project

The completion of the strategy signals the beginning of the test planning phase. For each type of testing identified in the master test strategy there should be a test plan identifying the components to be tested, the location of the test data, the test environment needs, the test procedures, resources required, and the tests schedule. For each plan a series of test conditions should be identified so that test cases with expected results can be generated for later execution. -------

What to include in the Testing Strategy


During the analysis phase, you gather and validate the business requirements for the solution. It makes sense that the Testing Strategy is completed during this phase as well. In a sense, you are defining the overall testing requirements.

The purpose of the Testing Strategy is to define the overall context for the entire testing process. The process is different depending on the specific characteristics of your solution. In many respects, this is the most important part of the testing process, since all future testing decisions will be made within the context of the strategy. Here are the basic parts of the testing strategy:

  • Project Overview: You can copy this from the Project Definition.

  • Business Risks: These are high-level risks of the project that will affect the overall testing strategy. For instance, the risk of doing business on the Internet may drive the need for rigorous system tests of firewalls, technical architecture, and security. The risks can be classified as high, medium, and low, depending on the nature and impact of the problem. For each high and medium risk, identify what elements in the overall testing approach will help ensure that the potential problem does not occur.
  • Testing Milestones: This section gives the reader a preliminary overview of the testing timelines. Obviously, since this document is created in the analysis phase, these dates are subject to later revision.

  • Testing Approach: This describes the testing process at a high level, including how you will conduct unit testing, integration testing, system testing, and acceptance testing. (If your project is large enough, each of these might be its own section.) This is where you make fundamental decisions regarding the type of testing that makes sense for your project. For instance, if you are implementing a packaged solution, the approach may start in system testing, with the vendor providing close support. If you are doing iterative development cycles, the testing approach will reflect this overall development life cycle. For system testing, define the major testing events, such as stress testing, security testing, disaster recovery testing, usability testing, and response time testing.

  • Testing Environment: Think through the technologies and facilities needed for the testing process. If the overall testing environment needs are understood up front, it will be easier to break out the specific activities required to put the environment in place. In addition, you may need to plan for and acquire some parts of the environment well in advance.

Depending on your project, there may be other high-level sections to include, such as testing objectives, testing assumptions, testing organization, and testing tools, along with effort and cost estimates.

-------

Key points to remember


The developer’s role here is not trivial. As you contribute to this strategy document, keep these three points in mind:

  • If you are working on a large project, you need to formulate an overall Testing Strategy during the analysis phase. The Testing Strategy defines the overall approach to testing and describes how the testing process will ensure that the solution has the appropriate level of quality and reliability.

  • The Testing Strategy provides the overall guidelines from which all future testing decisions are made. A well-crafted Testing Strategy allows the rest of the testing process to be defined more effectively.

  • The Testing Strategy needs to be understood and approved by the sponsor. If the strategy is accepted, there is a much better likelihood that the final solution will meet the customer’s expectations.

Testing Stop Process

This can be difficult to determine. Many modern software applications are so complex, and run in such as interdependent environment, that complete testing can never be done. "When to stop testing" is one of the most difficult questions to a test engineer. Common factors in deciding when to stop are:

  • Deadlines ( release deadlines,testing deadlines.)
  • Test cases completed with certain percentages passed
  • Test budget depleted
  • Coverage of code/functionality/requirements reaches a specified point
  • The rate at which Bugs can be found is too small
  • Beta or Alpha Testing period ends
  • The risk in the project is under acceptable limit.

Practically, we feel that the decision of stopping testing is based on the level of the risk acceptable to the management. As testing is a never ending process we can never assume that 100 % testing has been done, we can only minimize the risk of shipping the product to client with X testing done. The risk can be measured by Risk analysis but for small duration / low budget / low resources project, risk can be deduced by simply: -

  • Measuring Test Coverage.
  • Number of test cycles.
  • Number of high priority bugs.

Testing Start Process

Testing is sometimes incorrectly thought as an after-the-fact activity; performed after programming is done for a product. Instead, testing should be performed at every development stage of the product. Test data sets must be derived and their correctness and consistency should be monitored throughout the development process.

If we divide the lifecycle of software development into “Requirements Analysis”, “Design”, “Programming/Construction” and “Operation and Maintenance”, then testing should accompany each of the above phases. If testing is isolated as a single phase late in the cycle, errors in the problem statement or design may incur exorbitant costs. Not only must the original error be corrected, but the entire structure built upon it must also be changed. Therefore, testing should not be isolated as an inspection activity. Rather testing should be involved throughout the SDLC in order to bring out a quality product.

Introduction to Software Testing

Testing is a process used to help identify the correctness, completeness and quality of developed computer software. With that in mind, testing can never completely establish the correctness of computer software.

There are many approaches to software testing, but effective testing of complex products is essentially a process of investigation, not merely a matter of creating and following rote procedure. One definition of testing is "the process of questioning a product in order to evaluate it", where the "questions" are things the tester tries to do with the product, and the product answers with its behavior in reaction to the probing of the tester. Although most of the intellectual processes of testing are nearly identical to that of review or inspection, the word testing is connoted to mean the dynamic analysis of the product—putting the product through its paces.

The quality of the application can and normally does vary widely from system to system but some of the common quality attributes include reliability, stability, portability, maintainability and usability. Refer to the ISO standard ISO 9126 for a more complete list of attributes and criteria.

Testing helps is Verifying and Validating if the Software is working as it is intended to be working. Thins involves using Static and Dynamic methodologies to Test the application.

Because of the fallibility of its human designers and its own abstract, complex nature, software development must be accompanied by quality assurance activities. It is not unusual for developers to spend 40% of the total project time on testing. For life-critical software (e.g. flight control, reactor monitoring), testing can cost 3 to 5 times as much as all other activities combined. The destructive nature of testing requires that the developer discard preconceived notions of the correctness of his/her developed software.

Software Testing Fundamentals

Testing objectives include

1. Testing is a process of executing a program with the intent of finding an error.
2. A good test case is one that has a high probability of finding an as yet undiscovered error.
3. A successful test is one that uncovers an as yet undiscovered error.

Testing should systematically uncover different classes of errors in a minimum amount of time and with a minimum amount of effort. A secondary benefit of testing is that it demonstrates that the software appears to be working as stated in the specifications. The data collected through testing can also provide an indication of the software's reliability and quality. But, testing cannot show the absence of defect -- it can only show that software defects are present.

Find Broken Links in your application

Broken Links also sometimes called as dead links are those links on the web which are permanently unavailable. Commonly found, 404 error is one example of such link. Now the question is how can we identify broken links with the help of QTP during the run session?

There can be two ways to do this:

  1. Using Automatic Page checkpoint.
  2. By manually creating a Page checkpoint...

Best practises with QTP scripts


This post refers to a thought provoking question which was asked on Testing Tools forum. In this query jp@QTP is looking for ways to optimize QTP scripts for best performance. Everyone knows we use automated testing tools to optimize our testing process. Unless you make full use of the capability of the tool and unless a tool is used sensibly and with proper planning, it would not yield any results. Just record-and-playback is never the solution for any project. You need to go deep inside to understand the intricacies of any tool. Any software testing tool is only as good as the test engineer using it. On those thoughts, I feel this was one of the best questions asked in the forums of late.

Top 100 Web Testing Questions Asked in Actual Interviews

Top 100 Web Testing Questions Asked in Actual Interviews


What are the important test scenarios for testing a web site?
As a Tester you should test GUI of the website,test whether the page layout and design elements are consistent through out the site,Whether all the links provided in the website are working properly,What are the expected loads on the server?performance of the website (check for webserver response time and database query time)under heavy loads.
As a Test Engineer you should also test the functionality of each and every object
existing in the web page while testing a web application

WRITE TEST CASES FOR URL(ADDRESS) TESTING

1->Test Objective -- To Verify the URL AddressTest Procedure/Steps -- 1. Open Internet Explorer. > 2. Enter valid URL in address box. > 3. press Enter.Expected Result -- URL should be open properly.Actual Result -- URL Open properly.
2->1.type URL in the address bar(for eg.click www.yahoo.com) and click 'go' button.2.check to see whether the page is navigated to the yahoo home page.3.if navigated to yahoo home page test case is passed else failed4.also check to see when we enter the URL in the address bar and press the enter button in the keyboard it navigates to the yahoo home page.5.when we click the refresh button in the yahoo home page the same page should be displayed.thats very easy.just write what u do in real time environment with a proper test case format.thats it.
What bugs are mainly come in webtesting what severity and priority we are giving
The bug that mainly comes in web testing are cosmetic bugs on web pages , field validation related bugs and also the bugs related to scalibility ,throughput and response time for web pages.
During the website application testing,bug related to the link broken also comes.
What is the difference in testing a CLENT-SERVER application and a WEB application ?
Client-server is computing architecture which separates a client from a server, and is almost always implemented over a computer network. Each client or server connected to a network can also be referred to as a node. The most basic type of client-server architecture employs only two types of nodes: clients and servers. This type of architecture is sometimes referred to as two-tier.Each instance of the client software can send data requests to one or more connected servers. In turn, the servers can accept these requests, process them, and return the requested information to the client. Although this concept can be applied for a variety of reasons to many different kinds of applications, the architecture remains fundamentally the same.These days, clients are most often web browsers, although that has not always been the case. Servers typically include web servers, database servers and mail servers.The interaction between client and server is often described using sequence diagrams. Sequence diagrams are standardized in the UML.In software engineering, a Web application or webapp is an application that is accessed with a Web browser over a network such as the Internet or an intranet.
Client-server is computing architecture which separates a client from a server, and is almost always implemented over a computer network. Each client or server connected to a network can also be referred to as a node. The most basic type of client-server architecture employs only two types of nodes: clients and servers. This type of architecture is sometimes referred to as two-tier.In software engineering, a Web application or webapp is an application that is accessed with a Web browser over a network such as the Internet or an intranet.
How to test Browser compatibility testing
Testing the application with multiple browsers (ie IE,Netscape navigator,Mozilla Firefox etc)is called browser compatibility testing
What are the typical problems in web testing?
1:server problems(ie server down or under maintance)2:HardWare problem3:DataBase problem
How to do browser testing( create a standard script and run it for the different browser combinations.)
The GUI architecture and events messaging differs from browser to borwser like IE use Win32::OLE messaging and firefox must be using some GTK based messaging. So it is generally difficult to create one standard script that runs on all browsers. But tools like Winrunner, QTP must be using complex procedures inside them to handle different browsers.to me, if my application supports different browsers like IE, firefox, opera, netscape i will try to do manual testing.

What are the important scenarios for testing emails? how do you test emails?
which tool is best for testing email?
Test the email is not a very easy scenario.We can categorised the different part on which tester may perform the testing.1) for incoming mail with attachment2) for outgoing mail with attachment3) mail failure4) Other properties like ;Delete,Edit etc.........1) for incoming mail with attachment :-- 1. Chek the proper incoming address or id.2. Chek Not only the One address(TO),but also for the Ccc and Bcc Addresses.3. Check the max and min limit for number of addresses.4. Check if address has some error like @ or . is missing .5. Check if address has more than 1 @ sign .6. Check if . has arrives less than 1 or more than standard time (as per registered)7. Check if address has arrives more than 1 time.8. Check address only have @, ., _ and - special symbols that are standard signs.9. Check taht mail dose not have unnecessary content with it self.10. If there is/are any attachments then they open properly.11. The attachment size not exceeds the standard size.12. If there are more than 1 attachments then the calculated size must be under the Standard size.13. If email content have some images or some different Flash pic must show properly.14. Some time mail have some different extentions file then it shows properly.15. If the user read the mail ,then it should be marked as readable.other...........2) for outgoing mail with attachment :-- 1. Check the Address as we done prior.2. Here we must check for the attachments.3. For all the send pictures 4. Mail content should have the proper content.3) mail failure:-- Check for the mail failure4) Other properties like ;Delete,Edit etc.........

what happens in a web application when you enter all the data and click on submit buttonsuddenly the connection goes off?where the data will go pls answer immdiately ?
Its a Good Quetion actually after entering all the data we pressed on submit button it depends on when connection goes off means after some tiem like one or 2 minutes or immediately if it is immedialtely connection goes off then no data will be submitted
If the data reaches the web server by the time of disconnection,the system will persist the data in the database .If the connection fails before reaching the server ,the data won't be persisted and data will be lost.
What is the difference in testing a CLIENT-SERVER application and a WEB application ?
1->client/server application is a 2-tier application where as web application is an n-tier application.
in client server pplications we loaded the execution path in every system to call the AUT ,but in web applications we will use browsers to call the AUT.in web app. there are browser,web server and database server available ,but in client server app. forms & reporting and database server available.web app. for response time hits per seconds and throughputin client server app. for avg response time
2>client/server application : Is nothing but a 2 tire architecture ie, one server more clients.Web/server : N-tire architecture ie more servers and clients are interconnected.
3->client server application is installed in server and client machine is installed with exe file and we call application through exe file.client server transaction are predictable and controlled limited numbers of users2 tierweb/servern tierapplication installed in server and we call the application from browser not exe file.Transaction unlimited and are unpredictable.

What command is used to launch a application in winrunner?
invoke_application command used to launch application in WR. see function generator in WR

Invoke command we will use to invoke a application in winrunner.invoke_aplication(path)
What is the difference between testing in client-server applications and web based applications?
Client Server Testing:-In client server testing test engineer are conduct the following testings:-1.Behaviour testing(GUI TESTING)2.Input domain testing3.Error Handling testing4.Backend testingIn Web testing test engineer are condut the following testings:-1.Behaviour Testing2.Static web testing3.Input domain testing4.Backend testing5.Error handling testing5.Frame Level testing
What is your approach or how do you start Testing an Webapplication
The first thing u need is to go through the specification and without using the specification u are just playing with the application.So specification is the main interface to the for any software to be tested
First Do The GUI testing after finishing that we can go for Functionality Testing
During the passward field testing. What sould be the focus (give answer in one word)
1. password should be in encrypted form2. the field can not be copied either by right clicking of the mouse or by ctrl+c option

In n tier Architecture What are the factors should be considered for testing?
Basically 3-tier architecture is for windows based application. Where as n-tier architecture is for web-based applications. So, We should do the testing related to web-testing.
From the testability point of view what is the difference between client/server testing and web testing
Client Server testing is a three tier architecture and when testing has to be done on this we need to consider all types of testing like the stress testing , data - volume testing, load testing and performance testing. When u are doing a normal web testing then you will be testing navigation testing, frame testing, broken links or missing URL's and static text testing.
What type of testing is carried out to find memory- leakages?give me a sample example?Through Volume testing it is possible. i.e., An application tries to retrieve large amount of data that require large temporary buffer area. If the data exceed the buffer area the situation of memory leakage will occur and query will fail without returning any result as sorting didn’t got finished as buffer exceeds the limit.We need to know the memory size before the test execution and after test execution by using memory related API functions or MFC functions.
What are the important test scenarios for testing a web site?
As a Tester you should test GUI of the website,test whether the page layout and design elements are consistent through out the site,Whether all the links provided in the website are working properly,What are the expected loads on the server?performance of the website (check for webserver response time and database query time)under heavy loads.