Talk in TSQA 2022 - Matías Fornara and Federico Toledo
Automation has gone from optional to mandatory in the past few years when it comes to developing software at speed. It has led teams and especially testers to adapt and evolve together with new technologies for coping with the automation needs.
No matter the original motivation, you might have somehow ended up crafting a strategy for doing test automation.
Now the question is, how did it mature? When was the last time you actually took a moment to do a little retrospective regarding your automation strategy? More so, when was the last time that someone reviewed the scripts themselves?
We will share our experience reviewing the test strategy of multiple projects and teams, paying special attention to the quality of our automation efforts. By doing this we will try to show you how every detail counts, since asking the right questions at the right time, validating the way we are picking our selectors, making sure there is proper communication between the automators and the rest of the team, to taking a step back when it is necessary, to assess the current situation and how could be improved if it could be or changed towards a different direction.
TSQA - Improving test automation code and strategy
1. Improving test
automation code
and strategy
Matías Fornara
@matiasfornara
matias.fornara@abstracta.us
Federico Toledo
@fltoledo
federico@abstracta.us
2. Automation: pros
and cons
“The first rule of any technology used in a business is that
automation applied to an efficient operation will magnify
the efficiency.
The second is that automation applied to an inefficient
operation will magnify the inefficiency”
Bill Gates
6. Abstracta Blog: How to Create the Right Test Strategy for Your Project
https://abstracta.us/blog/software-testing/how-to-create-the-right-test-strategy-for-your-project/
Review your
testing and
quality strategy
8. If I cannot test something in a specific layer,
only then, go up.
A test goal could be accomplished moving the
test script to a lower level?
Synchronize “manual” and automation efforts:
What can we reduce, move, change?
A good use of the model:
Avoid duplications and rework
Quality Sense Podcast:
The role of test automation in Calendly’s test strategy
9. End to End
vs UI tests
- UI tests as unit tests for the UI
- End to End (all layers, atomic tests)
- Smoke tests, complete flows
https://martinfowler.com/articles/practical-test-pyramid.html
Martin
Fowler
10. A classic misconception:
End to End tests
End to end scripts, conceived as automating
a user flow, a very long user flow
If something fails, I need to re-run the test
and it can take minutes, several minutes.
Because a problem with the test design
11. Exploratory testing
at all levels
We can’t explore well without automating. We can’t automate well without exploring.
https://blog.testproject.io/2021/04/20/contemporary-exploratory-testing/
Maaret
Pyhäjärvi
12. - Unit tests are for developers
- collaborate, pair,
- assess risks and mitigate them in
top layers
- Mocks, it’s not that hard as it seems,
and can help to improve stability
More
considerations
13. Which tool is the best fit for your context?
Open source vs Commercial
Cover our needs?
Test Environments
Devices, platforms
Pipelines and CI/CD strategy
What, when, reports, traceability, environments
Other aspects of the test
automation strategy
Quality Sense Podcast:
Involving devs in the quality process
15. Are we aligned on the
expectations we have
from test automation?
abstracta.us
16. Collaboration challenges
How are we defining what to automate?
Who is involved in making this decision?
Tools (Task/Test Case Managers, other collaboration tools).
Are they helping us to give visibility to our work?
Is our test framework well documented?
Who looks at the execution reports?
17. What else can we do to bridge the gap between
product definition and automation?
Gherkin, a possible solution
BDD
(Behavior Driven Development)
Cucumber
JBehave
19. Guide, working agreement on
practices to follow
Version control.
Best Practices:
- Naming conventions for branches, packages, classes, operations.
- Design patterns.
- Emphasis on making a DRY (Don’t Repeat Yourself) and DAMP
(Descriptive And Meaningful Phrases) code.
- What to avoid?
General recommendations:
Don't trust a test you haven't seen fail!
20. Treat your test code as
production code
Peer review: quality control review by someone other
than the author.
Capturing errors on early stages, spread knowledge.
Recommended: Angie Jones article.
21. Is the test specific?
Pair Review Checklist
Does the test verify
what’s needed?
Can the test run
independently?
How is the test
data being
managed?
Is there a
separation of
concerns?
- GRASP
- Clean Code
Is there anything
that can be
modularized and
reused?
Are the selectors
reliable?
Is the wait strategy
solid?
22. Keep our technical debt visible and follow up on it.
Define Quality Profiles suitable to our language and objectives.
Define realistic Quality Gates and adjust them regularly.
Use it both remotely and locally.
23. What about low code tools?
Most of the practices also apply to low code tools!
Peer review.
DRY Tests:
Parameterizing.
Modularizing and grouping common steps .
Naming conventions.
26. 6
Offices
worldwide
+100
Quality Engineers
+13
Years in the
market
95%
Customer
retention rate
+400
Projects
We are an agile software testing company
that applies highly sophisticated
engineering and automation processes to
its testing practices and the software
development cycle, focused on increasing
product quality and reducing time to
market.