I was reading "Growing Object-Oriented Software, Guided by Tests" lately.
Authors of this book sugested to always start developing a feature with an end-to-end acceptance test (before starting TDD cycle) to not loose a track of progress and to make sure that you're still on the same page while unit-testing.
Ok, so I've start writing a veeeery simple application in python+django just to try this approach out. I want User to be able to ask a question via contact-form, the question should be then stored in a db, and a signal after completion should be send to notify mailer which will send follow-up message.
Question is - how you'd approach this first end-to-end test in this case? Do you have contain all possibilities in this first test, or maybe I'm misunderstanding this whole technique. 
Any examples would be most welcome.
You don't have to contain all possibilities in acceptance tests at all - you will still write unit tests. So I would say that a single tests "user can fill in the form, save it and load it back" is enough to start with. Then you can add more tests if you think that a particular aspect of your system is important enough that it needs an acceptance tests. Don't worry about handling all possibilities here, you will still write tons of unit tests where you will test everything!
The easiest way to start is to grow your acceptance test in parallel with the code: so start with testing that the user can input data, implement it until it stops failing, then add to the test the condition that the user has to load this data back etc. It will take a while to implement the initial infrastructure for the acceptance test, before you even start writing production code, but you can't escape from it anyway, and there are various benefits to have tests upfront.
"Zero Iteration" - end to end acceptance test in simple contact-form feature