1Software Testing Objectives
The Major Objectives of Software Testing:
- Uncover as many as errors (or bugs) as possible in a given timeline.
- Demonstrate a given software product matching its requirement specifications.
- Validate the quality of a software testing using the minimum cost and efforts.
- Generate high quality test cases, perform effective tests, and issue correct and helpful problem reports.
Major goals of Software Testing:
uncover the errors (defects) in the software, including errors in:
- requirements from requirement analysis
- design documented in design specifications
- coding (implementation)
- system resources and system environment
- hardware problems and their interfaces to software
2Software Quality Factors
Functionality (exterior quality)
- Correctness, reliability, usability, and integrity
Engineering (interior quality)
- Efficiency, testability, documentation, structure
Adaptability (future qualities)
- Flexibility, reusability, maintainability
3Software Testing Myths
- We can test a program completely. In other words, we test a program exhaustively.
- We can find all program errors as long as test engineers do a good job.
- We can test a program by trying all possible inputs and states of a program.
- A good test suite must include a great number of test cases.
- Good test cases always are complicated ones.
- Software test automation can replace test engineers to perform good software testing.
- Software testing is simple and easy. Anyone can do it. No training is needed.
4Software Testing Limits
- Due to the testing time limit, it is impossible to achieve total confidence.
- We can never be sure the specifications are 100% correct.
- We can never be certain that a testing system (or tool) is correct.
- No testing tools can copy with every software program.
- Tester engineers never be sure that they completely understand a software product.
- We never have enough resources to perform software testing.
- We can never be certain that we achieve 100% adequate software testing.
5Software Testing Principles
Principle #1: Complete testing is impossible.
Principle #2: Software testing is not simple.
Reasons:
Quality testing requires testers to understand a system/product completely
Quality testing needs adequate test set, and efficient testing methods
A very tight schedule and lack of test tools.
Principle #3: Testing is risk-based.
Principle #4: Testing must be planned.
Principle #5: Testing requires independence.
Principle #6: Quality software testing depends on:
Good understanding of software products and related domain application
Cost-effective testing methodology, coverage, test methods, and tools.
Good engineers with creativity, and solid software testing experience
6Software Testing Activities
Test Planning
Define a software test plan by specifying:
- a test schedule for a test process and its activities, as well as assignments
- test requirements and items
- test strategy and supporting tools
Test Design and Specification
- Conduct software design based well-defined test generation methods.
- Specify test cases to achieve a targeted test coverage.
Test Set up
- Testing Tools and Environment Set-up
- Test Suite Set-up
Test Operation and Execution
- Run test cases manually or automatically
Test Result Analysis and Reporting
- Report software testing results and conduct test result analysis
Problem Reporting
- Report program errors using a systematic solution.
Test Management and Measurement
- Manage software testing activities, control testing schedule, measure testing complexity and cost
Test Automation
- Define and develop software test tools
- Adopt and use software test tools
- Write software test scripts and facility
Test Configuration Management
- Manage and maintain different versions of software test suites, test environment and tools, and documents for various product versions.
7Bug Writing tips
12 Bug writing tips:
1.Be very specific when describing the bug. Don’t let there be any room for interpretation. More concise means less ambiguous, so less clarification will be needed later on.
2.Calling windows by their correct names (by the name displayed on the title bar) will eliminate some ambiguity.
3.Don’t be repetitive. Don’t repeat yourself. Also, don’t say things twice or three times.
4.Try to limit the number of steps to recreate the problem. A bug that is written with 7 or more steps can usually become hard to read. It is usually possible to shorten that list.
5.Start describing with where the bug begins, not before. For example, you don't have to describe how to load and launch the application if the application crashes on exit.
6.Proofreading the bug report is very important. Send it through a spell checker before submitting it.
7. Make sure that all step numbers are sequenced. (No missing step numbers and no duplicates.)
8.Please make sure that you use sentences. This is a sentence. This not sentence.
9.Don’t use a condescending or negative tone in your bug reports. Don’t say things like "It's still broken", or “It is completely wrong”.
10.Don’t use vague terms like “It doesn’t work” or “not working properly”
11.If there is an error message involved, be sure to include the exact wording of the text in the bug report. If there is a GPF (General Protection Fault) be sure to include the name of the module and address of the crash.
12.Once the text of the report is entered, you don’t know whose eyes will see it. You might think that it will go to your manager and the developer and that’s it, but it could show up in other documents that you are not aware of, such as reports to senior management or clients, to the company intranet, to future test scripts or test plans. The point is that the bug report is your work product, and you should take pride in your work.
No comments:
Post a Comment