I wrote my first reference to E2E back at the Hotsos Symposium in 2009. Quoting that blog…
|“I was thinking we would then as part of our DOE, try to understand E2E response time from the Client to the Web/App to the DB layer and visually overlay response times with the diagram. This would be a great way to show design anti-patterns in a quantifiable way.”|
The whole point of using the term E2E was to explain end-to-end response time and resource breakdown for the purpose of identifying software anti-patterns. I had the right idea, but it was the wrong term.
What I really meant to say was EoE (EoE=Execution of Experiment). Patrick helped me realize this recently that E2E just didn’t make sense because it implied everything was End 2 End, meaning a UI experiment was required. Not everything requires a UI experiment. Some experiments are run by non-UI mechanisms and therefore it might cause confusion.
So the solution going forward is to change E2E to EoE. The execution of experiment is intended to be a full analysis from end to end, but the dependency on a UI simulation is really driven by the test type and approach.
There are a few things missing with our DoE’s right now. First, our DoE’s do not necessarily have goals. By goals I’m really talking about non-functional requirements for performance and scalability. I think we need to address this gap in Sprint 7 going forward so that we have a goal to strive toward and then attempt to go beyond. Otherwise, how do we really know when the DoE is complete?
The other thing that’s missing is our testing approach. We should really justify why we are going to use a particular test tool. I was talking with Patrick the other day and I had mentioned that we have all of these different ways to run a test. We could run a Selenium test. We could execute a batch script. We could run a JUnitPerf. We could run a SQL script. We could even use LoadRunner. I’m sure the team is laughing at that one because I’ve been against using LoadRunner for DoE tests. I now want to make it such that any tool (so long that it could automated from Galileo) can be used for EoE as long as we justify it in the DoE. We really should justify our test approach in the DoE document.