Best documentation to start with before starting Automation

Question

We are integrating with an out sourcing team to start automating our regular test cases What is the best type of documents to explain our scenarios to the other team?

we want to explain to them how each module work; in each scenario there are use cases, do we have to explain these use cases in details? and what if one of those modules has a fully integration with the other modules, should the document mention everything in details?

we are documenting everything like the next example:

Scenario one:

• add user [use case one]
• active user [use case two]
• search for items [use case three ]
• . . . .

then we list all the steps in every use case using a template, we mention all steps, involved pages, what type of users are involved

do you thing that is informative?

Answer 1

The best advice I can give you is to ask the other team what information they need to be successful. I've been in the opposite position where I'm supposed to automate tests others have made. Aside from this being a bad practice, creating too detailed documents or creating the wrong details will only waste both of your teams time.

Send over what you have now, what you've created and then see what they respond with. You'll never know until you ask. They might want something closer to BDD specs then actual tests. Good luck!

Answer 2

First, I want to echo milinpatel17 's answer. If they are not cooperating NOW, at the start of the process when people should be psyched about it (see http://www.1000advices.com/guru/project_mgmt_7phases.html ), how would they be a few month into the project?

Specifically to your question: If you give them the scripts you now run manually, you will get an automated version of the scripts. But this is not efficient and not scalable. What you want is to re-think the test strategy with automation in mind. Think of types of actions you need automated (later, a number of actions will be put together into tests). This way the automation framework will be more modular, and allow you to bundle a number of action calls in a row into a test.

Think also in term of flows: The automation system should help you create possible flows through the system. Some of these flows are the tests you already have. But you don't have a whole lot since scripting flows for manual testing take a long time. If your automation system has flow building blocks (these are the "actions" mentioned above), and a way to specify a number of these via a text file, you now have a way to create many more flows than you had before, and can find all kind of assumptions the developers did on the order in which things HAVE to be in order to work well.

I like to compare your situation to Disney's "the sorcerer's apprentice" (https://www.youtube.com/watch?v=T8gOh0wEgLg). Is moving water from one place to another is best done with - albeit automated - pails? Automation allows you to think of totally different ways to achieve the same result. A pipe and a pump for example - which is way more efficient.