Hi all,
it, <cough/> depends… <duck_and_cover/>![Image]()
Well, really the first thing I do doesn't depend: With uTest cycles I carefull read the instructions, in scope and out of scope descriptions. Often there's already a hint about what the customer is particularly interested in. For projects outside uTest, well, I do essentailly the same with the corresponding documentation: Release notes, version control history, specification/requirements docs — and oftentimes a short chat with the project lead (helps a lot in figuring out what the most important part is at that particular release).
For practically all of my work here at uTest, most products are new to me (I'm not (yet) a uTester for a long time), so I start by 'cruising': I figure out what's is about, how it's supposed to be used and at the same time watch out of peculiarities, strange behaviour, odd layout etc.
Once I'm done I might make a more systematic 'tour' (as described in http://michaeldkelly.com/pdfs/Taking%20a%20Tour%20Through%20Test%20Country.pdf). After that, I usually have a good idea about what's going on (or should be going on).
Of course, gabbing a test case is also a good start — if and when the test case is well written.
Happy Testing
Stephan
it, <cough/> depends… <duck_and_cover/>
Well, really the first thing I do doesn't depend: With uTest cycles I carefull read the instructions, in scope and out of scope descriptions. Often there's already a hint about what the customer is particularly interested in. For projects outside uTest, well, I do essentailly the same with the corresponding documentation: Release notes, version control history, specification/requirements docs — and oftentimes a short chat with the project lead (helps a lot in figuring out what the most important part is at that particular release).
For practically all of my work here at uTest, most products are new to me (I'm not (yet) a uTester for a long time), so I start by 'cruising': I figure out what's is about, how it's supposed to be used and at the same time watch out of peculiarities, strange behaviour, odd layout etc.
Once I'm done I might make a more systematic 'tour' (as described in http://michaeldkelly.com/pdfs/Taking%20a%20Tour%20Through%20Test%20Country.pdf). After that, I usually have a good idea about what's going on (or should be going on).
Of course, gabbing a test case is also a good start — if and when the test case is well written.
Happy Testing
Stephan
