As a general rule, we should declare variables in the innermost scope that is applicable, i.e. do not use a wider scope than necessary.
a is being declared as an instance variable yet used as a local variable by the methods — i.e. always re-initializing it within the methods (not looking at the previous method's value) — then the instance variable is not maintaining (object) state between method invocations, and such a variable is being declared in a scope wider than necessary. Under these circumstances, I would find the member variable at issue rather than the local variable that shadows it.
Another general rule that instance members should have the same lifetime as the object itself — if we find instance members that only come into play after certain state or conditions, that suggests we have another object (e.g. two or more objects are being conflated).
On the other hand, if the
a instance variable is indeed carrying object state (i.e. is is used across/in-between methods invocations), then when a method (that because it is using a shadowing local variable of the same name) fails to use and/or update the instance variable, your tests ought to notice that something is amiss. If they don't either insufficient tests or the variable wasn't actually holding object state.