|
||
![]() |
![]() | |
Levels: Test Strategy (A)- Testing strategy for single test (B)- Combined testing strategy for black-box tests (C)- Combined strategy for black-box tests plus white-box tests or evaluation (D)- Combined strategy for all testing and evaluation activities Checkpoints: Test Strategy Strategy for single test Checkpoints: * Conscious risk analysis * Differentiation in scope and depth of the tests (subsystems, quality attributes), depending on the risks * >1 design technique is used, suitable for the desired testing depth * Re-tests also have a (simple) strategy definition * Strategy is defined, executed and controlled Test Strategy Improvement Suggestions (from 0 to A) * If only one technique is available, make simple variations, which give either more or less test depth * Define a re-test approach which makes a balance between total or partial testing * Divide the system under test in testable subsystems: give priorities * Divide the system under test in testable quality attributes: give priorities * To shorten the critical path testing-time: incremental testing Black-Box and /White-Box Testing Methodologies * Black-box testing approach: The software tester only knows what the software is supposed to do - he can't look in the box to see how it operates. If he types in a certain input, he gets a certain output. He doesn't know how or why it happens, just that it does. * White-box (clear-box) testing approach: The software tester has access to the program's code and can examine it for clues to help him with his testing - he can see inside the box. Based on what he sees, the tester may determine that certain numbers are more or less likely to fail and can tailor his testing based on that information. Note: There is a risk to White-box testing. It's very easy to become biased and fail to objectively test the software because you might tailor the tests to match the code's operation. Testing the product spec isn't something that all software testing engineers have luxury of doing. Sometimes you might come into a project midway through the development cycle after the specification is written and the coding started. If that's the case, don't worry - you can still use the Black-Box / White-Box testing techniques to test the final specifications. |
* QA's job at review meetings is to ensure that the product being built is testable. * QA's job during unit test is to ensure that the unit operates according to the agreed upon functional specification. * QA's job during certification is to ensure that the entire integrated product functions as a whole before it is delivered to the customer in all the myriad environments that are supported in today's information technology environment. ![]() When a problem is discovered a bug report is written. The author of the bug report must set a severity level. Severity Code ----> Severity Qualification 0-fatal ----> The program crashes, the cursor is frozen, or a system error message appears. 1-major ----> (A) The user experience a breakdown in some but not all functionality. 1-major ----> (B) The user encounters a breakdown in content or output. 2-minor ----> Level 1 or 2 condition does not occur, but user is impeded, inconvenienced, confused, or distracted. 3-fit & finish ----> Level 1, 2, 3 condition does not occur, but one of the following occurs: Screen layout not precise, formatting incorrect ![]() Bug Tracking Mechanisms Mechanisms for tracking issues and test requirements are requisite to the QA process. A mechanism is needed to enter and track issues in the product, and a similar mechanism is needed to specify and track certification criteria for the product. Two tools have been implemented to address these issues: * BF: A database designed to enter and track product defects. * GF: A database designed to specify and track certification criteria. TEST ALL DIMENSIONS OF QUALITY Functionality Performance Reliability EFFECTIVE BUG REPORTING * Report bugs as soon as possible * Effectively describe the bugs * Be nonjudgemental in reporting bugs * Follow up on your bug reports | |
TEST ALL DIMENSIONS OF QUALITY |
![]() VPN: Virtual Private Network. Imagine you are a company with offices all over the country or the globe. You want a cheap, secure way to talk between your offices and to send data between your offices. You can simply dial your offices over the PSTN - the Public Switched Telephone Network. You can lease dedicated, 24-hour per day, seven day a week lines between your offices. Or you can create a "Virtual Private Network." What this means is that you rent or acquire some part of someone else's network (a phone company, an internet provider) and you make your own network out of theirs. It's calling carving out a network. To do this, you might use a combination of software (e.g. PC Anywhere), dialing codes and some other equipments. RAS: Remote Access Server. Also called a Remote Access Device or in a bigger version, a Remote Access Concentrator. It is a piece of computer hardware which sits on a corporate LAN and into which employees dial on the public switched telephone network to get access to their mail and to software and data on the corporate LAN. |
![]() BF: This is the database, back-ended by Microsoft Exchange Server, used to track issues found during testing. Each BF describes one symptom. BF Bug Report: The BF report utility provides tools that allow users to dump the contents of the BF database into a file using the HTML table formatting directives. Bug Status: The status of a bug at any given point during a test cycle. DM: Development Managers. Those who are responsible for a particular project or set of projects. DOD: Do Or Die (a.k.a.,Basic Acceptance Test). This set of GF are the basic tests which will ensure the integrity of the product after each build. This establishes that the basic major functions of a product is still good. GF: This is a database, back-ended by Microsoft Exchange Server, used to store testing criteria entered by QA against product specifications produced by the development team. GF Bug Report: The GF report utility provides tools that allow users to dump the contents of the GF database into a file using the HTML table formatting directives. MRD: Marketing Requirement Document Unit Test Cycle: A complete cycle involves a series of functional tests, environmental tests, boundary tests, and hardware/software tests. The completion of a full test cycle certifies that the product will work at functional, environmental, boundary and various targeted levels. |
|
Web Performance Management Solutions On Line Training |
Talk Smart! ![]() Portrait of a QA Tester |