GET /api/work/erp-test-automation
Testing an ERP by hand, then automating a cloud app
Archived · · contributor · team of 10
Ten of us taught robots to re-test a business app every night, after testing it by hand first, which is how we found the bugs the robots would've missed.Two sprints on the CYDEO SDET program — fourteen user stories tested by hand against an ERP, then a Cucumber and Selenium suite against a cloud app.
- Java
- Selenium
- Cucumber
- Gherkin
- REST Assured
- JUnit
- Maven
- Jenkins
- Jira
Parameters
Request
curl "https://portfolio.dylansg0318.workers.dev/api/ work/ erp-test-automation"
Response200 OK · 2.5 KB
{ "id": "erp-test-automation", "title": "Testing an ERP by hand, then automating a cloud app", "status": "archived", "year": 2024, "category": "work", "role": "contributor · team of 10", "summary": "Two sprints on the CYDEO SDET program — fourteen user stories tested by hand against an ERP, then a Cucumber and Selenium suite against a cloud app.", "summary_plain": "Ten of us taught robots to re-test a business app every night, after testing it by hand first, which is how we found the bugs the robots would've missed.", "stack": [ "Java", "Selenium", "Cucumber", "Gherkin", "REST Assured", "JUnit", "Maven", "Jenkins", "Jira" ], "links": { "source": "https://github.com/drwekilowa/B34_G11_Sprint_2CloudAuto" }, "problem": "Sprint 1 was BriteERP, an Odoo-based ERP, and fourteen user stories covering login, logout, messaging channels, note cards, calendars, contacts, point-of-sale orders, manufacturing orders, expenses and role-based module access — a POS manager sees 22 modules, a sales manager 19, inventory 16, events 15, expenses 12. There was no automation in that sprint at all: the deliverable was a test plan, a test strategy and a regression pass that took the team a full day by hand. Sprint 2 moved to TryCloud, a Nextcloud-style collaboration suite, and turned that discipline into a Cucumber and Selenium suite. Ten-person teams both times.", "unique": "We wrote the manual test plan before a line of automation. Acceptance criteria per user story, executed by hand, bugs logged as we went: a missing word in the login error, an idle-logout timer that never fired, an Import option absent from a menu. Only then did the Gherkin get written, so the scenarios described behaviour we'd actually observed, not behaviour we assumed.", "ai": "None. 2024, pre-agent, every locator, step definition and hook was typed by hand, which is a good way to learn why page objects exist.", "learned": [ "Manual first isn't the slow way. Every scenario we automated blind in the first sprint had to be rewritten. Every one we automated after running it by hand passed on the first try.", "Page objects are a team contract. With ten people, the value wasn't reuse. It was that a locator changed in one place and nobody's step definitions broke.", "Green in CI isn't the same as tested. A suite that always passes because a wait is too generous is worse than a red one. We learned to make waits explicit and fail fast." ], "page": "https://portfolio.dylansg0318.workers.dev/projects/erp-test-automation" }
Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.
The problem
Sprint 1 was BriteERP, an Odoo-based ERP, and fourteen user stories covering login, logout, messaging channels, note cards, calendars, contacts, point-of-sale orders, manufacturing orders, expenses and role-based module access — a POS manager sees 22 modules, a sales manager 19, inventory 16, events 15, expenses 12. There was no automation in that sprint at all: the deliverable was a test plan, a test strategy and a regression pass that took the team a full day by hand. Sprint 2 moved to TryCloud, a Nextcloud-style collaboration suite, and turned that discipline into a Cucumber and Selenium suite. Ten-person teams both times.
What was unique
We wrote the manual test plan before a line of automation. Acceptance criteria per user story, executed by hand, bugs logged as we went: a missing word in the login error, an idle-logout timer that never fired, an Import option absent from a menu. Only then did the Gherkin get written, so the scenarios described behaviour we'd actually observed, not behaviour we assumed.
Where AI fit in
None. 2024, pre-agent, every locator, step definition and hook was typed by hand, which is a good way to learn why page objects exist.
Parameters
Request
curl "https://portfolio.dylansg0318.workers.dev/api/ work/ erp-test-automation? fields=problem%2Cunique%2Cai"
Response200 OK · 1.2 KB
{ "problem": "Sprint 1 was BriteERP, an Odoo-based ERP, and fourteen user stories covering login, logout, messaging channels, note cards, calendars, contacts, point-of-sale orders, manufacturing orders, expenses and role-based module access — a POS manager sees 22 modules, a sales manager 19, inventory 16, events 15, expenses 12. There was no automation in that sprint at all: the deliverable was a test plan, a test strategy and a regression pass that took the team a full day by hand. Sprint 2 moved to TryCloud, a Nextcloud-style collaboration suite, and turned that discipline into a Cucumber and Selenium suite. Ten-person teams both times.", "unique": "We wrote the manual test plan before a line of automation. Acceptance criteria per user story, executed by hand, bugs logged as we went: a missing word in the login error, an idle-logout timer that never fired, an Import option absent from a menu. Only then did the Gherkin get written, so the scenarios described behaviour we'd actually observed, not behaviour we assumed.", "ai": "None. 2024, pre-agent, every locator, step definition and hook was typed by hand, which is a good way to learn why page objects exist.", "page": "https://portfolio.dylansg0318.workers.dev/projects/erp-test-automation" }
Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.
The story
The capstone of my testing program: teams of ten, two sprints, and a business app with logins, calendars, contacts, sales orders and expenses. Re-checking it by hand after every change took a whole day.
We did something that felt slow and turned out to be the fastest path: before writing any automation, we tested everything by hand and wrote down exactly what “working” means. That hand pass caught real bugs a robot would’ve sailed past — an error message missing a word, an automatic logout that never happened, a menu missing an option. Then we taught the robots to repeat those checks every night, in minutes instead of a day.
That’s where the habits behind everything else on this site come from: check it yourself before you trust it, write down what “correct” means, and don’t trust a test that’s never failed.
The setup
Ten people, two sprints, two applications. Sprint 1 was BriteERP and it was entirely manual: fourteen user stories, acceptance criteria written out, executed by hand, bugs logged. Sprint 2 was TryCloud, and there we split the stories by module and shared one framework — a configuration-driven WebDriver factory, a hooks class for setup and teardown, browser utilities, and page objects per screen. I owned the Deck module end to end: the feature file, the page object and the step definitions. A third sprint covered API testing with REST Assured against a library system, where I took the create-a-user endpoint.
Manual before automated
The instinct on a test-automation course is to start automating. We didn’t. Each user story got acceptance criteria, and each criterion was run by hand first. That turned up real defects: the login error read “Wrong username password” with the “or” missing, the three-minute idle logout never fired, and the Point-of-Sale action menu was missing its Import option. The feature files that followed described behaviour we’d watched, not behaviour we hoped for.
The framework
Cucumber scenarios in Gherkin, step definitions in Java, Selenium underneath. Page objects held the locators (XPath and CSS), so a UI change was one edit. A properties file chose the browser and the environment. Jenkins ran the suite on a schedule and on demand, with Cucumber’s HTML report as the artefact.
What stuck
I still write the manual check before the automated one, and I still don’t trust a green run I haven’t seen fail.
What I learned
- Manual first isn't the slow way. Every scenario we automated blind in the first sprint had to be rewritten. Every one we automated after running it by hand passed on the first try.
- Page objects are a team contract. With ten people, the value wasn't reuse. It was that a locator changed in one place and nobody's step definitions broke.
- Green in CI isn't the same as tested. A suite that always passes because a wait is too generous is worse than a red one. We learned to make waits explicit and fail fast.
Parameters
Request
curl "https://portfolio.dylansg0318.workers.dev/api/ work/ erp-test-automation? fields=learned"
Response200 OK · 632 B
{ "learned": [ "Manual first isn't the slow way. Every scenario we automated blind in the first sprint had to be rewritten. Every one we automated after running it by hand passed on the first try.", "Page objects are a team contract. With ten people, the value wasn't reuse. It was that a locator changed in one place and nobody's step definitions broke.", "Green in CI isn't the same as tested. A suite that always passes because a wait is too generous is worse than a red one. We learned to make waits explicit and fail fast." ], "page": "https://portfolio.dylansg0318.workers.dev/projects/erp-test-automation" }
Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.