Archive for April, 2010

Top QA blogs listed

Testingminded listed the top 100 QA blogs here.  There are a ton of good blogs out there and it is great to see some centralized lists.

Here are the top 5:



Make sure to  check out his page to see the rest!

Lay Siege to your Servers

I had never used an open source load testing tool before I started working at my current company. But we are all about open source tools here, and have some great ones floating around. Siege was recommended by our Sys Admin Lead, who said he had not been able to find any other open source tools as powerful or easy to use as siege. With such a good recommendation, I set in to learn the program.

Siege is a load testing and benchmarking tool for web developers. It offers flexible options for customizing your script and then lays “siege” to your servers, testing their load capacity. It is incredibly handy, decently easy to use, and runs great on Linux  or OSX.

You can configure siege to test any number of concurrent users for a set amount of time.  Your tests can run against a single url, or to call a txt file containing a list of urls, so you can thoroughly test even complex webpages. You can download add ons like SPROXY from the same site that allows you to collect url data.

My favorite customizations are: -i (internet) to simulate internet users and -b (benchmark) which give s no delay for time testing. You can set a single test to repeat over again (-r) or print notifications to the screen (-v). You can even adjust the time delay (-d) to simulate actual human activity on the web page.

EX: here is a simple command, testing a single url.
 siege -c10 -t1 -i http://www.joedog.org/index/siege-home


Your script runs in the background (I run it on a different server, both for speed/accuracy and to keep my machine free) and when it finishes, it gives you your results and an overview of the test. Availability is the main thing to look at. It should always be at 100%, anything less means that users will have trouble accessing your site. Concurrency tells us the average number of simultaneous connections. Transaction rate is how fast each transaction was processed. These factors can all give you a good idea of what your website can handle.

Lifting the server siege...      done.
 Transactions:                 319 hits
 Availability:              100.00 %
 Elapsed time:               59.45 secs
 Data transferred:            0.75 MB
 Response time:                1.42 secs
 Transaction rate:            5.37 trans/sec
 Throughput:                0.01 MB/sec
 Concurrency:                7.63
 Successful transactions:         319
 Failed transactions:               0
 Longest transaction:           20.55
 Shortest transaction:            0.26


It is defiantly worth trying out to see if it fits your project, it has been a great addition to my QA toolbox.

Find a complete users manual and a download of the program on their main page: Joe Dog Software

Developers: A Ray of Sunshine

Developers may be the most blatantly, unashamedly  optimistic group of people I have ever known. In the face of all evidence to the contrary, they believe that this time, software will work, deadlines will be met, solutions will be easy and testing will find no bugs.  It doesn’t matter how quickly something was put together or how shaky the requirements, or how new the system – developers feel completely confident that things will be fine. This never ceases to amaze me. I hate being the rain cloud on their bright day, but at the same time, I do enjoy injecting a little realism.

Code freeze just two days before launch? No problem.

Late requirements? We can squeeze them in!

last minute fixes? It shouldn’t be too hard/ (and my favorite) This will just take a minute.

They deploy their hard work off to staging, crack open a beer, and sit in the sun while testing begins. Even before you start that first test, you know it is too early for that beer. You remember last release, and the one before that. You remember that “quick bug fix” that took two days of testing and reworking to straighten out. You know this time is not different. You know they have deployed code that is broken, and that in a matter of time and tests, you will find the first broken spot- and then the next. You know that no matter how long or how hard you work, when testing is over and the project goes live, there will still be more bugs uncovered days, weeks or months later. You can only hope that if you work really hard, you will catch all the big issues. But that is your job- to remember all the ways things have broken before.

Developers spend their days creating new systems and solving problems. They get instant gratification when they do little fixes and get their unit tests to pass. They thought up their own solution, and so are somewhat blinded to potential issues  by their very involvement. Software testers spend their days slogging through broken programs, early releases, and failed bug fixes. Once something is fixed, we stop using it. We read countless bug reports and user issues and spend our days writing test cases trying to find broken spots. We aren’t involved in that creative burst of fixing something or designing something. Our creativity comes from all the ways we find to break it.

So when you file that first bug of the testing cycle, remember… their optimism will come in handy when it is time to fix all the issues you find. Besides, we are optimistic in our own way. We fully believe that their are bugs out there to find, and each day, we are proved blissfully right. Each issue we file a little victory, because that is one less issue for there to be in production, which helps the developers, QA and project managers to feel more optimistic about the release as a whole.

QA toolbox- Firefox plug ins

Browser plug ins are invaluable tools for QA departments dealing with web software. Here are some very popular ones (and my favorites)…

Web Developer

I love this amazing, free testing tool. The Web Developer toolbar makes validations a breeze. You can perform CSS, HTML and link validations right from your menu bar.

HTMLL Validation with Web Developer

CSS Validation with Web Developer

It allows you to outline different page elements and display their title- which is really helpful when creating Selenium test scripts. You can also view your page without cookies or at a different resolution. This is one of the most helpful tools out there and I won’t sign off on a release with out it.

Firebug

I use this mostly to track cookies, but it also offers debugging, element inspection, and error  tracking for Javascript and xml.

Firebug error tracking

Yslow

Yslow is awesome. It works within the firebug window. Click over to the Yslow tab, open up the menu, and it grades the page you are on for performance. It even offers suggestions on how to make it faster.

Yslow- performance grades