Takeaways from Alan Richardson’s “Technical Web Testing 101” online course

Alan Richardson has a “Technical Web Testing 101” online course over at his CompendiumDev site. I think it’s been there for years but I only found out about it recently. I took it and I’m really glad I did. Some of the content I was already familiar with before, but I still learned a lot from the course. I’m recommending it for software testers who frequently test web applications, including APIs, since they’re the ones who will directly benefit from enrolling. It’s not free, but it’s not expensive either and its value is really well above the price.

Some takeaways:

  • Alan explains to me that technical testing is not the tools, or automation, or the techniques. Those things are only side-effects of exploration and learning what we have explored. The goal of technical testing, from what I gather, is having deep understanding of the application under test by learning the technology stack which the app uses and studying those technologies so that we can find more effective ways of testing, augmenting our usual user interface tests.
  • There are ways to create presentation slides and PDF files simply from text files formatted using a markup language called Markdown. This is interesting, as this enables us to maintain a single source of information for various file formats.
  • We tend to forget the viewing of page sources when testing web applications because we prefer using the more powerful browser developer tools. But sometimes they’re really useful too.
  • Burp Suite, Fiddler, and Zed Attack Proxy (ZAP) are great tools for learning in more detail what actually happens in the background when we use web apps, for understanding what HTTP requests are being passed by the software to the server and how server responds to those requests. They are especially useful for bypassing validations in the user interface and replicating requests easily without physically going back to the application.
  • It pays to learn a bit of Javascript scripting for purposes of validating whether javascript functions properly do what they need to do or not. And many of the web applications that we test these days contain some amount of javascript code. It can be fun to use them too – we can build page-specific bots we can just save and call anytime within the browser through snippets.
  • Wireshark can be used to view digital network traffic in public places.
  • As long as they’re on the same network, a desktop or a laptop can view/interact with an android or an ios phone through a proxy. Network traffic passing through a phone can even be recorded on Burp Suite or Fiddler or ZAP.
  • Alan has reminded me that there’s still a lot of books about software testing I haven’t read yet, and I should make it a point to go over them in the coming months. He’s also recommended spending some time glossing over books about psychotherapy.

Needless to say, the biggest takeaway from the course is understanding how Alan approaches software testing in general, which is something I advocate. That’s how I actually do my testing, although I don’t think I’m up to Alan’s standards of being technical yet. The process is difficult because it forces us to think so much more about the applications we test and the methods we use for testing, including getting better at analyzing risks and decision making, but rewarding in itself because we are able to understand a lot more about how stuff work which in turn helps us appreciate the processes behind software development and the people too.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s