I have an interview upcoming and I know there will be a technical competency question or whiteboard exercise around "How would you test *n*. n is likely part of a web application, coming up with test cases is not a problem whatsoever, I could talk forever about that, I need to refine my thought process so to speak to answer this: - Refer to the requirements in order to derive some test cases for tracability - Determine what is in scope for this testing (Security? Performance? etc). - Make a few assumptions based on what I know about the full system (for example if this was a login screen, I could make some assumptions about the password criteria when setting new passwords or registering). - Possibly talk about creating a Strategy Document, outlining things like entry, exit criteria, resources, deliverables etc. - Begin documenting test cases - Prepare testing environment - Execute said test cases (important to update them if the initial build received has differed what what was originally spoke about as some cases would be guesswork at best until this point, recording & following any defects through the defect life cycle - Produce reporting through the process, open defect count, defects vs. priority/severity, test cases executed vs. failures/non executed etc - Identify any good areas for automated testing How can I improve on the above in order to provide a top quality answer to the initial question?