First, let me state that I think that running anything as the non-oracle user on your filesystem may result in significant database issues! (I'll explain why in a minute)
Aside from the pathing issue, which you solved, I think that Colin is correct. You (or your admin) does need to give read on the binary:
[root@db01 ~]# useradd captjackvane
[root@db01 ~]# groups captjackvane
captjackvane : captjackvane
[root@db01 ~]# usermod -a -G oinstall captjackvane
[root@db01 ~]# groups captjackvane
captjackvane : captjackvane oinstall
[captjackvane@db01 OPatch]$ ls -ltrh opatch
-rwx--x--- 1 oracle oinstall 31K Mar 26 2013 opatch
[captjackvane@db01 OPatch]$ ./opatch lsinventory
/bin/sh: ./opatch: Permission denied
oracle@db01:(psu1) ~]$ chmod 750 ./opatch
oracle@db01:(psu1) ~]$ ls -ltrh opatch
-rwxr-x--- 1 oracle oinstall 31K Mar 26 2013 opatch
[captjackvane@db01 OPatch]$ ./opatch lsinventory
chmod: changing permissions of `/u01/oracle/app/product/db_1/.patch_storage': Operation not permitted
The chmod command failed for ./u01/oracle/app/product/db_1/.patch_storage.. It is possible that you have no permission to access it. OPatch cannot proceed!
OPatch returns with error code = 1
As you can see, I can now "execute" the binary, but other permissions issues remain. So here's where I get to my first point:
Running things, especially anything that stops/starts a database and/or the cluster as someone other than the Oracle user can lead to serious issues. I remember in my career-youth I accidentally started a development database as my physical user, instead of Oracle. Which meant that many (but not all) of the processes used by the database had my name on them (and by extension, my permissions) instead of Oracle.
Your best bet here is to use the Oracle user, or ask your admin to complete whatever the task is for you.
chmod g+r opatch
orchmod 750 opatch
.