We had a great time with the technical testing circus last night and I wanted to get a place for the fantastic hosts to update you all on their materials and how you can learn more on their topics.
Last night we were lucky enough to have 6 stalls including: @danielbilling exploring an insecure site to look at vulnerabilities @deborahlee speaking about accessibility testing @simon_tomes using Test Buddy to support exploratory testing @sjwatsonuk manipulating HTTP requests and responses with Fiddler @syed.ali showing how he uses OBS to enhance his exploratory testing
and me! Looking at how tracing with jaeger can support observability
Thanks everyone for making the time to come out and keep an eye on this thread for whn those great people update with some follow ons
Me first! I was super excited to share about observability as it is a fairly new term for people. If you want to learn more about the term check out Cindy Sridharan’s article here.
I used the idea of a spectrum from white box to black box testing to compare when a system makes it easy to understand what is going on inside (white box/observable) to when you only know inputs/outputs and it is hidden how it works which makes it hard to debug (blackbox/not observable).
From there we talked about Monitoring, Logging and Tracing as the three key ways to consume data from a system and to therefore make it more observable. Since Tracing is often the least well known I decided to showcase an example of this. Remember, you can think of tracing as watching a pinball machine. When the ball enters the machine you have the ability to watch it ping and pong around on the inside which is like when a requests pings and pongs around to different services. Tracing is just the log of all this movement.
The demo was just an implementation of this fantastic blog by Yuri Shkuro which created a Jaeger UI which is one of many awesome projects from the CNCF. It also shows how to spin up a test application to actually watch clicks on the browser turn into traces.
In some of the groups we spoke about logs vs events, or in another way, how to make tracing even more helpful. This is the blog by Charity Majors that really explains the difference and why it is important.
Hopefully you all can get a chance to look through this and give it a try. Feel free to reach out if you have any questions or observations as I am excited to get more QAs tinkering with this stuff!
Charters give structure and focus to your exploratory testing efforts. Think of them as an alternative to test scripts, test cases and randomly trying stuff out. Combine a charter with a time-boxed session (15 to 90 minutes is a helpful time) and you’ll have a good enough constraint to discover useful information worth sharing with your team.
Explore <target> with <resource> to discover <information>
So imagine you need to explore this Parking Calculator. You don’t have the spec or access to the developer who built it. How do you start testing?
Here are some example charters:
Explore the Lot selection feature on Chrome Desktop with different input methods to discover information related to accessibility risks
Explore the Lot selection feature with Chrome Desktop and Wave to discover useful information related to accessibility risks
Explore the parking calculator app with Fiddler to decrypt https traffic to discover security risks
Notice how you can swap out the <target>, <resource> and <information> in any number of combination. You could start with any one of those to drive the other two. For example, you might consider Chrome Dev Tools as your resource with knowledge that you can discover useful information about network and logging activities.
Log in to TestBuddy (create a free account if you don’t have one)
Capture 3 of your own charters including at least one of the tools you learnt at the Technical Testing Circus – just add it to the <resource> part of the charter
Set a timer for each charter
Start the timer and go explore! Capture notes describing what you discover
What will you discover today?
If you’d like to chat more feel free to comment here or send me a direct message on Twitter via @simon_tomes.
Fiddler is a web debugging proxy tool, which basically allows you to track your network traffic.
We started looking at the Fiddler UI, selecting the F12 ‘Capture Traffic’ option and did a test of the BBC Home page, looking at it from a Performance perspective. We interrogated the requests to see how many there were, and looked at the timeline tab to see the total page load time.
We selected to decrypt HTTPS traffic, and tested trying to log on to the BBC page using invalid credentials to see what response was received. We also looked at the cool feature which allowed us to take a request, drop it into the Composer tab, and manipulate the request to resend with different logon details, and try a variety of combinations without having to use the browser.
As well as testing at a UI level, point Fiddler at a web API endpoint and validate authorisation tokens to ensure that the endpoint is only available with the correct token, accepts the request in the correct format and then sends the correct response back.
Its a free tool, easy to download and install, so why not have a play with a site you are familiar with - you might find more requests and responses in the browser than you realised!
Feel free to contact me on Twitter @sjwatsonuk if you have any questions.
My session was based on accessibility testing - spreading awareness of it, sharing how it can be easy, cheap, simple and very valuable and some tools you can use to help
Improving accessibility actually improves the experience for all users, not just those with disabilities. If you can’t read some text easily, it’s likely people with visual impairments are struggling even more so.
• Disabilities can affect vision, hearing, brain and limbs.
• It’s the company, developer and tester’s responsibility to make the content as accessible as possible.
• Many tools to aid with accessibility testing are free, and many solutions do not take much time or effort. This should help pitch the idea to management.
• Some of the issues we looked at affected the following aspect of websites/applications:
o Text size
o Text colour
o Text format
o Alternative text
o Navigation method
