Software Manager, Agile Aficionado, Tech Dabbler, and Public Speaker. A lifelong learner, the prospect of something new and coffee are what get me up in the morning.
I find that hard, because the thought process for developing and testing is slightly different. It's not insurmountable though, part of the idea of disassociating yourself may help to role play a little, come at the test task with a persona. Customer, User, Hacker - whatever. Consider what this persona wants to accomplish with what you are testing and try to simulate those movements.
My easiest piece of advice is to look at the software and think "if I was going to break this, how would I do it?"
If you have coded to requirements, check against the Business Use Cases. Work with the PM, if you have one, or maybe someone on the Customer Support Team - they are an INVALUABLE resource. They talk to your customers all the time, so they have a good idea how customers are using the product.
Saying "Think outside the Box" is easy, doing it is hard. Figure out the Happy Path to what you are coding, then look at each step and think "what if I did z instead of x here" see what happens. Is the code resilient? Change inputs to something unsupported, try and past in lengths longer than the fields allow. Basically look at all the things you would normally use and inputs and use something completely different.
Software Manager, Agile Aficionado, Tech Dabbler, and Public Speaker. A lifelong learner, the prospect of something new and coffee are what get me up in the morning.
I find that hard, because the thought process for developing and testing is slightly different. It's not insurmountable though, part of the idea of disassociating yourself may help to role play a little, come at the test task with a persona. Customer, User, Hacker - whatever. Consider what this persona wants to accomplish with what you are testing and try to simulate those movements.
My easiest piece of advice is to look at the software and think "if I was going to break this, how would I do it?"
If you have coded to requirements, check against the Business Use Cases. Work with the PM, if you have one, or maybe someone on the Customer Support Team - they are an INVALUABLE resource. They talk to your customers all the time, so they have a good idea how customers are using the product.
Saying "Think outside the Box" is easy, doing it is hard. Figure out the Happy Path to what you are coding, then look at each step and think "what if I did z instead of x here" see what happens. Is the code resilient? Change inputs to something unsupported, try and past in lengths longer than the fields allow. Basically look at all the things you would normally use and inputs and use something completely different.
Some fantastic advice here, thanks for taking the time to do that :)
My pleasure, I hope it helps. Feel free to ask again if something else comes up.