Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
10 Cards in this Set
- Front
- Back
|
What makes a good Software Test engineer?
|
A good test engineer has a 'test to prevent' attitude a strong desire for quality, and an attention to detail
|
|
|
What's the role of documentation in QA?
|
Very Critical. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented in some form
|
|
|
What's the big deal about 'requirements'?
|
Requirements are essential. Proper requirements lay out how the system will be used by the end user. Knowing this, developers and QA will be able to properly develope the software, and QA to properly create the correct test cases to that of what the end user will use.
|
|
|
What steps are needed to develop and run software tests?
|
Obtain requirements, functional design, and internal design specifications and other necessary documents
Obtain budget and schedule requirements Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc. Determine test input data requirements Write test cases Maintain and update test plans, test cases, test environment, and testware through life cycle |
|
|
What's a 'test plan'?
|
A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort
|
|
|
What's a 'test case'?
|
A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly
|
|
|
What should be done after a bug is found?
|
The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere
|
|
|
What if the software is so buggy it can't really be tested at all?
|
The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type problems initially show up, with the focus being on critical bugs
|
|
|
How can it be known when to stop testing?
|
This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done
|
|
|
What if there isn't enough time for thorough testing?
|
Use risk analysis to determine where testing should be focused.
Prioritize the large bugs |
