What is Perl? - The QTP Knowledge blog

Perl is a programming language. Perl stands for Practical Report and Extraction Language. You'll notice people refer to 'perl' and "Perl". "Perl" is the programming language as a whole whereas 'perl' is the name of the core executable. Some of Perl's many strengths are:
Speed of development: You edit a text file, and just run it. You can develop programs very quickly like this. No separate compiler needed. I find Perl runs a program quicker than Java, let alone compare the complete modify-compile-runoh- no-forgot-that-semicolon sequence.
Power: Perl's regular expressions are some of the best available. You can work with objects, sockets...everything a systems administrator could want. And that's just the standard distribution. Add the wealth of modules available on CPAN and you have it all. Don't equate scripting languages with toy languages.
Usuability: All that power and capability can be learnt in easy stages. If you can write a batch file you can program Perl. You don't have to learn object oriented programming, but you can write OO programs in Perl. If auto incrementing nonexistent variables scares you, make perl refuse to let you. There is always more than one way to do it in Perl. You decide your style of programming, and Perl will accommodate you.
Portability: On the Superhighway to the Portability Panacea, Perl's Porsche powers past Java's jaded jalopy. Many people develop Perl scripts on NT, or Win95, then just FTP them to a Unix server where they run. No modification necessary.
Editing tools: You don't need the latest Integrated Development Environment for Perl. You can develop Perl scripts with any text editor. Notepad, vi, MS Word 97, or even direct off the console. Of course, you can make things easy and use one of the many freeware or shareware programmer's file editors.
Price: Yes, 0 guilders, pounds, dmarks, dollars or whatever. And the peer to peer support is also free, and often far better than you'd ever get by paying some company to answer the phone and tell you to do what you just tried several times already, then look up the same reference books you already own.
What can I do with Perl ?

Just two popular examples :

The Internet
Go surf. Notice how many websites have dynamic pages with .pl or similar as the filename extension? That's Perl. It is the most popular language for CGI programming for many reasons, most of which are mentioned above. In fact, there are a great many more dynamic pages written with perl that may not have a .pl extension. If you code in Active Server Pages, then you should try using ActiveState's PerlScript. Quite frankly, coding in PerlScript rather than VBScript or JScript is like driving a car as opposed to riding a bicycle. Perl powers a good deal of the Internet.

Systems Administration
If you are a Unix sysadmin you'll know about sed, awk and shell scripts. Perl can do everything they can do and far more besides. Furthermore, Perl does it much more efficiently and portably. Don't take my word for it, ask around. If you are an NT sysadmin, chances are you aren't used to programming. In which case, the advantages of Perl may not be clear. Do you need it? Is it worth it?
After you read this tutorial you will know more than enough to start using Perl productively. You really need very little knowledge to save time. Imagine driving a car for years, then realising it has five gears, not four. That's the sort of improvement learning Perl means to your daily sysadminery. When you are proficient, you find the difference like realising the same car has a reverse gear and you don't have to push it backwards. Perl means you can be lazier. Lazy sysadmins are good sysadmins, as I keep telling my boss.

A few examples of how I use Perl to ease NT sysadmin life:

User account creation: If you have a text file with the user's names in it, that is all you need. Create usernames automatically, generate a unique password for each one and create the account, plus create and share the home directory, and set the permissions.

Event log munging: NT has great Event Logging. Not so great Event Reading.
You can use Perl to create reports on the event logs from multiple NT servers.
Anything else that you would have used a batch file for, or wished that you could automate somehow. Now you can.

To learn more on Perl or VbScript and maybe a continue the series on Perl  follow the link below:

Source: What is Perl? - Sandip


Mobile Apps Testing & Mobile Apps Testing Links - Info on Software Testing

The most buzz words now a days are iPhone,HTC,Motorola,Samsung, Android, Blackberry etc.. all the internet and multimedia enabled smart phones.Now its just your mobile which has almost all the necessary features such as a camera, a phone and for text messaging, a visual voice mail, a portable media player, an internet client, with e-mail, web browsing, Wi-Fi connectivity, Bluetooth etc..Almost all these devices have virtual key board or a QWERTY keyboard which just looks like your handling a palmtop and not a mobile

Apart from all the features users are always given the best chance to add Apps to their mobile as per their interest, be it games, reference, GPS navigation, social networking etc..

When i started thinking on mobile applications, many questions came to my mind...

  • How are the applications developed for mobiles?
  • Can test driven development be done for mobile applications?
  • If so how should the testing be done?
  • From QA what are the steps i need to take care to ensure that the application is working fine?
  • Does the same test cases which i write for the application functional testing on portal/website (cross browser supported) holds good for mobile testing as well..?
  • and lot more....
Most of the mobile platforms are mutually incompatible i.e. most of the applications developed on one platform does not support the other platform. So its up to the application owners choice to decide on what all his application should support. For more information on mobile application development click here


As my focus is mostly on testing.. here are my understandings on the same:
Can test driven development be done for mobile applications?
Yes Test driven development is possible for mobile apps as well. 

Do we need to port the application daily into mobile and then test it? nope. There are Emulators/Simulators which can be used for testing. They simulate the actual device environment in our machines as shown above. All the functional aspects can be tested in the emulators. 

The major change that i have observed while testing the application on emulator and the actual device is the view. Now a days most of the mobiles have both landscape and portrait views. In emulators we can only check the portrait view. So at the end when we actually start testing on actual device, you'll find lot many resizing issues. This is again if your application supports both the views. most of the applications now are days are strictly developed for portrait view.

Important Mobile Apps Testing Links

Human Interface Guidelines:

Palm Information:
Installing Palm SDK:
Command line Tools:


Blackberry Dev Zone:
Blackberry Simulator:

For reading more on the same follow the link below:


Inspiring Testers [Walt Hays]

I was reading an interview article and was amazed by the variations in carrer Mr Walt Hays has.

Quoting from the "digitale stories" about him:

" Walt Hays got his bachelor’s degree in international relations from UC Davis, and went on to spend 14 years working in the software industry. He did software testing and tech support, moved into engineering management and eventually rose to become a vice president of products with close to 40 people working under his supervision. The company, Dantz Development, then was doing $10 million a year in sales with over 120 employees. The work was “complex, stressful and fascinating.” In 2002 he left the company, moved to Sebastopol and got his teaching credential at Sonoma State University. For the past six years he has been teaching mathematics at Analy High School in Sebastopol. "

To read about the interview:

Source: A High Tech Exec., Then a Teacher: Walt Hays - Digitale Stories


Code Debugging while exploratory testing - Journey begins...

Yesterday, I was reading a book “How we test software at Microsoft” by Alan page and his colleagues. I liked his approach of debugging the code before designing test cases or doing exploratory testing. I am quoting his words below:

“Frequently, when I am testing a component or feature for the first time and I have source code available, I use the debugger to test. Before I even write test cases, I write a few basic tests. These might be automated tests, or they might be just a few ideas that I have scribbled onto a pad. I set a breakpoint somewhere in the component initialization, and then use the debugger to understand how every code path is reached and executed. I note where boundary conditions need testing and where external data is used. I typically spend hours (and sometimes days) poking and prodding (and learning and executing) until I feel I have a good understanding of the component. At that point, I usually have a good idea of how to create an efficient and effective suite of tests for the component that can be used for the lifetime of the product.”

Source: Code Debugging while exploratory testing - Kashif


QTP Folder Structure for a testcase - Automation Testing with QuickTestPro

All the folders and files you should know if you are working on QTP:

P.S:  Click on the image and download for quick reference

Source:  Automation Testing with QuickTestPro - Baba


An introduction to soapUI for testing web services - XeBee

Soap UI  is a free, open-source desktop application specifically designed to inspect, develope, invoke and test WSDL or REST based web services.In this blog I have tried to introduce the tool and list some of its most useful features.In my successive blogs I will dig deeper and try to explain how it can be used to test functionality and performance of web services by anyone who is just starting with web services testing.

I have been using soapUI for a while now and it not only provides the capability to test services for its functionality but is also quite capable of load testing them under different scenarios.Add to it the limited but powerful capability to do compliance testing and we almost have a one stop solution for our testing needs as far as web services are concerned.

Its intuitive and interactive GUI stacked with useful features makes web service functional and performance testing a breeze.Since its free and open-source its power mainly lies in scripting using groovy and the user must have some experience with it as trivial tasks like loading values from files and passing property values in between test steps would require the user to write scripts.The soapUI project is hosted on sourceforge.

soapUI Pro

A commercial version of soapUI, soapUI Pro, which adds expert professional support and a number of nifty features to the soapUI interface is available and its been gaining popularity within the development community (programmers and testers alike).This is mainly due to its ease of usage,low cost of licensing (resulting in high ROI) and a excellent support team.SoapUI pro adds to the core functionality of soapUI some very user friendly and powerful features which makes it possible for a user having very less and even negligible scripting experience to use the tool extensively for testing services.

Some powerful features of soapUI/soapUI Pro

Some of the features of the tool which are worth mentioning are listed below :
  • Data driven testing of services to verify and assert request-response messages against a large set of data.
  • Load testing to measure performance alongwith ensuring that the functionality is not breaking by applying different load test strategies.
  • Schema and SOAP compliance assertions which can be included as default assertions in test cases to verify that incoming and outgoing messages are schema compliant and the response is not a soap fault.
  • Xpath,Xquery and groovy assertions to handle response validations.
  • WSDL,XSD and XML inspectors to verify wsdl,scehma and message content.
  • Support for groovy scripting: This enables creation of generic libraries for common functions that can be reused.
  • Covergae analyzer at project,test Suite and test case level to determine contract covergae.
  • Fairly interactive and intuitive UI which can act as a service client and hence we are not required to build any additional client interface.
  • A nifty editor for xml which provides different views(form and tree views in addition to xml view) for editing the xml requests and viewing responses
  • Customizable reporting using JUinit Style HTML reports or data exports.
  • A maven plug-in which can help integrate the tests with the build process.
  • Command line runner for running functional and load tests which dispenses the need for the UI for executing the tests.
  • Web service mocking and simulation.
  • Some recently added features like REST and AMF support,JMS and JDBC test steps.
  • Plugin for different IDEs like eclipse,Net Beans and IntelliJ.

Overall, I found the tool quiet powerful and capable of doing pretty much everything I wanted to do with it.Although there are a couple of things which need improvements such as the reporting in free version is pretty basic,security testing capability is still in its nascent stage and load testing cannot be done for concurrent users beyond certain limit (dependent on OS of the client machine) as it still does not support distributed load testing.

Despite this,I would encourage anyone involved in web service developement and testing to give their services a spin using the tool as it is worth the effort.I would say that its an excellent tool to get started with web service testing and can help developers and testers equally in developing and delivering robust and high quality web services timely and in an cost effective manner.

Source: An introduction to soapUI for testing web services - XeBee


How to do real database testing (10 tips to perform serious database tests) - Software Testing Space

Many (but not all) applications under test use one or more databases. The purposes of using a database include long-term storage of data in an accessible and organized form. Many people have only a vague idea about database testing. If you are serious about learning database testing, then read on...

Firstly, we need to understand what is database testing? As you would know, a database has two main parts - the data structures (the schema) that store the data AND the data itself. Let us discuss them one by one.

The data is stored in the database in tables. However, tables may not be the only objects in the database. A database may have other objects like views, stored procedures and functions. These other objects help the users access the data in required forms. The data itself is stored in the tables. Database testing involves finding out the answers to the following questions:

Questions related to database structure

1. Is the data organized well logically?

2. Does the database perform well?

3. Do the database objects like views, triggers, stored procedures, functions and jobs work correctly?

4. Does the database implement constraints to allow only correct data to be stored in it?

5. Is the data secure from unauthorized access?

Questions related to data

1. Is the data complete?

2. Is all data factually correct i.e. in sync with its source, for example the data entered by a user via the application UI?

3. Is there any unnecessary data present?

Now that we understand database testing, it is important to know about the 5 common challenges seen before or during database testing:

To read on and know the 10 tips follow the link:

Source: Software Testing Space


Regular Expression Cheat Sheets

Most of us use regular expressions to make our automated scripts more robust. It is difficult to remember different patterns in a RegEx therefore here are a couple of cheat sheets that will surely help:

P.S: Right click on these images and open the link in new window to save a personal copy and print.


Test Variations - ABAKAS

Once you have a base of test automation, it becomes easy to do variations on a test. What if I ran test X with changed configuration Y? What if I ran it with different hardware Z?

These are one of the benefits of a good test automation stack; it becomes fairly easy to run lots of variations on the same thing, and that can result in a lot of learning about how system behavior changes as various things flex. For example, I recently took a performance test we run and tweaked the setup to make it run with different memory allocations - and in not too long I had a much better understanding of how system throughput changes as a result of adding or constraining that particular resource.

This isn't the kind of test i need to run frequently. I run it every once in a while to make sure the system behavior in this area hasn't changed, but it's overkill to run it every single night with a lot of our automation.

So here's the dilemma: Do I check in the test with my modified configuration?

Pros to checking in:

  •  Next time I run it, I'll be sure I have the same setup, so my results are comparable
  • Someone else could run the same test and gather their own information from it (or a variation on it)
 Cons to checking in:

  •  Checked-in code that doesn't run is likely to get stale and stop working as other code changes around it. This goes for test code, too!
  • Someone might try to run it more frequently, and that will take up a lot of machines for very little benefit
There's no particular right answer here. Which one you choose will depend on how hard it was to set up, how much consistency matters, whether it's really likely to stop working, and how frequently you do want to run it. Pick the one that works for you; just make sure it's a choice you make, not something you fall into.

Source: Test-variations - ABAKAS

Testing web application using Selenium RC with eclipse - Vishal Sachan

I am planing to write a use full article here where I will cover end-to-end testing your web application using Selenium in Eclipse. This is in fact a detailed version of my prev article mentioned.

As said earlier I am not in touch with Selenium i.e I am not using this currently, so I will try my best to use my memory and old days 'R and D' to get it completed with high quality and quantity.

Here I will start with selenium IDE but will not go in detail as asuming that you people are comfirtable with IDE part. If you need any help in IDE then you can refer to other articles in this blog only.

Record and save you java script
1- Open Firefox and enter the URl to browse your application
2- Launch IDE from Tool menu.
3- Record your script
4- Choose the programing language as JAVA and save your script. To chose the language go to Option-> Clipboard format and select Java-Selenium RC

Now you have a java code saved in your disk. I am making it simple and not covering scripting in detail. My motive is to teach you the end to end process of using this IDE and RC to run a simple test using Eclipse. Rest You can change your script as per your need.
Now we have ur test with us.
The next step is to open your eclipse and create a project.

1- Creating you java project in eclipse
The first step in eclipse is to create/add your project. To do this follow the steps below:
   -> Launch Eclipse
   -> Create a java project named TestProject (for example)

2- Add Junit Library to your project
The next step is to add Junit Libraries which consist of following steps: 
  ->  Go to Project Properties
  ->  Go to Java Build Path
  ->  Click on Libraries tab
  ->  Click on 'Add Library' button
  ->  Select 'Junit' option from list and click on next
  ->  Select version 'Junit4' from drop down and click on finish.

4-Add Selenium Java Client Jar into Project:-
Once you added the java libraries , the next step is to add selenium jar file. you can find it under selenium-remote-control-1.0-beta-1\selenium-java-client-driver-1.0-beta-1 folder what you have downloaded from

To add this Jar file follow the below steps:
  ->  Go to Project Properties
  ->  Go to Java Build Path
  ->  Click on Libraries tab
  ->  Click on 'Add External Jars'  button
  ->  Browse and add the 'selenium-java-client-driver.jar' from the sourse where you had saved it.

5- Initiating the Selenium Test Server
To start the selenium test server, first go to the location where your JRE is placed. For example
C:\Program Files\Java\jre6\bin\
and then Run the command java -jar selenium-server.jar
here it is assumed that you have placed your selenium server.jar file in same location. In case if you have placed it in other location you can run it in following way:

C:\Program Files\Java\jre6\bin\java -jar jar “E:\SELENIUM\selenium-remote-control-1.0-beta-1\selenium-server-1.0-beta-1\selenium-server.jar”

This will start you selenium server.

6- Adding your test (Java class )  in our Project
To add you test (which you have saved earlier) as a java class file to the project (TestProject, already saved) follow the steps:
 ->  In eclipse go to create a new java class
 ->  Create it with name MyFirstTestCase (for example) and paste the code from the file u had saved it
 ->  Choose "com.thoughtworks.selenium.SeleneseTestCase" as its super class
 ->  Finish it

7- Modifying your test script (java class)
Once you are done with ur class file, it will look like,

import com.thoughtworks.selenium.SeleneseTestCase ;
public class MyFirstTestCase extends SeleneseTestCases {
      public void setUp() throws Exception {
            setUp( " " , "*firefox'); }

............ You test script..............

In case you want to run this in diff browser then simply you can change your script
setUp( " " , "*firefox'); to setUp( " " , "*chrome'); or whatever browser you need to run wid.

8- Running your test
Finally we are ready to tun our first test. To run this in eclipse you click on Run button
select option Run as "JUnit Test'

Ohh ya one thing I forgot to mention is that if you  have eclipse with JRE version lower than 1.5 in Build Path
then it might show some error related to version not supporting. So remove the default Eclipse JRE and add JRE version 1.5 or more to System Library in Build Path.
To add this follow the steps:
-> Go to Java Build path and select Libraries tab
-> Under this select JRE system Library
-> Remove your default one
-> Now click on add Library and select JRE system Library and click next
-> Add JRE
-> Now add this JRE to your class path

So finally I am done with your end to end execution of java test using selenium RC in eclipse. Thanks.

Source: Testing web application using Selenium RC with eclipse- Vishal Sachan


How to Write a Killer Software Testing QA Resume That Will Turn Into an Interview Call - Software Testing Help

Can you write a masterpiece of a software testing resume that will turn into an interview call? If not, read on. I’m sure after reading this article you will be able to write a killer flawless software testing and quality assurance resume that will definitely turn into an interview call.

Your resume is the very first step in any job application process. It’s an opportunity to advertise yourself and demonstrate that you are the best person for the available position. Getting an interview call depends on how you present your skills in resume or CV.

How Much Time Do You Get to Impress Employer?

Software testing market is becoming very competitive and getting the job is even more difficult. For a single QA job positions recruiters are getting hundreds of quality assurance tester resumes.

You must stand out from the crowd and writing a good resume is the very first opportunity to do so. Recruiters don’t have time to read all the resumes thoroughly. Your resume will be quickly scanned within 20 to 30 seconds. Yes, you get hardly 20 to 30 seconds to persuade your employer to take the decision if to call you for an interview.

Does that make sense? To make a first good impression on prospective employer you must represent yourself effectively on first page of your resume, rather the first half page of your resume is very important to make or break it.

I see so many candidates pay very little or no attention to write a good resume. They just copy and paste others resume without even bothering to change the interests and hobbies. Remember, no matter how talented you are, if you don’t present your skills properly in resume, no one is going to see your talent.

How to Make a Great First Impression From Your Resume or CV?

Many candidates write whole story about themselves without thinking what employer’s want. First focus on employer’s need. Read the job openings carefully. Note down all the job requirements. Judge yourself based on these requirements. Prepare list of your skills matching with job requirement and highlight these skill on first page of your resume.

How to Maximize Your Chances of Getting an Interview Call?

Make sure you have a clearly stated job objective mentioned on top of your resume. Keep it short one or two lines and avoid writing irrelevant cliches. Freshers always needs to keep different versions for different jobs. E.g.: If you are applying for software testing position highlight software testing skills at prominent place in your CV.

Writing a Killer Software Testing Resume or CV:

Here I’ll answer most commonly asked questions while preparing software testing fresher resume/experienced testing resume.

What if you don’t have software testing experience?

If you are a experienced software tester then you shouldn’t have any problem writing your project details.

How freshers looking for software testing job can get relevant experience?

1) The answer is simple. Get some experience by working on dummy projects available on internet. Search for online dummy projects (e.g. Inventory management software) and download test software and all available documents. Follow complete testing process like:
requirement analysis, writing test cases, executing test cases, logging defects and reparing test reports

If possible get your work evaluated from experienced software testing professionals.

2) By adding dummy projects learned from software testing courses:

If you have joined any software testing course to learn manual testing and automation tools then you can put this dummy project experience in your resume, which may range from 1 to 6 months. This way you will have at least some experience to put in your resume rather than keeping the experience section entirely blank. This will be an added advantage from other freshers resumes.

How to write project details in tester/QA resume?

In job experience section write details of projects you worked on. Write project details with following headings:
Project name:
(Optional) Client name:
Project description: (Brief project overview in 2-3 sentences)
Environment: (mention software coding language, testing tools etc.)
Team size:
On job accomplishments: (mention all key responsibilities)

Many candidates ask “What should I put in resumes if I’ve gap in my career?”

Don’t hesitate to put the valid reason for any gap in your career. Also you shouldn’t have any problem getting job after gap in your career. There could be thousands of reasons for career gap like – enjoying holiday, relocation, handling family business, skill upgrade, maternity etc. Be honest and I’m sure you will easily convince interviewer about your career gap.

On-the-job-accomplishments on first page of your resume:

Convince employer that you have problem solving skill by giving some real time examples from your work experience. Clearly state what was the problem and how you solved that problem at workplace. Prepare some solid examples to support your claims. You can put these examples in your resume also. Also be ready to answer all relevant questions asked by interviewer for your accomplishments. E.g: “When I joined so and so project in my company I saw the work was ad-hock and there wasn’t any standard software testing process. I took initiative building a standard software testing process that fits our project needs. By this streamlined process we managed our time effectively and started concentrating more on main software testing tasks”.

Mention relevant modules/subjects you studied

This will matter most for freshers. For software testing positions candidates having computer networking and system administration skills are preferred. If you studied any subject or completed any course related to computer networking and system administration then add it in you resume. If you have Linux/Unix operating system knowledge then put it in relevant-skills section of your resume.

Software testing certifications and training:

Software testing certification is an added advantage for all testing and QA positions. Rather, testing certifications like ISTQB, CSTE etc. are mandatory criteria for most of the companies. Always keep learning and equip yourself with necessary tools and skills so that you will never face any job problem in future. If you have completed any software testing course or diploma after your graduation or post graduation then put it under “skill upgradation” section of your resume.

How to learn software testing skills to put in resume?

IF you don’t have necessary relevant skills to add in your resume then learn those skills online. Like for software testing jobs learn defect tracking and test management tools. You can get all open source software testing tools online. Download widely used open source tools and start practicing at home.


1) Learn TestLink test management tool online: TestLink online

You can practice everything on above demo TestLink page. Once you get good hands on experience on TestLink tool you can put this skill in your resume.

2) Search for online version of Bugzilla defect management tool or download and install Bugzilla defect management tool on your home PC. Learn how to add and manage defects in Bugzilla. Once you get basic knowledge of this tool you can add this tool under “Defect management tools” skill section.

This way you can learn many automation tools online.

To get more Tips for Writing Effective Software Testing Resume continue reading from here:

Source:Software Testing Help - Vijay


Page Object Pattern Web Testing - Parsh

Having spent a number of years developing Web application Test Frameworks, I wanted to document the lessons I had learned:

The main lesson is: Use the Page Object Pattern as it works well:

  • Two distinct styles of test framework, the test, and the page object. The tests are therefore decoupled from the app implementation.
  • The page object should act as the interface to the app allowing access to all elements. It should model all the HTML pages. Any changes in the application HTML should only require a change to the page object code.
  •  The tests use Domain Specific Language and have little knowledge of the underlying implementation
  • Static page checks should be performed once by the app, ideally in the page object
  • Make use of XPATH as it is very powerful and is closely related to the HTML
  • Consider OO tests so that we can lever the power of encapsulation (e.g. code completion for page elements and actions), inheritance (e..g for common page elements such as headers) and polymorphism (e.g. for reducing custom code)
  • Build reporting into the framework and include screenshot taking. Ideally the report(s) should be based on data generated by the test e.g. in XML or a database
  • Provide a customer data driven test interface(e.g. spreadsheet) for customer specific tests.
  • Consider using a well established programming language (such as Java, Ruby, or C#) as it will come with a rich library set and lots of online advice
  • Consider whether non-JS needs to be supported as this will influence your technology decision
  • Test should be 'annotated' to allow grouping so that suites of tests can be defined, such as , Smoke, Integration, UAT,Performance etc
  • Create utilities where possible to avoid unnecessary code
  • Use ENUMs to define lists which can then easily be iterated over
  • Always test the app, and never internal representations, otherwise your tests are not testing the app
  • Reload the Page Object whenever you navigate to the app page and perform a static check on the Page ID to ensure the flow is as expected
  • Run cross browser tests using a VM framework
  • Run Smoke tests on all code checkins, and all tests on a nighlty basis
Source: Page-object-pattern-testing - Parsh


General Run Error in QTP

A useful list off error descriptions for QTP general run error :

P.S:  Right click on the image and download for quick reference


Web 2.0 Security Testing Approach - Make Money without a job


Web 2.0 can be defined as the evolving trend of www technologies and web design that aim to enhance creativity, communications, secure information sharing, collaboration and functionality of the web1. 0. In contrast to the static nature of Web 1.0, Web 2.0 systems rely heavily upon user generated content. In fact, Web 2.0 has been described as the “participatory Web.” For example blogs and photo sharing services enable consumers to add and update their own content. While the focus of Web 2.0 threats emanate primarily from new usage patterns, several technologies are so widespread in Web 2.0 applications, that security threats associated with them are characteristically considered Web 2.0 security threats. Examples of such technologies include AJAX, widgets, and application platforms such as blogs, wikis and social networks.

Web 2.0 Threats:

Web 2.0 is both a set of technologies as well as a new set of consumer behaviors. The combination of these two elements has created an enormous opportunity for attackers to exploit online resources for “fun and profit.” It is important t o understand the implications of these new risks, particularly when considering employing Web 2.0 technologies for professional and commercial use. Yamanner, Samy and Spaceflash type worms are exploiting “client-side” AJAX frameworks, creating new avenues of attack and compromising some of the confidential information. On the “server-side”, XML based Web services are replacing some of the key functionalities and providing distributed application access through Web services interfaces. These remote capabilities to invoke methods over GET, POST or SOAP from the Web browser itself provide new openings to applications. On other side, RIA frameworks running on XML, XUL, Flash, Applets and JavaScripts are adding new possible sets of vectors. RIA, AJAX and Web services are adding new dimensions to Web application security.

Top Web 2.0 Security Threats

Test Approach:

It is the goal of the our Security research team to further expose these threats as well as to promote the secure use of Web 2.0 technologies for business so that organizations can take advantage of the huge opportunities afforded by this next generation of the Web in order to do more business.

Our Web 2.0 Security Testing Framework comprises of some common web vulnerabilities such as XSS, Injections and CSRF as well as some new threats that are harder to mitigate and may fall into the realm of logic issues such as insufficient authentication and anti-automation. To top that, the abstract nature of Web 2.0 makes something like phishing, not usually associated with web applications into a Web 2.0 problem.


Automated exploitation and accurate vulnerability validation

Comprehensive coverage of all OWASP application vulnerabilities such as Cross-side scripting, SQL injections, HTTP response splitting, Parameter tampering, Hidden field manipulation, Backdoors/debug options, Stealth commanding, Session fixation, Automatic intelligent form filling, Forceful browsing, Application buffer overflow, Cookie poisoning, Third-party mis-configuration, HTTP attacks, XML/SOAP tests, Content spoofing, LDAP injection, XPath injection.

Support for modern websites using JavaScript, Macromedia Flash, AJAX, Java Applets, ActiveX.

Business logic verification and testing.

Combination of automated testing with expert validation & custom exploitation.

Prioritized threat profiling with effective remediation.

The following are the type of tests covered as per our guidelines…

1. AJAX Testing:
Ajax is one of the latest web development techniques to create more advanced and better responsive web application. Though the usability of AJAX provides lots of fruitful features but it also wide opens the possibility of vulnerability to be incorporated, if not designed/developed properly. The conventional web application vulnerabilities are applicable to AJAX based development along with several specific vulnerabilities like Cross Site request forgery (CSRF/XSRF).

1.1 Testing for Cross-site scripting vulnerabilities in AJAX
In the past few months several organizations including Yahoo mail and reported about the cross-site scripting attacks where malicious JavaScript code from a particular Web site gets executed on the victim’s browser thereby compromising information. AJAX gets executed on the client-side by allowing a malicious script to be exploited by an attacker. The attacker is only required to craft a malicious link to coax unsuspecting users to visit a certain page from their Web browsers. This vulnerability existed in traditional applications as well but AJAX has added a new dimension to it.

1.2 Testing for Malicious AJAX code execution
AJAX calls are very silent and end-users would not be able to determine whether or not the browser is making silent calls using the XMLHTTPRequest object. When the browser makes an AJAX call to any Web site it replays cookies for each request. This can lead to potential opportunities for compromise.

1.3 Testing for Client side validation in AJAX routines
Today in the era of Web 2.0, most applications use AJAX routines to perform a lot of activities on the client-side such as client-side validations for data type, content-checking, date fields, etc .Now developers often commit mistakes assuming that the validation is taken care of in AJAX routines. These client-side checks must be backed up by server-side checks as well. It is possible to bypass AJAX-based validations and to make POST or GET requests directly to the application – a major source for input validation based attacks such as SQL injection, LDAP injection, etc. that can compromise a Web application’s key resources.

2. Testing for Insufficient Authentication Control
In many Web 2.0 applications, content is trusted in the hands of many users, not just a select number of authorized personnel. That means there’s a greater chance that a less-experienced user will make a change that will negatively affect the overall system. This change in a system’s design can also be exploited by hackers who now have access to a greater number of “administrative” accounts whose passwords can often be easily cracked if the correct security controls are not in place. The systems also may have insufficient brute-force controls, permit clear text passwords, or have been tied together in a single-sign-on environment, making an attack that much riskier.

3. Testing for XML Poisioning
XML traffic goes back and forth between server and browser in many of the WEB 2.0 applications. Web applications consume XML blocks coming from AJAX clients. It is possible to poison this XML block. Not uncommon is the technique to apply recursive payloads to similar-producing XML nodes multiple times. If the engine’s handling is poor this may result in a denial of services on the server. Many attackers also produce malformed XML documents that can disrupt logic depending on parsing mechanisms in use on the server. There are two types of parsing mechanisms available on the server side – SAX and DOM. This same attack vector is also used with Web services since they consume SOAP messages and SOAP messages are nothing but XML messages. Large-scale adaptation of XMLs at the application layer opens up new opportunities to use this new attack vector.

XML external entity reference is an XML property which can be manipulated by an attacker. This can lead to arbitrary file or TCP connection openings that can be leveraged by an attacker. XML schema poisoning is another XML poisoning attack vector which can change execution flow. This vulnerability can help an attacker to compromise confidential information.

4. Testing for RSS/Atom Injection
This is a new WEB 2.0 attack. RSS feeds are common means of sharing information on portals and Web applications. These feeds are consumed by Web applications and sent to the browser on the client-side. One can inject literal JavaScripts into the RSS feeds to generate attacks on the client browser. An end user visits this particular Web site loads the page with the RSS feed and the malicious script – a script that can install software or steal cookies – gets executed. This is a lethal client-side attack. Worse, it can be mutated. With RSS and ATOM feeds becoming integral part of Web applications, it is important to filter out certain characters on the server-side before pushing the data out to the end user.

5. Testing for Information Integrity
Data integrity is one of the key elements of data security. Although a hack could lead to loss of integrity, so can unintentional misinformation. A great example of this in the public arena is a mistaken edit on Wikipedia which is then accepted as fact by many of the site’s visitors. In a business environment, having systems open to many users allows a malicious or mistaken user or users to post and publish inaccurate information which destroys the integrity of the data.

6. Testing for WSDL Scanning and Enumeration
WSDL (Web Services Definition Language) is an interface to Web services. This file provides key information about technologies, exposed methods, invocation patterns, etc. This is very sensitive information and can help in defining exploitation methods. Unnecessary functions or methods kept open can cause potential disaster for Web services. It is important to protect WSDL file or provide limited access to it. In real case scenarios, it is possible to discover several vulnerabilities using WSDL scanning.

7. Testing for CSRF
In CSRFs, victim visit what appear to be innocent-looking web sites, but which contain malicious code which generates requests to a different site instead. Due to heavy use of AJAX, Web 2.0 applications are potentially more vulnerable to this type of attack. In legacy apps, most user-generated requests produced a visual effect on the screen, making CSRF easier to spot. Web 2.0 systems’ lack of visual feedback make this attack less apparent. A recent example of a CSRF involved vulnerability in Twitter in which site owners could get the Twitter profiles of their visitors.

8. Testing for web services routing issues
Web services security protocols have WS-Routing services. WS-Routing allows SOAP messages to travel in specific sequence from various different nodes on the Internet. Often encrypted messages traverse these nodes. A compromise of any of the intermediate nodes results in possible access to the SOAP messages traveling between two end points. This can be a serious security breach for SOAP messages. As Web applications move to adopt the Web services framework, focus shifts to these new protocols and new attack vectors are generated.

9. Testing for Insufficient Anti Automation
Programmatic interfaces of Web 2.0 applications let hackers automate attacks easier. In addition to brute force and CSRF attacks, other examples include the automated retrieval of a large amount of information and the automated opening of accounts. Anti-automation mechanisms like Captchas can help slow down or thwart these types of attacks.

When introducing Web 2.0 into the workplace, it’s important to have a good understanding of the types of risks involved. However, that said, while Web 2.0 may present different types of challenges, those are not necessarily any worse than the risks involved with legacy applications – they’re just different. And the opportunities that Web 2.0 technology can provide a business make overcoming these potential threats worth the effort.

10. Testing for Parameter manipulation with SOAP
Web services consume information and variables from SOAP messages. It is possible to manipulate these variables. For example, “10” is one of the nodes in SOAP messages. An attacker can start manipulating this node and try different injections – SQL, LDAP, XPATH, command shell – and explore possible attack vectors to get a hold of internal machines. Incorrect or insufficient input validation in Web services code leaves the Web services application open to compromise. This is a new available attack vector to target Web applications running with Web services.

11. Testing for XPATH Injection in SOAP Messages
XPATH is a language for querying XML documents and is similar to SQL statements where we can supply certain information (parameters) and fetch rows from the database. XPATH parsing capabilities are supported by many languages. Web applications consume large XML documents and many times these applications take inputs from the end user and form XPATH statements. These sections of code are vulnerable to XPATH injection. If XPATH injection gets executed successfully, an attacker can bypass authentication mechanisms or cause the loss of confidential information. There are few known flaws in XPATH that can be leverage by an attacker. The only way to block this attack vector is by providing proper input validation before passing values to an XPATH statement.

12. Testing for RIA Thick Client Binary Manipulation
Rich Internet Applications (RIA) use very rich UI features such as Flash, ActiveX Controls or Applets as their primary interfaces to Web applications. There are a few security issues with this framework. One of the major issues is with session management since it is running in browser and sharing same session. At the same time since the entire binary component is downloaded to the client location, an attacker can reverse engineer the binary file and decompile the code. It is possible to patch these binaries and bypass some of the authentication logic contained in the code. This is another interesting attack vector for WEB 2.0 frameworks.

Tools Used:
OWASP Sprajx Tool

The most three important technological vectors for the WEB 2.0 application are AJAX, RIA and Web services. Despite the huge benefits afforded by Web 2.0; they do not come without a cost. To enable increased user interaction, integration APIs and web applications need to be more complex and they need to support an ever-increasing set of clients. With these new technologies come new security issues, and ignoring them can lead to big disasters for the corporate world. In this document, the discussion was restricted to only some common attacks but there are several other attack vectors as well. With the invent of Web 2.0 we also focuses on the security aspects associated with different components of Web 2.0. to grow security awareness, secure coding practices and secure deployments which offer the best defense against these new attack vectors.

Source:Make Money without a job - Tony James

How to do Cookies Testing - Software Testing Stuff

Below is a list of major scenarios for cookies testing of a website. Multiple test cases can be generated from
these scenarios by performing various combinations.

  1. Check if the application is writing cookies properly or not.
  2. Test to make sure that no personal or sensitive data is stored in the cookie. If it is there in cookies, it should be in encrypted format.
  3. If the application under test is a public website, there should not be overuse of cookies. It may result in loss of website traffic if browser is prompting for cookies more often.
  4. Close all browsers, delete all previously written cookies and disable the cookies from your browser settings. Navigate or use that part of web site which use cookies. It should display appropriate messages like "For smooth functioning of this site please enable cookies on your browser."
  5. Set browser options to prompt whenever cookie is being stored / saved in your system. Navigate or use that part of web site which use cookies. It will prompt and ask if you want to accept or reject the cookie. Application under test should display an appropriate message if you reject the cookies. Also, check that if pages are getting crashed or data is getting corrupted.
  6. Close all browsers windows and manually delete all cookies. Navigate various web pages and check and see if these web pages show unexpected behavior.
  7. Edit few cookies manually in notepad or some other editor. Make modifications like alter the cookie content, name of the cookie, change expiry date etc. Now, test the site functionality. Corrupted cookies should not allow to read the data inside it.
  8. Cookies written by one web site should not be accessible by other website.
  9. If you are testing an online shopping portal, Check if reaching to your final order summary page deletes the cookie of previous page of shopping cart properly and no invalid action or purchase got executed from same logged in user.
  10. Check if the application under test is writing the cookies properly on different browsers as intended and site works properly using these cookies. This test can be done on browsers like different versions of internet explorer, Mozilla Firefox, Netscape, Opera etc.
  11. If the application under test is using cookies to maintain the logging state for users. Check if some id is being displayed in the address bar. Now, change the id & press enter. It should display an access denied message and and you should not be able to see other user's account.
Source: Software Testing Stuff


Setting up flex testing with selenium - Maria Marcano

Recently I was looking for tools to support automated testing for flex applications. I have a test suite in SeleniumRC and C# I was looking for options to continue using this environment. Here’s what I found:

Flash Selenium, Selenium Flex API

These two projects provides capabilities to interact with Flex UI components and web pages through selenium RC.
Selenium Flex API automatically exposes Flex APP UI and FlashSelenium  allowing us to call ActionScript methods to interact with Flex elements. Note that this approach requires us to compile our flex applications with Selenium Flex API library.
To start coding your test:
  • Rebuild your Flex application with sfapi.swc add the compiler argument:  -include-libraries "..\libs\sfapi.swc"
  • Include FlashSelenium.dll library in the seleniumRC test project.
To be able to run test on firefox you need to specify the browserString *firefoxproxy instead of *firefox since firefox doesn't like javascript calling flash when javascript comes from another window (the way selenium calls flash objects).
This a “hello world” example:

public class MyAppInFlexTest
    private ISelenium selenium;
    private FlashSelenium.FlashSelenium flashApp;

    public void SetupTest()
        selenium = new DefaultSelenium("localhost", 4444, @"*firefoxproxy", @"http://localhost/testapp.html");
        //selenium = new DefaultSelenium("localhost", 4444, @"*iexplore", @"http://localhost/testapp.html");
        //selenium = new DefaultSelenium("localhost", 4444, @"*googlechorme", @http://localhost/testapp.html);
        flashApp = new FlashSelenium.FlashSelenium(selenium, "MyAppInFlex");

    public void TeardownTest()

    public void TestMethodFlashSelenium()
        flashApp.Call("doFlexType", "usernameTextInput", "from selenium flex");
        flashApp.Call("doFlexClick", "secureCheckBox", "");

Source: Maria Marcano - Setting up flex testing with selenium


Skills for Automation - Software Testing tips

Last few months I was in interviewing candidates for Silktest and QTP. Many of them are good at tool related technical terms and concepts. But they are not comfortable to write few string handling functions. Main issue is many of the testers are not interested in hard-core programming. I strongly feel that programming skills is required apart from framework implementation. I used to give following tasks to any new comer for automation side.

Assignments for Automation
  1. Write a script to create a file,Read a file,Append a file and Delete it.
  2. To invoke browser and navigate through links,URL&button.
  3. To get Current Time like "24May2005-10hh-20mm-45ss"
  4. Find - Which window is active now in the taskbar.
  5. Prepare a script and the results should be stored into Excel sheet and Text file.
    Excel sheet should contain one line for each testcase and Text file should contain the information for all events.
  6. Automate simple Testcase without using GUI file. You should pass physical description directly.
  7. Retriving data from Database,Excel.
  8. Update data in Database,Excel.
  9. Access DLL functions.
  10. Implement function for following string problems
    Find and Replace in a given string.
    Get position of substring for given times.
    Get file name only from file's full path.
  11. Print list of files available in a directory.
  12. Create functions to create the log
    First log should contain all the details of the Script Actions.
    Second log file should contain only pass/fail detail of Testcases/Scenarios.
  13. Using any XML Parser, try to parse the XML contents based on given tag.

Source: Software Testing tips - Skills for Automation


Automation benefit measured by EMTE - Dorothy Graham

Being able to run tests that we would not have had time to run manually is one of the benefits of automated testing; we should be able to measure this benefit in some way.

What is EMTE?

EMTE stands for "Equivalent Manual Test Effort" and is a way of measuring the benefit of running automated tests.
If an automated test (A) would have taken 4 hours to run manually, then its EMTE is 4 hours; another test (B) that would have taken 7.5 hours to run manually has an EMTE of 7.5 hrs.
In a test cycle, if Test A is run five times, and Test B is run twice, then the EMTE for that cycle is 5*4 hrs + 2*7.5 hrs = 20 + 15 = 35 hours EMTE.

What is EMTE used for?

EMTE can be used as a way to measure a benefit of test automation (automated running of functional tests).
When tests are automated, they can be run in much less time than they could be run manually. Our tests A and B may be able to run in 5 and 10 minutes respectively, for example. So we can achieve "4 hours' worth" of manual testing in 5 minutes of automated testing. Whenever we run Test A, we can "clock up" 4 hours of EMTE.

Is EMTE a good thing?

Yes, because it is a way to show the benefit of automation.
Costs (of automation as well as other things) tend to become visible by themselves - managers see that people are spending time on the automation. But what is the benefit of this automation? If you don't make benefits visible to managers, there is a risk that they will not see the benefits, and may eventually conclude that there are no benefits. EMTE is one way to do make an automation benefit visible.

So how could it be a bad thing?

I have had discussions with a couple of people recently (thanks Julian and Wade) about abusing EMTE, and yes, it can be abused (as any metric can). Here is how it could be mis-used:
"Test A takes 5 minutes, so let's run it 12 times every hour for 2 hours. This gives 24*4 hours of EMTE = 96 hours. This will make us look really great!"

The problem is that after the first run, the other 23 runs are being done just for the sake of looking good, not for a valuable benefit in terms of running that test. This is an abuse of EMTE, and is a bad thing.

What to do about it?

Use EMTE (and other measures of the benefit of test automation) sensibly.
Perhaps only "count" EMTE once a day, however many times a test is run? (e.g. in continuous integration testing)

In what other ways can the benefit of automation be shown? (e.g. more coverage, freeing testers to find more bugs, number of times tests are run, more variety of data used?)
Have you encountered the abuse of this (or other automation) measures? How have you solved the problem?

Source: Dorothy Graham -Blog

Tour of being an independent test consultant - Tester Tested !

Hiya! Hope you are doing very well. I am Pradeep Soundararajan, your tour guide for the next few minutes. I am glad you chose to take this tour of being an independent test consultant.

Here are some questions you might have: How does it feel to be an independent test consultant? What is it like to be one such in India? Will I be able to survive? Will I make enough money to run my family? Will I make as much money as the organization I am employed is paying me? Will I get enough paid work? What if I don't get paid work for a long time? Will people want my kind of skills? How do I know someone needs a consultant? How do I get clients? How will my family take this? What do I explain to my spouse? What kind of a pressure does society add when I am not in any paid work for a while? How does it feel to work from home not just for a day but for an entire month, or maybe a year or more? Will I have enough money to pay my home loan EMI?

These are some common questions that have popped up from those who have wanted to take the tour. So, if you have these questions or maybe even more, you won't be disappointed with this tour.

Some people ask me, "Hey, can you give me a few clients of yours and help a fellow Indian to also be an independent consultant?" I want to help people be independent consultants in India. By that, of course, I mean, I'd like to see them do stuff that helps them get credibility, reputation, paid work and clients for themselves.

I'd like to take you through the journey of having been an independent consultant. A journey that is not so often written or spoken about

Tour Point 1: Knowing enough about enough

If you want to be an independent test consultant, there are some prerequisites that you need to fulfill. You need to be bold enough, skilled enough, curious enough, pleasing enough and willing to talk to people or do some work good enough to get good enough people to talk to you.

That's a magical formula right? No one knows what "enough" means and hence it is a problem and an opportunity in disguise. If you knew what "enough" meant, you are kinda through to anything you want to achieve. I think, not knowing how much is "enough" makes you to work hard and get close enough. Oops, close enough?

I have been able to survive so far. I have no clue if my current skills are enough for me to survive for the next year and I am on a constant upgrade of skills and knowledge. I invest money on learning and my investment for July 2010 is on a few books, Ethical Hacking Guide to Corporate Security by Ankit Fadia & Job Interviews - Walter Vierera. Time is a much more important investment than money for me. So, just by spending money on those books wouldn't mean much unless I make a further investment of time on it.

Tour point 2: Love for failures

Many projects today suffer because people working on it aren't willing to try new ideas. They are special people on earth who know things would fail even before trying them out. However, as a consultant, if you try to be like them, you'd be expensive for your clients. You would do what their employees are doing for a price much higher than the employee cost.

Its important to not fail at a client's location but should that stop me and you from loving failures? I have a lab where I can experiment ideas whose results I don't know yet and that lab is the world of my colleagues, community and my gurus.

It's OK to fail, once in a while, at a client's location because even if you do great stuff, there could be things beyond your control that might make it look very bad. However, if you can get that client to call you back for more paid work in future, it boosts your confidence a great deal.

It happened to me. I was black listed in an organization and now they not just white listed me but want to work with me closer. Their CEO is in direct touch with me. If I feared failing, I would have done more mediocre stuff than what they thought I actually did.

Tour point 3: Excellence instead of money

India is a great place for some inspiring movies. I strongly recommend that you watch the movie "3 idiots". No, don't Google and read the story, just watch it. There are several good messages in it and one of them is, "Excellence instead of money". This movie is a super duper hit in India. I just wish people not just like such movies but also bring in necessary changes to their lives.

I want to be rich but I want to be rich while I am excellent. I wouldn't mind money coming on my way but money wouldn't necessarily make me feel rich. I want to be rich in testing skills and knowledge. I want to be rich in knowing many testers and how they work. In the process, if money follows, I am super happy.

Tour point 4: Don't expect people around you to understand what you are trying to do

When an article about me appeared on a few national news papers, my article was published on a few magazines, I was interviewed by CNBC TV18, I was on news for a local TV channel, my parents were so proud of me that I can bet they were flying high. However, whenever they see me sitting in home for more than a week without any paid work, they start to ask me, "Why don't you join some company like Infosys?"

If you expect your parents or spouse to completely understand what independent test consulting means then you'd be inviting disappointment. I was expecting them to understand what I was trying to do but experience teaches that I shouldn't. This has nothing to do with the respect we have for them but a learning of what we can't help them understand.

While at home, I am glued to the computer, trying to learn something, practice testing or support my clients post my onsite engagement or reply to emails. Some people around me take it for granted that I am jobless. Someone calls me and say, "Hey, you are at home only na, so why don't you come pick our luggage and keep it there?" It irritates a lot. I am at home but not jobless. I am trying to generate a paid work, which is a part of my work. People don't understand that. So, be ready for all that.

Tour point 5: No promotions and no designation change

If you were used to being an employee for long and then chose to be a consultant, you must know that there is no one who is going to give you a promotion. It is what you call yourself that matters. I am calling myself a Consulting Tester or just an Independent Test Consultant. If I am bored of it in 2012, I may call myself a Senior Consulting Tester. I give myself fancy title sometimes. I was calling myself a Test Magician and then I am now calling myself a Brainual Tester.

Tour point 6: Being an independent consultant doesn't mean you are the expert

Without saying much, I am not an expert and I am an independent consultant. James Bach, Michael Bolton, Elizabeth Hendrickson, Jerry Weinberg, Scott Barber, Matt Heusser, Jonathan Kohl, Karen Johnson are experts who are independent consultants. People like Ben Simo, Jon Bach, Cem Kaner, Vipul Kocher, Ashok are experts who are employees. There are some good thinkers and future experts like Meeta Prakash, Parimala, Lanette Creamer, Ajay, Santhosh Tuppad, Sajjadul Hakim, Ramit Manohar, Sharath Byregowda, Shmuel Gershon, Issi Hassan, Markus Gartner, who are employees, too.

So, independent consultants don't necessarily mean an expert. Employee don't necessarily mean a non expert. If I had to be an independent consultant only after becoming an expert, I wouldn't have been one till now. If I don't be an independent consultant, I don't know if I would ever get close enough to an expert while being an employee.

So, if you are waiting to be an expert and then be an independent consultant because you thought there was a strong relationship between them, you could be wrong.

Tour point 7: Tackling loneliness

Even in 2nd most populous country in the world, there are a lot of people I have seen who feel lonely. So, loneliness is not about people not being around you but about people whom you want to be around you not being around you. For me, my first wife is my laptop, just like many others I guess. So, despite having two wives (laptop and the one to whom I am married), I get lots of situations where I feel lonely. Loneliness is not always a problem; its a blessing in disguise. Ask our fellow bloggers, they'd tell you that they churned out a cool post during such situations.

However, being an independent consultant and working from home means, I have no colleagues that I meet on a daily basis. I meet a lot of new people every year but meet the same people very few times. Having no colleagues to meet on a daily basis means frustration at times.

When I go through Facebook or Orkut and see some people posting photos of their team member's birthday party celebrations, team outing to a hill station, team lunch, going to movie as a team... it hurts me a lot. I just take it as though I am in a penance of becoming a good tester and I have to bear with all of it. Recently, I was pissed off when I found no one to join me for a movie that I wanted to go. Even if I did find, their timing and my timing was off. Hey, employees are pissed off too. So, I am still fine.

To enjoy the tour continue to read on from here:

 Source: Tester Tested - Pradeep Soundararajan's Software Testing Zen


QTP Frameworks - LearnQTP

I have worked on innumerable frameworks from the basic keyword driven to complex hybrid frameworks. Lots of my friends who had either never worked on a framework or had just begun their carrer in testing/QTP would ask how do I start my own framework. This is one of the best videos you can find that explains basics of both a Keyword Driven and a Data Driven framework. Hope to have some more updates from Ankur soon:
Keyword Driven Framework - Learn QTP

Data Driven Framework - Learn QTP

Database Testing Tips

Some cool database testing tips by db testers..
Happy Reading!

P.S: Right click and save the image to be able to read the content clearly.


Software Performance Testing Handbook - Learn To Win

Here is an excellent book for anyone who wants to learn "Performace Testing"

Download the book here!

Happy Reading!

Source: Learn To Win - Ramya Moorthy

Undocumented Secrets of QTP

This time something I explored on QTP, some of the undocumented features of QTP :
I am sure if you use QTP you will love this collection:

Best of Testing tips from twitter

Tips from twitter @  Dailytestingtip

Rethinking user interface test automation - Gojko Adzic

Geoff Bache presented on “Making GUI testing productive and Agile” today at Agile Testing Days 2010. Bache started by saying that there is an assumption in the community at the moment that GUI testing is hard to pull off correctly, much harder than data-driven testing, and that many teams have given up on that approach. But instead of bypassing the user interface, he advised teams to re-think the entire user interface testing approach and make it productive.
Record/playback implementations are tightly coupled with user interface layouts which makes them brittle and hard to maintain. That is the reason why teams gave up on user interface tests. According to Bache, the problems with data-driven approach (how he called API-level testing with tools such as FitNesse, Concordion or Cucumber) are that it doesn’t give non-programmers confidence in the whole system working and it deals with abstractions, and abstract tests require writers who can think in abstractions.

To get the confidence in the system and also easy maintenance, Bache advised combining domain-language descriptions of use cases with recorded user interface actions. The pyUseCase recorder tool he built allows teams to record actions and assign domain names to such recorded actions, which can later be combined into scripts. This provides a level of abstraction to make the test system more reusable and easier to maintain, but also makes recorded test cases easier to understand. There are similar tools for Java and .NET. (Bache said that Java Use Case recorder is no longer maintained, though).

Bache also advised teams to re-think the traditional approach of assertions as a way to validate actions in scripts. “Assertions mean variables, and variables mean programming. This breaks nice domain language use cases and starts mixing them with programming concepts” said Bache. This reduces readability. Instead of that, he advised verification by logging – inspecting textual log outputs of the system to validate that a function was performed correctly. “Tests are much more about behaviour change management than assertions”, said Bache, “It’s more about here is what my test does today, and I can manage a change of that tomorrow”. He uses TextTest to compare textual outputs of the system.

This approach allows teams to record domain activities, combine them into readable scripts and, save detect behaviour changes by comparing log outputs. Teams can focus on behaviour changes and domain language use cases. “Often the devil is in the detail and you want to manage changes in detail when your system behaviour changes”, said Bache. Instead of defining assertions, teams can inspect changes and decide whether the changes were expected or unexpected.

As additional advantages of this approach, Bache said it allows teams to create new tests required little or no programming. Resulting tests are robust and readable and cheap to maintain when user interface layout changes.

From my experience, aligning tests with the business domain model (which Bache called “thinking in abstractions”) works well for user interface tests as well and it allows teams to avoid the sine of death of UI test automation. More importantly, it allows teams to drive their business model using tests. But this is not at odds with the Use Case recording model. I see how Use Case Recorders can be very useful when recorded user interface testing is the only thing you can do, such as in implementing functional test automation on legacy system, especially when the state of the system depends on a large number of factors.

Source: Rethinking user interface test automation - Gojko Adzic