Full Stack Testing Done Well
•Download as PPT, PDF•
0 likes•1,390 views
This presentation was given for the Selenium DC & Arlington Ruby co-meetup
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Recently uploaded
Recently uploaded (20)
Full Stack Testing Done Well
- 1. ∞ Full Stack Testing Done ~Well by Dave Haeffner
- 3. Fuhl-stak-tezting v. The act of verifying web functionality through a standard web-browser instance – often by way of automation.
- 5. Slow Setup Neglect Noise
- 6. We have the technology…
- 7. Flight paths, fork in the road, etc - Pic?
- 11. While technology is important, it’s not the most important part. That is to say, you’re doing it wrong.
- 13. ¿Cómo se dice?
- 15. You down with S.R.P.?
- 17. Dave Haeffner @TourDeDave http://tourdedave.com/mycard http://tourdedave.com/slideshare
Editor's Notes
- Thank you to Arlington Ruby for helping to co-organize this meetup – this… colliding of worlds Hopefully this doesn’t turn into something like a West Side Story dance-off – But who would be the Jets and who would be the Sharks? [pause] Oh, and a huge thanks to our sponsor Sauce Labs – they provided the pizza and soda Apologies for the fake-promise of beer – new location, new rules – and I think they’re prison rules – sorry everyone But I digress – on to the talk!
- A little bit about me… I love things in the 3 rd person, so here goes… “ Dave Haeffner is an experienced automated tester, and formerly the Senior Quality Assurance Analyst at The Motley Fool; responsible for creating, implementing, and overseeing their automated web testing infrastructure. He was a speaker at Agile 2010, a co-organizer of the DC Selenium meetups, and is an active member in the Selenium and Ruby communities. Dave has worked with small startups and large government contractors to improve their quality practices.” Enough about me, let’s talk turkey
- Just to make sure we’re all on the same page, how would YOU define full stack testing?
- Based on the turn-out, I rather assume that full-stack testing leaves a bad taste in your mouth I’d like to hear from you why that is Go ahead, yell them out
- Here’s what I had … besides this picture I think we covered a good deal of them Slow runs Ops overhead to get automation going – typically not inline w/ standard tech infrastructure This leads to neglect of the infrastructure and the tests Which ultimately leads to noise
- How are you solving these problems? Do you use Selenium? Do you hate Selenium? Do you use a Ruby gem? Some other amalgamation of technology?
- It used to be that there were two paths to automated web testing with Selenium Record & Playback => limited functionality, and lead to hell Record & Playback exported to a programming language and executed by the RC The latter tended to lead to greener pastures But it involved more technical overhead And test runs were still fairly slow Selenium web-driver has taken some of the bite out of this, but is Selenium worth it? What do you think?
- Here’s my take on Selenium Back in 2009, the book Born to Run was published, in it there was a section on minimalist running Talked about Nike > lead to Vibram 5 fingers and minimal shoes I think that Jason Huggins did the same thing with Selenium by creating Saucelabs Selenium in the cloud, meeting the demands of the market he created by causing them pain
- That’s all well and good, but who on your team uses the tests that are written? Is there manual testing? Who writes the tests? Who maintains them? Who handles the infrastructure? Is the Business Owner involved?
- Pucker up, because I’m about to lay some knowledge on you that some of you may consider heresy Are you ready? [dramatic pause]
- I’ve been asking you all of these questions as a lead up to this moment… Are you really ready? [Dramatic pause] Can I get a drumroll please? It’s more about business value & process. Put another way, it’s how effective you are over how efficient you are But you can get closer to both Here are some ways to scratch that itch
- Place what you’re looking to test into 3, well defined categories – or, buckets 1) Heatbeat 2) Money Makers 3) Back breakers
- Consider a more whole team approach to software quality Acceptance Test Driven Development is a great approach It positions you well to automate
- Make it often, and make it part of everyone’s workflow Build a feedback loop Something central for the whole team to rally around It also gives you a place to offload the heavy lifting
- 1-2 minutes to execute a test suite 1 unique account per test suite 1 test suite can have many test scenarios (assuming it doesn ’ t violate the first rule) 1 assertion per test scenario 1 interpretation of test results
- Run things faster, either in your own internal stack Or offload to the cloud What kinds of solutions do you use for this?
- Take questions here Announce next meet up will be with Arlington Ruby. Details forthcoming. Stay tuned!