Performance testing tool

This is in fact most crucial test for time critical applications such as stock management systems which gets refreshed every minute creating huge load on web site as there are thousands of users accessing the web site at the same moment.

For such applications stress testing with more than 10,000 users is a basic test. The WAPT Pro comes with default “Load Agents” functionality to test average load on any web site. But for high capacity test with more than 10,000 users we can now leverage the power of x64 Load Engine extension.

x64 Load Engine is similar to Load Agents feature on WAPT Pro installation. The main difference is in the ability of load engine to generate huge load using 64 bit Windows systems. Using one 64 bit server you can dramatically increase the load testing capacity on web site under test. The x64 Load Engine can be configured in such a way that using slightly high end hardware you can easily generate more than 100k virtual users load on web site.

Assume that you want to stress test your web site with 100,000 concurrent virtual users. You can achieve this using 4 servers each with 25,000 virtual users. Setup this load engine on 4 systems and use them concurrently to achieve desired web site load. This powerful x64 Load Engine effectively utilizes the available memory resources on 64 bit system architecture.

WAPT Pro x64 Load Engine Installation:
- You can install x64 Load Engine on 64 bit version of Windows XP/2003/Vista/2008/Win7 OS.
- x64 Load engine works best on following hardware configuration:
Core i5/Phenom or CPU better than this, 8+ GB RAM and Gigabit Ethernet

How to install:    
x64 Load Engine is a WAPT Pro extension so it runs on WAPT Pro tool similar to Load Agents. To use this load engine you must have WAPT Pro installed first. You can download and install x64 Load Engine from below mentioned link. After installation you can start using load engine using the WAPT pro workplace itself.
Download WAPT Pro x64 Engine .

x64 Load Engine Pros:
- You can generate almost unlimited virtual users (test load) on Windows 64 system.
- Easy to install, learn and configure
Check out below screenshot to know the simplicity of x64 Load Engine Manager:

This is in fact most crucial test for time critical applications such as stock management systems which gets refreshed every minute creating huge load on web site as there are thousands of users accessing the web site at the same moment.

For such applications stress testing with more than 10,000 users is a basic test. The WAPT Pro comes with default “Load Agents” functionality to test average load on any web site. But for high capacity test with more than 10,000 users we can now leverage the power of x64 Load Engine extension.

x64 Load Engine is similar to Load Agents feature on WAPT Pro installation. The main difference is in the ability of load engine to generate huge load using 64 bit Windows systems. Using one 64 bit server you can dramatically increase the load testing capacity on web site under test. The x64 Load Engine can be configured in such a way that using slightly high end hardware you can easily generate more than 100k virtual users load on web site.

Assume that you want to stress test your web site with 100,000 concurrent virtual users. You can achieve this using 4 servers each with 25,000 virtual users. Setup this load engine on 4 systems and use them concurrently to achieve desired web site load. This powerful x64 Load Engine effectively utilizes the available memory resources on 64 bit system architecture.

WAPT Pro x64 Load Engine Installation:
- You can install x64 Load Engine on 64 bit version of Windows XP/2003/Vista/2008/Win7 OS.
- x64 Load engine works best on following hardware configuration:
Core i5/Phenom or CPU better than this, 8+ GB RAM and Gigabit Ethernet

How to install:    
x64 Load Engine is a WAPT Pro extension so it runs on WAPT Pro tool similar to Load Agents. To use this load engine you must have WAPT Pro installed first. You can download and install x64 Load Engine from below mentioned link. After installation you can start using load engine using the WAPT pro workplace itself.
Download WAPT Pro x64 Engine.

x64 Load Engine Pros:
- You can generate almost unlimited virtual users (test load) on Windows 64 system.
- Easy to install, learn and configure
Check out below screenshot to know the simplicity of x64 Load Engine Manager:

- No restrictions on the size of used virtual memory

x64 Load Engine Cons:
- No evaluation period available
- Works with WAPT Pro only

As said earlier in my comment, this tool is very useful for performance, stress & load testers. Other testers can get a glimpse of the performance testing scope which is very interesting to work on!

- No restrictions on the size of used virtual memory

x64 Load Engine Cons:
- No evaluation period available
- Works with WAPT Pro only

As said earlier in my comment, this tool is very useful for performance, stress & load testers. Other testers can get a glimpse of the performance testing scope which is very interesting to work on!

Read more »

Story of how a hang becomes a crash (because testers love reporting crashes)

I am doing my first exploratory testing workshop for 2011 and first from Moolya Software Testing Pvt Ltd. and I am excited about it. You can find the details by clicking on this link . If you are in India and plan to attend it, please do it quickly. I usually don't take a lot of participants although I know I'd gain more money out of more participants. Ever since I announced it yesterday, there are 4 seats that got filled within 5 hours.


Now, I am going to tell you a story that I had been hiding for quite a while. Not intentionally hiding but was planning to blog about it and the time is right now :)


I provide many applications to test in my workshop. At the end of a testing session, I check with the participants if they found any crashes with the application. Not to be surprised, a room full of testers, they do report crashes.


I ask them to reproduce it with me watching what they do and here is a shocking information; most of what they report as crash weren't crashes at all. What you are about to read is also a great example of confirmation bias that I have witnessed.


Here is what they are doing: They are performing an input constraint attack or providing a large set of characters as an input to a field and hits the "Submit" button. They wait for 10 seconds to see what the application does and on seeing the application in not responding state, kill the application and report that as a crash. 


Awesome! Isn't it?


Now, I got conscious of the fact that testers seem to be reporting a hang as a crash and was keen in looking at live projects during my consulting assignments. I get access to the bug tracking system during my consulting (wow) and I see patterns of such reports. 


I go filter out some of the crash reports from the bug tracking system and try to attempt what the tester did to report that type of a crash and bang, that's a hang.


I have made this point to testers who attend my workshop in order to help them be more conscious of what they are seeing versus what they are reporting versus what they are eager to report versus what they should be reporting. 


It seems to me that testers have an anxiety to report crashes. There's nothing wrong in it but it goes horribly wrong when you report a crash by fooling yourselves and the people around you. I recently blogged about the Obsessive Checking if being mentioned disorder that I was suffering from and here is a relevant excerpt from it, "Months later, I started replacing every word by my name till I saw my name on others post. So, I may have read a few posts without actually learning anything from it because all I saw is "Pradeep" & "Tester Tested" on those posts."


Now, why is that relevant to this post? I see that the testers I have witnessed who report hangs as crashes also appear to have a similar problem of obsession towards reporting crashes that they appear to not see a hang but see a crash. I would love if you ask if these testers ever report a hang? Yes, they do. If an application recovers before they kill, that's a hang.


I understand that an application might have hanged because it has crashed but how do you know? Oh yeah, allowing the GUI to fool you and me?


Here is an excerpt ( and tweaked to hide confidential information ) from an issue that I reported on Sep 30, 2010 @ 12: 13 PM IST (thank you Jira) while testing a new OS that is soon to be launched. No, not Chrome OS.


"I opened Media Player application and made an attempt to subscribe to a podcast. 
The application appeared to hang and it also did not allow me to close using the X mark on top right corner.


In an attempt to kill it, I navigated to XXXXX (product name masked) and tried closing it from there. However, the XXXX is open and Media player still seems to be remaining in the hung state.


From that point, I might be forced to reboot the system to get out of it or can escape by waiting for a longer time that I waited for Media Player to recover (>5 mins). No user to my knowledge would wait for more than 5 mins to see the Media Player function. Even a reboot appears to be a faster option" 

Now, if that was the Description, here is the summary :

"Unable to kill a XXXX when the application in it appears to hang or is busy"

• Why I posted the above? Is it because I wanted people to note the usage of the word "appears"?
• Why did I make a few words in it bold? Is it to highlight it?

Long ago, well, not so long ago, I blogged about how teaching testing is helping me test better. The above post and the bug report I posted, is another example of how teaching testers has helped me do it a lil better.


Now if you are going to be sitting at my workshop and be worried if you are going to make mistakes that I am going to highlight, please be informed that you are paying to my workshop to get into the safest environment to fail. No managers watching you. No clients frowning at you. No appraisals being done. Just your own dream of personal excellence aching you for not being there yet but being happy that you know why you are not there. Its a wonderful feeling.

Read more »

Technology that failed in India ( Testing Bowl of the world )

Once while at work I was getting my test cases reviewed about a project/domain which I was new to and one of my colleague gave a strong comment "Pradeep , please think of more cases".

I was a bit dissapointed because already there were enough test cases that it will take 3 days to complete a cycle and I thought "should I further shoot at my own legs ?" ( the more cases I write , more I have to test , its painful , isnt it ? ) .

I tried to defend that testing would become complex if more cases are there than beyond the objective of the release/product requirements.

Ha ! thanks to what I told , he tshared with me a great story which happened in his previous company and it is one of the best lessons I have had as a tester !

__ This (could be a) is True Story that happened in some company ___

A digital camera was released in the market and after sometime a customer came back complaining that .......


Problem :The camera's software was crashing continously while he tried to capture images.

FIR : They first asked some basic information from the customer and made an attempt to reproduce the issue but it was not reproducible.

Analysis :

1) Software is crashing - so they listed out all possible scenarios where the software could crash.
2) Tried putting the camera to all listed possibilities.
3) Giving a report to the management that it was unable to be reproduced.

Further Analysis :

Taking this as a challenge , a great tester had the following concern -

1) He was concerened what festival was it ?
2) He was concerned what was the customer was trying to capture ?
3) He was concerned what is the frequency of the crash the customer noticed ?
4) He was concerened about all other surrounding factors like temperuature , place where the festival was celebrated ... etc ?

Outcome of Analysis :

1) The festival was Diwali or Deepavali !
2) The customer was trying to capture fire crackers , explosion , fireworks display in an open ground at around 22 00 hours ( night ).

What a fantastic tester was he !

He identified the problem and told the developers

"The camera software is crashing when the viewfinder is black ( because of dark night ) and a sudden gush of light through the firecracker explosion is putting the DSP ( digital signal processor ) to a load/stress beyond its boundaries to display the image. And at this point of time when the user tries to capture it simply crashes"


What he said ?

was right !

Finally they fixed it and now today its a robust digital camera !

____ End of a probable true story _____

Summary of lessons -

1) Collect real time data for testing a product/application.
2) When you are unable to reproduce an issue , think out of the box , think out of the black box.
3) When you are unable to reproduce an issue call someone who can dig deeper than you.
4) Dont assign test case draft to the person who is going to test it, he may omit complicated cases to bring down his/her complexity in executing it.
5) Review the cases with a non team member/customers/domain specailist/tester network.
6) When you release a product : aniticpate and be prepared to face such situation.
7) Hate the product while testing and love the product after its release - emotional testing ( ha new concept introduced by me , i do it , to be frank )
8) Good Testers not only report bugs , they suggest a solution ! ( more to come abt this )
9) Keep learning to be a good tester !
10) Test all your products in India , its Testing Bowl of the world !
11) Dont terminate an issue just because you are unable to reproduce , it could kill your company !

Read more »