Tips on Interview » Testing Tools

Loadrunner and Performance Testing Training Institutes

admin — Thu, 12 Jul 2012 02:54:51 +0000

Loadrunner and Performance Testing Training Institutes

HP LoadRunner is a load testing product that determines application scalability, behavior, and performance. It emulates thousands of virtual users, and identifies and isolates performance bottlenecks across and within each tier. Load runner is an mercury interactive automated testing tool for testing the load and performance of an application under test. While the application is under load, Loadrunner accurately measures, monitors and analyzes a system’s performance and functionality.

Loadrunner is a industry standard enterprise level load testing tool
We perform load testing once we are done with interface (GUI) testing.
Load Runner has 4 components:

*Virtual User Generator (VUGEN)
* Controller
* Analysis
* Load Generator.

Performance Testing is the process by which software is tested and tuned with the intent of realizing the required performance. Performance Testing is testing conducted to evaluate the compliance of a system or component with specified performance requirements.
The performance testing is a part of performance engineering commonly referred to as load, spike, and stress testing, as well as validating system performance.

Performance testing is all about applying production workloads to pre-deployment systems while simultaneously measuring system performance and end-user experience. Performance Testing with Loadrunner professionals have lots of opportunities in their career.

The Best Loadrunner and Performance Testing Training Institutes in Hyderabad are

1) Revanth Technologies
B1, 3rd Floor,
Eureka Court, Near Image Hospital,
Ameerpet, Hyderabad
Ph : 040 – 64559566
+91 9290971883
Email ID : revanthonlinetraining@gmail.com
Website : http://www.revanthtechnologies.com/loadrunner-and-performance-testing-online-training-from-india.php

2) Online Training from India
B1, 3rd Floor,
Eureka Court, Near Image Hospital,
Ameerpet, Hyderabad
Ph : +91 9290931214
Email ID : onlinetrainingfromindia@gmail.com
Website : http://www.onlinetrainingfromindia.com/loadrunner-and-performance-testing-online-training-from-india.php

3) Srihitha Technologies
B7,3rd Floor,
Eureka Court, Near Image Hospital,
Ameerpet,Hyderabad
Ph : 040 – 64619566
+91 9394799566
Email ID : srihithaonlinetraining@gmail.com
Website : http://www.srihithatechnologies.com/loadrunner-and-performance-testing-training.php

LoadRunner Training Institutes

admin — Mon, 09 Jul 2012 02:49:13 +0000

LoadRunner Training Institutes

LoadRunner is a testing tool that load tests the application by emulating an environment in which multiple users work concurrently. While the application is under load, LoadRunner accurately measures, monitors and analyzes a system’s performance and functionality. Load runner is a mercury interactive automated testing tool for testing the load and performance of an application under test.

LoadRunner is a performance and load testing product by HP for examining system behavior and performance, while generating actual load. LoadRunner works by creating virtual users who take the place of real users operating client software, such as sending requests using the HTTP protocol to IIS or Apache web servers. Load Runner enables you to test your system under controlled and peak load conditions. The main objective of using Load Runner is to simulate the real time scenario where multiple users concurrently login to use a given application.

LoadRunner consists of:

Virtual User Generator (VUGen): We can emulate the real world user behavior using VuGen that’s why the name virtual user [Dictionary meaning: Existing or resulting in essence or effect though not in actual fact, form, or name]. This is the place where we record and write automated scripts.

Controller: Here we run the scripts generated above. This controls the various load generators and scenarios associated with them.

Analysis: This gives the detailed results and presents them beautifully using reports, charts and graphics.

The Best LoadRunner Training Institutes in Hyderabad are

ETL Testing Training Institutes

admin — Sat, 07 Jul 2012 05:32:16 +0000

ETL Testing Training Institutes

There are several software tools that can be used to support the process, but sometimes specific software programs need to be coded to achieve the objective. In such case ETL (Extract, Transform and Load) is a process in data warehousing responsible for pulling data out of the source systems and placing it into a data warehouse. ETL is a set of computer programs or processes that capture the appropriate data from the routine or operational systems, clean it up, and store it a standard and consistent format.

ETL Testing verifies that data is transformed correctly according to various business requirements and rules. It makes sure that all projected data is loaded into the data warehouse without any data loss. ETL testing validates the data transformed correctly from OLTP to data warehouse. The ETL methodology maintains a process for providing audit and logging capabilities.

There are numerous tools that help you with ETL process – Informatica, Control-M being a few notable ones. ETL tool is used to make a perfect integration between different data sources from different departments. ETL tool will work as an integrator, extracting data from different sources; transforming it in preferred format based on the business transformation rules and loading it in consistent Database known are Data Warehouse.

ETL Tester is responsible to executing back-end data-driven test efforts with a focus on data transformations between various systems and a data warehouse.

The Best ETL Testing Training Institutes in Hyderabad are

Software Testing Tools Training Institutes

admin — Fri, 06 Jul 2012 11:39:25 +0000

Software Testing Tools Training Institutes

Software Testing is a crucial tool to provide a quality product without any bug or issue. Software testing is more than just error detection.As computers and software are used in critical applications, the outcome of a bug can be severe. Bugs can cause huge losses. Hence, Software Testing is the process of executing a program or system with the intent of finding errors. The role of a software tester is also crucial as they are trained to pick out flaws, if any, in the software.

Software testing is done in each phase of product life cycle from requirement specifications, design, coding, to the user acceptance. Correctness testing and reliability testing are two major areas of testing. The proper use of testing tools makes testing easier, more effective, and more productive. During the release of code testing is very essential, then a software tester must efficiently manage workload, have high productivity, exhibit optimal time management and organization skills.

To become a software tester it requires in depth analytical and technical skills to test the applications with many complex software structures. Knowledge of programming languages is required for unit testing, scripting skill essential for Automation testing. Testing has created several levels and types and specialization in various types of testing for a software tester such as in functional, performance, security and management tools like Quality Center from HP, CQTM from IBM etc.

As the quality is very prominent for the users along with constant advancements in software quality testing, the field of software testing have a great advance in future due to the changes.

The Best Software Testing Tools Training Institutes in Hyderabad are

Basic Concepts of Software Testing

admin — Sun, 24 Jun 2012 03:20:23 +0000

Basic Concepts of Software Testing

Software testing is a field with no set “best practices.” Because so much of testing is based on the particular context of the test, it’s often difficult to clarify, categorize and dispense advice on aspects of software testing. Testing is often confused with the processes of quality control and quality assurance. Testing is the process of creating, implementing and evaluating tests.

Software Tester is the one who performs testing and find bugs, if they exist in the tested application.

The goal of Software Testing is to:

* Demonstrate That Faults Are Not Present
* Find Errors
* Ensure That All the Functionality Is Implemented
* Ensure the Customer Will Be Able To Get His Work Done

Software testing is an important part of the software development process. In normal software development there are four important steps referred to as PDCA:

* Plan: Define the goal and the plan for achieving that goal.

* Do/Execute: Depending on the plan strategy decided during the plan stage we do execution accordingly in this phase.

* Check: Check/Test to ensure that we are moving according to plan and are getting the desired results.

* Act: During the check cycle, if any issues are there, then we take appropriate action accordingly and revise our plan again.

So developers and other stakeholders of the project do the “planning and building,” while testers do the check part of the cycle. Therefore, software testing is done in check part of the PDCA Cycle.

Software testing is the process of executing a program / application under positive and negative conditions by manual or automated means. It checks for the Specification, Functionality and Performance.

There are different types of software testing:

Black box testing is a testing strategy based solely on requirements and specifications. Black box testing requires no knowledge of internal paths, structures, or implementation of the software being tested.

White box testing is a testing strategy based on internal paths, code structures, and implementation of the software being tested. White box testing generally requires detailed programming skills.

Gray box testing: In this we look into the “box” being tested just long enough to understand how it has been implemented. Then we close up the box and use our knowledge to choose more effective black box tests.

Modes of Testing

* Static Analysis does not involve actual program execution. The code is examined, it is tested without being executed Ex: – Reviews

* Dynamic In Dynamic, The code is executed. Ex: – Unit testing

The basic terms and concepts of software testing:

* Software Quality: Learn how software quality is defined and what it means.

* Software quality is the degree of conformance to explicit or implicit requirements and expectations.

* Dimensions of Quality: Learn the dimensions of quality. Software quality has dimensions such as Accessibility, Compatibility, Concurrency, Efficiency.

* Software Quality Assurance: Learn what it means and what its relationship is with Software Quality Control. Software Quality Assurance is a set of activities for ensuring quality in software engineering processes.

* Software Quality Control: Learn what it means and what its relationship is with Software Quality Assurance. Software Quality Control is a set of activities for ensuring quality in software products.

* SQA and SQC Differences: Learn the differences between Software Quality Assurance and Software Quality Control. SQA is process-focused and prevention-oriented but SQC is product-focused and detection-oriented.

* Software Development Life Cycle: Learn what SDLC means and what activities a typical SDLC model comprises of. Software Development Life Cycle defines the steps/stages/phases in the building of software.

* Definition of Test: Learn the various definitions of the term ‘test’.

Levels of Software Testing

admin — Sun, 24 Jun 2012 03:09:46 +0000

Levels of Software Testing

Software Testing is the process of running a program in order to find the errors and mistake of the program at the time of execution. The main intention of Software Testing is to evaluate an attribute and to check the potentiality of the program whether it gives the required output. Testing is not just giving data’s and obtaining the output, it is entirely different – it works at the time if the software fails to function or if it never gives the required output.

Tests are frequently grouped by where they are added in the software development process, or by the level of specificity of the test. Each completed level represents a milestone on the project plan and each stage represents a known level of physical integration and quality. These stages of integration are known as test levels.

The following are the levels of Software testing:

Unit Testing:

Unit testing is a procedure used to validate that a particular module of source code is working properly. The procedure is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed.

The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. Unit testing provides a strict, written contract that the piece of code must satisfy.

Integration Testing:

After completing the unit testing and dependent modules development, programmers connect the modules with respect to HLD for Integration Testing. Integrated System Testing (IST) is a systematic technique for validating the construction of the overall Software structure while at the same time conducting tests to uncover errors associated with interfacing.

The objective is to take unit tested modules and test the overall Software structure that has been dictated by design.

System Testing:

The purpose of this test is to evaluate the systems compliance with the specified requirements. System testing is performed throughout the system as part of a functional specification (s) (FRS) and / or a System Requirement Specification (SRS). System testing is a phase of inquiry, where the emphasis is to have almost a destructive attitude and test not only the design but also the behavior and believed the same expectations.

System testing includes load testing and stress testing. Once the load testing and stress tests are completed successfully, the next level of Alpha or Beta Testing will proceed.

Usability Testing:

This section includes different concepts and definitions of Usability testing from Software point of view. It is a black box technique and is used to identify any error(s) and improvements in the Software by observing the users through their usage and operation.

During this test, testing team concentrates on the user friendliness of build interface. It consists of following sub tests.

User Interface Test: Ease of use (screens should be understandable to operate by End User.

Speed in interface: – Less number of task to complete task

Manual Support Test: – Context sensitiveness of user manual.

Functional Testing:

Functional Testing of the software is conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements.

Performance Testing:

Performance testing measures the efficiency with respect to time and hardware resources of the test item under typical usage. This assumes that a set of non-functional requirements regarding performance exist in the item’s specification. Performance testing is considered as one of the important and mandatory testing type in terms of following aspects:

Speed (i.e. Response Time, data rendering and accessing)
Capacity
Stability
Scalability

Load Testing:

Also Known as Scalability Testing. This type of testing identifies the maximum capacity of Software and its behavior at peak time.

During this test, test engineers execute application build under customer expected configuration and load to estimate performance.

Most of the time, Load testing is performed with the help of automated tools such as Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test etc.

Stress Testing:

Stress testing evaluates the performance of the test item during extreme usage patterns. Typical examples of “extreme usage patterns” are large data sets, complex calculations, extended operation, limited system resources, etc.

During this test, Test engineers estimates the peak load. To find out the maximum number of users for execution of out application user customer expected configuration to estimate peak load.

Security Testing:

Security testing involves the testing of Software in order to identify any flaws ad gaps from security and vulnerability point of view.
Security testing should ensure:

Confidentiality
Integrity
Authentication
Availability
Software data is secure
Software is according to all security regulations.
Input checking and validation etc.

Smoke testing:

Smoke testing is non-exhaustive software testing, ascertaining that the most crucial functions of a program work, but not bothering with finer details.

Smoke testing determines whether the system is sufficiently stable and functional to warrant the cost of further, more rigorous testing. Smoke testing may also communicate the general disposition of the current code base to the project team. Specific standards for the scope or format of smoke test cases and for their success criteria may vary widely among projects.

Alpha Testing:

The application is tested by the users who doesn’t know about the application. Done at developer’s site under controlled conditions
Under the supervision of the developers.

Acceptance Testing:

Acceptance Testing is a level of the software testing process where a system is tested for acceptability. The purpose of this test is to evaluate the systems compliance with the business requirements and assess whether it is acceptable for delivery.

It is the final test action before deploying the software. The goal of acceptance testing is to verify that the software is ready and can be used by the end user to perform the functions for which the software was built.

Beta Testing:

This test is performed after Alpha testing has been successfully performed. In beta testing a sample of the intended audience tests the application. Beta testing is also known as pre-release testing.

Before the final release of the software is released to users for testing where there will be no controlled conditions and the user here is free enough to do what ever he wants to do on the system to find errors.

Regression Testing

Testing with the intent of determining if bug fixes have been successful and have not created any new problems whenever a change in a software application is made. This type of testing is done to ensure that no degradation of baseline functionality has occurred.

The intent of Regression testing is to ensure that a change, such as a bug fix did not result in another fault being uncovered in the application.

Monkey Testing:

Testing the application randomly like hitting keys irregularly and try to breakdown the system there is no specific test cases and scenarios for monkey testing.

How do you create a test plan/design?

admin — Thu, 17 Mar 2011 13:56:19 +0000

How do you create a test plan/design?

Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speaking…

* Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application.
* Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases.
* It is the test team that, with assistance of developers and clients, develops test cases and scenarios for integration and system testing.
* Test scenarios are executed through the use of test procedures or scripts.
* Test procedures or scripts define a series of steps necessary to perform one or more test scenarios.
* Test procedures or scripts include the specific data that will be used for testing the process or transaction.
* Test procedures or scripts may cover multiple test scenarios.
* Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope.

* Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment.
* Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing.
* A pretest meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release.

Inputs for this process:

* Approved Test Strategy Document.
* Test tools, or automated test tools, if applicable.
* Previously developed scripts, if applicable.
* Test documentation problems uncovered as a result of testing.
* A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code, and software complexity data.

Outputs for this process:

* Approved documents of test scenarios, test cases, test conditions, and test data.
* Reports of software design issues, given to software developers for correction.

Manual Testing Interview Questions for Fresher

admin — Sat, 12 Feb 2011 03:18:17 +0000

The following below mentioned Questions are frequently asked questions for fresher Manual Testing job.

What is Manual Testing?

What is smoke Testing?

What is Alpha Testing?

What is the accessibility testing?

What is Ad Hoc Testing?

What is the Alpha Testing?

What is Beta Testing?

What is Component Testing?

What is Compatibility Testing?

What is Data Driven Testing?

What is Concurrency Testing?

What is Conformance Testing?

What is Context Driven Testing?

What is Conversion Testing?

What is Depth Testing?

What is Recovery Testing?

What is the Regression testing?

What is the Re-testing testing?

What is Stress Testing?

What is Sanity Testing?

What’s the Volume Testing?

What’s the Usability testing?

What is Scalability Testing?

What is Soak Testing?

What’s the User Acceptance testing?

What is Localization Testing?

What is Loop Testing?

What is Mutation Testing?

What is Positive Testing?

What is Monkey Testing?

What is Negative Testing?

What is Path Testing?

What is Ramp Testing?

What is Performance Testing?

What is Dynamic Testing?

What is End-to-End testing?

What is Endurance Testing?

What is Installation Testing?

What is Gorilla Testing?

What is Exhaustive Testing?

Bug Reports Interview Questions

admin — Sat, 27 Nov 2010 13:27:37 +0000

Bug Reports frequently asked questions

1. Be very specific when describing the bug. More concise means less ambiguous, so less clarification will be needed later on. Don’t let there be any room for interpretation.

2. Calling windows by their correct names (by the name displayed on the title bar) will eliminate some ambiguity.

3. Don’t be repetitive. Don’t repeat yourself. Also, don’t say things twice or three times.

4. Try to limit the number of steps to recreate the problem. A bug that is written with 7 or more steps can usually become hard to read. It is usually possible to shorten that list.

5. Start describing with where the bug begins, not before. For example, you don’t have to describe how to load and launch the application if the application crashes on exit.

6. Proofreading the bug report is very important. Send it through a spell checker before submitting it.

7. Make sure that all step numbers are sequenced. (No missing step numbers and no duplicates.)Please make sure that you use sentences.

8. Don’t use a condescending or negative tone like “it’s still broken” or “it is completely wrong” in your bug reports and also Don’t use vague terms like “It doesn’t work” or “not working properly”.

9. If there is an error message involved, be sure to include the exact wording of the text in the bug report. If there is a GPF (General Protection Fault) be sure to include the name of the module and address of the crash.

10. Bug report is your work Product, and you should take pride in your work. Once the text of .the report is entered, you don’t know whose eyes will see it. You might think that it will go to your manager and the developer and that’s it, but it could show up in other documents that you are not aware of, such as reports to senior management or clients, to the company intranet, to future test scripts or test plans.

Winrunner Interview Questions

admin — Thu, 18 Nov 2010 14:24:14 +0000

Winrunner Interview Questions

1 Define Winrunner?

Ans: Winrunner is Mercury Interactive Functional Testing Tool.

2 Give short answer about Winrunner?

Ans: Winrunner helps you automate the testing process, from test development to execution. You can create adaptable and reusable test scripts that challenge the functionality of your application. Prior to a software release, you can run these tests in a single overnight run enabling you to detect defects and ensure superior software quality.

3 What kind of applications Winrunner suits?

Ans: Visual Basic, Power Builder, Active-X, Java and Web Applications

4 How many types of Run Modes are available in Winrunner?

Ans: Winrunner provides three types of Run Modes.

* Verify Mode
* Debug Mode
* Update Mode

5 What is the Verify Mode?

Ans: In Verify Mode, Winrunner compares the current result of application to its expected result.

6 What is Debug Mode?

Ans: In Debug Mode, Winrunner tracks the defects in a test script.

7 What is Update Mode?

Ans: In Update Mode, Winrunner updates the expected results of test script.

8 How many types of recording modes available in Winrunner?

Ans: There are two type of recording in Winrunner.

* Context Sensitive recording records the operations you perform on your
Application by identifying Graphical User Interface (GUI) objects.
* Analog recording records keyboard input, mouse clicks, and the precise x- and Y-coordinates traveled by the mouse pointer across the screen.

9 What do you mean by Context Sensitive recording?

Ans: Winrunner captures and records the GUI objects, windows, keyboard inputs, and Mouse clicks activities through Context Sensitive Recording.

10 What is the meaning of Analog recording?

Ans: It captures and records the keyboard inputs, mouse click and mouse movement. It will not capture the GUI objects and Windows.

11 Where are stored Debug Result?

Ans: Debug Results are always saved in debug folder.

12 What is Winrunner testing process?

Ans: Winrunner involves six main steps in testing process.

* Create GUI map
* Create Test
* Debug Test
* Run Test
* View Results
* Report Defects

13 What is the GUI SPY?

Ans: You can view the physical properties of objects and windows through GUI SPY.

14 How many types of modes for organizing GUI map files?

Ans: Winrunner provides two types of modes-

* Global GUI map files
* Per Test GUI map files

15 What is contained in GUI map files?

Ans: GUI map files stored the information, it learns about the GUI objects and windows.

16 How does Winrunner recognize objects on the application?

Ans: Winrunner recognize objects on the application through GUI map files.
When Winrunner runs a test, it uses the GUI map to locate objects. It reads an
Object’s description in the GUI map and then looks for an object with the same Properties in the application being tested.

17 What is the difference between GUI map and GUI map files?

Ans:
* The GUI map is actually the sum of one or more GUI map files. There are two modes for organizing GUI map files.
* Global GUI Map file: a single GUI Map file for the entire application
* GUI Map File per Test: Winrunner automatically creates a GUI Map file for each test created. GUI Map file is a file which contains the windows and the objects learned by the Winrunner with its logical name and their physical description.

18 How do you view the GUI map content?

Ans: We can view the GUI map content through GUI map editor.

19 What is the use of the checkpoint?

Ans: Checkpoint enables you to check your application by comparing it’s expected results Of application to actual results.

20 What is Execution Arrow?

Ans: Execution Arrow indicates the line of script being executed.

21 How does Win Runner evaluate test results?

Ans: Following each test run, Win Runner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window.

22 What are the reasons that Win Runner fails to identify an object on the GUI?

Ans: Win Runner fails to identify an object in a GUI due to various reasons.

* The object is not a standard windows object.
* If the browser used is not compatible with the Win Runner version, GUI Map Editor will not be able to learn any of the objects displayed in the browser Window.

23 How to use Win Runner to check whether the record was updated or the record Was deleted or the record was inserted or not?

Ans: Using Win Runner check point features: Create->dDB checkpoint->Runtime Record Check

24 How to use Win Runner to test the login screen?

Ans: When you enter wrong id or password, you will get Dialog box.
1. Record this Dialog box
2. User win_exists to check whether dialog box exists or not
3. Playback: Enter wrong id or password, if win_exists is true, then your application is Working good. Enter good id or password, if win_exists is false, then your Application is working perfectly.

Different kinds of Testing

admin — Thu, 18 Nov 2010 13:43:31 +0000

Different kinds of Testing

1 White box testing - In white box testing tests Are based on coverage of code statements, branches, paths, and conditions, it is purely based on knowledge of the internal logic of an application’s code.

2 Unit testing – Unit testing is typically done by the programmers and not by testers, as it requires detailed knowledge of the internal program design and code. It is the most ‘micro’ scale of testing; to test particular functions or code modules. It is not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.

3 Incremental integration testing - It is done by programmers or by testers, continuous testing of an application as new functionality is added; requires that various aspects of an application’s functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed.

4 Integration testing – This type of testing is especially relevant to client/server and distributed systems, it involves testing of combined parts of an application to determine if they function together correctly. The ‘parts’ can be code modules, individual applications, client and server applications on a network, etc.

5 Functional testing – This is black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn’t mean that the programmers shouldn’t check that their code works before releasing it (which of course applies to any stage of testing.)

6 System testing – It covers all combined parts of a system, it is black-box type testing that is based on overall requirements specifications.

7 End-to-end testing - This type of testing is similar to system testing, IT is the ‘macro’ end of the test scale which involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

8 Sanity testing – It is typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort.

For example, if the new software is crashing systems every 10 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a ‘sane’ enough condition to warrant further testing in its current state.

9 Regression testing – Automated testing tools can be especially useful for this type of testing re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle..

10 Acceptance testing – final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.

11 Load testing – This involves testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.

12 Stress testing – Stress testing term is often used interchangeably with ‘load’ and ‘performance’ testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.

13 Performance testing - Ideally ‘performance’ testing (and any other ‘type’ of testing) is defined in requirements documentation or QA or Test Plans, Performance testing term often used interchangeably with ‘stress’ and ‘load’ testing

14 Usability testing – This type of testing is done for ‘user-friendliness’. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.

15 Install/uninstall testing – testing of full, partial, or upgrade install/uninstall processes.

16 Recovery testing –This testing is done to check how well a system recovers from hardware failures, crashes, or other catastrophic problems.

17 Security testing – security testing is done to know how well the system protects against unauthorized internal or external access, willful damage, etc this may require sophisticated testing techniques.

18 Compatibility testing – This method is used for testing how well software performs in a particular hardware/software/operating system/network/etc. environment.

19 Exploratory testing – often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.

20 Ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.

21 User acceptance testing – This testing is done for determining if software is satisfactory to an end-user or customer.

22 Comparison testing – comparing software weaknesses and strengths to
competing products.

23 Alpha testing – It is typically done by end-users or others, not by programmers or testers.It involves testing of an application when development is nearing completion, Minor design changes may still be made as a result of such testing.

24 Beta testing – testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.

25 Mutation testing – a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (‘bugs’) and retesting with the original test data/cases to determine if the ‘bugs’ are detected. Proper implementation requires large computational resources.

Testing Interview Questions

admin — Thu, 18 Nov 2010 13:40:22 +0000

Testing Interview Questions Asked In Companies

1. What is configuration Management?
2. What is change management?
3. What are Severity and priority levels?
4. What is Data integrity and Data validity?
5. What are the browsers available and explain their versions?
6. Is it possible that Quality variates project to project?
7. What are GUI Map files and explain their Contents?
8. What is Data base check point and why we go for that?
9. What is the difference between the Client server application and a Web application?
10. Does win runner Supports Web applications?
11. What is process Management?
12. What is an Error, Defect, and Bug?
13. What is Quality?
14. Which version of Win runner you are using?
15. What is Build Verification and why we go for it?
16. What is Defect density?
17. What is Integration testing?
18. What is Static testing and types of Static testing?
19. What is Validation testing?
20. What is Data driven testing and why we go for data driven testing?
21. What is the definition of Testing?
22. What is Sanitation Testing?
23. What is a test plan?
24. Actually when will be the testing people will be involved in the project?
25. Define low priority and high severity?
26. Whom do you report the Bugs?
27. What are the contents present in a test plan?
28. Which model will you follow?
29. Which Bug tracking tool do you use and what are the contents present in it?
30. If a bug is reported what will be the Next work done?
31. How to write test cases using Use case diagrams?
32. For a given condition (X>=0<100) how many test cases you can write?
33. Explain Classical water fall model?
34. Integration testing is conducted by developers or testers?
35. An application is given how do you test for example the money deposited in account no.2 should be transferred to Account no.1?
36. What is V model?
37. What is BUG life cycle?
38. What is alpha testing and beta alpha testing?
39. What is verification testing and validation testing?
40. What are ISO and CMM standards levels?
41. Which should be given more preference I.e. severity or priority?
42. How to use the test director in your project?
43. What is use of recovery manager in QTP?
44. What are the add INS in QTP?
45. What are expressions in QTP?
46. If the developers are not convinced with your bug in this case what will you do?
47. If the developers are developing the application then what is the job assigned to the testers?
48. What is system testing?
49. What is smoke testing?
50. What is sanity testing?

TESTING INTERVIEW QUESTIONS probably asked for Second Round.

51. What are joins and subjoins in the data bases?
52. What is data driven testing?
53. What is verification and validation?
54. What is Quality Assurance (QA) and Quality Control (QC)?
55. Is Verification is related to QA and Validation is related to QC?
56. Which type of model you follow basically in your project?
57. What is a use case?
58. How to test a Bike?
59. How to test a Lift (Elevator).?
60. Which configuration Management tool do you use?
61. Which Bug tracking tool do you use?
62. Explain Bug life cycle?
63. What is Regression testing?
64. What is ALPHA testing and BETA testing?
65. What types of testing comes under Non functional testing?
66. What is TEST DIRECTOR?
67. What is CMM and CMM I ?
68. What are Expressions in Win runner?
69. What is a Compile module?
70. Is it Necessary to open the tool first or the application first?
71. After getting a bug what will you do?
72. If you add a new object or a new module for the existing application then how will you test the application?
73. Which Defect tracking tool do you use?
74. What is change management?
75. What is smoke Testing?
76. What is sanity testing?
77. A application is given to you but the requirements and functionalities are missing what will you do to start the testing?
78. Which testing documents will be received by the client?
79. What is BVA and ECP?
80. Do we have recovery manger in Win runner?
81. How does the win runner recognizes the project?
82. How is win runner is used in the project?
83. What is the difference between Sleep and wait in win runner?
84. What is integration testing and types of testing present?
85. What is system testing?
86. What is data driven testing?
87. What is functionality testing?
88. If requirements are given to you then how do you write the test cases for it?
89. What are the types of recording modes in win runner?
90. What are the three modes of running a test in win runner?
91. What is synchronization point?
92. What are the contents present in a test case?
93. Do we need testing for the project?
94. What is code review and code walk through?
95. At which phase the testing starts (begin) in the project?
96. How do we test Client server applications and a Web application?
97. What is verification and validation?
98. What is adhoc testing?
99. What is traceability matrix?
100. What is base line document?
101. What is Test Life Cycle?
102. What is regression testing and retesting?
103. What is a BUG LIFE CYCLE?
104. What is a Bug?
105. What are defects?
106. What is functionality testing and system testing?
107. A project has to be released in one day but the testing people got that project from the developers half of the day before so what they have to do to complete the testing process?
108. What are severity level and priority levels?
109. Which version of WINRUNNER and QTP you are using in the project?
110. What is the use of Recovery manager in QTP?
111. What is retesting and regression testing?
112. Write the SQL queries for the following EMP table to select the employee id and his details from EMP table?
113. For example: employee dept and employee id and employee name and employee salary?

Performance Testing Interview Questions

admin — Thu, 18 Nov 2010 12:19:17 +0000

Performance Testing Interview Questions

Q) What is Performance testing?

A) Timing for both read and update transactions should be gathered to determine whether system functions are being performed in an acceptable time frame. This should be done standalone and then in a multi user environment to determine the effect of multiple transactions on the timing of a single transaction.

Q) What is Ramp up? How do you set this?

A) This option is used to gradually increase the amount of Vusers/load on the server. An initial value is set and a value to wait between intervals can be specified. To set Ramp Up, go to? Scenario Scheduling Options?

Q) Explain the following functions: -

lr_debug_message: – The lr_debug_message function sends a debug message to the output log when the specified message class is set.

lr_output_message – The lr_output_message function sends notifications to the Controller Output window and the V user log file.

lr_error_message – The lr_error_message function sends an error message to the LoadRunner Output window.

lrd_stmt – The lrd_stmt function associates a character string (usually a SQL statement) with a cursor. This function sets a SQL statement to be processed.

lrd_fetch – The lrd_fetch function fetches the next row from the result set.

Q) What does v user_init action contain?

A) V user_init action contains procedures to login to a server.

Q) How many types of V user are available in LoadRunner?

A) There are many types of V user like DB V user, SAP V user, Web V user, RTE, GUI V user.

Q) What does v user_end action contain?

A) V user_end section contains log off procedures.

Q) What is V user Generator?

A) There are two methods – GET & POST.

Q) What is Think Time?

A) it is used for making the v-users wait for some time between the requests in order to simulate as if the real users are using the server.

Q) What is the Transaction?

A) To measures the performance of the server, we define the Transaction.

Q) What’s the Rendezvous Point?

A) We can insert Rendezvous Points into V user script to emulates the heavy load on the server.

Q) What’s the V user Inuit Section?

A) In V user In it section, LoadRunner records log in the server.

Q) What are the section contain by the VuGen while creating a V user script?

A) VuGen contain the three section-
* V user In it Section
* Action Section
* V user end Section

Q) How do you edit the script?

A) We can edit the script by inserting the Transaction Points and Rendezvous Points.

Q) What’s the running V user graph?

A) It displays the number of V users that execute the V user script each seconds of scenario run.

Q) What’s the percentile graph?

A) It displays the percentage of transaction which were performed with in given time.

Q) What does Result window contain?

A) Result Window open with two panes-
* Tree Pane
* Summary Pane

Q) How many types of Correlation?

A) Correlation are two types-
* Manual Correlation
* Automatic Correlation

Q) What is Automatic Correlation?

A) Automatic Correlation is set some rules for correlation.

Q) Where do you set automatic correlation options?

A) Automatic correlation from web point of view can be set in recording options and correlation tab. Here we can enable correlation for the entire script and choose either issue online messages or offline actions, where we can define rules for that correlation. Automatic correlation for database can be done using show output window and scan for correlation and picking the correlate query tab and choose which query value we want to correlate. If we know the specific value to be correlated, we just do create correlation for the value and specify how the value to be created.

Q) Which Correlation function you have used?

A) web_reg_save_param

Q) What is the syntax for think time?

A) lr_think_time

Q) What is the Elapsed Time?

A) It is total time take since request is set and obtained the result.

Q) What is a scenario?

A) A scenario defines the events that occur during each testing session. For example, a scenario defines and controls the number of users to emulate, the actions to be performed, and the machines on which the virtual users run their emulations.

Q) If you want to stop the execution of your script on error, how do you do that?

A) The lr_abort function aborts the execution of a Vuser script. It instructs the Vuser to stop executing the Actions section, execute the vuser_end section and end the execution. This function is useful when you need to manually abort a script execution as a result of a specific error condition. When you end a script using this function, the Vuser is assigned the status “Stopped”. For this to take effect, we have to first uncheck the? Continue on error? Option in Run-Time Settings.

Q) What is Scenario Wizard?

A) We can create new scenario through Scenario Wizard.

Q) If web server, database and Network are all fine where could be the problem?

A) The problem could be in the system itself or in the application server or in the code written for the application.

Q) What is Rendezvous graph?

A) It displays that when V users released from rendezvous point and how many V users released from each point.

Q) What is Correlation?

A) Correlation is used to obtained the data which are unique in every time of script run and which are generated by nested queries.

Q) What is the relation between Response Time and Throughput?

A) The Throughput graph shows the amount of data in bytes that the V users received from the server in a second. When we compare this with the transaction response time, we will notice that as throughput decreased, the response time also decreased. Similarly, the peak throughput and highest response time would occur approximately at the same time.

Q) What is think time? How do you change the threshold?

A) Think time is the time that a real user waits between actions. Example: When a user receives data from a server, the user may wait several seconds to review the data before responding. This delay is known as the think time. Changing the Threshold: Threshold level is the level below which the recorded think time will be ignored. The default value is five (5) seconds. We can change the think time threshold in the Recording options of the Vugen.
For more interview questions visit

Manual Testing Interview Questions

admin — Thu, 18 Nov 2010 11:42:57 +0000

Manual Testing Interview Questions

1 What makes a good Software QA engineer?

Ans: The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see ‘what’s missing’ is important for inspections and reviews.

2 What is ‘Software Testing’?

Ans: Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, ‘if the user is in interface A of the application while using hardware B, and does C, then D should happen’). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should. It is oriented to ‘detection’. (See the Bookstore section’s ‘Software Testing’ category for a list of useful books on Software Testing.)

• Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they’re the combined responsibility of one group or individual. Also common are project teams that include a mix of testers and developers who work closely together, with overall QA processes monitored by project managers. It will depend on what best fits an organization’s size and business structure.

3 What is ‘Software Quality Assurance’?

Ans: Software QA involves the entire software development PROCESS – monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to ‘prevention’. (See the Bookstore section’s ‘Software QA’ category for a list of useful books on Software Quality Assurance.)

4 Can you explain me what makes a good test engineer?

Ans: A good test engineer has a ‘test to break’ attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers’ point of view, and reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.

5 What is the role of documentation in QA?

Ans: Critical. (Note that documentation can be electronic, not necessarily paper.)QA practices should be documented such that they are repeatable. Specifications,designs, business rules, inspection reports, configurations, code changes, test plans,test cases, bug reports, user manuals, etc. should all be documented. There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used if possible.

6 What is a test case?

Ans: • A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.

• Note that the process of developing test cases can help find problems in there quirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it’s useful to prepare test cases earlyin the development cycle if possible.

7 What makes a good Test manager or QA?

Ans: A good QA, test, or QA/Test (combined) manager should have following qualities

• Try to get familiar with the software development process
• be able to maintain enthusiasm of their team and promote a positive atmosphere,despite
•What is a some what ‘negative’ process (e.g., looking for or preventing problems?)
• be able to promote teamwork to increase productivity
• be able to promote cooperation between software, test, and QA engineers
• have the diplomatic skills needed to promote improvements in QA processes
• have the ability to withstand pressures and say ‘no’ to other managers when quality’s insufficient or QA processes are not being adhered to
• have people judgment skills for hiring and keeping skilled personnel
• be able to communicate with technical and non-technical people, engineers,managers, and customers.
• be able to run meetings and keep them focused

8 What is configuration management?

Ans: Configuration management covers the processes used to control, coordinate,and track: code, requirements, documentation, problems, change requests, designs,tools/compilers/libraries/patches, changes made to them, and who makes the changes.(See the ‘Tools’ section for web resources with listings of configuration management tools. Also see the Bookstore section’s ‘Configuration Management’ category for useful books with more information.)

9 What if the software is so buggy it can’t really be tested at all?

Ans: The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules, and indicates deeper problems in the software development process (such as insufficient unit testing or insufficient integration testing, poor design, improper build or release procedures, etc.) managers should be notified, and provided with some documentation as evidence of the problem.

10 What should be done after a bug is found?

Ans: The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn’t create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available (see the ‘Tools’ section for web resources with listings of such tools). The following are items to consider in the tracking process:
• Complete information such that developers can understand the bug, get an idea of it’s severity, and reproduce it if necessary.
• Bug identifier (number, ID, etc.)
• Current bug status (e.g., ‘Released for Retest’, ‘New’, etc.)
• The application name or identifier and version
• The function, module, feature, object, screen, etc. where the bug occurred
• Environment specifics, system, platform, relevant hardware specifics
• Test case name/number/identifier
• One-line bug description
• Full bug description
• Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn’t have easy access to the test case/test script/test tool
• Names and/or descriptions of file/data/messages/etc. used in test
• File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem
• Severity estimate (a 5-level range such as 1-5 or ‘critical’-to-’low’ is common)
• Was the bug reproducible?
• Tester name
• Test date
• Bug reporting date
• Name of developer/group/organization the problem is assigned to
• Description of problem cause
• Description of fix
• Code section/file/module/class/method that was fixed
• Date of fix
• Application version that contains the fix
• Tester responsible for retest
• Retest date
• Retest results
• Regression testing requirements
• Tester responsible for regression tests
• Regression testing results
A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers need to know when retesting is needed, developers need to know when bugs are found and how to get the needed information, and reporting/summary capabilities are needed for managers.

11 What if the project isn’t big enough to justify extensive testing?

Ans: Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the same considerations as described previously in ‘What if there isn’t enough time for thorough testing?’ apply. The tester might then do ad hoc testing, or write up a limited test plan based on the risk analysis.

12 How can it be known when to stop testing?

Ans: This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are:
• Deadlines (release deadlines, testing deadlines, etc.)
• Test cases completed with certain percentage passed
• Test budget depleted
• Coverage of code/functionality/requirements reaches a specified point
• Bug rate falls below a certain level
• Beta or alpha testing period ends

13 What can be done if requirements are changing continuously?

Ans: It is a common problem and a major headache.

• Work with the project’s stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible.
• It’s helpful if the application’s initial design allows for some adaptability so that later changes do not require redoing the application from scratch.
• If the code is well-commented and well-documented this makes changes easier for the developers.
• Use rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes.
• The project’s initial schedule should allow for some extra time commensurate with the possibility of changes.
• Try to move new requirements to a ‘Phase 2′ version of an application, while using the original requirements for the ‘Phase 1′ version.
• Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application.
• Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted – after all, that’s their job.
• Balance the effort put into setting up automated testing with the expected effort required to re-do them to deal with changes.
• Try to design some flexibility into automated test scripts.
• Focus initial automated testing on application aspects that are most likely to remain unchanged.
• Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
• Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans)
• Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk that this entails).

14 What if the application has functionality that wasn’t in the requirements?

Ans: It may take serious effort to determine if an application has significant unexpected or hidden functionality, and it would indicate deeper problems in the software development process. If the functionality isn’t necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer. If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only effects areas such as minor improvements in the user interface, for example, it may not be a significant risk.

15 How does a client/server environment affect testing?

Ans: Client/server applications can be quite complex due to the multiple dependencies among clients, data communications, hardware, and servers. Thus testing requirements can be extensive. When time is limited (as it usually is) the focus should be on integration and system testing. Additionally, load/stress/performance testing may be useful in determining client/server application limitations and capabilities. There are commercial tools to assist with such testing. (See the ‘Tools’ section for web resources with listings that include these kinds of test tools.)

Testing Tools Interview Questions

admin — Thu, 18 Nov 2010 11:27:53 +0000

Testing Tools Interview Questions

1 What’s a ‘test case’?

Ans: A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results. Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it’s useful to prepare test cases early in the development cycle if possible.

2 What is the ‘software life cycle’?

Ans: The life cycle begins when an application is first conceived and ends when it is no longer in use. It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.

3 How is testing affected by object-oriented designs?

Ans: Well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application’s objects. If the application was well-designed this can simplify test design.

4 What is verification? Validation?

Ans: Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walk through, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed.

5 What are the five common problems that occur during software development?

Ans: Poor Communication – This is due to miscommunication for a developer as he don’t know what is needed by a customer. Or customers have unrealistic expectations. Poorly written requirements-This occurs when requirements are unclear, incomplete, not testable and too general. Schedules which are unrealistic-This occurs when too much of work is crammed in too little time. Inadequate testing –if none knows whether or not software is good until customers complain or system crashes. Adding new features after development is underway –This is a common practice to add new features after development is underway.

6 who is called a good test engineer?

Ans: Good test engineer is one s who · Has a strong desire for quality, and “test to break” attitude. who takes the point of view of the customer, Has a strong desire for quality, Tactful and diplomatic · Has good oral and written communication skill. Has previous worked in software development .

7 What is the role of documentation in QA?

Ans: In quality assurance Documentation plays a critical role, ALL the designs,Specifications ,code changes, test plans, business rules, inspection reports, configurations, test cases, bug reports, user manuals should be documented, all the practices should be documented, so that they are repeatable. Use documentation change management if possible, ideally there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information.

8 What is a software project test plan?

Ans: A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The completed document will help people outside the test group understand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product.

9 What is a test case?

Ans: A test case is a document that contains particulars such as Test case Name, objective, test case identifier, test conditions/setup, Input data requirements/steps and expected results.A test case describes an input, action, or event and its expected result, in order to determine if a feature of an application is working correctly, since it requires you to completely think through the operations of the application the process of developing test cases can help find problems in the requirements or design of an application. For this reason, if possible it is useful to prepare test cases early in the development cycle.

10 What is configuration management?

Ans: Configuration management (CM) covers the tools and processes used to control, coordinate and track code, requirements, problems, designs, documentation, change requests, tools, patches, compilers, libraries, who makes the changes and changes made to them. >

11 What is a software error?

Ans: One common definition of a software error is a mismatch between the program and its specification. Other definitions of software error areThere can never be an absolute definition for bugs, nor an absolute determination of their existence. The extent to which a program has bugs is measured by the extent to which it fails to be useful. This is a fundamentally human measure.” “A mismatch between the program and its specification is an error in the program if and only if the specification exists and is correct.”

“A software error is present for when the program does not do what its end user reason ability expects to do.”

12 How do you know when to stop testing?

Ans: Common factors in deciding when to stop testing are.
* Deadlines, e.g. release deadlines, testing deadlines.
* Test budget has been depleted.
* Bug rate falls below a certain level.
* Test cases completed with certain percentage passed.
* Coverage of code, functionality, or requirements reaches a specified point.
Beta or alpha testing period ends.

13 What is verification? Validation?

Ans: Verification typically involves reviews and meetings to evaluate documents, Code, plans, requirements, and specifications. This can be done with checklists, issues lists, walk throughs, and inspection meetings Validation typically involves actual testing and takes place after verifications are completed.

14 Explain some Software Testing Principles?

Ans: Complete testing is impossible. Software testing is not simple because
* Quality testing requires testers to understand a system/product completely.
* Quality testing needs adequate test set, and efficient testing methods.
* A very tight schedule and lack of test tools.

3. Testing is risk-based.

4. Testing must be planned.

5. Testing requires independence.

6. Quality software testing depends on:

Good understanding of software products and related domain application Cost-effective testing methodology, coverage, test methods, and tools. Good engineers with creativity, and solid software testing experience

Testing Dictionary

admin — Thu, 18 Nov 2010 08:07:36 +0000

Testing Dictionary

Acceptance Testing: Formal testing conducted to determine whether or not a system satisfies its acceptance criteria – enables an end user to determine whether or not to accept the system.

Alpha Testing: Testing of a software product or system conducted at the developer’s site by the end user.

Affinity Diagram: A group process that takes large amounts of language data, such as a list developed by brainstorming, and divides it into categories.

Audit : An inspection/assessment activity that verifies compliance with plans,policies, and procedures, and ensures that resources are conserved. Audit is a staff function; it serves as the “eyes and ears” of management.

Automated Testing: That part of software testing that is assisted with software tool(s) that does not require Operator input, analysis, or evaluation.

Beta Testing: Testing conducted at one or more end user sites by the end user of a delivered software product or system.

Bottom-up Testing : An integration testing technique that tests the low-level components first using test drivers for those components that have not yet been developed to call the low-level components for test.

Boundary Value Analysis : A test data selection technique in which values are chosen to lie along data extremes. Boundary values include maximum, mini-mum, just inside/outside boundaries, typical values, and error values.

Brainstorming : A group process for generating creative and diverse ideas.

Branch Coverage Testing : A test method satisfying coverage criteria that requires each decision point at each possible branch to be executed at least once.

Black-box Testing: Functional testing based on requirements with no knowledge of the internal program structure or data. Also known as closed-box testing. Black box testing indicates whether or not a program meets required specifications by spotting faults of omission — places where the specification is not fulfilled.

Bug : A design flaw that will result in symptoms exhibited by some object (the object under test or some other object) when an object is subjected to an appropriate test. problem by representing the relationship between some effect and its possible cause.

Cause-effect Graphing : A testing technique that aids in selecting, in a systematic way, a high-yield set of test cases that logically relates causes to effects to produce test cases. It has a beneficial side effect in pointing out incompleteness and ambiguities in specifications.

Check sheet : A form used to record data it is gathered.

Clear-box Testing : Another term for white-box testing. Structural testing is sometimes referred to as clear-box testing; since “white boxes” are considered opaque and do not really permit visibility into the code. This is also own glass-box or open-box testing.

Client : The end user that pays for the product received, and receives the benefit from the use of the product. .

Control Chart : A statistical method for distinguishing between common and special cause variation exhibited by processes,

Customer (end user) : The individual or organization, internal or external to the producing organization, that receives the product.

Cyclomatic Complexity : A measure of the number of linearly independent paths through a program module.

Data Flow Analysis : Consists of the graphical analysis of collections of(sequential) data definitions and reference patterns to determine constraints that can be placed on data values at points of executing the source program.

Debugging : The act of attempting to determine the cause of the symptoms of malfunctions detected by testing or by frenzied user complaints.

Defect : NOTE: Operationally, it is useful to work with two definitions of a defect: 1) From the producer’s viewpoint: a product requirement that has not been met or a product attribute Possessed by a product or a function performed by a product that is not in the statement of requirements that define the product.2) From the end user’s viewpoint: anything that causes end user dissatisfaction, whether in the statement of requirements or not.

Defect Analysis : Using defects as data for continuous quality improvement. Defect analysis generally seeks to classify defects into categories and identify possible causes in order to direct process improvement efforts.

Defect Density: Ratio of the number of defects to program length (a relative number).

Desk Checking: A form of manual static analysis usually performed by the originator. Source code documentation, etc., is visually checked against requirements and standards.

Dynamic Analysis : The process of evaluating a program based on execution of that program. Dynamic analysis approaches rely on executing a piece of software with selected test data.

Dynamic Testing : Verification or validation performed which executes the system’s code.

Error : 1) A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition; and 2) a mental mistake made by a programmer that may result in a program fault.

Error-based Testing : Testing where information about programming style, error-prone language constructs, and other programming knowledge is applied to select test data capable of detecting faults, either a specified class of faults or all possible faults.

Evaluation : The process of examining a system or system component to determine the extent to which specified properties are present.

Execution: The process of a computer carrying out an instruction or instructions of a computer.

Exhaustive Testing : Executing the program with all possible combination of values for program variables.

Loadrunner Interview Questions

admin — Thu, 18 Nov 2010 07:58:36 +0000

Loadrunner Interview Questions

Q) How do you debug a LoadRunner script?

A) VuGen contains two options to help debug V user scripts-the Run Step by Step command and breakpoints. The Debug settings in the Options dialog box allow us to determine the extent of the trace to be performed during scenario execution. The debug information is written to the Output window. We can manually set the message class within your script using the lr_set_debug_message function. This is useful if we want to receive debug information about a small section of the script only.

Q) What is extension of LoadRunner result file?

A) .lrr

Q) How do you perform functional testing under load?

A) Functionality under load can be tested by running several V users concurrently. By increasing the amount of V users, we can determine how much load the server can sustain.

Q) How many types of checkpoints are available in LoadRunner?

A) Load Runner provides two types of checkpoints-

* Text Checkpoints

* Image Checkpoints

Q) How to load LoadRunner Agent?

A) Controller instructs the RCl to lunch the LoadRunner Agent.

Q) How many types of running mode in LoadRunner?

A) LoadRunner provides two types of recording level-

* HTML based script

* URL based script

Q) What Component of LoadRunner would you use to play back the script in multi user mode?

A) The Controller component is used to playback the script in multi-user mode. This is done during a scenario run where a v user script is executed by a number of v users in a group

Q) What is the Load Testing Process?

A) Load Testing process have five steps-

* Plan Test

* Create V user script

* Define Scenario

* Run Scenario* Analyze Results.