Q91. What is gamma testing?
A: Gamma testing is testing of software that has all the required features, but it did not go through all the in-house quality checks. Cynics tend to refer to software releases as "gamma testing".
Q92. What is glass box testing?
A: Glass box testing is the same as white box testing. It is a testing approach that examines the application's program structure, and derives test cases from the application's program logic.
Q93. What is open box testing?
A: Open box testing is same as white box testing. It is a testing approach that examines the application's program structure, and derives test cases from the application's program logic.
Q94. What is black box testing?
A: Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, nor the "inner workings" of the software. You CAN learn to do black box testing, with little or no outside help. Get CAN get free information. Click on a link!
Q95. What is functional testing?
A: Functional testing is same as black box testing. Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, nor the "inner workings" of the software.
Q96. What is closed box testing?
A: Closed box testing is same as black box testing. Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, nor the "inner workings" of the software.
Q97. What is bottom-up testing?
A: Bottom-up testing is a technique for integration testing. A test engineer creates and uses test drivers for components that have not yet been developed, because, with bottom-up testing, low-level components are tested first. The objective of bottom-up testing is to call low-level components first, for testing
Q98. What is software quality?
A: The quality of the software does vary widely from system to system. Some common quality attributes are stability, usability, reliability, portability, and maintainability. See quality standard ISO 9126 for more information on this subject.
Q99. How do test case templates look like?
A: Software test cases are in a document that describes inputs, actions, or events, and their expected results, in order to determine if all features of an application are working correctly. Test case templates contain all particulars of every test case. Often these templates are in the form of a table. One example of this table is a 6-column table, where column 1 is the "Test Case ID Number", column 2 is the "Test Case Name", column 3 is the "Test Objective", column 4 is the "Test Conditions/Setup", column 5 is the "Input Data Requirements/Steps", and column 6 is the "Expected Results". All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. They also help in learning where information is located, making it easier for users to find what they want. Lastly, with standards and templates, information will not be accidentally omitted from a document. You CAN learn to create test case templates, with little or no outside help. Get CAN get free information.
Click on a link!
Q100. What is a software fault?
A: Software faults are hidden programming errors. Software faults are errors in the correctness of the semantics of computer programs.
Q101. What is software failure?
A: Software failure occurs when the software does not do what the user expects to see.
Q102. What is the difference between a software fault and a software failure?
A: Software failure occurs when the software does not do what the user expects to see. A software fault, on the other hand, is a hidden programming error. A software fault becomes a software failure only when the exact computation conditions are met, and the faulty portion of the code is executed on the CPU. This can occur during normal usage. Or, when the software is ported to a different hardware platform. Or, when the software is ported to a different complier. Or, when the software gets extended.
Q103. What is a test engineer?
A: Test engineers are engineers who specialize in testing. We, test engineers, create test cases, procedures, scripts and generate data. We execute test procedures and scripts, analyze standards of measurements, evaluate results of system/integration/regression testing.
Q104. What is the role of test engineers?
A: Test engineers speed up the work of the development staff, and reduce the risk of your company's legal liability. We, test engineers, also give the company the evidence that the software is correct and operates properly. We also improve problem tracking and reporting, maximize the value of the software, and the value of the devices that use it. We also assure the successful launch of the product by discovering bugs and design flaws, before...
users get discouraged, before shareholders loose their cool and before employees get bogged down. We, test engineers help the work of software development staff, so the development team can devote its time to build up the product. We, test engineers also promote continual improvement. They provide documentation required by FDA, FAA, other regulatory agencies, and your customers. We, test engineers save your company money by discovering defects EARLY in the design process, before failures occur in production, or in the field. We save the reputation of your company by discovering bugs and design flaws, before bugs and design flaws damage the reputation of your company.
Q105. What is a QA engineer?
A: QA engineers are test engineers, but QA engineers do more than just testing. Good QA engineers understand the entire software development process and how it fits into the business approach and the goals of the organization. Communication skills and the ability to understand various sides of issues are important. We, QA engineers, are successful if people listen to us, if people use our tests, if people think that we're useful, and if we're happy doing our work. I would love to see QA departments staffed with experienced software developers who coach development teams to write better code. But I've never seen it. Instead of coaching, we, QA engineers, tend to be process people.