Q: 10
You are working on a TAS for standalone application. The automated tests are developed based on a
automation framework that allows interaction with GUI elements using on object orientated API.
The GUI elements include menus, buttons, radio buttons, text toolbars and their properties.
Whilst automating a test, you have discovered that the GUI elements of some third party
components are not identifiable by the automated tool you are using.
Which of the following is the FIRST step that you take to investigate this issue?
Options
Discussion
Why not check with the third-party vendor first to confirm testability before trying workarounds like C? That seems most ISTQB-ish.
Wish ISTQB would stop hammering on "root cause first" every time, but here it's clearly A. If the vendor doesn't support automation, nothing else really works reliably. Not 100 percent but that's what similar questions usually expect.
Maybe A makes the most sense since ISTQB loves starting with root cause before jumping to workarounds. C feels quick but that's more a hack than a first investigation step. Not fully certain but I'd put A for exam logic, anyone disagree?
I don’t think D fits for the FIRST action, it’s A. The exam likes you to start by checking vendor support instead of jumping to workarounds (trap is C). Happened in similar exam scenarios, too.
A tbh. You gotta check with the vendor first before wasting time on workarounds. If their component isn't designed for automation, none of the other steps will help anyway. I think this is standard practice with third party stuff in TAEs, but happy to hear if someone does it differently.
A
Its B-seen similar questions in practice tests and sometimes browser behavior throws off GUI recognition. Official guide isn't very clear on this.
I'd say A. You always want to check testability with the third-party vendor up front, that's ISTQB thinking for "first step". C is tempting for a workaround but kind of a trap, since that can break easily. If someone thinks otherwise, let me know but pretty sure A is safest here.
A , since ISTQB always wants you to address root cause first. If third party controls don't support automation, no workaround will be stable in the long run. Verifying testability with the provider is key here before trying hacks like C. Pretty confident but open to other takes.
Nah, I think A is it here. ISTQB usually expects you to check testability with the vendor/provider first-C is tempting but that's more of a workaround than a proper investigation. Pretty sure A lines up better with what they want for 'first step', but open if anyone sees it differently.
Be respectful. No spam.
