In your example the TESTCB is superfluous since the non-zero return code from the OPEN should be enough to determine if the ACB is open. If the OPEN macro specifies more than one ACB then each ACB should be checked if OPEN returns a non-zero return code.
I do very little VSAM, so I find find TESTCB and SHOWCB very confusing myself. I generally break the rule about examining the VSAM control blocks directly. This rule was established to make programs more portable between OS/360 type systems (like z/OS) and DOS type systems (like VSE), something that I doubt is actually done very often. To aid enforcement of this rule IBM isn't very forthcoming about where the real field definitions are located, but it isn't too hard to dig out the IFGACB and IFGRPL macros in z/OS and go directly to the fields in the ACB and RPL. Of course, the DFSMS folks then claim, "We want to be able to move those fields," something that hasn't happened in nearly 40 years, and it ain't gonna happen. In 1972 or so the party line was. "VSAM is the future, all those obsolete things like QSAM and BSAM are going to be pushed out." Another thing that hasn't happened, and ain't gonna happen. VSAM, after 20+ years of struggle did succeed in pushing ISAM out, but few people lament that disappearance. For what it's worth I'm one of the few people that do lament the loss of ISAM. Used properly, ISAM was very good, but it was seldom used properly. Most of the time VSAM performance is at least fairly consistent, something ISAM never could claim.