How to automate functionality of this complex web application?

Question

I am tasked with creating regression suite from scratch for this huge, confusing mess of a software.

General idea is like this:

1. User presses "Create this thing", first step of thing creation is displayed, user fills many boxes, dates, checks many checkboxes, if everything is OK, user can proceed to step two, adds different information relevant to step two, refines existing from step one, uploads some data, moves to step three, etc.
2. In total there are 12 steps, each step depends on previous one in what data to display, what options are available for user etc.
3. Its not possible to open step 9, and check how that works. You need to either open existing thing that is left at step 9, or create new and move through all the steps.
4. New features are added to existing steps. Like, in step 8, tool is added that lets user do some stuff, affecting some other steps. (main manual testing happens testing these features)
5. This workflow is further split by sub-workflows accessible in specific steps (again, depending on general data entered in this thing)
6. All these things after creation (starting from step one) are grouped into tons of reports, moved to different systems etc

It's all weird business logic that doesn't really make sense to anyone including users and new features adding further complexity just keep getting thrown on top of it.

My problem and question is this: How do you automate functionality of this?

So far, my approach, using webdriver/c#/nunit has not been very successful, due to following reasons:

• [Test] methods are supposed to be simple- test one thing, assert something. I cant assert one thing. Because if that stuff I need to test is in step 5 and only accessible if I did something in step 3, my small simple test needs to "Create new thing" , and move correctly through all steps up to 5. Oh. And then create another and fill different data in step 3. And now my simple test is huge.

• [Test]s are supposed to be independent. I cant do tests that test one thing, then pass some data to [Test]2 etc and move thorough steps in that way.

• Management wants to automate User stories. "Button move to step 3 takes you to step 3" type. Useless, because you can always move to step 3 if you press the button, what matters is what happens during transition and what happens depends on various data entered in previous steps. Ahhh.

So to at least try something I try to organize tests like this:

1. Describe elements in one place according to where they are found. Describe all common used methods in one place. Like PageObect model.
2. Create huge "Create thing" function that takes many arguments, like what data to input in which step, at which step to stop and automates creation without really testing anything. And various others that automate some functionality depending on arguments passed but don't test anything themselves.
3. When creating [Test]s I call functions that create and move thing through workflow first, with arguments that I need for that specific test. Then I manipulate some data and make assertions for that specific feature that I got to.
4. So now my tests are kind of small and independent of each other BUT in reality they do a lot of crap and take a long time. And are horrible to debug.

Answer 1

I imagine your application to be somewhat analogous to an auto-insurance website.

Page 1: Fill personal info
Page 2: Fill vehicle info
Page 3: Fill previous insurance history
Page 4: Choose insurance type
Page 5: See Quote

There are validations to be performed in each page but you cannot move onto 'Page 2' without filling 'Page 1'. The approach you listed seems to be ideal for the scenario. You will actually test the business flow every time. The additional execution time will be the trade-off. I don't see a problem in the maintenance aspect though, since everything is still organised.

I could not think of any better approach that would not skip the UI layer. But if you have an option to skip UI layer in certain test phases, you could go with other frameworks. Example, if 'Page 2' uses a webservice, you can test it directly just by passing dummy 'Page 1' values.

Answer 2

Preparation and planning is the key.

"If I had eight hours to chop down a tree, I'd spend the first six of them sharpening my axe."

1. Try to create a quick map/sketch of the workflow
2. Define small methods/actions/steps that are reusable (in this case at least 12 steps)
3. In your defined methods use switch to decide when to change actions/data used
4. For every method use optional parameters or define default cases
5. Do not validate/check to many things in the action steps, rather define separate validation steps
6. Use variables to check some conditions and execute actions if needed
7. Use Page Objects if possible to create scenarios to make things more simple
8. Define simple methods/steps to have something functional and improve after
9. Write smaller test that you can combine later
10. Define some scenarios, start implementing after

If you don't have any plan you risk to create a test/suite that is hard to maintain, is not stable, is not efficient, you could waste some time rewriting the tests, code is hard to understand.

Answer 3

Yes, your app is designed in a way it is really hard to test by a E2E script. Let's hope you started by having plenty of unit tests.

Use page object to provide services to your test. Then, start with creating few "happy path" tests exercising most commonly used functionality.

When done, start adding functionality which interrogates page object in which status it is (what happened after some action) and what should be done next. Yes, it is lots of complicated business logic duplicated in your test code. Yes, it will be fragile and hard to maintain. It is designed that way.

When you are frustrated, repeat to yourself: it pays the same per hour. And look up that website (c2.com, the first original wiki), it is exhaustive repository with 20 years worth of programming wisdom, like life strategies.