- Inspect Element
- Find the src attribute of an image on a page
- Edit it to the url of another, different image
In my Sigist slides you’ll find some ‘tips’ for improving your web technical skills which cover this type of skill.
Asking and investigating:
- How is the site doing that?
- What are the risks of doing that?
- Could you test that?
- Do you understand it?
I find that interesting. They have a different core set of beliefs underpinning their approach to testing than I do. They test differently, but it means I have to explain ‘why?’ for something that I do ‘because’.
I have studied the testing domain. I’ve read a lot of ‘testing’ books and have a fairly sound grasp of the testings techniques, principles and the many, varied reasons, why we might test.
None of those books, described the technology of the system.
Very few of those books used the technology of the system as a way of identifying risk.
Risk tends to be presented as something associated with the business. Business Risk. e.g. "Risk of loss of money if the user can’t do X".
I spend a lot of time on projects understanding the technology, to identify risk in how we are using the technology and putting it together.
- If we are using multiple databases and they are replicating information across to stay in synch, then is there a risk that a user might visit the site and see one set of data, then the next visit see a different set (because now they are connected to a database that hasn’t had the information replicated across to it?).
- Is there a risk that something goes wrong when we visit the site and it is pulling out information from a database that is currently being synched to?
If people do know, and we have ‘strategies’ for coping with it - our load balancer directs the same user to the same database. Are there any risks with our implementation of that strategy? Will our test environment have the same implementation? Could we even encounter a manifestation of this risk when we are testing?
As well as knowing the requirements. I want to understand the pieces, and how they are put together.
Because I know from putting together plastic models as a child, or flatpack furniture as an adult, that there are risks associated with putting things together.
I have to learn about technology to do this. I then have to interpret that technology with my ‘testing mind’ and in terms of the system of the project I’m working on.
I suspect that is a better ‘why?’ answer; for learning the technology, and the associated technical skills, than my more flippant:
- Q: Why would I use this?
- A: Well, if you don’t have the skill, you never will. If you learn it right, then you might.
You'll find some simple tasks to help expand this in my Sigist slides