Monday, June 29, 2009

Exploratory Testing

Exploratory Testing

An interactive process of concurrent product exploration, test design, and test execution. The heart of exploratory testing can be stated simply: The outcome of this test influences the design of the next test.

The plainest definition of exploratory testing is test design and test execution at the same time. This is the opposite of scripted testing (predefined test procedures, whether manual or automated). Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan. This may sound like a straightforward distinction, but in practice it's murky. That's because "defined" is a spectrum. Even an otherwise elaborately defined test procedure will leave many interesting details (such as how quickly to type on the keyboard, or what kinds of behavior to recognize as a failure) to the discretion of the tester. Likewise, even a free-form exploratory test session will involve tacit constraints or mandates about what parts of the product to test, or what strategies to use. A good exploratory tester will write down test ideas and use them in later test cycles. Such notes sometimes look a lot like test scripts, even if they aren't. Exploratory testing is sometimes confused with "ad hoc" testing. Ad hoc testing normally refers to a process of improvised, impromptu bug searching. By definition, anyone can do ad hoc testing

What kinds of specifics affect ET? Here are some of them:

1. the mission of the test project
2. the mission of this particular test session
3. the role of the tester
4. the tester (skills, talents, and preferences)
5. available tools and facilities
6. available time
7. available test data and materials
8. available help from other people
9. accountability requirements
10. what the tester‘s clients care about
11. the current testing strategy
12. the status of other testing efforts on the same product
13. the product, itself- its user interface - its behavior - its present state of execution - its defects- its testability- its purpose
14. what the tester knows about the product- what just happened in the previous test - known problems with it- past problems with it - strengths and weaknesses - risk areas and magnitude of perceived risk - recent changes to it - direct observations of it- rumors about it - the nature of its users and user behavior - how it‘s supposed to work - how it‘s put together - how it‘s similar to or different from other products
15. what the tester would like to know about the product

Software Testing Training

http://www.qacampus.com


QACampus is Center of Education for anything and everything about software testing.


http://www.crestech.in

http://www.crestechsoftware.com.au

Boundary Value Analysis

Boundary Value Analysis

Large number of errors tend to occur at boundaries of the input domain.

BVA leads to selection of test cases that exercise boundary values.

BVA complements equivalence partitioning. Rather than select any element in an equivalence class, select those at the ''edge' of the class.

Examples:

For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1).

If input conditions specify a number of values n, test with (n-1), n and (n+1) input values.

Apply 1 and 2 to output conditions (e.g., generate table of minimum and maximum size).

If internal program data structures have boundaries (e.g., buffer size, table limits), use input data to exercise structures on boundaries.


Software Testing Training

http://www.qacampus.com


QACampus is Center of Education for anything and everything about software testing.


http://www.crestech.in

http://www.crestechsoftware.com.au

About Software Testing

About Software Testing

Process of evaluation of Software application: To verify it satisfy the specified requirements With intent to find errors To Check if the system ?Fit for Purpose? Simulation of real time scenarios.

Testing is not a one-time activity—applications need to be tested throughout their lifecycle. Every version upgrade, module addition, or enhancement, as well as every implementation at a new site or increase in user load, needs to be put through comprehensive testing. The Program Doesn‘t Work Nobody would pay you to test if their program didn‘t have bugs. All programs have bugs. Any change to a program can cause new bugs, and any aspect of the program can be broken. You DON‘T ?verify that the program is working.? You FIND bugs. “If you set your mind to show that a program works correctly, you’ll be more likely to miss problems than if you want and expect the program to fail.” Complete Testing is Impossible:

1. There are a nearly infinite number of paths through any non-trivial program.
2. There are a virtually infinite set of combinations of data that you can feed the program.
You can’t test them all.
1. Therefore, your task is to find bugs --not to find all the bugs.
2. You want to find as many bugs as possible
3. Find the most serious bugs
4. Find bugs as early as possible
5. Your challenges will require judgment, trade-offs, and efficiency.

“Q: How many QA testers does it take to change a lightbulb?
A: QA testers don't change anything. They just report that it's dark.” Kerry Zallar?

Software Testing Training

http://www.qacampus.com


QACampus is Center of Education for anything and everything about software testing.


http://www.crestech.in

http://www.crestechsoftware.com.au

Tuesday, May 26, 2009

Automated Functional Testing

Automated Functional Testing

By Bhrigu Malhotra

First of all let me make you all aware that I’m a developer and what you are going to read further is a developer’s account, so it may sound to you like a layman tester. But what I’m going to share is something which has been very helpful to me to ‘functionally’ test the web application our team has been building and I thought this may help you as well. So even if you are a tester, try to think the way developer’s think for some time, I’m sure this would be useful to you too.

Before I go ahead, I think we all understand that Functional Testing is testing the functionality of our application which means you’d probably be going through a login using some credentials, clicking some links, verifying some outputs - in simplest terms. Now just give it a thought that if you can automate these i.e. invest some time for once and then while you are sipping a cup of coffee, someone is testing what you coded. Change your code 10 times and run your test 10 times to ensure nothing breaks, so easy. Not just this if you have continuous integration server setup which runs your tests, you’d come to know immediately if and when someone else broke your code. Believe me ones who have used it, feel it is fantastic.

There are a variety of tools available for this over internet each with pros/cons but I’m going to share some info here about one which I liked very much and have been using for a while now. I’d also share why I preferred it over others.

Ok, no longer prolonging the suspense the tool I’m talking about is called Canoo WebTest (webtest.canoo.com) which is a free Open Source tool for automated testing of web applications in a very effective way. The primary reason why I liked it is that it is FAST; very fast … most of the test cases that I’ve written are executed in less than a minute and that too over remote applications deployed on servers on the other side of globe. Second reason for liking it so much is the ease of writing; very quickly you can build up your tests. Though they have released a WebTest recorder plug-in which when installed in Mozilla Firefox can record the script for you, but believe me the more you start writing there test cases, the less reliant you will become on the recorder. Third thing is these tests do not use a browser so that completely eliminated browser-specific issues which some tools are plagued with.

Now some things about WebTest which some people don’t like is you actually do not see the tests being executed i.e. loading of a browser window, automatic clicking on buttons and errors on the screen (if any). But that I feel that it is so by design …. Doing all this takes time and then browser issues too creep in, so I’m happy like this way only. I agree they can improve on reporting of errors but again the objective of this tool is to test and just to test, if you want to report issues manual intervention is needed.

At last I’ll just say go give it a try, I’m sure once past initial hiccups, you’ll start liking it the way I am.


http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au

Script Maintenance

Script Maintenance

By Renu Bala

Script maintenance is a great challenge faced by automation testers. As the course of development proceeds, applications undergo changes, which cause automation test scripts to break. For example, Developers change underlying attributes (like object name) that the test script rely upon to identify the object. So testers need to rework on scripts.

Script maintenance at some level is a fact of automation but too much maintenance can be a drain on team’s time, resulting in decreasing value of automation. Automation testing tool that build scripts that are resistant to breaking are extremely valuable.

Testers must constantly update scripts to handle minor application changes but testers may make mistakes when they update scripts.

One solution to these changes is to update the object map so that all scripts can reference updated object map and identify objects.

Second solution to these changes is Script Assure Technology introduced by Rational Functional Tester. This technology makes test scripts more resilient to changes in applications. With script assure technology, RFT evaluates the closeness of objects that it finds and attempts to match something that is closest. If objects are close enough, test continues with no intervention from tester and will log a warning so that tester is made aware of a possible discrepancy. So more tests can execute with less intervention, even with significant changes being made to objects in application. In this way RFT automatically finds changed target objects in application without object remapping. Benefit of this technology is reduced maintenance and more reliable scripts. Additionally, this flexibility is completely under tester’s control. Tester can determine what level of closeness is sufficient enough for the project.



http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au

How to Access Command prompt from QTP

How to Access Command prompt from QTP


By Parul Wahi

We can even access Microsoft Windows command prompt also known as MS-DOS from QTP interface.cmd.exe is a 32-bit command prompt used in Windows NT, 2000 and XP and offers disk and file maintenance functions as well as network functions. It can be found under System32 folder.

To launch cmd.exe from QTP write :

SystemUtil.Run “cmd.exe”, “”, “c:\WINDOWS\system32”,”open”

Once DOS window launches, this window can be leant and added to object repository

To write on command prompt window use the following code:

Window( “object class:=ConsoleWindowClass”).Type “Ping crestechsoftware.com”

Window( “object class:=ConsoleWindowClass”).Type micReturn

Using WshShell object

The WshShell object gives your scripts the ability to work with Windows shell .Your scripts can use the WshShell object to perform a number of system administration tasks, including running programs, reading from and writing to the registry, and creating shortcuts.

Following are the list of few methods used with wcript object:

1)The Environment property helps in getting environment variables

2)The Exec method returns a WshScriptExec object, which provides status and error information about a script run with Exec along with access to the StdIn, StdOut, and StdErr channels. The Exec method allows the execution of command line applications only.

3)Pop Up Method Displays text in a pop-up message box.

4)RegRead Method helps in reading from registry

Example

The following example demonstrates the basics of the Exec method.

Dim WshShell, oExec

Set WshShell = CreateObject(”WScript.Shell”)

Set oExec = WshShell.Exec(”calc”)

Do While oExec.Status = 0

WScript.Sleep 100

Loop

WScript.Echo oExec.Status


http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au

How to Execute QTP script from Command Prompt using Automation Object Model

How to Execute QTP script from Command Prompt using Automation Object Model

By Parul Wahi

In order to run QTP scripts on schedule, we can run them directly from command line.

In order to do so we can make use of QTP Automation Object Model which can help us in automating QuickTest operations. Using the objects, methods, and properties exposed by the QuickTest automation object model, we can write scripts that configure QuickTest options and run tests instead of performing these operations manually using the QuickTest interface.

In the following code we are trying to execute a QTP script called “Google_search” from command line. Let’s create a script in QTP and save it as Google_search.Write the following code in a vbs (VB Script) file as save it as demo.vbs:

Dim qtApp ‘ Declare the Application object variable

Dim qtTest ‘ Declare a Test object variable

Dim qtResultsOpt ‘Declare a Run Results Options object variable

Set qtApp = CreateObject(”QuickTest.Application”) ‘ Create the Application object

qtApp.Launch ‘ Start QuickTest

qtApp.Visible = True ‘ Make the QuickTest application visible

qtApp.Open “C:\Documents and Settings\pwahi\Desktop\Google search“, True ‘ Open the test in read-only mode

‘ set run settings for the test

Set qtTest = qtApp.Test

qtTest.Run’ Run the test

WScript.StdOut.Write “Status is:” & qtTest.LastRunResults.Status ‘ Check the results of the test run

qtTest.Close ‘ Close the test

Set qtTest = Nothing ‘ Release the Test object

Set qtApp = Nothing ‘ Release the Application object

Now in order to execute QTP script from command line we have to execute the above created vbs file from command prompt which will in turn launch QTP, open the script, run it and will display the result in command prompt only. Open command prompt and write following code:

C:\Documents and Settings\pwahi\Desktop>cscript //nologo demo.vbs

And press enter

This command will execute the demo.vbs file which in turn launch QTP, open the script Google search, execute it and will display the result in QTP result file. We can also see the results in command prompt as shown below.



http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au