Private corporate batches, live online cohorts and 1-on-1 mentoring in cross-platform mobile automation for native, hybrid and mobile-web apps on Android and iOS over the W3C WebDriver protocol — 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 Appium as a protocol and a driver stack rather than a set of method calls: how the WebDriver session reaches UiAutomator2 and XCUITest, why a capability set behaves differently on a simulator than on a real device, and how locator strategy decides whether a suite survives the next redesign. Sessions run against live emulators and real devices, and cover the operational edges — gesture reliability, hybrid context switching, permission and system dialogs, Appium 2 driver management, parallel execution and CI wiring — with every concept demonstrated against a running application rather than slides. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained inform the framework and pipeline design decisions.
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 Appium that means a trainer who has run it in production — cross-platform mobile automation for native, hybrid and mobile-web apps on Android and iOS over the W3C WebDriver protocol — 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 Appium batchAppium is an open-source automation framework for driving native, hybrid and mobile-web applications on Android, iOS and Windows. It is built on the W3C WebDriver protocol, which means test code talks to an Appium server over HTTP using the same request model that browser automation uses, and the server translates each command into whatever the platform's own automation technology requires — UiAutomator2 or Espresso on Android, XCUITest on iOS. The consequence is the reason teams choose it: one client library, one test structure and one set of skills spanning two operating systems that share nothing underneath.
The object model is small and worth learning precisely. A session is created from a set of capabilities that name the platform, the automation driver, the device or emulator and the application under test. Elements are found through locator strategies — accessibility id, id or resource-id, class chain and predicate string on iOS, UiAutomator selectors on Android, and XPath as the slow last resort. Interaction happens through element methods and the W3C Actions API for gestures such as swipe, long press, pinch and drag. Hybrid applications add contexts, where the driver switches between NATIVE_APP and a WEBVIEW context to automate embedded web content with the same session.
Appium 2 changed how the project is packaged rather than how it is used: drivers and plugins became independently installed and versioned components managed through the Appium extension CLI, so a driver can be upgraded for a new iOS release without waiting for a server release. What Appium deliberately does not do is also worth knowing — it does not build your application, manage a device fleet, or provide parallelism on its own. Those come from the Android SDK and Xcode toolchains, from running multiple server instances or a grid, and from real-device clouds when local hardware is not enough.
Mobile is where the release pressure is highest and the feedback loop is worst. Two operating systems, a long tail of device models, OS versions that change annually and app-store review windows combine to make manual regression testing on mobile more expensive than on any other platform, and slower than the release cadence teams want.
Appium is the default answer because it is the only widely adopted option that is genuinely cross-platform, open-source and vendor-neutral. Espresso and XCUITest are faster and more stable within their own platform, but they are two separate codebases, two languages and two skill sets; every commercial device cloud speaks Appium, so a suite written against it stays portable when the execution target changes. That portability is exactly what an organisation is buying.
The skill gap is in the operational half. Writing a first Appium test is a morning's work. Keeping a mobile suite green across an OS upgrade, structuring locators so a design change does not rewrite the suite, handling permission dialogs and biometric prompts, running dozens of sessions in parallel against emulators or a device cloud, and integrating all of it into a pipeline that runs on every pull request — that is what teams hire for and what most tutorials never reach.
How the pieces fit before any code is written. The WebDriver protocol, the Appium server as a translator, and the platform drivers underneath it — UiAutomator2, Espresso, XCUITest. An honest comparison with Espresso and XCUITest used directly, including where Appium is the wrong choice.
Topics: Native, hybrid and mobile-web applications and how each is automated · The W3C WebDriver protocol and the client-server model · Appium server, drivers and the request lifecycle · UiAutomator2, Espresso and XCUITest underneath · Appium 1 versus Appium 2 — drivers and plugins as extensions · Where Espresso or XCUITest is the better answer
The step that defeats most first attempts. Node and Appium 2 installation, the extension CLI for drivers and plugins, Android SDK platform-tools and emulator images, Xcode command line tools and simulators, and appium-doctor as a diagnostic. Then real-device setup: developer options, ADB authorisation, provisioning and WebDriverAgent signing.
Topics: Installing Appium 2 and managing drivers with the extension CLI · Android SDK, platform-tools, AVD Manager and emulator images · Xcode, simulators and command line tools · appium-doctor and reading its output · ADB fundamentals: devices, install, logcat, shell · Real device setup on Android and iOS · WebDriverAgent and code signing on iOS · Appium Inspector for exploring an app
How a test attaches to a device. W3C capabilities and the vendor prefix, the capabilities that matter for each platform, application installation versus attaching to an installed app, and the session lifecycle including timeouts, resets and teardown.
Topics: W3C capabilities and the appium: prefix · platformName, automationName, deviceName, udid and app · Installing, launching, backgrounding and resetting an application · noReset, fullReset and what state persists between tests · Session timeouts and newCommandTimeout · Multiple sessions and server port allocation · Reading and interpreting the Appium server log
The decision that determines maintenance cost for the life of the suite. Every locator strategy on both platforms, the accessibility identifiers that developers must supply, and the performance and brittleness cost of XPath. Then interaction: typing, clearing, keyboard handling, attributes and assertions.
Topics: Accessibility id and why it should be the default · Android: id and resource-id, UiAutomator selectors · iOS: class chain and predicate string · XPath — cost, fragility and the narrow cases where it is justified · Finding single and multiple elements, chained lookups · Element attributes, text, displayed and enabled state · Keyboard handling, text entry and hiding the keyboard · Working with developers to add stable identifiers
Where mobile automation diverges from browser automation. Implicit versus explicit waiting and why sleeps hide race conditions rather than fixing them, the W3C Actions API for gestures, scrolling strategies on both platforms, and hybrid apps where the driver switches into a webview context mid-session.
Topics: Implicit waits, explicit waits and expected conditions · Why Thread.sleep produces flaky suites · The W3C Actions API: pointer input, pauses and sequences · Swipe, scroll, long press, drag and pinch · Scrolling to an element on Android and iOS · Contexts: NATIVE_APP and WEBVIEW, switching and chromedriver · Permission dialogs, system alerts and biometric prompts · Deep links, notifications and device orientation
Turning scripts into something a team can maintain. Page object structure for mobile with a shared abstraction across platforms, the test runner and its lifecycle hooks, configuration and environment handling, data-driven cases, assertions, logging and reporting artefacts that make a failure diagnosable.
Topics: Page objects and screen abstractions across two platforms · TestNG or JUnit lifecycle, groups and dependencies · Driver factory and thread-safe driver management · Configuration: environments, devices and secrets · Data-driven tests from CSV, JSON or a provider · Assertions and soft assertions · Reporting with Allure or equivalent, screenshots and video on failure · Project structure, build tooling and dependency management
Getting from one device to many. Running multiple Appium server instances, port and system-port allocation, thread-safe driver handling, and the trade-offs between emulators, simulators, a local device rack and a commercial device cloud. Then the practical matter of which device and OS combinations are worth running.
Topics: Multiple server instances and port management · systemPort, wdaLocalPort and per-session isolation · Thread-safe drivers and parallel test runner configuration · Emulators and simulators versus real devices — what each misses · Selenium Grid and Appium in a grid topology · Device clouds: session capabilities, artefacts and limits · Choosing a device and OS matrix from real usage data · Execution time, cost and the point of diminishing returns
The part that decides whether the suite is still running in six months. Wiring Appium into a pipeline with headless emulators, artefact publication and result reporting; then the maintenance reality — OS upgrades, driver upgrades, flake triage and the smoke-versus-regression split that keeps pull request feedback fast.
Topics: Pipeline stages: build the app, start the server, run, publish · Headless emulators and containerised Android in CI · Publishing JUnit results, screenshots and videos as artefacts · Smoke suite on pull requests, full regression on a schedule · Flake detection, quarantine and root-cause triage · Surviving an OS or driver upgrade · Versioning the suite alongside the application · Handing the suite over to an application team
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall Appium 2, add the UiAutomator2 and XCUITest drivers with the extension CLI, launch an emulator and a simulator, and take a first session on each.
Replace every XPath locator in a sample suite with accessibility ids, resource-ids, predicate strings and UiAutomator selectors, then measure the runtime and stability difference.
Build reusable swipe, scroll-to-element, long-press and pinch helpers using the W3C Actions API, working identically on Android and iOS.
Automate a hybrid application that starts native, crosses into an embedded webview for a checkout flow, and returns — in a single session.
Configure system ports, thread-safe drivers and runner parallelism to run one suite simultaneously across two emulators and a real device.
Build the application, start Appium, run a smoke suite against a headless emulator in CI, publish screenshots and JUnit results, and fail the build only for real defects.
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
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
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.
| 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.