Private corporate batches, live online cohorts and 1-on-1 mentoring in continuous testing strategy — suite shape, automation in the pipeline, and a release signal engineers actually trust — 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 software testing as suite design rather than tool training: choosing the level a check belongs at, shaping the pyramid so failures localise, contract testing between services, test data and environment strategy, and the parallelisation and selection work that gets a pipeline inside a ten-minute budget. Sessions cover the parts most courses skip — quarantining and fixing flakes instead of retrying them, reading coverage and mutation scores without being misled by either, and deciding which tests block a release versus which merely report. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained inform the judgement calls on where to stop testing.
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 Software Testing that means a trainer who has run it in production — continuous testing strategy — suite shape, automation in the pipeline, and a release signal engineers actually trust — 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 Software Testing batchSoftware testing is the engineering practice of producing evidence about whether a system behaves as intended, and of producing it fast enough to act on. It is usually described by level — unit, component, integration, contract, system and end-to-end — and by intent, where functional checks sit alongside performance, security, accessibility, resilience and data-quality testing. Continuous testing is what happens when those levels are wired into a delivery pipeline so that every commit produces a release decision backed by evidence rather than by a calendar.
The shape of the suite matters more than its size. The test pyramid is the conventional target: many fast, isolated, deterministic unit tests; a smaller band of integration and consumer-driven contract tests that verify the seams between components; and a deliberately thin layer of end-to-end journeys that exercise the system as a user would. The inverted shape — a handful of unit tests under a wall of slow browser tests — is the single most common cause of a suite that takes hours, fails randomly and localises nothing, because when a broad test goes red it tells you the system is broken but not where.
In practice the hard parts of software testing are not assertions. They are test data that is realistic without being production data, environments that can be created and destroyed per pipeline run, dependencies you do not own and therefore stub or virtualise, flaky tests that must be quarantined and fixed rather than retried forever, and the runtime budget that decides whether developers wait for the result or route around it. Coverage, mutation score, escaped-defect rate and suite duration are the instruments used to steer all of that — each useful, each easy to game.
Release cadence has moved faster than most test estates. A two-week manual regression cycle was defensible when releases were quarterly; it cannot gate a change set that ships daily, and organisations that keep it end up either releasing untested or not releasing. The response is either to test less, which shows up later as escaped defects and incident load, or to rebuild testing as an engineering activity owned by the team that writes the code.
That rebuild is where the demand sits. The manual test analyst role has largely been repriced into quality engineering: people who write code, design the suite, own the pipeline stages that run it, and can argue about where a check belongs rather than only executing it. Job specifications now ask for contract testing, test containers, ephemeral environments, parallel execution and flake triage — none of which appear in a traditional certification syllabus.
The economics push the same way. Cloud CI is billed by the minute, so a slow suite is a line item; a flaky suite is worse, because it burns the minutes and destroys trust in the result at the same time. Teams that can cut a ninety-minute pipeline to twelve without losing coverage are making a measurable difference to both delivery speed and spend.
The decisions taken before any test is written. Risk-based prioritisation, the levels available and what each is good at, the difference between verification and validation, and the cost model that explains why a check is cheap at one level and ruinous at another. Ends with a written strategy rather than a tool choice.
Topics: Test levels: unit, component, integration, contract, system, end-to-end · Functional versus non-functional intent · Risk-based prioritisation and what deliberately goes untested · The cost of a test: write, run, maintain, diagnose · Testing quadrants and who owns which quadrant · Definition of Done and the release decision
The layer that carries most of the suite. Arrange-act-assert structure, naming that survives, testing behaviour rather than implementation, and the test doubles taxonomy — stub, mock, fake, spy — with the over-mocking failure mode that produces tests which pass while the system is broken.
Topics: Arrange-act-assert and test naming · Testing behaviour rather than internals · Stubs, mocks, fakes and spies — and when each is wrong · Parameterised and property-based testing · Test-first workflow and its honest limits · Refactoring under test · Component tests: the whole unit with its collaborators faked
The seams. Testing against real databases and message brokers with disposable containers, the difference between an integration test and an end-to-end test, and consumer-driven contract testing — the technique that lets services deploy independently without spinning up an integrated environment first.
Topics: Integration tests against real dependencies with disposable containers · Database, migration and repository testing · Message and event-driven integration testing · Consumer-driven contracts and the provider verification loop · Contract broker workflow and can-i-deploy checks · Schema compatibility and versioning · Service virtualisation for third parties you cannot call
The thin top layer, done deliberately. Selecting the small number of journeys worth automating, locator strategy that survives a redesign, explicit waiting instead of sleeps, controlling state through APIs rather than through the UI, and the parallel-execution model that keeps a browser suite inside the pipeline budget.
Topics: Choosing which journeys deserve an end-to-end test · Locator strategy and test IDs · Explicit waits, deterministic synchronisation and why sleeps fail · Page object and screenplay structuring · Seeding state through APIs instead of the interface · Cross-browser and mobile execution · Parallel runs, sharding and grid or cloud execution · Screenshots, videos and trace artefacts for diagnosis
The characteristics that only fail in production if nobody checks them earlier. Load and soak profiles and the difference between them, percentile-based acceptance criteria, static and dynamic security testing in the pipeline, automated accessibility checks and their limits, and fault injection to test the behaviour of the system when a dependency misbehaves.
Topics: Load, stress, soak and spike profiles · Acceptance criteria on percentiles rather than averages · Baselining and performance regression detection in CI · SAST, DAST and dependency scanning as pipeline stages · Automated accessibility checks and what they cannot catch · Chaos and fault injection: latency, errors, dependency loss · Data quality and migration testing
The constraint that quietly caps everything else. Fixtures and factories versus shared seed data, generating realistic data without copying production, masking and subsetting when you must, and moving from long-lived shared environments to ephemeral per-pipeline ones so tests stop interfering with each other.
Topics: Fixtures, factories and builders · Deterministic data and test isolation · Synthetic data generation and realistic distributions · Masking, subsetting and the legal position on production data · Ephemeral environments per branch or per pipeline run · Containerised dependencies and compose-based topologies · Cleaning up: teardown, leakage and cross-test contamination
Where the strategy meets the build. Staging tests so the fast ones run first, setting a time budget for the commit stage and defending it, test selection and caching, parallel execution, and deciding which results block a promotion versus which are advisory. Then the flake problem, which is a process problem as much as a technical one.
Topics: Pipeline stages and the shift-left ordering · The commit-stage time budget and how to hold it · Test selection, caching and incremental runs · Parallelisation, sharding and test balancing · Blocking gates versus advisory reports · Flake detection, quarantine and the fix-or-delete rule · Retries: the narrow case where they are acceptable · Reporting: JUnit XML, dashboards and trend data
The instruments and their failure modes. What line and branch coverage do and do not tell you, mutation testing as the check on the tests themselves, escaped-defect and defect-detection metrics, and how to report quality to management in a way that survives contact with an incident.
Topics: Line, branch and condition coverage — reading the number correctly · Coverage targets and why a blanket percentage backfires · Mutation testing and mutation score · Escaped defects, mean time to detect and defect density · Suite health: duration, flake rate, maintenance cost · Exploratory testing as a complement to automation · Reporting quality to non-engineering stakeholders
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a suite dominated by slow browser tests, classify every test by level, push checks down to the cheapest level that can hold them, and measure the runtime difference.
Write a consumer-driven contract between two services, verify it in the provider build, and demonstrate that either service can deploy first without an integrated environment.
Take an end-to-end suite that fails one run in five, instrument it, find the real causes — timing, shared data, ordering — and get it green twenty runs in a row.
Replace a shared test environment with a containerised topology created and destroyed by the pipeline, with test data built by factories rather than a seed dump.
Stage a monolithic test job, add selection, caching and parallel shards, and bring feedback time under ten minutes with coverage held constant.
Assemble coverage, mutation score, flake rate, suite duration and escaped-defect data for a service, then defend a prioritised plan for the next quarter.
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
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
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.
| 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.