Generic controls are those controls that an automated testing tool doesn’t natively recognize. They may show up with actions like LMouseClick or MouseMove on them along with the coordinates that the mouse action occurred at. These aren’t very useful when testing, as their available actions are limited and you might have to go through some extra work if you want to checkpoint data on them. QA Wizard Pro 2010 introduced a feature to change all of that.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon
When developing a web application, several versions of the application may exist on different servers for testing purposes before the application is published to the live site. A developer may use a web server on their own machine to test a site while they are developing it. Alpha or beta versions of the web application may be put on a staging server so the QA group can test it. Finally, the application will be published to a live site. In QA Wizard Pro, it’s easy to use a single script to run an automated test against the web application in each configuration.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponKeyword-driven testing is a testing methodology that allows you to separate the actions that you want to perform from the automated script that executes the given actions. The actions can be entered into a table, such as an Excel spreadsheet, and then run by an automated script. Since the QA Wizard Pro scripting language mirrors these keywords in its own implementation, keyword-driven testing with QA Wizard Pro is easy.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponThere are many tests required in order to release a piece of software. Among the lists of tests that must be run, many of the tests are repeated for each release of the software and possibly repeated even more frequently. Each of those tests has a cost associated with it. Either it costs you time to run the test, or it costs you quality to skip it.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponPerhaps you have looked at how you manually test your application and sorted through all of your tests to select some good candidates for automation. You’ve selected an automated testing tool and have started converting some of your manual tests to scripts. But is the extent of automated testing just to change manual tests into automated ones? Now that you’ve embraced automated testing, what can you do now that you couldn’t do before?
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponOne decision you may find yourself having to make when beginning automated testing is selecting which of your tests to automate. Automating all of your tests may sound appealing at first, but is both difficult and impractical. Some tests are better suited for manual testing while some make excellent candidates for automated testing.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponA smoke test (in software) is a quick test done after a build has completed successfully, but before QA fully tests it.
Microsoft claims that after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software.
Because the sooner we find a defect, the cheaper it is to fix it, we use a continuous build process utilizing QA Wizard Pro to automatically perform a smoke test each time a build finishes. This lets developers know right away if something that they checked in recently caused a problem.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponAutomating UI tests has the down side of needing to be able to control the mouse and the keyboard as well as needing to be able to see the application running on the screen. This can cause trouble if you need to use the computer for other things or want to keep the workstation secure while the tests are running. Luckily, there are tools available to allow you to automate in a virtual environment and still be able to use or lock the hosting computer.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponAutomating UI tests has the down side of needing to be able to control the mouse and the keyboard as well as needing to be able to see the application running on the screen. This can cause trouble if you need to use the computer for other things or want to keep the workstation secure while the tests are running. Luckily, there are tools available to allow you to automate in a virtual environment and still be able to use or lock the hosting computer.
To setup an example virtual environment, I installed Microsoft Virtual PC. It’s available from Microsoft as a free download, all you need is a way to install an operating system that you want to use to test on it. The operating system doesn’t even need to be the same as your host computer. In my tests, I used Windows Vista to run a Virtual PC with Windows XP SP2.
I installed the virtual machine additions by using the “Install or Update Virtual Machine Additions” item in the “Actions” menu. This allows you to resize the virtual PC in the same manner as you resize other windows on your desktop. It also allows the mouse to cross into and out of the virtual PC window seamlessly. This mouse feature will cause the automation problems however, as we need to allow the virtual PC to completely control the mouse if we want it to test the UI. We can turn off the mouse capture by going to “Settings” in the “Edit” menu. From the dialog, select “Mouse” and uncheck the box labeled “Use pointer integration”. Note that this can only be done while the virtual machine is running.
Within the virtual machine, I would also recommend turning off any screen savers and setting the power options to “Always On” so that you can be certain that your automated tests will be able to run uninterrupted.
Now that the virtual machine is setup, you can start your automated UI tests within the environment. After the test has started, pressing the right-hand Alt key will release the mouse from being locked in the virtual machine and allow you to continue to use the host PC as normal. This includes locking the host machine, or even running another copy of the virtual machine to run multiple tests at the same time.
I review a lot of UI design lately, and this is the thought that most often comes to mind:
“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”
~Antoine de Saint-Exupery
