Introducing testers to HTTP and Fiddler?

We really need to get our testers into using Fiddler to determin page size and site speed as part of their pre release testing process. I have sat with some of them to talk about fiddler but I'm looking for some easy to understand resources for learning Fiddler.

More importantly I think it might be ideal if I can find an easy to read resource that will explain the role of http in using the web what the difference between http and the browser is (maybe explanations of the http and upper layers but in a way a tester can understand).

Does anyone have any suggestions or resource links?

Our testers 开发者_StackOverflow社区are mostly from the point and click UA testing school rather than the more dynamic end of things. All help greatly appreciated.

thanks,

b

---

A video well worth having them watch is PDC 2009 session on Fiddler by the Author of the product Eric Lawrence.

---

If you want your testers to do this then it would be better if you set up something like ShowSlow with Yslow and when they are working through the site it will automatically record the data for you. This will remove any potential issues for them forgetting to do this step.

If you want to automate the process you can use Selenium and YSlow. I did a talk last year at Google Test Automation Conference where I discussed the process of doing this. The talk can be found here

---

If you're only looking to ensure page size is reasonable then I don't believe that knowledge of HTTP is necessary. You're better of training them on yslow or google page speed. These tools provide a higher level view of why a page is loading slowly and what can be done to mitigate it. All they need to know about HTTP is that bigger pages and more requests = slower loading. That is true for all network protocols, though.

---

A good resource I started with was Whittaker's "How to Break Web Software: Functional and Security Testing of Web Aplications and Web Services". This provides a good introduction to performing Web testing "under the covers", so to speak.

While, more geared to debugging, this PDC presentation ( http://microsoftpdc.com/Sessions/CL25 ) may prove to be a nice intro to Fiddler for your QA folks.

---

No matter what tool you are introducing into your organization it's good to have some basic Software Roll out concepts in mind while doing this. There are a lot of resources out there describing software roll out plans and although most of them describe how to introduce software in organizations with hundreds or thousands of users there are things to learn even if we are 'only' talking about a dozen or testers or so.
Some ideas that I think might fit you are:

Evangelist
Talk to testers and try to find one or two people who are more interested and enthusiastic about the Fiddler idea then the rest of your team. Give him/her/them time (payed working hours) to learn more about tool and to do a presentation about it to the other tester. Make sure it's someone that the other testers know and respect.

Pilot
Do a pilot project ( who better to be in charge of this than your Evangelist/s ) as a proof of concept. The pilot project should be limited to a small part of a system and the test should be of the nature that you can throw away if it does not work out. The pilot could be time-boxed and there should be an evaluation with the whole team afterwords. This will give your organization some experience in Fiddler and learn to avoid the big beginner mistakes. And it will, hopefully, show the rest of the testing team that Fiddler (or what ever tool you choose) is pretty cool and get excited about it.

Training
Of course you should dedicate time to do training properly. Just saying "read this easy to read document then start testing" is probably not going give much to the testers. Buy books on Fiddler. Let your Evangelist have a 2-hour "getting up and running with Fiddler" tutorial.

Incremental Roll out
Instead of going for a Big-bang approach where you tell you tester to start using Fiddler to test everything you should start with only limited number of test for the first release. And then you make some more tests for the next release, and maintain the first once. After a few releases you'll have a whole heap of stable and good tests using Fiddler. This way it won't take to much time of the tester so they can still do their other testing.

Read More
There are plenty of articles about software roll out plans on the web that can help you with this.

Hope this helps /Jonas