🎉 V1 of Ministry of Testing 'Automation Engineer in Testing' Curriculum complete

MoT Content Discussions
,
1

Hi all,

I’m very pleased to announce that our first ‘Community Co-created Curriculum’ is complete, thanks to the hard work of testing community members and Ministry of Testing.

The ‘Automation Engineer in Testing’ Curriculum covers the core tasks an Automator completes as part of their role. Each task has specific steps and learning outcomes attached to them to help:

  • Guide those looking to learn about Automation on what they should learn.
  • Give teachers of automation a structure to their teaching and what to focus on.
  • Help managers hire the right kind of Automators.
  • Help Automators evaluate their own experiences.

You can find a copy of the curriculum in the link below:

As always, this is a curriculum that has been created with the help of the testing community. So if you have any questions or feedback to give. Please let us know in this thread.

18 Likes
2

Is there a timeline for when the content of the course is going to be available? The curriculum looks great! Or maybe it is already available, I’m fairly new to navigating the MoT website so it’s very possible I’m just not finding it. Thanks!

1 Like
3

@sirtthe9th We’re going to put a plan into action to build content for our version of the curriculum very soon. We have lots of material ready we just need to structure to align with the new curriculum.

2 Likes
4

Thanks to @friendlytester for signposting me to this in the Q&A at the end of his S.A.C.R.E.D. livestream :+1:

5

Fascinating, thanks for sharing (-:

I’m in the early stages of an open source project to co-design a curriculum for community professionals (architects, builder, managers, etc).

Would love to pick your brains if you have time?

Ta,
James.

6

I’ve booked a call in @jacattell and invited @sarahdeery as she’s the brains behind the operation :slight_smile:

1 Like
7

The most important topic is missing : “knowledge of the application under test”. This otherwise you can’t assert if you are designing the correct framework / tools and tests. An automation engineer shouldn’t blindly create a script from a test case written in text format. I try to avoid manual and automated test naming.

1 Like
8

You raise an interesting point @xbartels we do in fact cover knowledge of the application under the step “Model the context” but I wonder if ‘Context’ is too broad a word to use.

Agreed that understanding is required before making decisions hence the Strategy and Planning modules.

1 Like
10

Hello @mwinteringham . Came across this from your recent talk in SeleniumConf.

This is a fantastic initiative because there hasn’t been a well thought holistic curriculum for test automation created.

I have gone through the Google doc and it looks comprehensive. May I check with you if the curriculum intends to walk a tester through:

  1. Fundamentals of all different kinds of automated tests (UI unit, UI component, backend unit, backend component, integration, end-end) and not just focus on end-end UI tests? Yes testers need to know what unit tests are how they are written in different contexts.

  2. Given a feature in a sprint how to plan & distribute the coverage to different levels of automated tests based on the risk, testability & layer that is most suitable to automate the coverage.
    For example, deciding that 3 scenarios are best covered as unit tests, 2 best covered as integration and 1 best covered as end-end test.

Traditionally a lot of testers are rarely exposed to above 2 points in their learning or upskilling journey and I feel this gap needs to be closed.

Also another question: Is this curriculum the end goal or is there something more coming out of this curriculum from your side?

Looking forward to your thoughts on this.

1 Like
11

Hello Abhijeet,

Thank you for the kind words :slight_smile: I can answer on Marks’ behalf as he is off ill today.

  1. Absolutely, in section ’ Creating Automated Checks’ we will teach ‘determine what layer the automated check should be on’.
  2. Yep, absolutely, covered in the same section on page 6.

Have a re-read of that section and see if it satisfies your concerns.

We have two ends goals. This curriculum is open source and we will maintain it and look to update it 1-N times a year.
Our second goal is Ministry of Testing will implement courses/paths/content etc to satisfy this curriculum on our own site. We also hope other training providers and teachers build content against this curriculum and it becomes the defacto curriculum for automators.

Hope this helps.

3 Likes
12

Hello Richard! :wave: Wow nice to see your reply! :slight_smile: I am big fan of your work and thanks for all that you do for the testing community :star_struck:

Thanks for such a quick response! Noted on your inputs.

Just another question:
Does the section “Creating automated checks” also intend to cover the “when” of test automation? Testers are typically used to implementing automated tests AFTER features are released to production - more as a regression coverage activity rather than proactive test automation.

So it’d be great if that section (or any other section in the curriculum) also covers answers to questions/topics like:

  • When should you automate tests? (all kinds - unit, integration, end-end)
  • What are the benefits of writing tests as part of the dev cycle VS writing them as regression checks post the product release?
  • An overview of TDD & BDD practices from the perspective of automation.

Cheers!

1 Like
13

The ‘when’ is dependent on your testability, so I believe this would be covered in the strategy section of the document.

We’ll be discussing testability and explaining what could be done in common scenarios. Or more specifically, what a certain aspect of testability means you can/can’t do. So I believe we will cover this in strategy and planning. We’ll also be covering goals, which I believe will cover some of this as well.

  1. We won’t tell people what they should do, instead we’ll share the types of testing that are possible when you have specific testability characteristics.
  2. We’ll discuss this in:

Identify and set automation goals

  • Describe what an automation goal looks like
  • Align automation goals with testing strategy goals
  • Consider how automation might help in a given context
  • Formulate a list of automation goals
  1. I can’t recall the exact reasons why, but we removed TDD/BDD after much discussion with the community, and agreed it would most likely appear in a different curriculum such as one aimed at Developers. We most likely mention using gherkin-esque tooling, and the pros/cons, but won’t cover BDD it it’s entirety. TDD will be covered in the strategy part, as in, if your team are practicing TDD, it will afford you a few options.
2 Likes
14

Thanks Richard.

Agree that when depends on testability but I’d say testability also depends on when you’d ideally want to automate.

I have seen both sides of the spectrum in my experience and I noticed that if I tell my product team that the automated test coverage needs to be part of the dev cycle and not after release, they ensure that testability is taken care of earlier (as long as I as a tester call out testability gaps).

If I don’t do that (and my automated tests will be done after release) then devs kind of take it for granted that nothing needs to be done in terms of testability. Hope that clarifies :slight_smile:

1 Like