One of our Developers put together a nice Maven Integration document that will go out with our website refresh later this month.  Given the popularity of Maven, I thought I would share it before the site-refresh goes live! Read more..

There is a great article by 37signals called “Have an Enemy”.  By knowing your “enemy”, you know what you don’t want to be.  This is pretty much how LiquidTest was conceived. We knew there were problems in the Test Automation space and we knew there were a lot of questionable practices by some of the established players in the space. The following is a list of principles LiquidTest was founded upon: Read more..

LiquidTest is available as a plug-in for the two most popular Integrated Development Environments (IDE), Eclipse and Visual Studio.  This discussion (also available as a PDF here..) will focus on the Eclipse version and will provide Eclipse-specific tips for LiquidTest users. Read more..

LiquidTest has many varied features and functions. In this blog post I will explain a small but important feature with an example. This feature is a small check box you see at the bottom of your browser when recording a test with LiquidTest, called Dynamic Element. Read more..

This post follows on from part 1 where we walked through the Ubuntu, Subversion and LiquidTest (Eclipse) setup. Assuming that your project is now in your subversion repository we walk through the Continuous Integration setup with the popular (and Open Source) Hudson CI server. Read more..

One of the most powerful features of LiquidTest is its “out of the box” integration potential. Because LiquidTest utilizes industry standard languages (such as Java) and Unit testing frameworks (such as JUnit) the integration possibilities are not limited by vendor-specific frameworks. The purpose of this tutorial is to give those not familiar with Continuous Integration servers a quick “heads up” on the potential and usefulness in automating the running LiquidTest Test Cases on headless servers. Read more..

Websites and web-applications have become technically complex, leading to a need for advanced automated test scripts that can validate their functionality. These scripts typically “walk through” a specific process and check to make sure certain actions and objects operate as expected. As the user provides different input into these web-applications, they change their behavior or present different datasets, prompts, or error messages, so it is not enough to simply run scripts with one set of values. Instead, the script needs to be able to run many different iterations of the same test, each with a different set of values. The ability to take actions (like entering text, choosing a radio-button, clicking a link, or validating returned content) dynamically is called parameterization, and a test that does this is often referred to as a “parameterized” or “data-driven” test. Read more..

Manual testing is typically how most companies begin their journey into the jungle of software testing. Only companies where the founders are experienced test automation people would start automated testing from day one, and even then it is highly unlikely. So how does a company know when it is time to make the jump to automated testing? Read more..

Recently I was reading an article that divided software development/testing people into four camps; Developers, Developer-Testers, Tester-Developers, and Testers. We are all familiar with two of these categories, Developers and Testers. In the traditional sense, Developers develop the code and pass it along to Testers who test it. So, what about the other two categories? Read more..

One of the critical failings of automated web application testing comes when existing (previously recorded) test cases break due to changes with web infrastructures and back-end changes. Organizations invest significant time and money in building test infrastructures and recording automated tests, to find that far too often tests break when changes are made to minor content or page structure. Read more..