Custom automated test tools that can be adapted and/or built out and deployed around the needs of the environment, equipment, tools and development style of just about any team that finds itself in need of additional automated test support.

Hard Water

Why have Firmys create custom solutions with Hard Water?

  • Hard Water finds the cracks.
  • It fixes the leaks in your project.
  • It smooths out your process.

Easy to implement, dynamic, custom automation tools that conform to your process.

 

  • Fits into your teams processes
  • Put it anywhere in your pipeline
  • Use it in an embedded environment
  • Use the same tools for testing, deployment and monitoring
  • Highly and easily extensible
  • Version awareness
  • Project/product agnosticism
  • Flat structure for functionality (any existing methods can be called from anywhere within the project-side repository)
  • Headless GUI manipulation in container, using Selenium, Docker and Hard Water's API.
  • Structure with correlation to test cases, allowing for direct verification documentation generation.
  • Hooks for use with many front-ends and dashboards, including CLI, Jenkins, VersionOne and HP ALM.
  • Can be embedded and used as a heavy-duty diagnostic and/or remote configuration tool.

Hard Water Automation framework is there with you from the first design meeting, regardless of your design and development process. It can be customized for many different types of teams. It helps to structure good processes and automation around what works for you.

An example of Functional Testing using the Hard Water framework.

Story: Users have secure access to project web site
Feature: Project <home page> is securely accessible via <splash page>

Test Case: User accesses <home page> via <splash page> using <valid credentials>
Step 1: User navigates to <splash page> url
Step 2: User enters <valid credentials> in <authentication form> on <splash page>
Step 3: User clicks submit on <authentication form>

Here is what the code looks like for the automated test case.

def test_case_user_accesses_homepage_via_splashpage(self):
feature("Project <home page> is securely accessible via <splash page>")
test_case("User accesses <home page> via <splash page> using <valid credentials>")
step("User navigates to <splash page> url", self.splashpage.navigate_to)
step("User enters <valid credentials> in <authentication form> on <splash page>",self.stepsauthentication.enter_splashpage_credentials)
step("User clicks submit on <authentication form>", self.browser.click, self.splashpage.submit)

Notice how it reads just as the verification text reads. In fact, because of how Hard Water handles class instancing and aliasing, it is not necessary to change test cases/scenarios once they have been created, thus creating a much more stable automated test repository.

Versioning is handled dynamically, and the framework will handle grabbing the correct logic based on the version information you have given it.

Documentation.

Not only does the test case in code match verification, but documentation matches the verification structure as well, and tracks important data to the project and tests dynamically, allowing for audit-ready documentation straight from the test automation output. Any information and verification you need can be tracked and reported easily and automatically.

The above code creates the following output in console. (note that variable text will be replaced by test instance information)

.......................................
FEATURE: Project <home page> is securely accessible via <splash page>
TEST CASE: User accesses <home page> via <splash page> using <valid credentials>
.......................................
19:54:51 - PASS: STEP 001: User navigates to <splash page> url
19:54:51 - PASS: STEP 002: User enters <valid credentials> in <authentication form> on <splash page>
19:54:51 - PASS: STEP 003:User clicks submit on <authentication form>
.......................................

Trust is a big deal in automation.
On failure, detailed information on the failure will be provided, both regarding the type of failure, and whether it is an automation failure, or a genuine issue with the project.

Hard Water also creates jUnit XML reports, for use with Jenkins and other front-ends and dashboards.

In addition, it will fit in just about any point in a project pipeline.

Hard Water is containerized and can be embedded, not just for testing, but for many types of tasks. It uses its own API and can be instanced in order to fill many functional gaps that other tools haven't touched, or areas where other tools would have trouble abstracting and integrating.