The only path I have cared about is the path of experimenting and gaining knowledge.
Giving cute names to “manual testing” by itself does not solve the core of the problem – the problem that testing done in this manner is not just thought of as “less technical” than the fancy sounding counter-parts; it is more often than not, treated as less technical by testers themselves. This is despite the fact that the more complex the testing problem is, the more likely is that it needs human intelligence.
You want to call it human testing, brain-centric testing, neurological testing or just testing – your wish – now, focus on the real thing that matters -> knowledge. I can empathise with the reasoning why some testers object to the term “manual testing”. I myself do that occasionally. The difference is that I don’t stop there and I don’t keep intervening. I let the discussions proceed on the core discussion.
If you are engaged in “manual testing” and dealing with a web application via its GUI, here’s a partial list of items for your consideration even at this user-centric layer:
1. Start with the interface – different types of GUI components, navigation areas, divs, widgets and their relationship to HTML. Study types of embeddings in HTML (CSS/JS/IFrame/Img).
2. Different types of events that a user interaction can trigger – keyboard, mouse events etc and what are the handlers for them in the interface.
3. Find the type of validation mechanism: Is it client side? Is it server side? HTML based? JavaScript based? Is there a regular expression involved?
4. Understand how Browser works: Focus first on the three primary components – a DOM parser, a downloader for embedded resources and a renderer. Study how this sequencing works behind the scenes in displaying a web page to you. As a bonus study the difference between DOM and SAX style of XML parsing. Ask yourself, why browser chooses DOM? When would SAX be saxy? (sorry couldn’t help the joke).
5. Understand which parts of your web application use AJAX and web sockets. Unlike bound methods, these have a vague relationship with when a user action takes place vs when an outcome is experienced in the browser. With web sockets the interaction can be flipped (server -> browser) along with the more common browser -> server communication.
6. Study the network sequence using DevTools in the browser, cookie mechanism, caching (and its types for different resources in a given page).
7. Are there embeddings at the end of the HTML Page? Why aren’t they in the <head> section? Dig deeper. Study lazy vs greedy loading.
and so on.
Relate the above information to the way you are exploring an app during testing. I deliberately picked the GUI interface, because the role of technical knowledge is extremely downplayed at this layer. As you go into deeper layers, this approach will serve you even better.
Rahul Verma: My Petty Bits 
Leave a comment