We recently had the opportunity to work with a client on a very short engagement. Here is what our dedicated expert accomplished in the first 13 days.
- Fixed build
- First defects detected with automation
- Reviewed existing automated test suites
- Enabled running UI tests on any browser
- Created a source of truth for automation
- Began testing continuously
- Outlined milestones for continued success with automation
The client’s test automation code base was stale. The build hadn’t been run properly, with one button-press in a long time (if ever). We identified issues within the build on day one (Maven, Nexus Sonatype, & Java) and fixed them quickly. Our dedicated expert ramped up on the code base in a couple days. He was running tests in the first week. His ramp-up’s impact on the rest of the team was nominal.
In less than 13 days the team had working build profiles in the pom files that would build the automation code base and run the tests from any system.
First Defects Detected
Detecting the first issue with automation is always a milestone for us with clients.
This client had existing test cases in Selenium Webdriver. The status and reliability of many tests were unknown. Beaufort Fairmont’s dedicated expert worked through many of these tests and realized that some of them were actually pointing out legitimate defects. These were logged and development was able to run the tests to expose the issue and debug through it saving time and money.
Reviewed Existing Test Suites
Test cases must be continuously reviewed in order for the team to rely on them to detect change. The client asked us to review their tests. We had them running in days and were able to comment on a significant portion of those tests’ soundness and reliability in less than 13 days.
Running Against Any Browser
This client’s automation framework had lacked attention for a while. One key element for the client was being able to run any browser for the tests. Our dedicated expert found the bug buried deep in the framework that was forcing all tests to be run with the chrome driver. Others on the team had tried to find the issue, but couldn’t. This is where extensive experience with different automation code bases and many different tools comes in handy. We found the issue in a one-hour pair-programming session.
Because we were able to fix the build earlier, now the client can run any browser from any client using a simple maven command.
Source of Truth
How do you know your test executions are trustworthy? You have to run them in more than one place. But, how do you know which is reliable? Create a source of truth.
In this short engagement, our dedicated expert was able to create a test agent in the CI system to run the tests. This system became the source of truth for testing.
So many companies struggle to get continuous testing started. The client trusted us with permission to create build jobs in their CI system. Because of this, and because we know CI systems well, we were able to set up jobs to run specific test suites many times a day. Previously, the client was running these tests by hand, once per release (about once a month). When this is the case, we don’t catch changes to the system under test fast. Development slows down. And feedback is stale.
The CI pipeline jobs we introduced are already providing developers with what they need to move forward more quickly. Issues will be triaged daily and there will be no surprises at the end of a one month release cycle.
Our success is when our clients are successful. We wanted to make sure the client had a path forward whether we were helping them or not. So we created a high-level plan with attainable objectives that they can use for the months and years ahead.
When You’re Ready
This is one of the many success stories our clients have experienced over the last 10 years. When you’re ready for an experience like this, contact us.