I've started a new career at a company which has not used test automation before and whole and manual QA level is very basic.

Before making any e2e tests I'd like to know:

What exactly should I have before to do that, like user-stories, acceptance criterias, etc. (and who should make em) - so I would know how exactly should I design test scenarios; OR maybe its not necessity at all and I could design them as I go through user stories of product (thats very doubtful)

3 Answers 3


First of all, e2e tests tend to be brittle due to many steps that can go wrong.

That's why you should limit the number of e2e tests (and UI tests in general). Always remember you want to have a test piramyd, not the test ice-cream cone.

But, for those tests you are automating, RCRCRC heuristic can be useful:

enter image description here

Of course, this works for all testing, but it is a starting point. I would personally talk to the product owner or business analyst to see what is the core functionality of the application and to other testers to see what are the repetitive/boring parts of the test (like filling up the login form).

  • Thanks, an brilliant article and a way to go I suppose!
    – Orkhan M.
    Commented Sep 23, 2019 at 10:20

If Agile environment:

I recommend you combine two things:

  • Guidance from the Agile Test Pyramid and Agile Testing Quadrants This makes sure you have a small number of e2e tests which is hard to do

  • Guidance form the business about what is supported, what to test, what breaks, etc.

You will need to work closely with the business to turn the Pyramid and Quadrants concepts into real implementations. I recommend reading 'Agile Testing' by Crispin and Gregory to help you.

  • 1
    Another new user gets burned instead of helped. no wonder our site isn't growing ! Remember you can UPDATE THE QUESTIONS instead Commented Sep 19, 2019 at 10:44
  • 1
    I think QA automation is mostly have a purpose to free manual QA on the routines never change (old product features) to get them more time to spend on testing new product features and this is why its not often small number of tests and they're not even hard to do.
    – Orkhan M.
    Commented Sep 19, 2019 at 11:32
  • 2
    I agree, freeing more time for better exploratory testing by automating the routine tasks is a great benefit. I do caution against considering them equivalent or you'll end up testing too much through automated UI testing. YOu get the number of UI tests small by having a LOT of fast unit tests. 10,000 unit tests should be runnable in a few minutes if dependencies are fully removed. 100 UI tests+might (but totally depends on situation) end up meaning 5000 actual UI tests because that many UI tests needs to be run to cover multiple devices... browsers... versions... Commented Sep 19, 2019 at 12:26
  • This is frequently an easy sell to engineers but a very very hard sell to the business. You have to go high level and goals for speed etc Any failure (and they will always happen) will be seen as proof to test in the UI more. Resist that automatic response unless no other choice. Essentially there is critical high level education that needs to take place. Given it is engineers trying to tell the business about this is can be a tough position as business expects to tell engineering what the goals are. Commented Sep 19, 2019 at 15:34

Manual QA should have some test scenarios.

Then you go to:

  • QA to ask which take the most time to test manually
  • BA/SPO to ask which part of the app / functionality have the biggest impact business side / end users
  • dev team to ask which parts of the functionality are least covered with unit and other lower-level (on the testing pyramid) tests and which parts include the most spaghetti code and "monsters be here" code

Based on this three criteria assign numerical value (1-5 points for each category, where bigger number means that automation is more needed) to existing test cases and start with those most valued (e.g 15 or 14 points)

  • I'm not sure if I should write automated scenarios based on that on manual and not even every BA/SPO + dev team could give you a true steps to do automated QA, they can only appoint you to a good directiond; I was reading @Mate Mrše's answers (article on Fowler's site) and its brilliant - steps, pros and cons and, my favourite part - theresnosilverbullet in QA but you should imply every kind of testing to provide a product of quality.
    – Orkhan M.
    Commented Sep 23, 2019 at 10:16
  • It's not their job to give you scenarios (or steps for scenarios!), but their input in invaluable as which areas to cover with automated tests. Manual test scenarios are usually sufficient stepping stone to start with automation project.
    – Prome
    Commented Sep 23, 2019 at 11:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.