Here they are:
Well, before, as a QC, I have to write test case for each feature, of course, but there was no peer-meeting to review test case before implementing-phase. What I suggest to do is we should have a meeting (in at least 1 hours) with developers to go through the potential business or test cases (not all). During the meeting, I will keep asking question about ambiguous place in requirement for people discussion until it's clear enough for implementation. The priority of this meeting to make sure all or most of requirements can be: (1) measurable, (2) clear & consistent, and optional is to find missing requirements if any.
>> Yup, QC must care about quality, of course, but on time also very important. It's not very easy to balance it. And this is my point of view, the factors made me confident to deliver task done with good quality and on time are:
+ My technical skill related to this task.
+ The requirement or spec should be clear and understandable.
+ Last but not least, time constraint of course.
>> OK easy :), let's presume that I am working on a product of company not the outsource. First (1)What it is! I study it and note it down, then (2)Question it! I will ask myself if it is really necessary to put in current milestone or sprint. And think about the top risk to have this implemented. Discuss it, then put this change request item to product backlog or somewhere whatever, just a place to store the changes, not at the time but during implementation phase and, (3)Keep track it, talk to dev to figure out the impact if any, based on that go straight to update the test case of related feature. Finally, test it over not only itself but also its parent features.
--------------------------------------------
That's all for now. Actually, there are more questions interesting than this. I will go back to share it later :)


2 comments: