Yeah, I learned by clicking on everything. I didnât realise that the responsive view helps me test css breakpoints until I was clicking about and experimenting.
Click, Right click, and double click on everything!
1 Like
Oh I almost forgot - if you havenât already you may want to check out Umar Hansas DevTools blog where he posts the latest tools within Dev Tools being released by Chrome /https://umaar.com/dev-tips/
Hello, the Device Toolbar I use as a quick test to simulate devices in order to quickly get initial feedback on whether the page adapts based on the CSS media rules applied.
Whilst it may be good to give you a quick visual indication of any potential issues on smaller displays I tend to use the âRemote Debuggingâ within Chrome DevTools (this lives within the more tools menu) if I want to be really certain of how things render on physical devices.
It may be worth looking at something like BrowserStack rather than relying on the device toolbar alone depending on your needs.
Youâve spotted a really good âtechnical puzzleâ. I should really just leave clues so that people would have to investigate the reasons using the dev tools.
ButâŚ
-
What youâre seeing on the left is the actual file
-
What youâre seeing on the bottom is the content type that the server told the browser the file represented, some of the images are sent as âcontent-type: image/pngâ and some as âcontent-type: image/pngâ
As an exercise:
- Right click on the image and choose âopen in new tabâ
- Open the network tab so you can see the traffic
- Refresh the page
- Have a look at the HTTP message and see if you can spot the difference between one listed as âimage/pngâ and one listed as âimage/jpegâ
1 Like
Hey guys, thank you for your time. Youâve mentioned manipulating CSS - can you elaborate on using dev tools to do this? And provide an example of how youâve done that? Many thanks,
Yeah the âliveâ facility on the selenium grid tools might help as well - Saucelabs have a âliveâ plan, and I think some of other grid system do as well.
Agreed - I read that and follow on twitter as well.
1 Like
Hello, for me currently Dev Tools offers me the tools I believe I need. Iâm guessing over the next few months or year though they will release even more fantastic tools which I didnât know I needed 
I find that if DevTools doesnât offer something I think I need Iâll either try to get an extension for Chrome or failing that, if I cannot find an extension for what I need Iâd attempt to make my own or help others develop one.
Thank you 
⌠added padding because post must be 20 charactersâŚ
2 Likes
Hi Adam,
To answer that Iâll have to limit functionality to âwhat would I expect to be implemented in a browserâ. Because I never expected Firefox to implement amending HTTP messages in a browser and if I donât limit it, I could be listing stuff all day
-
HTML, CSS and JavaScript validation could be useful (because the browser has a habit of âfixingâ HTML, and ignoring CSS errors)
-
I find the memory monitoring and performance tools a bit of a hassle to use, they could be simpler. Iâd rather see it real time than creating profiles.
Oh and on that note - Alan has created a cool extension here which I contribute to which you may wish to check out https://github.com/eviltester/usefuljssnippetextension/
1 Like
⌠oh⌠andâŚ
-
Having the tabs viewable at the same time e.g. seeing traffic while browsing DOM
-
JavaScript event hook indicators on the page so I can see what has JavaScript events attached without having to hunt through the DOM view
-
Breakpoints on cookie changes
-
Custom alerts on certain headers
I expect over time some of this will make its way in over time, and some of these are probably available as Chrome plugins if I really wanted them.
Hi Elizabeth,
I listed the addons that I use further up. I havenât tried Lighthouse (Iâll have to research it, thanks for mentioning it).
The plugins are easier to use the less JavaScript heavy the app is. With a JavaScript heavy app, because the DOM is changing so much, I have to remember to use the tools more often.
As I mentioned above, whilst I do use some extensions for non-test related stuff, I think the majority of add-ons/extensions I use are for accessibility testing.
- Lighthouse - I like using this built in audit tool to get quick feedback on potential accessibility issues as an initial check.
- aXe - I like using this add-on to get further feedback on potential accessibility issues
- WAVE - I tend to use this extension to compare the findings within aXe to quickly check some of the accessibility issues the add-ons believe they have found
- Chrome Lens - this is really cool extension for checking to see how people with visual impairments view your site. For example if you have a web form and you rely on colours to indicate errors and do not also display a message with an error this tool would help you identify an issue for a person with a visual impairment. It also offers a built in tool to check how your page flows to ensure it tabs for example in a logical flow across the page.
Hi Penny,
I prefer CSS locators because they work in the find functionality of all browser DOM views. Xpath, only works in firefox (I think)
I only tend to use XPath for extreme situations like navigating back up the tree i.e. finding a child and then traversing up to the parent.
And CSS locators tend to be understood by the front end programmers, and no-one seems to really understand XPath anymore unless you have some XSLT technology in your app.
Hi Penny, I tend to never use XPath but similarly to Alan I could be tempted to use it in extreme cases for example where I couldnât use an ID or CSS locator.
Wherever possible Iâd always try to work within my team to make the UI easier to test by getting unique selectors where possible implemented to help with the teams automation efforts.
Like Alan, I prefer CSS locators. I prefer them because I find they help me write cleaner code when attempting to implement and maintain tests where as XPath can become quite a pain not only in initially attempting to locate the element you wish to interact with but also to maintain that test should the UI change.
Hi Penny, thanks for multiple questionsâŚ
I rely on the official developer site:
But Iâm also trying to use a feature that Viv showed me, which is the release notes link in the dev tools itself. The help menu in the dev tools has links to âdocumentationâ which is the link above and the release notes for the current version.
And I follow the developer tool twitter accounts.
You can see the calls that the browser makes to a REST API via Ajax. Iâve used this to reverse engineer APIs for applications to help me automate my marketing work. These APIs are often not public but are usually stable enough for the type of work I do.
I normally use a Proxy tool for this and make API calls from Insomnia or Postman through the proxy to capture the requests.
I also feed my mobile device through the proxy to see what traffic is being sent over HTTP.
I normally rely on a proxy for API testing. Then I can fuzz the requests.
1 Like
Hi James,
The CSS view are on the right of the DOM view or the Inspect view. And I find it useful to switch on and off different CSS styles.
And I can amend them which is useful when raising a defect and suggesting a potential fix.
It also has the ability in the dev tools to force element state - e.g. toggle hover , active focus etc. Which I find useful for testing and taking screenshots when there is a problem.
And using the dev tools to block requests to prevent CSS being loaded can be useful to see just how much work the CSS is doing.
I literally have all of these installed and can second this recommendation 
3 Likes