This is the way I'd look at this:
A data entry setup with over 1000 fields spread over what sounds like a 12 screen wizard is not a valid candidate for multi-threading. Each thread is still going to have to enter all 1000 fields for a valid end-to-end test.
You do not want to do this more than you absolutely must.
I'd suggest you work it this way:
- For each screen, find element names or IDs so you can fill directly (excellent suggestion from Niels)
- For each screen, determine how much information is passed to and from that screen. You're going to mock this so you can test a screen at a time.
- Use a headless browser such as PhantomJS for the functional testing. The same test actions performed with PhantomJS are much faster because the test system has no need to render anything, and in something this unwieldy, rendering is going to be a significant time factor.
- Data drive and use the page object pattern.
onblur() type event (if the onscreen validation is using
onchange() you should be okay)
None of these suggestions change your core problem: an application requiring this much data entry is probably a bad application. If a developer handed something like this to me, I'd be asking them for ways to cut down the amount of data entry and ways to optimize record creation that did not require so many fields to be used.
I'd be stunned if your users really need to fill in all 1000+ fields. More likely there are groups of fields that should be considered duplicates, a relatively small set that is actually required for a record, and a lot of fields that should be calculated or inferred from other data.