Auto-translation used

How I accelerated the RSAT test run 12 times in one sprint at Microsoft

Working in the RSAT team at Microsoft, I came across the fact that before each major release, the QA team spent up to three days running full tests — each script was run sequentially, and the average processing time for one build reached 48-72 hours.

Before the next Finance update & Operations key managers were already preparing for night shifts. I suggested dramatically speeding up the entire process by parallel processing and reorganizing the stages.

  1. Dividing tests into blocks Instead of a single stream of 400 scenarios, I suggested splitting them into four thematic groups: Ledger, Inventory, Sales, and Procurement.
  2. Run parallelization We have set up parallel queues in Azure DevOps, running four "packages" of tests simultaneously.
  3. Optimizing data preloading By removing the reauthorization and loading in each cycle, we took a single step to prepare a common context that was used by all threads.
  4. Integration into the pipeline We have implemented a new stage of "Parallel RSAT" in the YAML configuration of the assembly, while maintaining the usual order of reports and logs.

As a result, after a sprint, a full run of all UAT scenarios took 6 hours instead of 72 - the QA team received reports in the evening, and not just by the end of the working week.

  • The running time dropped from 48-72 hours to 6 hours.
  • The load on the servers was distributed evenly, without "bottlenecks" and delays
  • Prompt feedback: testers started getting the first results in the middle of the sprint, not "next week"
  • Team spirit: Automation allowed QA engineers to focus on analyzing the results instead of waiting for the build

Comments 0

Login to leave a comment