Skip to content
All projects

Sageworks · Case study

Selenium Test Automation

Turning manual test cases for Sageworks’ banking software into automated Java and Selenium tests, plus helpers that made the next test easier to write.

Illustration of a stack of test cards wired to a robotic arm pressing a button on a browser window, beside a column of green check marks.
Illustration1 / 5
Illustration. The other images are screenshots of real public pages.
Role
Software Quality Assurance Intern: test automation in Java and Selenium.
Company
Sageworks

Overview

William’s first job: two summers and a spring semester in QA at Sageworks, the Raleigh company behind lending and credit-risk software for banks and credit unions, now part of Abrigo. He converted manual test cases into Selenium WebDriver tests written in Java, repaired tests that had broken, and wrote shared libraries so other people’s automation took less effort.

Problem

Manual test cases need a person clicking through the same screens before every release. Automated UI tests remove that repetition, but only if they are reliable and cheap to write; otherwise they break and get ignored.

Architecture

Selenium Test Automation system designJava test suiteUnder testManual test casesWritten stepsAutomated testsJavaShared helpersReusable librarySeleniumWebDriver APIQA teamReviews failuresTest resultsPass · failSageworks web appUnder testBrowserReal clicks, typingautomatecallcommandsdriveloadreportfailuresnew cases
RequestAsync eventData read / writeMoving dots show which way data flows.
  1. Manual test cases → Automated tests: async event, automate
  2. Automated tests → Shared helpers: request, call
  3. Shared helpers → Selenium: request, commands
  4. Selenium → Browser: request, drive
  5. Browser ↔ Sageworks web app: request, load
  6. Automated tests → Test results: data read / write, report
  7. Test results → QA team: async event, failures
  8. QA team → Manual test cases: async event, new cases

What made it hard

  • Translating written manual steps into repeatable automated tests.
  • Fixing tests that broke when the application changed.
  • Pages that load at their own pace.
  • The same setup and locator code copied into every test.

Solution

Each manual case became a Java test that drives a real browser through Selenium WebDriver. Common steps moved into a shared helper library, so a UI change is fixed in one place and a new test is mostly calls to existing helpers. Results show which cases pass and which need a closer look.

Skills used

  • Java
  • Selenium
  • WebDriver
  • Automated testing

Impact

  • Turned manual test cases into automated tests that run without anyone clicking through.
  • Brought broken tests back to passing.
  • Left shared libraries that made the next person’s automation easier.

Decisions

  1. 01Keep page details in shared helpers, not in every test.
  2. 02Wait for conditions instead of sleeping for a fixed time.
  3. 03Fix a test that fails for the wrong reason before writing the next one.