@friendlytester and I are continuing to develop our learning journey and we have another question we’d like to ask.
“What aspects of your context impact your testability?”
For example, I once worked on a project where the product we developed was third party application that we simply updated with new features. It meant nearly 90% of the product was a black box to us and any changes we made had the risk of breaking core features. It proved difficult to test confidently when new features were introduced.
We look forward to your answers and thanks in advanced for your contribution
Hi Mark & Richard, here are some of my examples - hope it’s like that you had in mind:
Currently, I am doing yet another project – this one is primarily based on Infrastructure as Code (IaC) and Functions as Services (FaaS) and creating an API engine/event-driven broker. Everything in the API development is higher-order cloud work. While we can automate most - we have to rely heavily on the cloud provider and API platform services.
Similarly, I was working with a life science company implementing a SaaS document management solution. We had to verify both customer-specific configuration and vanilla features. The SaaS solution would render the HTML with classes as guid’s making classic web automation very hard.
A friend of mine is testing conveyor belts, another is testing rail tunnels - when you move into the physical space though with a heavy software component things get less testable. I guess. Sometimes it’s about how big bets your stakeholder wants to take.
Which reminds me of this: How do you test for climbing up Yosemite’s El Capitan 3000 feet / 900 meters?
