Q: What testing approaches can you tell me about?
A: Each of the followings represents a different testing approach: black box testing, white box testing, unit testing, incremental testing, integration testing, functional testing, system testing, end-to-end testing, sanity testing, regression testing, acceptance testing, load testing, performance testing, usability testing, install/uninstall testing, recovery testing, security testing, compatibility testing, exploratory testing, ad-hoc testing, user acceptance testing, comparison testing, alpha testing, beta testing, and mutation testing.
Q: What is stress testing?
A: Stress testing is testing that investigates the behavior of software (and hardware) under extraordinary operating conditions.
For example, when a web server is stress tested, testing aims to find out how many users can be on-line, at the same time, without crashing the server. Stress testing tests the stability of a given system or entity.
Stress testing tests something beyond its normal operational capacity, in order to observe any negative results. For example, a web server is stress tested, using scripts, bots, and various denial of service tools.
Q: What is load testing?
A: Load testing simulates the expected usage of a software program, by simulating multiple users that access the program's services concurrently. Load testing is most useful and most relevant for multi-user systems, client/server models, including web servers.
For example, the load placed on the system is increased above normal usage patterns, in order to test the system's response at peak loads.
Q: What is the difference between stress testing and load testing?
A: Load testing generally stops short of stress testing.
During stress testing, the load is so great that the expected results are errors, though there is gray area in between stress testing and load testing.
Load testing is a blanket term that is used in many different ways across the professional software testing community.
The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing.
Q: What is the difference between performance testing and load testing?
A: Load testing is a blanket term that is used in many different ways across the professional software testing community. The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing.
Q: What is the difference between reliability testing and load testing?
A: Load testing is a blanket term that is used in many different ways across the professional software testing community. The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing.
Q: What is automated testing?
A: Automated testing is a formally specified and controlled method of formal testing approach.
Q: What is the difference between volume testing and load testing?
A: Load testing is a blanket term that is used in many different ways across the professional software testing community. The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing.
Q: What is incremental testing?
A: Incremental testing is partial testing of an incomplete product. The goal of incremental testing is to provide an early feedback to software developers.
Q: What is software testing?
A: Software testing is a process that identifies the correctness, completeness, and quality of software. Actually, testing cannot establish the correctness of software. It can find defects, but cannot prove there are no defects.
Q: What is alpha testing?
A: Alpha testing is final testing before the software is released to the general public. First, (and this is called the first phase of alpha testing), the software is tested by in-house developers. They use either debugger software, or hardware-assisted debuggers. The goal is to catch bugs quickly.
Then, (and this is called second stage of alpha testing), the software is handed over to software QA staff for additional testing in an environment that is similar to the intended use.
Q: What is beta testing?
A: Following alpha testing, "beta versions" of the software are released to a group of people, and limited public tests are performed, so that further testing can ensure the product has few bugs.
Other times, beta versions are made available to the general public, in order to receive as much feedback as possible. The goal is to benefit the maximum number of future users.
Q: What is the difference between alpha and beta testing?
A: Alpha testing is performed by in-house developers and software QA personnel. Beta testing is performed by the public, a few select prospective customers, or the general public.
Q: 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".
Q: What is boundary value analysis?
A: Boundary value analysis is a technique for test data selection. A test engineer chooses values that lie along data extremes. Boundary values include maximum, minimum, just inside boundaries, just outside boundaries, typical values, and error values. The expectation is that, if a systems works correctly for these extreme or special values, then it will work correctly for all values in between. An effective way to test code, is to exercise it at its natural boundaries.
Q: What is ad hoc testing?
A: Ad hoc testing is a testing approach; it is the least formal testing approach.
Q: What is clear box testing?
A: Clear 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.
Q: 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.
Q: What is open box testing?
A: Open 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.
Q: 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.
Q: What is functional testing?
A: Functional testing is the 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.
Q: What is closed box testing?
A: Closed box testing is the 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.
Q: 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, for testing purposes.
Q: 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.
Q: What is software fault?
A: A software fault is a hidden programming error. A software fault fault is an error in the correctness of the semantics of a computer program.
Q: What is software failure?
A: Software failure occurs when the software does not do what the user expects to see.
Q: What is a requirements test matrix?
A: The requirements test matrix is a project management tool for tracking and managing testing efforts, based on requirements, throughout the project's life cycle.
The requirements test matrix is a table, where requirement descriptions are put in the rows of the table, and the descriptions of testing efforts are put in the column headers of the same table.
The requirements test matrix is similar to the requirements traceability matrix, which is a representation of user requirements aligned against system functionality.
The requirements traceability matrix ensures that all user requirements are addressed by the system integration team and implemented in the system integration effort.
The requirements test matrix is a representation of user requirements aligned against system testing.
Similarly to the requirements traceability matrix, the requirements test matrix ensures that all user requirements are addressed by the system test team and implemented in the system testing effort.
Q: Give me a requirements test matrix template!
A: For a simple requirements test matrix template, you want a basic table that you would like to use for cross-referencing purposes.
How do you create one? You can create a requirements test matrix template in the following six steps:
Step 1: Find out how many requirements you have.
Step 2: Find out how many test cases you have.
Q: What is the difference between a software fault and software failure?
A: A software failure occurs when the software does not do what the user expects to see. Software faults, on the other hand, are hidden programming errors. Software faults become software failures 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. Other times it occurs 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.
Q: What is a test engineer?
A: We, test engineers, are engineers who specialize in testing. We 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.
Q: What is a QA engineer?
A: QA engineers are test engineer, but they 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. A QA engineer is successful if people listen to him, if people use his tests, if people think that he's useful, and if he's happy doing his 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, QA engineers tend to be process people.
Q: How do test case templates look like?
A: Software test cases are documents that describe inputs, actions, or events and their expected results, in order to determine if all features of an application are working correctly.
A software test case template is, for example, 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. It also helps in learning where information is located, making it easier for a user to find what they want. Lastly, with standards and templates, information will not be accidentally omitted from a document.
Once QA tester has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions.
Q: What is the role of the test engineer?
A: We, test engineers, speed up the work of the development staff, and reduce the risk of your company's legal liability.
We also give your company the evidence that the software is correct and operates properly.
We, test engineers, improve problem tracking and reporting, maximize the value of the software, and the value of the devices that use it.
We, test engineers, 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 the software development staff, so the development team can devote its time to build up the product.
We, test engineers, promote continual improvement.
We 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.
Q: What are the QA engineer's responsibilities?
A: Let's say, an engineer is hired for a small software company's QA role, and there is no QA team. Should he take responsibility to set up a QA infrastructure/process, testing and quality of the entire product? No, because taking this responsibility is a classic trap that QA people get caught in. Why? Because we QA engineers cannot assure quality. And because QA departments cannot create quality.
What we CAN do is to detect lack of quality, and prevent low-quality products from going out the door. What is the solution? We need to drop the QA label, and tell the developers that they are responsible for the quality of their own work. The problem is, sometimes, as soon as the developers learn that there is a test department, they will slack off on their testing. We need to offer to help with quality assessment, only.
Q: What metrics can be used in for software development?
A: Metrics refer to statistical process control. The idea of statistical process control is a great one, but it has only a limited use in software development.
On the negative side, statistical process control works only with processes that are sufficiently well defined AND unvaried, so that they can be analyzed in terms of statistics. The problem is, most software development projects are NOT sufficiently well defined and NOT sufficiently unvaried.
On the positive side, one CAN use statistics. Statistics are excellent tools that project managers can use. Statistics can be used, for example, to determine when to stop testing, i.e. test cases completed with certain percentage passed, or when bug rate falls below a certain level. But, if these are project management tools, why should we label them quality assurance tools?
Q: What is role of the QA engineer?
A: The QA Engineer's function is to use the system much like real users would, find all the bugs, find ways to replicate the bugs, submit bug reports to the developers, and to provide feedback to the developers, i.e. tell them if they've achieved the desired level of quality.
Q: What metrics can be used for bug tracking?
A: Metrics that can be used for bug tracking include the total number of bugs, total number of bugs that have been fixed, number of new bugs per week, and number of fixes per week.
Other metrics in quality assurance include...
McCabe metrics: cyclomatic complexity metric (v(G)), actual complexity metric (AC), module design complexity metric (iv(G)), essential complexity metric (ev(G)), pathological complexity metric (pv(G)), design complexity metric (S0), integration complexity metric (S1), object integration complexity metric (OS1), global data complexity metric (gdv(G)), data complexity metric (DV), tested data complexity metric (TDV), data reference metric (DR), tested data reference metric (TDR), maintenance severity metric (maint_severity), data reference severity metric (DR_severity), data complexity severity metric (DV_severity), global data severity metric (gdv_severity).
Q: What metrics can be used for bug tracking? (Cont'd...)
McCabe object-oriented software metrics: encapsulation percent public data (PCTPUB), access to public data (PUBDATA), polymorphism percent of unoverloaded calls (PCTCALL), number of roots (ROOTCNT), fan-in (FANIN), quality maximum v(G) (MAXV), maximum ev(G) (MAXEV), and hierarchy quality (QUAL).
Other object-oriented software metrics: depth (DEPTH), lack of cohesion of methods (LOCM), number of children (NOC), response for a class (RFC), weighted methods per class (WMC), Halstead software metrics program length, program volume, program level and program difficulty, intelligent content, programming effort, error estimate, and programming time.
Line count software metrics: lines of code, lines of comment, lines of mixed code and comments, and lines left blank.
Q: How do you perform integration testing?
A: First, unit testing has to be completed. Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements.
Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team.
Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.
Q: What metrics are used for test report generation?
A: Metrics that can be used for test report generation include...
McCabe metrics: Cyclomatic complexity metric (v(G)), Actual complexity metric (AC), Module design complexity metric (iv(G)), Essential complexity metric (ev(G)), Pathological complexity metric (pv(G)), design complexity metric (S0), Integration complexity metric (S1), Object integration complexity metric (OS1), Global data complexity metric (gdv(G)), Data complexity metric (DV), Tested data complexity metric (TDV), Data reference metric (DR), Tested data reference metric (TDR), Maintenance severity metric (maint_severity), Data reference severity metric (DR_severity), Data complexity severity metric (DV_severity), Global data severity metric (gdv_severity).
McCabe object oriented software metrics: Encapsulation percent public data (PCTPUB), and Access to public data (PUBDATA), Polymorphism percent of unoverloaded calls (PCTCALL), Number of roots (ROOTCNT), Fan-in (FANIN), quality maximum v(G) (MAXV), Maximum ev(G) (MAXEV), and Hierarchy quality(QUAL).
Other object oriented software metrics: Depth (DEPTH), Lack of cohesion of methods (LOCM), Number of children (NOC), Response for a class (RFC), Weighted methods per class (WMC), Halstead software metrics program length, Program volume, Program level and program difficulty, Intelligent content, Programming effort, Error estimate, and Programming time.
Line count software metrics: Lines of code, Lines of comment, Lines of mixed code and comments, and Lines left blank.
Q: What is the "bug life cycle"?
A: Bug life cycles are similar to software development life cycles. At any time during the software development life cycle errors can be made during the gathering of requirements, requirements analysis, functional design, internal design, documentation planning, document preparation, coding, unit testing, test planning, integration, testing, maintenance, updates, re-testing and phase-out.
Bug life cycle begins when a programmer, software developer, or architect makes a mistake, creates an unintentional software defect, i.e. a bug, and ends when the bug is fixed, and the bug is no longer in existence.
What should be done after a bug is found? When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested.
Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations.
A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.
Q: What is integration testing?
A: Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team.
Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable / acceptable, based on client input.
Q: How do test plan templates look like?
A: The test plan document template describes the objectives, scope, approach and focus of a software testing effort.
Test document templates are often in the form of documents that are divided into sections and subsections. One example of this template is a 4-section document, where section 1 is the "Test Objective", section 2 is the "Scope of Testing", section 3 is the "Test Approach", and section 4 is the "Focus of the Testing Effort".
All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. It also helps in learning where information is located, making it easier for a user to find what they want. With standards and templates, information will not be accidentally omitted from a document.
Once QA tester has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions.
Q: What is a software project test plan?
A: A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product.
The completed document will help people outside the test group understand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that no one outside the test group will be able to read it.
Q: When do you choose automated testing?
A: For larger projects, or ongoing long-term projects, automated testing can be valuable. But for small projects, the time needed to learn and implement the automated testing tools is usually not worthwhile.
Automated testing tools sometimes do not make testing easier. One problem with automated testing tools is that if there are continual changes to the product being tested, the recordings have to be changed so often, that it becomes a very time-consuming task to continuously update the scripts.
Another problem with such tools is the interpretation of the results (screens, data, logs, etc.) that can be a time-consuming task.
Q: What's the ratio between developers and testers?
A: This ratio is not a fixed one, but depends on what phase of the software development life cycle the project is in. When a product is first conceived, organized, and developed, this ratio tends to be 10:1, 5:1, or 3:1, i.e. heavily in favor of developers. In sharp contrast, when the software is near the end of alpha testing, this ratio tends to be 1:1 or 1:2, in favor of testers.
Q: What is your role in your current organization?
A: I'm a QA Engineer. The QA Engineer's function is to use the system much like real users would, find all the bugs, find ways to replicate the bugs, submit bug reports to the developers, and to provide feedback to the developers, i.e. tell them if they've achieved the desired level of quality.
Q: How can I learn to use WinRunner, without any outside help?
A: I suggest you read all you can, and that includes reading product description pamphlets, manuals, books, information on the Internet, and whatever information you can lay your hands on. Then the next step is actual practice, the gathering of hands-on experience on how to use WinRunner.
If there is a will, there is a way. You CAN do it, if you put your mind to it. You CAN learn to use WinRunner, with little or no outside help.
Q: Should I take a course in manual testing?
A: Yes, you want to consider taking a course in manual testing. Why? Because learning how to perform manual testing is an important part of one's education. Unless you have a significant personal reason for not taking a course, you do not want to skip an important part of an academic program.
Q: To learn to use WinRunner, should I sign up for a course at a nearby educational institution?
A: Free, or inexpensive, education is often provided on the job, by an employer, while one is getting paid to do a job that requires the use of WinRunner and many other software testing tools.
In lieu of a job, it is often a good idea to sign up for courses at nearby educational institutes. Classes, especially non-degree courses in community colleges, tend to be inexpensive.
Q: How can I become a good tester? I have little or no money.
A: The cheapest i.e. "free education" is often provided on the job, by an employer, while one is getting paid to do a testing job, where one is able to use many different software testing tools.
Q: What software tools are in demand these days?
A: There is no good answer to this question. The answer to this question can and will change from day to day. What is in demand today, is not necessarily in demand tomorrow.
To give you some recent examples, some of the software tools on end clients' lists of requirements include LabView, LoadRunner, Rational Tools and Winrunner.
But, as a general rule of thumb, there are many-many other items on their lists, depending on the end client, their needs and preferences.
It is worth repeating... the answer to this question can and will change from one day to the next. What is in demand today will not likely be in demand tomorrow.
Q: Which of these tools should I learn?
A: I suggest you learn some of the most popular software tools (e.g. WinRunner, LoadRunner, LabView, and Rational Rose, etc.) with special attention paid to the Rational Toolset and LoadRunner.
Q: What is software configuration management?
A: Software Configuration management (SCM) relates to Configuration Management (CM).
SCM is the control, and the recording of, changes that are made to the software and documentation throughout the software development life cycle (SDLC).
SCM covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, and changes made to them, and to keep track of who makes the changes.
We, test engineers have experience with a full range of CM tools and concepts, and can easily adapt to an organization's software tool and process needs.
Q: What are some of the software configuration management tools?
A: Software configuration management tools include Rational ClearCase, DOORS, PVCS, CVS; and there are many others. Rational ClearCase is a popular software tool, made by Rational Software, for revision control of source code.
DOORS, or "Dynamic Object Oriented Requirements System", is a requirements version control software tool.
CVS, or "Concurrent Version System", is a popular, open source version control system to keep track of changes in documents associated with software projects. CVS enables several, often distant, developers to work together on the same source code.
PVCS is a document version control tool, a competitor of SCCS. SCCS is an original UNIX program, based on "diff". Diff is a UNIX utility that compares the difference between two text files.
Q: Which of these roles are the best and most popular?
A: In testing, Tester roles tend to be the most popular. The less popular roles include the roles of System Administrator, Test/QA Team Lead, and Test/QA Managers.
Q: What other roles are in testing?
A: Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Leads, Test/QA Managers, System Administrators, Database Administrators, Technical Analysts, Test Build Managers, and Test Configuration Managers.
Depending on the project, one person can and often wear more than one hat. For instance, we Test Engineers often wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager as well.
Q: What's the difference between priority and severity?
A: The simple answer is, "Priority is about scheduling, and severity is about standards."
The complex answer is, "Priority means something is afforded or deserves prior attention; a precedence established by order of importance (or urgency). Severity is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles, e.g. a severe code of behavior."
Q: What is documentation change management?
A: Documentation change management is part of configuration management (CM). CM covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes.
QA tester has had experience with a full range of CM tools and concepts. QA tester can easily adapt to your software tool and process needs.
Q: What is up time?
A: "Up time" is the time period when a system is operational and in service. Up time is the sum of busy time and idle time.
For example, if, out of 168 hours, a system has been busy for 50 hours, idle for 110 hours, and down for 8 hours, then the busy time is 50 hours, idle time is 110 hours, and up time is (110 + 50 =) 160 hours.
Q: What is upwardly compatible software?
A: Upwardly compatible software is compatible with a later or more complex version of itself. For example, an upwardly compatible software is able to handle files created by a later version of itself.
Q: What is upward compression?
A: In software design, upward compression means a form of demodularization, in which a subordinate module is copied into the body of a superior module.
Q: What is usability?
A: Usability means ease of use; the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a software product.
Q: What is user documentation?
A: User documentation is a document that describes the way a software product or system should be used to obtain the desired results.
Q: What is a user manual?
A: User manual is a document that presents information necessary to employ software or a system to obtain the desired results.
Typically, what is described are system and component capabilities, limitations, options, permitted inputs, expected outputs, error messages, and special instructions.
Q: What is the difference between user documentation and user manual?
A: When a distinction is made between those who operate and use a computer system for its intended purpose, a separate user documentation and user manual is created. Operators get user documentation, and users get user manuals.
Q: What is user friendly software?
A: A computer program is user friendly, when it is designed with ease of use, as one of the primary objectives of its design.
Q: What is a user friendly document?
A: A document is user friendly, when it is designed with ease of use, as one of the primary objectives of its design.
Q: What is a user guide?
A: User guide is the same as the user manual. It is a document that presents information necessary to employ a system or component to obtain the desired results.
Typically, what is described are system and component capabilities, limitations, options, permitted inputs, expected outputs, error messages, and special instructions.
Q: What is user interface?
A: User interface is the interface between a human user and a computer system. It enables the passage of information between a human user and hardware or software components of a computer system.
Q: What is a utility?
A: Utility is a software tool designed to perform some frequently used support function. For example, a program to print files.
Q: What is utilization?
A: Utilization is the ratio of time a system is busy, divided by the time it is available. Uilization is a useful measure in evaluating computer performance.
Q: What is V&V?
A: V&V is an acronym for verification and validation.
Q: What is variable trace?
A: Variable trace is a record of the names and values of variables accessed and changed during the execution of a computer program.
Q: What is value trace?
A: Value trace is same as variable trace. It is a record of the names and values of variables accessed and changed during the execution of a computer program.
Q: What is a variable?
A: Variables are data items whose values can change. One example is a variable we've named "capacitor_voltage_10000", where "capacitor_value_10000" can be any whole number between -10000 and +10000.
Keep in mind, there are local and global variables.
Q: What is a variant?
A: Variants are versions of a program. Variants result from the application of software diversity.
Q: What is verification and validation (V&V)?
A: Verification and validation (V&V) is a process that helps to determine if the software requirements are complete, correct; and if the software of each development phase fulfills the requirements and conditions imposed by the previos phase; and if the final software complies with the applicable software requirements.
Q: What is a software version?
A: A software version is an initial release (or re-release) of a software associated with a complete compilation (or recompilation) of the software.
Q: What is a document version?
A: A document version is an initial release (or a complete re-release) of a document, as opposed to a revision resulting from issuing change pages to a previous release.
Q: What is VDD?
A: VDD is an acronym. It stands for "version description document".
Q: What is a version description document (VDD)?
A: Version description document (VDD) is a document that accompanies and identifies a given version of a software product.
Typically the VDD includes a description, and identification of the software, identification of changes incorporated into this version, and installation and operating information unique to this version of the software.
Q: What is a vertical microinstruction?
A: A vertical microinstruction is a microinstruction that specifies one of a sequence of operations needed to carry out a machine language instruction. Vertical microinstructions are short, 12 to 24 bit instructions. They're called vertical because they are normally listed vertically on a page. These 12 to 24 bit microinstructions instructions are required to carry out a single machine language instruction.
Besides vertical microinstructions, there are horizontal as well as diagonal microinstructions as well.
Q: What is a virtual address?
A: In virtual storage systems, virtual addresses are assigned to auxiliary storage locations. They allow those location to be accessed as though they were part of the main storage.
Q: What is virtual memory?
A: Virtual memory relates to virtual storage. In virtual storage, portions of a user's program and data are placed in auxiliary storage, and the operating system automatically swaps them in and out of main storage as needed.
Q: What is virtual storage?
A: Virtual storage is a storage allocation technique, in which auxiliary storage can be addressed as though it was part of main storage. Portions of a user's program and data are placed in auxiliary storage, and the operating system automatically swaps them in and out of main storage as needed.
Q: What is a waiver?
A: Waivers are authorizations to accept software that has been submitted for inspection, found to depart from specified requirements, but is nevertheless considered suitable for use "as is", or after rework by an approved method.
Q: What is the waterfall model?
A: Waterfall is a model of the software development process in which the concept phase, requirements phase, design phase, implementation phase, test phase, installation phase, and checkout phase are performed in that order, probably with overlap, but with little or no iteration.
Q: What are the phases of the software development process?
A: Software development process consists of the concept phase, requirements phase, design phase, implementation phase, test phase, installation phase, and checkout phase.
Q: What models are used in software development?
A: In software development process the following models are used: waterfall model, incremental development model, rapid prototyping model, and spiral model.
Q: What is SDLC?
A: SDLC is an acronym. It stands for "software development life cycle".
Q: What is the difference between system testing and integration testing?
GOOD MANUAL TESTING INTERVIEW QUESTIONS
