Senior Software Engineers & Engineering Leaders who want to break free from firefighting and lead their team toward reliable delivery, and who have the self-initative to drive change across their teams.
QA Automation Engineers who want to shift into a proactive role - shaping requirements, uncovering scenarios before implementation, rather than manual regression testing.
Pure managers who no longer do any technical work: this isn’t a fit for you - but it may be for your team. Let’s talk about how to get them in.
Startup teams in MVP phase: If your product is too new, you won’t feel the pain of manual QA enough to make this stick.
Junior or Mid-level engineers: This program requires architectural thinking and team influence. It’s best suited once you’ve reached senior level. (Exception: if you’re on the cusp and highly motivated, reach out.)
This course is language-agnostic & library-agnostic.
To help participants spend less time in setting up and doing hands on work, I will be providing demo projects with the following:
Java
TypeScript
.NET
In all of them, I plan to use mainly Playwright. But in your specific case, you can choose anything else (e.g. Selenium, Cypress, Appium, etc.) since the principles are similar.
In the ATDD Sandbox you can use any language, but I recommend choosing the one your QA Automation Engineers already use to reduce resistance and learning curves. If you don’t have QA Automation Engineers yet, consider the most common industry languages (Java, C#, Python, TypeScript). Since Smoke, Acceptance, and E2E tests are system-level black-box tests, they’re often best owned by QA Automation Engineers, though teams can decide who writes them. What matters is that the language is readable by both developers and QA Automation Engineers.
You’ll be able to have full freedom how you setup your ATDD project, I recommend choosing whatever best matches your Real Life Project. You will be able to choose: [1] Repository Structure (mon-repo vs multi-repo), [2] System Architecture (Monolith or Modular Monolith or Microservices), [3] UI (Web App or Mobile App or Desktop App or Console App, or multiple of these), [4] Tech Stack (programming language, libraries), [5] External System (REST API and/or SOAP Service, System Clock, ML/AI/Math Libraries, Hardware, etc.), [6] Environments & Deployment (you won’t be required to use real environments, you’re free to use Docker Compose instead; but if you want to use real environments & deployment you can).
You'll be able to store your sandbox project on GitHub, publicly visible. Licences under MIT licence.
For Pipeline Architecture, you'll be able to use GitHub Actions.
The first phase of our transformation journey is automated deployment, which requires the skillset to build a pipeline. Most likely, in your company, there’s already some DevOps Engineer who builds pipelines. For purposes of this course, you’ll learn the pipeline architecture that’s needed. However, we won’t dwell too much into the implementation of the pipeline (instead we’ll use Docker Compose as a replacement) because the focus of this course is on Acceptance Tests & ATDD. At work, it’ll be necessary to engage your DevOps Engineer in terms of implementing the Pipeline, but you’ll be there to provide inputs regarding the Pipeline architecture.
As part of ATDD Samdbox Project Review, you’ll still have access to continued review, even after the dates written above, because I provide lifetime access.
You have the self-initiate to introduce change in your company, but you have limited time. Most likely, your company won’t support learning during your work hours, so you’re left with time after work, which is limited. The long slow path would be to read lots of books, watch lots of courses, attend trainings, try to find mentors, then do trial-and-error implementation in your personal project, then do trial-and-error to convince your manager to adopt this, then eventually when you do get approval from your manager to implement the changes you would do it slowly and make lots of mistakes (because it’s your first time so most likely you’d introduce ineffective ATDD), your initiative would fail (because ineffective ATDD is worse than manual testing), the team would conclude that ATDD doesn’t work and would go back to Manual QA, plus you would lose your own reputation/trust and your team/management will say “ATDD doesn’t work”.
Unfortunately, I had no one to help me, so I spent 10+ years to get to where I am now, I had spent $10,000+ buying books on Amazon, bought many courses, didn’t have time to read and watch everything I bought, made my own project with lots of trial-and-error, made mistakes when I first tried things in real projects, faced resistance, etc.
That’s why I made the ATDD Accelerator Program, so that you don’t have to go through that painful journey.