How selectors work and what are they

• Selectors (or locators) are only some pieces of text that help us identify something in a document. How they look like, the syntax, is an agreement between the creator of structure and the user.
• I use the word structure instead of document or web page because selectors work for anything. Heck, technically even Regex (Regular expressions) can be considered as selectors up to a point. There are JSON selectors, DB selectors etc, apps structure, excel documents structure etc.
• There is a bit of software called an interpreter which is coded to understand the text of selectors and return some parts of the structure accordingly.
• Same structure can be interrogated by multiple interpreters and will work just fine, as long as the interpreter understands both the syntax and the structure. Each interpreter will have some sorts of limitations that might be important or not to you.
• If all you care is web testing and you want to learn something limited, learn CSS.
• If you want to learn a way of thinking learn XPath, because it will also apply to XML. Many things in this world are XML because it is also used for validating the data contained inside. Is much much smarter and useful.
• Here's a google search string that can help you out with syntax comparison: https://www.google.com/search?q=xpath+and+css+selector+cheat+sheet. Many people have created similar images already. Pick the one that you like most and thank the creator.

Why is the information from one picture different from others?

• Because the interpreters for XPath and CSS have evolved over time and have versions. This is why "Learn the craft, not the tool." . The best is to read about the standards in the official documentation to have an idea about what's possible and just google the syntax when needed.

Thank you for reading the TL;DR section. From here on we will continue with the history of selectors and the logic inside them.

Commonalities and differences between XPath and CSS:

What are XPath selectors?

At their core, they were designed to apply for a communication standard called XML. This XML functions on the idea that important bits start with <> and end with </>. What's between the "<" and ">" signs are called tags. Those tags can have additional strings that explain why the tag is important. Those strings are called attributes. Most of the time those attributes have values.

What are CSS selectors?

When the internet started to become popular, people needed a way to create web pages. So they took the existing XML and agreed on some specific tags. You can find them here. But the main concept was kept: start with <>, end with </>, have attributes.

However

Safety:

XPath was too smart and slow at that time. It was meant for the industry and web needed something fast. If a web page breaks most of the time, no lives are lost. If the coordinates of the metal melting machine or petrol pump have the wrong format, disaster happen.

Features:

For many years CSS was unable to go from child element to parent element. Which was OK, because the idea behind CSS was to make things beautiful and animated and as fast as possible, in order for the public to enjoy web pages. XPath supported functions and it allows the users to operate on a piece of text before searching for that text in order to be robust. For example, it was able to capitalize, lower case and concatenate text. CSS can't do that even today and doesn't have to. The role of this in functionality, in web applications, was taken by JavaScript and browsers.

Using selectors for finding bugs:

Let's start from a list of known facts:

• When a bug is reported closer to the source it is faster for the developer to fix it thus cheaper.

If a bug is found by a selector it means that it comes broken from the frontend framework, backend or database. So that's 3 levels deep. If the same bug is reported by what's going towards the server after your test did things it can also come from the processing inside the frontend application or the processing inside the test. This is 4 levels deep and +1 team involved (the QA to looks at the test).

• The HTML elements are also used by crawlers and third party libraries. The visible text inside the elements, not always.

Something might look good for your website, but it can be broken for someone else in very, very expensive ways. Usually it will affect your SEO ranking and business visibility, the way your website is displayed on a different device or browser, the way your website is displayed for people with disabilities etc.

• The modern frontend frameworks come with custom elements that are not visible in the HTML. They are visible in the DOM and are forced to add many attributes to the HTML elements.

This will make your web page really slow in time. Try to design some selectors that are not affected by this. Write your selector in such a way that tests all the aspects of point #2 but skips as many elements as possible because those can be subject to change when upgrading the frontend framework. This will make your tests faster and more robust.

Conclusion:

1. Stay away from QA software tools that rely on magic selectors with just the words visible on the screen. They look good, but they can put you in trouble in unexpected ways.
2. Pay very close attention to the "self-healing" selectors. They are very good at hiding bugs from you once you get to the habit of "next, next, confirm, OK".
3. If not needed, don't focus on writing your own testing framework, this time is better spent analyzing selectors and bringing value to your company.

Collaborating with developers:

• Organize your selectors in a way that makes sense for you and your team.
  1. Keep them in one document and use a version control system.
     • This way you can see the history of the changes and revert them if needed.
     • You can also see who changed what and when. This is very useful when you have a team of people working on the same project.
     • You can also see the differences between the selectors and the structure of the web page. This is very useful when you have a team of people working on the same project and you want to see what changed in the structure of the web page.
  2. Or keep them in the classes where the logic of the test exists. This way changes can be more granular.
• When the selectors get complicated and you need to use functions, try to use the same functions as the developers. This way you can ask them for help if needed.
• If possible ask your developers to add specific IDs to the important elements.
  1. This way you can use the IDs in your selectors and the developers can use the IDs in their code.
  2. This will make the code more readable and easier to maintain for both of you.

Conclusion:

1. Stay away from QA software tools that keep the selectors inside the tests. They look good at first but become a nightmare to maintain in time due to duplication.
2. Don't keep your selectors private. Use a QA tool that promotes collaboration and transparency. This way you can ask for help from your team and you can help them when needed.
3. Avoid tools that don't support concatenating selectors, functions and inserting values into your selectors. They will fail as soon as you encounter a calendar, a table or a list.
4. Avoid tools that don't support the latest versions of XPath and CSS.
5. Don't believe the narrative that testing and development are decoupled and that you can use hardcoded values for all your tests. They are not. You will end up in a situation where you cannot apply your test to a production environment and your tests cannot be run over a new environment or database. Or you will need resources for upgrades and your QA team will become expensive, thus at risk of being replaced.
6. If your project is multi-language include the value of the translation in the selectors alongside the value of the important attributes.

Collaborating with marketing:

• Understand from your sales/marketing team which HTML tags and attributes are important for their partners.

Everyone sells or buys data in one way or another. Make sure their HTML tags and attributes are targeted by your tests and that they are not affected by the frontend framework.

• Understand what elements they rely the SEO and marketing campaigns on.

Help them be in a better place when they want to try something new from a third party tool. The same IDs you use in your tests they can use in their campaigns. This way they can be more independent and you can focus on targeting more customers.

Conclusion:

1. Stay away from QA software tools that hide these aspects from you, because you will not be able to serve your team at the highest standard.
2. Integrate their third party tools in your tests with the correct conditions. This way you can help them and they can help you.
3. Make sure your website or application becomes functional and visible for everyone as soon as the marketing popups have been closed.
4. Make sure your website or application continues to load and function even if the marketing popups do not load properly.
5. People DO USE add blockers, make sure your website or application continues to load and function even if the marketing popups are blocked.

Collaboration with the business:

• Understand if your business has to generate some XML/JSON/CSV files for the partners, reporting tools or integrations.
• Understand based on their documentation, not your implementation, what are the restrictions for the tags and attributes.

Conclusion:

Pick a tool that can help you test the structure of the files you generate.

Collaboration with the QA team:

• If possible, don't rely on a tool that is focused on coding if there is a codeless tool which serves your needs.
• It seems to be a good idea to head into coding, but understand that such a tool will increase the cost of your department, will make you dependent on the developers, and in times of crisis your team will be among the first which will be downsized due to many reasons.

Credits:

• Initial text: gabriel@qality.tech