Private corporate batches, live online cohorts and 1-on-1 mentoring in browser automation with WebDriver — locators, waits, the Page Object Model and data-driven test frameworks — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Selenium as a framework engineering problem rather than a command reference — locator strategy that survives UI change, explicit and fluent waits as the cure for flakiness, and the Page Object Model with Page Factory as the structure that keeps a growing suite maintainable. Sessions work live against real applications through the awkward parts: alerts and confirmation dialogs, modal boxes and pop-ups, multiple windows and frames, drag and drop, dropdowns and multi-select, and mouse and keyboard sequences through the Actions class. The course then builds outward into data-driven testing with Apache POI, keyword-driven and hybrid frameworks, parallel execution on Selenium Grid, and running the whole suite in CI so a failure blocks a merge.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Selenium that means a trainer who has run it in production — browser automation with WebDriver — locators, waits, the Page Object Model and data-driven test frameworks — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Selenium batchSelenium is an open-source suite for automating web browsers. It is not a testing framework — it drives a browser, and you supply the framework, the assertions and the reporting around it. That distinction explains most of what people find surprising about it: Selenium will click, type, navigate and read the page, and everything else is engineering you do yourself.
The suite has three parts. Selenium WebDriver is the core: a language binding — Java, Python, C#, JavaScript, Ruby — that speaks the W3C WebDriver protocol to a browser driver such as ChromeDriver or GeckoDriver, which in turn controls a real browser. Selenium IDE is a record-and-playback browser extension, useful for exploration and poor as a basis for a maintained suite. Selenium Grid distributes execution across machines and browsers so a suite that takes an hour serially takes minutes in parallel.
Writing Selenium that works once is easy. Writing Selenium that still works in six months is the actual skill, and it comes down to three things: locators that survive UI change, so CSS and well-formed XPath rather than brittle absolute paths; synchronisation, because explicit waits on a condition are the difference between a reliable suite and a flaky one; and structure, which is why the Page Object Model exists. Around that, a real framework adds data-driven execution from external sources, keyword-driven abstraction, reporting and CI integration — the difference between a pile of scripts and a suite a team trusts enough to gate a release on.
Release cadence broke manual regression testing. A team shipping weekly cannot re-test a large application by hand each time, so the regression suite becomes automated or it becomes theatre — a shrinking subset that gets checked while everything else is assumed fine. Selenium remains the most widely used way to automate that at the browser level, and W3C WebDriver standardisation means those skills now transfer across drivers and tools rather than being tied to one vendor.
What organisations actually struggle to hire is not someone who can write a test. It is someone who can build a suite that stays green for the right reasons. Most automation efforts die of flakiness: tests that fail intermittently, get re-run until they pass, and eventually get ignored — at which point the suite has negative value, because it consumes time and provides no signal. Fixing that is a synchronisation and design problem with well-understood solutions that most teams never apply.
The third factor is where tests run. A suite that only runs on someone's laptop does not gate anything. Making tests run in CI on every merge, in parallel across browsers, producing a report someone reads, is what converts test automation from a side project into a delivery control — and it is usually the specific thing a private batch is booked to build.
What Selenium is and — importantly — what it is not. The three components and the role of each, how WebDriver actually talks to a browser through the W3C protocol and a driver binary, and an honest assessment of the advantages and the disadvantages against other automation tools.
Topics: What Selenium is · The components of Selenium: WebDriver, IDE and Grid · How WebDriver, the browser driver and the browser interact · The W3C WebDriver protocol and what standardisation changed · Why Selenium is chosen over other tools, and where it is not · Advantages and disadvantages of Selenium · Language bindings and choosing one
A working development environment before any test logic. Language binding, build tool, test runner, driver management and the project layout you will keep for the rest of the course — then the first script that opens and closes a browser, which is where most environment problems surface.
Topics: Selenium hands-on environment setup · Project setup with a build tool and dependency management · Test runner setup and first test class · Browser drivers and automatic driver management · Commands to open and close a browser · Driver quit versus close and why it matters · Headless execution and browser options · Diagnosing driver and version mismatch errors
The command surface you use in every test. Get commands for reading page state, navigation commands and how they differ from setting a URL directly, and switch commands for moving between windows, frames and alerts — the source of a large share of confusing failures.
Topics: Basic commands in Selenium · Get commands: title, current URL, page source, text · Navigation commands: to, back, forward, refresh · Navigation versus direct URL assignment · Switch commands: window, frame, alert, default content · Window size, position and maximise · Cookies and browser state between tests
The single biggest determinant of whether a suite survives. What a WebElement is, every locator type and when each is appropriate, and XPath written properly — axes, functions, contains and text matching — rather than the absolute paths a browser copy-selector produces and the next release breaks.
Topics: What web elements are · Types and techniques of locators · id, name, className, tagName, linkText and partialLinkText · CSS selectors in depth · Customising XPath to locate elements · XPath axes, functions and text matching · Absolute versus relative XPath and why one is a liability · Relative locators in modern Selenium · Hands-on locating elements in a real web application
Why tests fail intermittently and how to stop it. Implicit, explicit and fluent waits, expected conditions, the interaction between implicit and explicit waits that produces bizarre timeouts, and why a fixed sleep is both slower and less reliable than a condition.
Topics: Why timing failures happen in browser automation · Implicit waits and their scope · Explicit waits and expected conditions · Fluent waits, polling intervals and ignored exceptions · Custom expected conditions · Mixing implicit and explicit waits: the trap · Page load and script timeouts · Diagnosing a flaky test methodically
The parts of real applications that break naive scripts. Alerts of all three kinds, modal dialogs and pop-ups, multiple windows, drag and drop, dropdown and multi-select handling, and mouse and keyboard sequences through the Actions class.
Topics: Different types of alerts: simple, confirmation and prompt · Handling modal dialog boxes and pop-ups · Handling multiple windows using switch window commands · Working with drag and drop of an element · Handling elements in a dropdown list · Multiple selection from a list of options · Mouse hover actions · Keyboard and mouse actions with the Action and Actions classes · File upload and download handling
Moving from scripts to a framework. What a framework actually is, the recognised types and what each optimises for, and the ingredients every one of them needs: structure, configuration, test data, reporting, logging and a runner that can group, order and parallelise.
Topics: What a test framework is · Types of framework: linear, modular, data-driven, keyword-driven, hybrid · Main ingredients of a framework · Test runner features: groups, priorities, dependencies, parallel execution · Configuration management and environment switching · Assertions: hard versus soft · Logging and reporting · Directory structure and project conventions
The design pattern that keeps maintenance cost flat as a suite grows. Separating page structure from test intent so a UI change touches one class instead of forty tests, Page Factory annotations and lazy initialisation, and how page objects compose for flows that span pages.
Topics: What the Page Object Model is and the problem it solves · What Page Factory is · FindBy annotations and element initialisation · Page objects that return page objects for flow chaining · Keeping assertions out of page objects · Base page and shared component objects · Hands-on Page Object Model with a worked example · Refactoring an existing suite into page objects
Separating test data from test code so coverage grows without new code. What Apache POI is and how it reads and writes Excel workbooks, wiring spreadsheet rows into a data provider, and the practical concerns — data cleanup, independence between rows, and where test data should actually live.
Topics: What a data-driven framework is · What Apache POI is and how it is used · Reading Excel workbooks, sheets, rows and cells · Writing results back to a workbook · Feeding external data into a test runner data provider · Handling data types and empty cells safely · Test data independence and cleanup between rows · Hands-on: importing data from a spreadsheet and asserting on results · Alternatives to Excel: CSV, JSON, database and API-sourced data
The last mile. Keyword-driven and hybrid frameworks where test steps are described rather than coded, then execution at scale: Selenium Grid with a hub and nodes, containerised browsers, cross-browser runs, and CI integration so a regression failure blocks a merge and produces a report someone reads.
Topics: The concept of a keyword-driven framework · Designing a keyword vocabulary and dispatcher · Hybrid frameworks combining data and keyword approaches · Selenium Grid architecture: hub and nodes · Running Grid nodes in containers · Parallel and cross-browser execution · Reporting: HTML reports, screenshots on failure, logs · Running the suite in a CI pipeline · Failing a build on regression and triaging the result
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a suite full of copied absolute XPath, change the application markup, watch it fail, then rebuild the locators so the same change is harmless.
Diagnose a suite that fails intermittently, replace sleeps with explicit and fluent waits, and prove stability over repeated consecutive runs.
Automate a page with a confirmation alert, a modal, a new window, a multi-select and a drag-and-drop interaction, using Actions where required.
Refactor a flat suite into page objects with Page Factory, then apply a real UI change and demonstrate that only one class needed editing.
Wire Apache POI into a data provider so a tester adds twenty scenarios by adding spreadsheet rows, with per-row results written back.
Run the full framework in parallel on Selenium Grid from a CI pipeline, publish reports and failure screenshots, and block a merge on a real regression.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.