Ioana Bucur
Test Automation Engineer
Who I am
I am a young professional who has been working in GUI test automation for over 5 years.
In my various projects in various industry branches across different countries (Romania, Germany and Switzerland), I have encountered one constant value that holds true: communication and common understanding is the key to cooperation.
What I do
I write software which tests other software.
Who I work closest with (stakeholders)
- Manual testers and test automation engineers
- Test managers
- Requirements engineers
- Developers
- Project managers/product owner
What methodologies I use
- ISTQB knowledge base and testing practices: The ISTQB (International Software Testing Qualifications Board) web page is a good place to start in order to become familiar with the general testing practices, techniques and vocabulary. Knowing the theoretical aspects of testing allows you to tailor that knowledge to each specific project.
- BDD (Behaviour-Driven Development): Writing tests that can be understood at first glance by anyone, regardless of their technical background is very useful, especially in agile teams.
- CI (Continuous Integration): It is a great way to get quick feedback about your tests.
- Scrum, Kanban, SAFe: Whether you like it or hate it, agile is here to stay, so it is vital to understand how some of the most popular agile methodologies and frameworks work.
What additional skills I need to have
- Good communication skills & empathy
- Perseverance
- Attention to detail
- Inventiveness
What tools I use
Some popular tools and frameworks used for GUI testing include:
- UFT (Micro Focus Unified Functional Testing)
- Squish
- Ranorex
How they work
These tools are able to recognise and interact with the elements on the user interface and trigger events in the same way a user would.
They make it possible for the test automation engineer to simulate user behaviour on the screen of a device by clicking buttons, typing in text, scrolling through a table – without actual human intervention.
What programming languages I need to know
Depending on the tools and technologies used, a test automation engineer needs to be familiar with various programming languages and frameworks.
The primary language needs to be the one used to write the automated tests.
When choosing a language for developing your tests, you need to keep in mind what testing tool you are going to work with and make sure they work well together.
It would make little sense to develop your tests with Java if your tool is based on .net technology.
Another important aspect to consider is the technologies used for the GUI.
All good automation tools have their custom APIs (Application Programming Interfaces) to help you interact with the GUI elements, but understanding (at least on a basic level) the native technologies used for the GUI is going to help you take your test automating game to a whole new level.
Some programming languages I have used to develop tests include Python, C# and VBScript. Additionally, understanding Qt, HTML and JavaScript frameworks and being able to access native methods has helped me overcome some of the limitations of the test automation APIs and build leaner and faster tests.
What challenges I face
- Unstable environment: Agility is great, but when there are daily or hourly deployments and the environment is inherently unstable, it is very difficult to build and execute reliable tests.
Possible solution: Propose setting up a separate, more stable testing environment where you can develop your automated tests.
- Elements on the GUI cannot be recognised: Test automation tools recognise buttons, tables and other elements on the GUI by using a set of properties such as the element name, the position on the screen or the text contained by the element.
As a best practice, front-end developers usually give unique names or IDs to the GUI elements so they are easily identified and distinguished from one another even if changes are made to the screen. Testers can use these unique identifiers in their automated tests to recognise and interact with the GUI elements.
Possible solution: If this is not the case, you need to get together with the development team and set up a naming convention for the GUI elements so they are more easily accessible.
If this is not possible then you need to get creative. Some knowledge about the technologies used will help you with that. Explore properties such as the element’s position on the screen, its size or the instance number. However, when working with variable properties, keep in mind that they will change when changes are made to the screen, so your tests will need to be adapted as well.
- Restricted API functionality: Sometimes the functionality the test automation tool provides does not meet your needs.
Possible solution: Having a good knowledge of the GUI technology can save you in these cases. Try exploring the native methods and properties of the GUI elements to find a solution for your problem.
- Security policies and user rights management: Your testing tools and/or test users might need special rights in order to be able to perform certain actions.
Possible solution: Tight communication with the security officer and the user rights administrators is needed to overcome these issues.
Conclusion
In the agile, constantly changing environment of IT, good communication and a shared understanding is vital for the success of a project.
I encourage everyone to talk openly about their daily work and to listen to some of the challenges their colleagues face every day.
By doing that, we might be able to build bridges across departments, teams and even organisations that will help us overcome those challenges.
Glossary
GUI – Graphical User Interface
UFT – Micro Focus Unified Functional Testing
ISTQB – International Software Testing Qualifications Board
BDD – Behaviour-Driven Development
SAFe – Scaled Agile Framework
API – Application Programming Interfaces
HTML – HyperText Markup Language
VBScript – Visual Basic Script
IT – Information Technology
