Saturday, December 29, 2007

Facts about QTP

1. How Does Run time data (Parameterization) is handled in QTP?

A)

You can then enter test data into the Data Table, an integrated spreadsheet with the full functionality of Excel, to manipulate data sets and create multiple test iterations, without programming, to expand test case coverage. Data can be typed in or imported from databases, spreadsheets, or text files.

2) What is keyword view and Expert view in QTP?

A)

QuickTest’s Keyword Driven approach, test automation experts have full access to the underlying test and object properties, via an integrated scripting and debugging environment that is round-trip synchronized with the Keyword View. Advanced testers can view and edit their tests in the Expert View, which reveals the underlying industry-standard VBScript that QuickTest Professional automatically generates. Any changes made in the Expert View are automatically synchronized with the Keyword View.



3) Explain about the Test Fusion Report of QTP ?

A)

Once a tester has run a test, a TestFusion report displays all aspects of the test run: a high-level results overview, an expandable Tree View of the test specifying exactly where application failures occurred, the test data used, application screen shots for every step that highlight any discrepancies, and detailed explanations of each checkpoint pass and failure. By combining TestFusion reports with QuickTest Professional, you can share reports across an entire QA and development team.



4) To which environments does QTP supports ?

A)

QuickTest Professional supports functional testing of all enterprise environments, including Windows, Web, ..NET, Java/J2EE, SAP, Siebel, Oracle, PeopleSoft, Visual Basic, ActiveX, mainframe terminal emulators, and Web services.



5) What is QTP ?

A)

QuickTest is a graphical interface record-playback automation tool. It is able to work with any web, java or windows client application. Quick Test enables you to test standard web objects and ActiveX controls. In addition to these environments, QuickTest Professional also enables you to test Java applets and applications and multimedia objects on Applications as well as standard Windows applications, Visual Basic 6 applications and .NET framework applications...



6) Explain QTP Testing process ?

A)

The QuickTest testing process consists of 6 main phases: Create your test plan Prior to automating there should be a detailed description of the test including the exact steps to follow, data to be input, and all items to be verified by the test. The verification information should include both data validations and existence or state verifications of objects in the application. Recording a session on your application As you navigate through your application, QuickTest graphically displays each step you perform in the form of a collapsible icon-based test tree. A step is any user action that causes or makes a change in your site, such as clicking a link or image, or entering data in a form. Enhancing your test Inserting checkpoints into your test lets you search for a specific value of a page, object or text string, which helps you identify whether or not your application is functioning correctly. NOTE: Checkpoints can be added to a test as you record it or after the fact via the Active Screen. It is much easier and faster to add the checkpoints during the recording process. Broadening the scope of your test by replacing fixed values with parameters lets you check how your application performs the same operations with multiple sets of data. Adding logic and conditional statements to your test enables you to add sophisticated checks to your test. Debugging your test If changes were made to the script, you need to debug it to check that it operates smoothly and without interruption. Running your test on a new version of your application You run a test to check the behavior of your application. While running, QuickTest connects to your application and performs each step in your test. Analyzing the test results You examine the test results to pinpoint defects in your application. Reporting defects As you encounter failures in the application when analyzing test results, you will create defect reports in Defect Reporting Tool.



7) Explain the QTP Tool interface.

A)

It contains the following key elements: Title bar, displaying the name of the currently open test Menu bar, displaying menus of QuickTest commands File toolbar, containing buttons to assist you in managing tests Test toolbar, containing buttons used while creating and maintaining tests Debug toolbar, containing buttons used while debugging tests. Note: The Debug toolbar is not displayed when you open QuickTest for the first time. You can display the Debug toolbar by choosing View > Toolbars > Debug. Action toolbar, containing buttons and a list of actions, enabling you to view the details of an individual action or the entire test flow. Note: The Action toolbar is not displayed when you open QuickTest for the first time. You can display the Action toolbar by choosing View > Toolbars > Action. If you insert a reusable or external action in a test, the Action toolbar is displayed automatically. Test pane, containing two tabs to view your test-the Tree View and the Expert View Test Details pane, containing the Active Screen Data Table, containing two tabs, Global and Action, to assist you in parameterizing your test Debug Viewer pane, containing three tabs to assist you in debugging your test-Watch Expressions, Variables, and Command. (The Debug Viewer pane can be opened only when a test run pauses at a breakpoint.) Status bar, displaying the status of the test

8) How QTP recognizes Objects in AUT?

A)

QuickTest stores the definitions for application objects in a file called the Object Repository. As you record your test, QuickTest will add an entry for each item you interact with. Each Object Repository entry will be identified by a logical name (determined automatically by QuickTest), and will contain a set of properties (type, name, etc) that uniquely identify each object. Each line in the QuickTest script will contain a reference to the object that you interacted with, a call to the appropriate method (set, click, check) and any parameters for that method (such as the value for a call to the set method). The references to objects in the script will all be identified by the logical name, rather than any physical, descriptive properties.

9) What are the types of Object Repositorys in QTP?

A) QuickTest has two types of object repositories for storing object information: shared object repositories and action object repositories. You can choose which type of object repository you want to use as the default type for new tests, and you can change the default as necessary for each new test. The object repository per-action mode is the default setting. In this mode, QuickTest automatically creates an object repository file for each action in your test so that you can create and run tests without creating, choosing, or modifying object repository files. However, if you do modify values in an action object repository, your changes do not have any effect on other actions. Therefore, if the same test object exists in more than one action and you modify an object's property values in one action, you may need to make the same change in every action (and any test) containing the object.

10) Explain the check points in QTP?

A) . A checkpoint verifies that expected information is displayed in a Application while the test is running. You can add eight types of checkpoints to your test for standard web objects using QTP. A page checkpoint checks the characteristics of a Application A text checkpoint checks that a text string is displayed in the appropriate place on a Application. An object checkpoint (Standard) checks the values of an object on a Application. An image checkpoint checks the values of an image on a Application. A table checkpoint checks information within a table on a Application An Accessiblity checkpoint checks the web page for Section 508 compliance. An XML checkpoint checks the contents of individual XML data files or XML documents that are part of your Web application. A database checkpoint checks the contents of databases accessed by your web site

11) In how many ways we can add check points to an application using QTP.

A) We can add checkpoints while recording the application or we can add after recording is completed using Active screen (Note : To perform the second one The Active screen must be enabled while recording).

12) How does QTP identifes the object in the application

A) QTP identifies the object in the application by LogicalName and Class. For example : The Edit box is identified by Logical Name : PSOPTIONS_BSE_TIME20
Class: WebEdit

13) If an application name is changes frequently i.e while recording it has name “Window1” and then while running its “Windows2” in this case how does QTP handles?

A) QTP handles those situations using “Regular Expressions”.

14) What is Parameterizing Tests?

A) When you test your application, you may want to check how it performs the same operations with multiple sets of data. For example, suppose you want to check how your application responds to ten separate sets of data. You could record ten separate tests, each with its own set of data. Alternatively, you can create a parameterized test that runs ten times: each time the test runs, it uses a different set of data.

15) What is test object model in QTP ?

A) The test object model is a large set of object types or classes that QuickTest uses to represent the objects in your application. Each test object class has a list of properties that can uniquely identify objects of that class and a set of relevant methods that QuickTest can record for it. A test object is an object that QuickTest creates in the test or component to represent the actual object in your application. QuickTest stores information about the object that will help it identify and check the object during the run session. A run-time object is the actual object in your Web site or application on which methods are performed during the run session. When you perform an operation on your application while recording,

QuickTest: identifies the QuickTest test object class that represents the object on which you performed the operation and creates the appropriate test object .
Reads the current value of the object’s properties in your application and stores the list of properties and values with the test object .
Chooses a unique name for the object, generally using the value of one of its prominent properties.
Records the operation that you performed on the object using the appropriate QuickTest test object method For example, suppose you click on a Find button with the following HTML source code: QuickTest identifies the object that you clicked as a WebButton test object. It creates a WebButton object with the name Find, and records the following properties and values for the Find WebButton:
It also records that you performed a Click method on the WebButton. QuickTest displays your step in the Keyword View like this: QuickTest displays your step in the Expert View like this: Browser("Mercury Interactive").Page("Mercury Interactive"). WebButton("Find").Click

16) What is Object Spy in QTP?

A) Using the Object Spy, you can view the properties of any object in an open application. You use the Object Spy pointer to point to an object. The Object Spy displays the selected object’s hierarchy tree and its properties and values in the Properties tab of the Object Spy dialog box.

17) What is the Diff between Image check-point and Bit map Check point?

A) Image checkpoints enable you to check the properties of a Web image. You can check an area of a Web page or application as a bitmap. While creating a test or component, you specify the area you want to check by selecting an object. You can check an entire object or any area within an object. QuickTest captures the specified object as a bitmap, and inserts a checkpoint in the test or component. You can also choose to save only the selected area of the object with your test or component in order to save disk Space For example, suppose you have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. You can record the new map that is displayed after one click on the control key that zooms in the map. Using the bitmap checkpoint, you can check that the map zooms in correctly. You can create bitmap checkpoints for all supported testing environments (as long as the appropriate add-ins are loaded). Note: The results of bitmap checkpoints may be affected by factors such as operating system, screen resolution, and color settings.

18) How many ways we can parameterize data in QTP ?

A) There are four types of parameters: Test, action or component parameters enable you to use values passed from your test or component, or values from other actions in your test. Data Table parameters enable you to create a data-driven test (or action) that runs several times using the data you supply. In each repetition, or iteration, QuickTest uses a different value from the Data Table. Environment variable parameters enable you to use variable values from other sources during the run session. These may be values you supply, or values that QuickTest generates for you based on conditions and options you choose. Random number parameters enable you to insert random numbers as values in your test or component. For example, to check how your application handles small and large ticket orders, you can have QuickTest generate a random number and insert it in a number of tickets edit field.

19) How do u do batch testing in WR & is it possible to do in QTP, if so explain?

Ans: Batch Testing in WR is nothing but running the whole test set by selecting "Run Testset" from the "Execution Grid".The same is possible with QTP also. If our test cases are automated then by selecting "Run Testset" all the test scripts can be executed. In this process the Scripts get executed one by one by keeping all the remaining scripts in "Waiting" mode.

20)If i give some thousand tests to execute in 2 days what do u do?

Ans : Adhoc testing is done. It Covers the least basic functionalities to verify that the system is working fine.

22) what does it mean when a check point is in red color? what do u do?

Ans : A red color indicates failure. Here we analyze the the cause for failure whether it is a Script Issue or Envronment Issue or a Application issue.

23. what do you call the window testdirector-testlab?

Ans : "Execution Grid". It is place from where we Run all Manual / Automated Scripts

24. how do u create new test sets in TD

Ans : Login to TD. Click on "Test Lab" tab.

1.What are the Features & Benefits of Quick Test Pro(QTP)..?

Operates stand-alone, or integrated into Mercury Business Process Testing and Mercury Quality Center. Introduces next-generation “zero-configuration” Keyword Driven testing technology in QuickTest Professional

2 . Where can I get Quck Test pro(QTP Pro) software..

Introduction to QuickTest Professional 8.0, Computer Based Training: Please find the step to get QuickTest Professional 8.0 CBT Step by Step Tutorial and Evaluation copy of the software. The full CBT is 162 MB. You will have to create account to be able

3. How to handle the exceptions using recovery secnario manager in Qtp?

There are 4 trigger events during which a recovery scenario should be activated. They are A pop up window appears in an opened application during the test run. A property of an object changes its state or value. A step in the test does

4. what is the use of Text output value in Qtp?

Output values enable to view the values that the application talkes during run time.When paramaterised, the values change for each iteration.Thus by creating output values, we can capture the values

5. What is the file extension of the code file & object repository file in QTP?

Objects file .TSRScript file per action .MTS

6. Explain the concept of object repository & how QTP recognises objects?

With QTP 8.2 ,there available QTP Plus,setup.It provides Repositories Merge Utility.The Object Repository Merge Utility enables user to merge Object repository files into a single Object repository file.

7. What are the properties you would use for identifying a browser & page when using descriptive programming ?

"name" would be another property apart from "title" that we can use. ex: Browser("name:="xxx"").page("name:="xxxx"")..... OR We can also use the property "micClass". ex: Browser("micClass:=browser").page("micClass:=page")....&nbs

8. What are the different scripting languages you could use when working with QTP ?

vb script
9. Give me an example where you have used a COM interface in your QTP project?

Com inteface appears in the scenario of front end and back end.for eg:if you r using oracle as back end and front end as VB or any language then for better compatibility we will go for an interface.of which COM wil be one among those intefaces.

Software Testing Process






Table of Contents
1. WHY DO WE NEED TO TEST?
2. WHAT IS TESTING?
2.1 Testing Techniques.
2.2 Testing Phases.
3. WHY DO WE NEED TO PLAN TESTING?
4. SOFTWARE TEST PROCESS:
4.1 Test Artifacts:
4.1.1 Test Plan:
4.1.2 Test Environment:
4.1.3 Test Case:
4.1.4 Test Data:
4.1.5 Test Tools:
4.1.6 Test Scripts:
4.1.7 Test Log:
4.1.8 Bug Report:
5. TRAITS OF A GOOD TESTER.
6. TESTING ROLES.
7. WHEN TO STOP TESTING?







1.Why do we need to test?


It is the primary duty of a software vendor to ensure that software delivered does not have defects and that the customer’s day-to-day operations do not get affected. This can be achieved by rigorously testing the software. In spite of rigorous testing, software delivered may contain some defects.
Defects can exist in the software, as the human who can make mistake designs it. To a large extent, the circumstances under which the software has been developed are major reasons for inducing defects in the software.
The most common reasons that cause bugs in software are found to be:
1.Poor requirements - if requirements are unclear, incomplete, too general, or not testable, there will be problems.
2.Unrealistic schedule - if too much work crammed in too little time, problems are inevitable.
3.Inadequate testing - no one will know whether or not the program is any good until the customer complains or the system crashes.
4.Miscommunication - if developers don't know what's needed or customers have erroneous expectations, problems are guaranteed.
5.Changing requirements – Customer without understanding impact of a change on software may request frequent changes. Frequent Changes directly affect the timelines of the project. Ultimately it is testing which takes least priority.
6.Assumptions and complacency – often projects make assumptions on key design or architectural issues that may prove costly in the end.

2. What is Testing?
“Testing is an activity in which a system or component is executed under specified conditions; the results are observed and recorded and an evaluation is made of some aspect of the system or component
· “ - IEEE
*Executing a system or component is known as dynamic testing.
*Review, inspection and verification of documents (Requirements, design documents Test Plans etc.), code and other work products of software is known as static testing.
*Static testing is found to be the most effective and efficient way of testing.
*Successful testing of software demands both dynamic and static testing.
*Measurements show that a defect discovered during design that costs $1 to rectify at that stage will cost $1,000 to repair in production. This clearly points out the advantage of early testing.
*Testing should start with small measurable units of code, gradually progress towards testing integrated components of the applications and finally be completed with testing at the application level.
*Testing verifies the system against its stated and implied requirements, i.e., is it doing what it is supposed to do? It should also check if the system is not doing what it is not supposed to do, if it takes care of boundary conditions, how the system performs in production-like environment and how fast and consistently the system responds when the data volumes are high.

2.1Testing Techniques:


Software can be tested either by running the programs and verifying each step of its execution against expected result or by statically examining the code or the document against its stated requirement or objective. These 2 distinct methods have led to the popularization of 2 techniques of software testing viz.
Static Testing:
This is a non-execution-based testing technique. The Design, code or any document may be inspected and reviewed against a stated requirement and for some standards against some guideline/checklist. Static Testing includes:
*Walk-through - code reading and inspections with a team
*Reviews - Formal techniques for specification and design, code reading and inspections.
*Logical correctness proving-
Many studies show that the single most cost-effective defect reduction process is the classic structural test - the code inspection or walk-through. Code inspection is like proof-reading - it can find the mistakes the author missed - the "typo's" and logic errors that even the best programmers can produce.

Dynamic Testing:


This is an execution-based testing technique. Here, the program, module or the entire system is executed (run) and the output is verified against the expected result. Dynamic execution of tests is based on one of the following:
*Specifications (black box testing) - test cases based on specifications
*Code (glass box testing) - test cases based on the code
*Methodology
White box testing:
This testing technique takes into account the internal structure of a system or component. Complete access to the object's source code is needed for white-box testing. This is known as ‘white box’ testing because you get to see the internal working of the code. White box testing helps to:


1.Traverse complicated loop structures
2.Cover common data areas,
3.Traverse 100,000 lines of spaghetti code and nests of ifs.
4.Cover control structures and sub-routines
5.Evaluate different execution paths
6.Traditionally, this kind of testing has been done using interactive debuggers, or by actually changing the source code.


Now, there are a number of testing tools that let you perform white-box testing on executables, without modifying the source and without incurring the high overhead of an interactive debugger. These tools speed testing and debugging because there is no need to wait for test support code to be inserted into the program. Unit testing and some part of integration testing come under white box testing category.

Black Box Testing:


Functional tests examine the observable behavior of software as evidenced by its outputs, without any reference to internal functions. This is the essence of ‘black box’ testing.

1.Black box tests better attack the quality target. It is an advantage to create the quality criteria from this point of view from the beginning.
2.In black box testing, software is exercised over a full range of inputs and the outputs are observed for correctness. How those outputs are achieved, or what is inside the box are immaterial.
3.Black Box testing technique can be applied once unit and integration testing is completed. i.e. each line code has been covered through white-box testing.

2.2Test phases:


Unit Test:


Testing of individual units or groups of related code is known as Unit Testing. A developer generally carries out unit testing himself/herself (self-test) or they test each other’s modules (independent test). He/she needs to prepare Unit Test plan, which is a prerequisite to start testing. The Plan should take care of:
1. Standards specified (Ex. GUI related)
2. Field validations, boundary values.
3.Basic functionality of the component (add/delete/modify/query activities)
3. Code coverage and exception handling.
4. Negative or destructive testing

Integration Test:
Testing in which software components, hardware components, or both are combined and tested to evaluate the interfaces and interaction between them is known as Integration Testing. This may again be done by the developer themselves or independently amongst them. Integration test plan should take care that:
1.Multiple components being integrated provide necessary communications, links and data sharing.
2.Integrated components work cohesively to perform a specified task.
Larger systems often require several integration steps. There are four basic integration test methods:
· Incremental (Random)
· Big-bang (All-at-once)
· Bottom-up
· Top-down

System Test:
It can be defined as testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. During System testing one focuses solely on the outputs generated in response to inputs provided and execution conditions, rather than verifying the internal structure of the program/system. i.e. the system is validated against its functional requirements. System testing is carried out when Unit and Integration testing have been completed successfully.

A system tester should have a good understanding of architecture and application domain of the system. The System test plan needs take care following details:
1.Compliance of a system or component with its specified functional requirements.
2.Validation of business rules
3.Validation of system resource (H/W) and the application response when multiple components are executed simultaneously
4.Destructive tests to determine if the software does things it shouldn't do.
1. Inter and intra components dependencies.
2. Controlled environment under which the testing will be
carried out
3. Data that will go as inputs to the various tests and the
corresponding expected output
4. Coverage of all critical decision making components

User Acceptance test:
This is a formal testing conducted to enable the end-user of the system (customer or any of his authorized personnel) to determine whether to accept a system or component. The user himself will typically carry out this test or will certainly participate in this test activity. He may evaluate the system against functional, operational and performance requirements.
Regression testing:
This involves re-testing of the system or component to verify that modifications / enhancements have not introduced unintended defects on some existing features / modules. It would also involve re-testing prior bug fixes to ensure they work with the current fix / enhancement. The emphasis of regression testing is to ensure that the new modifications have not adversely affected existing functionality.
Performance testing:
This is a testing conducted to evaluate the system’s ability to meet the required performance levels. Performance testing requires special skills. Many Performance testing tools are available and it is always preferred that tools are used for performance testing. These tools simulate load in terms of the number of concurrent users accessing the system. Performance tests are referred to as non-functional tests. Performance test plan should take care of:
1.Number of concurrent users accessing at any point in given time.
2.System’s performance under high volume of data.
3.Stress testing for systems, which are being scaled up to larger environments or implemented for the first time.
4.Operational intensive transactions. (Most frequently used transactions)
5.Volume intensive transactions (for both volume and stress testing)

3.Why do we need to plan/design testing?

Complete testing of software is impossible for several reasons:
a. Can’t test all inputs
The number of inputs you can feed to a program is typically infinite. We use rules of thumb (heuristics) to select a small number of test cases that we will use to represent the full space of possible tests. That small sample might or might not reveal all of the input-related bugs.
· Valid Inputs: Consider a function that will accept any integer value between 1 and 1000. It is possible to run all 1000 values but it will take a long time. To save time, we normally test at boundaries, testing perhaps at 0, 1, 1000, and 1001. Boundary analysis provides us with good rules of thumb about where we can shortcut testing, but the rules aren’t perfect.
· Invalid Inputs: Suppose you only tested –1, 0, and 1001 as your invalid numerical inputs. Some programs will fail if you enter 999999999999999—a number that has too many characters, rather than being too numerically large.
· Edited Inputs: If the program accepts numbers from 1 to 1000, what about the following sequence of keystrokes: 1 1 1 1000 ? If you entered single digits and backspaced over them hundreds of times, could you overflow an input buffer in the program? There have been programs with such a bug. How many variations on editing would you have to test before you could be absolutely certain that you’ve caught all the editing-related bugs?
· Timing Considerations: The program accepts any number between 1 and 9999999. You type 123, then pause for a minute, then type 4567. What result? If you were typing into a telephone, the system would have timed you out during your pause and would have discarded 4567. Timing-related issues are at the heart of the difference between traditional systems and client/server systems. How much testing do you have to do to check for timeouts and their effects?
b. Can’t test all combinations of inputs
Suppose a program lets you add two numbers. The program’s design allows the first number to be between 1 and 100 and the second number between 1 and 25. The total number of pairs you can test (not counting all of the pairs that use invalid inputs) is 100 x 25 (2500).

In general, if you have V variables, and N1 is the number of possible values of variable 1, N2 is the number of possible values of variable 2, and NV is the number of values of variable V, then the number of possible combinations of inputs is N1 x N2 x N3 x . . . x NV. (The number is smaller and the formulas are more complicated if the values available for one variable depend on the value chosen for a different variable.)

We can use heuristics (domain testing) to select a few "interesting" combinations of variables that will probably reveal most of the combination bugs, but we can’t be sure that we’ll catch all of them.
c. Can’t test all the paths
A path through a program starts at the point that you enter the program, and includes all the steps you run through until you exit the program. There is a virtually infinite series of paths through any program that is even slightly complex.

Consider an example of a software program in a flowchart-like format as shown below:



(Refer the Diagram 1 at the top)

The program starts at point A and ends at Exit. You get to Exit from X. When you get to X, you can either exit or loop back to A. You can’t loop back to A more than 19 times. The twentieth time that you reach X, you must exit. There are five paths from A to X. You can go A to B to X (ABX). Or you can go ACDFX or ACDGX or ACEHX or ACEIX. There are thus 5 ways to get from A to the exit, if you only pass through X once.

If you hit X the first time, and loop back from X to A, then there are five ways (the same five) to get from A back to X. There are thus 5 x 5 ways to get from A to X and then A to X again. There are 25 paths through the program that will take you through X twice before you get to the exit.

There are 53 ways to get to the exit after passing through X three times, and 520 ways to get to the exit after passing through X twenty times. In total, there are 5 + 52 + 53 + 54 + . . . + 520 = 1014 (100 trillion) paths through this program. If you could write, execute, and verify a test case every five minutes, you’d be done testing in a billion years.

One alternative to complete path testing is sub-path testing. A sub-path is just a series of steps that you take to get from one part of the program to another. In the above example, A to C is a sub-path. So are ACD, ACDF, and ACDFX. Under this viewpoint, once you’ve tested ACDFX, you wouldn’t test this sub-path again. You’d probably test ABX, ACDFX, ACDGX, ACEHX and ACEIX once each, plus one test that would run you through X the full 20 times.

If you go through a sub-path with one set of data one time, and a different set of data the next, you can easily get different results. And the values of the data often depend on what you’ve done recently in some other part of the program.

d. Can’t test for all of the other potential failures
A system can fail in the field because the software is defective, the hardware is malfunctioning, or the humans who work with the system make a mistake. If the system is designed in a way that makes it likely that humans will make important mistakes, the system is defective. Therefore, to find all defects in a system, you have to test for usability issues, hardware/software compatibility issues, requirements conformance issues, timing issues, etc. There are lots and lots of additional tests.
4.Software Test Process:
For every product/application testing, the following steps constitute the typical Testing process:
1. Test Planning:
a. Prepare Test Plan
· Define Test objectives
· Identify environmental needs
· Identify the test tools to be used, if any
· Identify the Test team
· Assess risks
· Identify critical success factors
· Write Test cases
· Determine sequence/integration procedure
· Determine Test stop and resume criteria
· Identify the no. Of test cycles to be carried out
· Review Test Plan
2. Test Execution:
a. Setup Test Environment
· Identify the Testing server
· Setup restorable Test data
· Set up the applicable test tools
b. Set up the CM environment for the test environmental assets such as
· Application/Product code
· Test data
· Test scripts
· System configuration files
c. Ensure that the Test environment closely simulates the user’s platform
· Browsers
· OS
· Hardware
d. Execute Tests
· Unit Testing
· Integration Testing
· System Testing
· User Acceptance Testing
3. Test Evaluation
a. Review Test Results
· Define how defects are to be classified
· Setup criteria in place to prioritize/evaluate defects

Test Artifacts:
Test Plan:
It is a plan document that covers the overall plan for entire Testing activities for the project. This includes the scope and objective of the plan, references to other documents, the test items and their prioritization, tests to be conducted, tools to be used, environment setup, resources and infrastructure, test entry and exit criteria, test measurements.
Test Environment/Bed:
It is a combination of hardware and software platforms together with other third-party products, application configuration and data on which a Testing activity is performed.
Test Case:
This is a series of steps for executing a program or a set of programs, along with a set of data that should be provided as inputs. In addition, a test case also specifies the expected output for each step to be executed.
Test Data:
It is a set of values that should be provided as input while executing a test, along with the expected output associated with that step.
Test Tools:
These are third-party/In house products that aid in automating the Testing activity. These tools typically work on a record-and-playback mechanism and aid in simulation of production-like loads for simulated Load and Performance Testing. Most of these tools also provide output/error logging and reporting features for a consolidated view of results and to help compare/contrast them.
Test Scripts:
A set of scripts, which when executed in a particular sequence, runs the test and logs/displays the output as desired. Test scripts are typically used while regression testing where the test sequence is recorded and played back later, as desired through the scripts. The scripting language varies with the tools being used.
Test Log:
A file that logs the output /errors during manual /automated testing activities. These files provide a consolidated view of results and help compare/contrast them. They provide data on test coverage and the proportion of tests that passed/failed. They also log the errors reported against each test executed along with the input data.
Bug Report:
The Bug report is a consolidated document, which gives details of all the bugs found during the test execution process. Once the bug is found then by assigning the seveority, register the bugs using Bug tracking tool the bugs are reported to Team lead.
The priority is decided by either the client, Team lead or project leader.
BUG REPORT Consists of:
1.Bug Identifier.
2.Bug description.
3.Status (Open, Fixed, Closed, New).
4.Severioty.
5.Detected by.
6.Dectected on Dt.
7.Product Version.
8.Platform.
5.Traits of a good tester:
Software test engineers require technical skills, but they also require other characteristics that help them appreciate the customer or user’s perspective while testing it. The following are some traits that can help a tester test a system/application thoroughly:
· Destructive creativity: A software test engineer can't be afraid of causing a product to crash and burn. In software testing, boundaries are meant to be crossed, not obeyed.
· Detective skills: In an ideal world, the software to be tested should be well documented and updated regularly. Due to time pressures, it may become impossible to update requirements document, or requirements may just not be available. Under such situations, it is difficult to track changes and prepare a test plan.
Because we don't create software in an ideal world, the test engineer must be able to figure out how things work on his own. Typically, some design or functional specifications will be available, so the test engineer can use these documents to begin his research. Skilled testers should find ways and means of getting right information required for testing.

· Understanding the product as the sum of its parts: The developer will concentrate on his piece of code rather than entire system; this induces bugs when components are assembled and tested. Whereas a tester cannot afford to have the same mentality. His strength lies in understanding individual components of a system, and testing the same from system perspective.

· Appreciating the users’ perspective: The test engineer must also act as an advocate for the customer. The program under test may perform reliably and may meet all requirements, but it may not be operable under production. So it is essential for tester to simulate production like environment.
· Requirements change: Testers should have the patience to test and retest the same system or component repeatedly. It is nature of software that it evolves every day. A customer with ever changing market needs is prone to request for frequent changes in software. The objective of a tester is to identify a defect early in software life cycle, thus minimizing defects that get released along with software.

· A skeptical, but not hostile attitude: The test engineer must not accept things at face value, but must be tenacious in questioning everything until it's all proven. The engineer must, however, balance this skepticism and stubbornness with a spirit of cooperation with the rest of the project team. The test engineer must remember to assault the integrity of the programs, not the programmers.

An eagerness to embrace new technologies: The Internet is increasing the rate at which technology is changing. A testing team needs to be as much equipped technologically, as the development team itself. Knowing the technology himself
helps him appreciate what is achievable within the given architectural framework and what is not. This helps build a stronger rapport with the development team. The development team and testing team need to coexist to achieve a common.




6.Testing Roles:
Test Management
· The role - Define test strategies, allocate resources, manage project risks, produce project plans, develop processes.
· Knowledge - Industry knowledge, risk management and project planning using available tools
· Skills - Excellent communicator, flexible, leadership, diplomatic
· Experience - Industry specific, a variety of platform and application types, detailed testing methods.
Test Planning
· The role - Define test requirements, plan tests, ensure test coverage, identify test conditions, identify re-tests
· Knowledge - How systems and technology support business processes, the role of data, software development life cycle, testing techniques and terminology
· Skills - Requirements analysis, interviewing, prioritization, data analysis, working with limited time and information
· Experience - Using applications, acceptance-testing applications, documenting activities, using software in the work environment, business processes.
Test Design
· The role - Design the tests and prepare test data, produce scripts, set up automated tests, prepare test cases, prepare data tables for automation
· Knowledge - The application under test, the data, writing test scripts, what tests to automate/run manually
· Skills - Re-use of Test Assets, data manipulation, communicator, methodical
· Experience - Clear documentation, reporting, creating instruction sets, defining data requirements.
Test Execution
· The role - Execute tests, record test scripts, maintain statistics and metrics, check test data setup, test environment setup, execute re-tests
· Knowledge - Understanding of the importance of testing, awareness of tools, how to progress against a plan
· Skills - Observation, accuracy, methodical, co-ordination, problem solver
· Experience - Following instructions, problem reporting and solving, and relevant testing tools.
Problem Identification
· The role - Identify and record problems, maintain metrics, re-create problems
· Knowledge - Application under test, testing tools, problem management, change control, configuration management, metrics
· Skills - analysis, pro-active, intuitive, identify solutions, diplomatic
· Experience - Incident reporting, causal analysis, problem solving
Test Asset Administration
· The role - Maintaining a directory of all test assets, apply change control to assets
· Knowledge - Change and version control, configuration management
· Skills - Ability to organize; version and configuration management
· Experience - Change and version control, release management, asset management.


Environment Management
· The role - To set up and maintain environments for testing, provide quality data and test tools
· Knowledge - Environment maintenance utilities, how to run environments from a system perspective
· Skills - Operational analysis skills, DBA skills, system programming
· Experience - System support, experience in one of the above disciplines

7.When to Stop Testing?
It is very well perceived that testing like any other activity, needs time, effort and cost. Testing should be stopped when any of the above parameter exceeds budget. It is always advised to discuss budget required for testing with the customer. Ensure optimization in terms of functionality, reliability, effort, time and risks associated with each of the above parameters, is covered during discussion. Document the same as part of the Test strategy and get the same signed off by the customer. During Test execution these parameters provide guidelines for further action.
The following points describe situations how and when testing can be stopped.
· The test stop criteria can depend on the methodology adopted for software development. E.g. If the project works on incremental model the testing can be restricted by the functionality developed during that cycle taking into account Time to Market.
· Incase if changes are frequent, and changes are implemented in parallel with development, then testing of both will not help Time to Market. Under these circumstances it is advised, that you list critical transactions and prioritize and test only those transactions.
· Time lines of the project may be very narrow and you may not be able to test 100 % functionality. Under these circumstances arrive at the % of functional testing that can be completed within the specified timeline so that quality is not compromised. Once again prioritize critical transactions.
· In the test strategy, severity of defects needs to be defined where you specify the nature of fatal, major, minor and cosmetic error. Project teams can specify in the test strategy, that software will be released with minor/cosmetic bugs.
· There are times when testing cannot be continued simply because the defect found is a showstopper and there is no round about way of continuing testing for the remaining part of the software. In such a situation, the tester will not have any choice but to fix and close the defect quickly and then proceed.

Wednesday, December 19, 2007

Knock Nevis/Jahre Viking/Sea Wise Giant/Happy Giant-Worlds Largest floating Object




Knock Nevis/Jahre Viking : Worlds largest moving object!!!!!!!!!!!!




























































Welcome aboard the TT Jahre Viking, a ship so huge that when fully laden she can not pass through the 32-mile-wide English channel that separates England from France, what to speak of the Suez and Panama canals. For, when laden, she sits 24.6 meters in the water, a depth great enough to deny her entry to most of the worlds major ports.

EVEN in an age of superlatives, she continues as the ultimate superlative, a ship so huge that she would comfortably swallow up Indias largest ship, the 25,000-tonne aircraft carrier INS Vikrant, in her holds. On land, at 485.46 meters from tip to tip, she would dwarf the worlds tallest man-made land structure, the 424-metre Petronas tower of Malaysia. At sea she is fully 100 per cent bigger than the new breed of competing super tankers like the ill-fated Exxon Valdez.

A brief history of Jahre Viking
But, perhaps, proving the old adage that its lonely at the top, life hasnt exactly been bed of roses for this giant which defies classification (in shipping parlance she has been dubbed ULCC, an ultra large crude carrier). Built in 1979 for a Greek shipping magnate towards the fag end of the super tanker boom that followed the oil embargo of 1973, her original owner went bankrupt even before she put out to sea. Following this her builders, the Japanese conglomerate Sumitomo offered her to a Hong Kong owner.
But before taking delivery, her new owner set an unusual condition. Already massive at 480,000 tonnes, he ordered that her length be increased several more meters to add another 87,000 tonnes to her load-carrying capacity to make her, at 564,763 tonnes, the largest ship to ever be built.
Two years later, in 1981, she was finally ready to be put to sea under the name the Sea Wise Giant.
As the timing goes, her launch was not without hassles. Unfortuitous. Two major oil-producing states of Iran and Iraq were locked in a bitter war, and with the Arab world believed to be bankrolling if not actually backing Iraq, any ship carrying Iranian or Arab oil (in effect every tanker playing the Persian Gulf, the source of most of the worlds oil), was seen as a legitimate military target by the other country.


Against this backdrop it was too much to expect the Sea Wise Giant to sail without hindrance. Still, for the first few years of her life she plied her trade unmolested in the Gulf of Mexico, even doubling as a storage tanker, ill fate propelled her towards a more active duty in the Persian Gulf, and transformed her into a sitting duck for would-be takers.
As expected, disaster struck soon enough. While sailing the Hormuz Straits in 1986, she was targeted by Iraqi jets, who fired their full complement of Exocet missiles into her hull. The Sea Wise Giant never had a chance. Extensively damaged, she sank in the shallow waters off Irans Kharg Island.
Here she would sit out for the remainder of the war. And might have sat indefinitely had it not been for her uniqueness and what maritime assessors saw as her enduring value. The Sea Wise Giant, or what remained of her, was bought by a Norwegian company, re-floated, and towed to the Keppel shipyard in Singapore. After major conversions and repairs she was re-launched in 1991 as the TT Jahre Viking, quite simply the largest ship that set sail again.
But although she now regularly sails into the sunset, parting the seas before her as she goes, life is still not bed of roses aboard the Jahre Viking. To quote KPS Kang, a Chandigarh youth, back after a stint as Chief Officer aboard her. "When you work as Chief Officer on the worlds biggest ship your responsibilities are bigger in every sense of the word". In his case it meant looking after cargo, discharge and maintenance of 46 tanks and 31,541 square meters of deck.

At sea, especially when negotiating rocky straits and shallow waters, the need for constant depth current monitoring is that much greater. And at port, or what substitutes as port, single-buoy moorings in the open sea or ship-to-ship transfer of cargo entail a lot of risk. The risk of accidents or spillage is much higher than with ships working out of safe harbours.
In tacit recognition of this and her sheer size, the Jahre Viking has been designated in the class of worst-case scenarios by the US Coast Guard, prompting strict international monitoring and compensatory vigilance on the part of her crew and a goodbye to the occasional perk like a Singapore sling to a setting tropical sun. (Following the Exxon Valdez disaster off the coast of Alaska blamed on its drunken captain; most tankers adopted a no-alcohol policy).
Surprisingly, for a ship her size, the Jahre Viking packs in a rather small crew of 40, about the same number as aboard two Air India Jumbos. And all of these are of non-Norwegian origin. In fact, barring the occasional Russian junior officer, all officers, including her captain, are Indians. The crew is almost entirely Filipino.

In March 2004, the Jahre Viking was sent by its new owner, Fred. Olsen Production a.s (FOP), wholly owned subsidiary of First Olsen Tankers, to the shipyard Dubai Dry-docks to be refitted as a floating storage and offloading unit ("FSO")
There, it was given its current name, Knock Nevis. The ship now operates as an FSO at the Al Shaheen oilfield in the waters of Qatar.
Source and for more information see : http://members.tripod.com/






Tuesday, December 11, 2007

How Bluetooth works

Hi

This is a simple article which i got through one of the forwards in a freinds group.This will give you a clear picture in a simple way as how bluetooth works.



There are lots of different ways that electronic devices can connect to one another.

For example:

Component cables

Electrical wires

Ethernet cables

WiFi

Infrared signals

When you use computers, entertainment systems or telephones, the various pieces and parts of the systems make up a community of electronic devices. These devices communicate with each other using a variety of wires, cables, radio signals and infrared light beams, and an even greater variety of connectors, plugs and protocols.

The art of connecting things is becoming more and more complex every day. In this article, we will look at a method of connecting devices, called Bluetooth, that can streamline the process. A Bluetooth connection is wireless and automatic, and it has a number of interesting features that can simplify our daily lives.

The Problem:

When any two devices need to talk to each other, they have to agree on a number of points before the conversation can begin. The first point of agreement is physical: Will they talk over wires, or through some form of wireless signals? If they use wires, how many are required -- one, two, eight, 25? Once the physical attributes are decided, several more questions arise:

How much data will be sent at a time? For instance, serial ports send data 1 bit at a time, while parallel ports send several bits at once. How will they speak to each other? All of the parties in an electronic discussion need to know what the bits mean and whether the message they receive is the same message that was sent. This means developing a set of commands and responses known as a protocol.

Setting up a conversation between multiple devices often means a large array of cables, connectors and adapters. In order to make home electronics more user friendly, we need a better way for all the electronic parts of our modern life to talk to each other. That's where Bluetooth comes in. Bluetooth is a standard developed by a group of electronics manufacturers that allows any sort of electronic equipment -- from computers and cell phones to keyboards and headphones -- to make its own connections, without wires, cables or any direct action from a user.

The Bluetooth Solution

Bluetooth takes small-area networking to the next level by removing the need for user intervention and keeping transmission power extremely low to save battery power. Picture this: You're on your Bluetooth-enabled cell phone, standing outside the door to your house. You tell the person on the other end of the line to call you back in five minutes so you can get in the house and put your stuff away. As soon as you walk in the house, the map you received on your cell phone from your car's Bluetooth-enabled GPS system is automatically sent to your Bluetooth-enabled computer, because your cell phone picked up a Bluetooth signal from your PC and automatically sent the data you designated for transfer. Five minutes later, when your friend calls you back, your Bluetooth-enabled home phone rings instead of your cell phone. The person called the same number, but your home phone picked up the Bluetooth signal from your cell phone and automatically re-routed the call because it realized you were home. And each transmission signal to and from your cell phone consumes just 1 milliwatt of power, so your cell phone charge is virtually unaffected by all of this activity

Bluetooth is essentially a networking standard that works at two Levels :

It provides agreement at the physical level -- Bluetooth is a radio-frequency standard.

It provides agreement at the protocol level, where products have to agree on when bits are sent, how many will be sent at a time, and how the parties in a conversation can be sure that the message received is the same as the message sent.

The big draws of Bluetooth are that it is wireless, inexpensive and automatic. There are other ways to get around using wires, including infrared communication. Infrared (IR) refers to light waves of a lower frequency than human eyes can receive and interpret. Infrared is used in most television remote control systems. Infrared communications are fairly reliable and don't cost very much to build into a device, but there are a couple of drawbacks. First, infrared is a "line of sight" technology. For example, you have to point the remote control at the television or DVD player to make things happen. The second drawback is that infrared is almost always a "one to one" technology. You can send data between your desktop computer and your laptop computer, but not your laptop computer and your PDA at the same time.

These two qualities of infrared are actually advantageous in some regards. Because infrared transmitters and receivers have to be lined up with each other, interference between devices is uncommon. The one-to-one nature of infrared communications is useful in that you can make sure a message goes only to the intended recipient, even in a room full of infrared receivers. Bluetooth is intended to get around the problems that come with infrared systems. The older Bluetooth 1.0 standard has a maximum transfer speed of 1 megabit per second (Mbps), while Bluetooth 2.0 can manage up to 3 Mbps. Bluetooth 2.0 is backward compatible with 1.0 devices.

Let's find out how Bluetooth networking works.

Why is it called Bluetooth?

Harald Bluetooth was king of Denmark in the late 900s. He managed to unite Denmark and part of Norway into a single kingdom then introduced Christianity into Denmark. He left a large monument, the Jelling rune stone, in memory of his parents. He was killed in 986 during a battle with his son, Svend Forkbeard. Choosing this name for the standard indicates how important companies from the Baltic region (nations including Denmark, Sweden, Norway and Finland) are to the communications industry, even if it says little about the way the technology works.

Bluetooth Operation

Bluetooth networking transmits data via low-power radio waves. It communicates on a frequency of 2.45 gigahertz (actually between 2.402 GHz and 2.480 GHz, to be exact). This frequency band has been set aside by international agreement for the use of industrial, scientific and medical devices (ISM).

A number of devices that you may already use take advantage of this same radio-frequency band. Baby monitors , garage-door openers and the newest generation of cordless phones all make use of frequencies in the ISM band. Making sure that Bluetooth and these other devices don't interfere with one another has been a crucial part of the design process. One of the ways Bluetooth devices avoid interfering with other systems is by sending out very weak signals of about 1 milliwatt. By comparison, the most powerful cell phones can transmit a signal of 3 watts. The low power limits the range of a Bluetooth device to about 10 meters (32 feet), cutting the chances of interference between your computer system and your portable telephone or television. Even with the low power, Bluetooth doesn't require line of sight between communicating devices. The walls in your house won't stop a Bluetooth signal, making the standard useful for controlling several devices in different rooms.

Bluetooth can connect up to eight devices simultaneously. With all of those devices in the same 10-meter (32-foot) radius, you might think they'd interfere with one another, but it's unlikely. Bluetooth uses a technique called spread-spectrum frequency hopping that makes it rare for more than one device to be transmitting on the same frequency at the same time. In this technique, a device will use 79 individual, randomly chosen frequencies within a designated range, changing from one to another on a regular basis. In the case of Bluetooth, the transmitters change frequencies 1,600 times every second, meaning that more devices can make full use of a limited slice of the radio spectrum. Since every Bluetooth transmitter uses spread-spectrum transmitting automatically, it's unlikely that two transmitters will be on the same frequency at the same time. This same technique minimizes the risk that portable phones or baby monitors will disrupt Bluetooth devices, since any interference on a particular frequency will last only a tiny fraction of a second.

When Bluetooth-capable devices come within range of one another, an electronic conversation takes place to determine whether they have data to share or whether one needs to control the other. The user doesn't have to press a button or give a command -- the electronic conversation happens automatically. Once the conversation has occurred, the devices -- whether they're part of a computer system or a stereo -- form a network. Bluetooth systems create a personal-area network (PAN), or piconet, that may fill a room or may encompass no more distance than that between the cell phone on a belt-clip and the headset on your head. Once a piconet is established, the members randomly hop frequencies in unison so they stay in touch with one another and avoid other piconets that may be operating in the same room. In the next section, we'll check out an example of a Bluetooth-connected system

Piconets

Let's say you have a typical modern living room with the typical modern stuff inside. There's an entertainment system with a stereo, a DVD player, a satellite TV receiver and a television ; there's also a cordless telephone and a personal computer. Each of these systems uses Bluetooth, and each forms its own piconet to talk between the main unit and peripheral.

The cordless telephone has one Bluetooth transmitter in the base and another in the handset. The manufacturer has programmed each unit with an address that falls into a range of addresses it has established for a particular type of device. When the base is first turned on, it sends radio signals asking for a response from any units with an address in a particular range. Since the handset has an address in the range, it responds, and a tiny network is formed. Now, even if one of these devices should receive a signal from another system, it will ignore it since it's not from within the network. The computer and entertainment system go through similar routines, establishing networks among addresses in ranges established by manufacturers. Once the networks are established, the systems begin talking among themselves. Each piconet hops randomly through the available frequencies, so all of the piconets are completely separated from one another.

Now the living room has three separate networks established, each one made up of devices that know the address of transmitters it should listen to and the address of receivers it should talk to. Since each network is changing the frequency of its operation thousands of times a second, it's unlikely that any two networks will be on the same frequency at the same time. If it turns out that they are, then the resulting confusion will only cover a tiny fraction of a second, and software designed to correct for such errors weeds out the confusing information and gets on with the network's business.

Flexible Tranmission

Most of the time, a network or communications method either works in one direction at a time, called half-duplex communication , or in both directions simultaneously, called full-duplex communication. A speakerphone that lets you either listen or talk, but not both, is an example of half-duplex communication, while a regular telephone handset is a full-duplex device. Because Bluetooth is designed to work in a number of different circumstances, it can be either half-duplex or full-duplex.

The cordless telephone is an example of a use that will call for a full-duplex (two-way) link, and Bluetooth can send data at more than 64 kilobits per second (Kbps) in a full- duplex link -- a rate high enough to support several voice conversations. If a particular use calls for a half-duplex link -- connecting to a computer printer, for example -- Bluetooth can transmit up to 721 Kbps in one direction, with 57.6 Kbps in the other. If the use calls for the same speed in both directions, Bluetooth can establish a link with 432.6-Kbps capacity in each direction.

Bluetooth Security :

In any wireless networking setup, security is a concern. Devices can easily grab radio waves out of the air, so people who send sensitive information over a wireless connection need to take precautions to make sure those signals aren't intercepted. Bluetooth technology is no different -- it's wireless and therefore susceptible to spying and remote access, just like WiFi is susceptible if the network isn't secure. With Bluetooth, though, the automatic nature of the connection, which is a huge benefit in terms of time and effort, is also a benefit to people looking to send you data without your permission.

Bluetooth offers several security modes, and device manufacturers determine which mode to include in a Bluetooth-enabled gadget. In almost all cases, Bluetooth users can establish "trusted devices" that can exchange data without asking permission. When any other device tries to establish a connection to the user's gadget, the user has to decide to allow it. Service-level security and device-level security work together to protect Bluetooth devices from unauthorized data transmission. Security methods include authorization and identification procedures that limit the use of Bluetooth services to the registered user and require that users make a conscious decision to open a file or accept a data transfer. As long as these measures are enabled on the user's phone or other device, unauthorized access is unlikely. A user can also simply switch his Bluetooth mode to "non-discoverable" and avoid connecting with other Bluetooth devices entirely. If a user makes use of the Bluetooth network primarily for synching devices at home, this might be a good way to avoid any chance of a security breach while in public.

Still, early cell-phone virus writers have taken advantage of Bluetooth's automated connection process to send out infected files. However, since most cell phones use a secure Bluetooth connection that requires authorization and authentication before accepting data from an unknown device, the infected file typically doesn't get very far. When the virus arrives in the user's cell phone, the user has to agree to open it and then agree to install it. This has, so far, stopped most cell-phone viruses from doing much damage.

Other problems like "bluejacking, " "bluebugging" and "Car Whisperer" have turned up as Bluetooth-specific security issues. Bluejacking involves Bluetooth users sending a business card (just a text message, really) to other Bluetooth users within a 10-meter (32-foot) radius. If the user doesn't realize what the message is, he might allow the contact to be added to his address book, and the contact can send him messages that might be automatically opened because they're coming from a known contact. Bluebugging is more of a problem, because it allows hackers to remotely access a user's phone and use its features, including placing calls and sending text messages, and the user doesn't realize it's happening. The Car Whisperer is a piece of software that allows hackers to send audio to and receive audio from a Bluetooth-enabled car stereo. Like a computer security hole, these vulnerabilities are an inevitable result of technological innovation, and device manufacturers are releasing firmware upgrades that address new problems as theyarise.

Monday, December 10, 2007



Hi

I am pathanjali.I blog various articles related to my profession and also interests.

Just started

I have just started to blog