Every developer assumes the code they write is going to work perfectly. I would know, I have made that assumption too many times.
As aggravating as it may get, the computer will always do what you tell it. Every once in awhile you will spool up a program and it seems to be flawless. Every feature is working as you intended. The software is working flawlessly on your devices in the office. So, you decide to show it to your boss. You are super excited to see the look on your boss’s face when he launches the application, and then it happens.
Your boss spent 3 minutes fiddling with the app and he already broke it, but you can’t even figure out how to recreate it. Most likely, your boss did something you never tried on your dev machine because he interacts with technology different than you do.
Throughout high school, my teachers always told me to make sure I knew my audience when writing a paper. It turns out teachers are right sometimes. This is not a cookie cutter situation though. I’m not writing to a school board about the lack of parking spots for sophomore students. Most likely, your application is written for an unknown user type.
The first thing I do when testing software is getting familiar with the product and the users. Knowing what the app does is very important. Will you be interacting with an API? Will there be in-app purchases? Can the users interact with each other? Each question will result in a different method of testing. Knowing what user type is already using the app is also very important, but not for the reason you would think.
The second thing I do is take everything I know about the app and assume it is broken. Then I try to find out where it is broken. This is where you do NOT trust the developer. If they told you the application can only make an in app purchase if the user has a credit card on file, try making a purchase without a user.
Make sure the developer doesn’t do your job for you before you even start testing. In that case, he shouldn’t have hired you in the first place.