Testing overview
Download as DOCX, PDF0 likes855 views
UAT involves developing a test strategy, scenarios, and scripts. The test strategy outlines the testing approach, including people, tools, procedures, and support. Test scenarios describe situations to test. Test scripts define actual inputs and expected results. An effective test strategy is specific, practical, and justified, clarifying major tasks and challenges. It identifies the type and timing of testing, critical success factors, and tradeoffs.
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
28. What are cursor attributes
%ROWCOUNT , %NOTFOUND , %FOUND ,%ISOPEN
29. What is a cursor for loop.
Cursor For Loop is a loop where oracle implicitly declares a loop variable, the loop
index that of the same record type as the cursorâs record.
30. Difference between NO DATA FOUND and %NOTFOUND
NO DATA FOUND is an exception raised only for the SELECTâŠ.INTO statements
hen the where clause of the querydoes not match any rows. When the where clause
of the explicit cursor does not match any rows the %NOTFOUND attribute is set to
TRUE instead.
31. What a SELECT FOR UPDATE cursor represent.
SELECTâŠâŠFROMâŠâŠFORâŠâŠUPDATE[OF column-reference][NOWAIT] The processing done in
a fetch loop modifies the rows that have been retrieved by the cursor. A convenient way of
modifying the rows is done by a method with two parts: the FOR UPDATE clause in the
cursor declaration, WHERE CURRENT OF CLAUSE in an UPDATE or declaration statement.
32. What âWHERE CURRENT OF â clause does in a cursor.
LOOP
SELECT num_credits INTO v_numcredits FROM
classes WHERE dept=123 and course=101;
UPDATE students SET current_credits=current_credits+v_numcredits
WHERE CURRENT OF X;
END LOOP; COMMIT; END;
33. What is use of a cursor variable? How it is defined.
A cursor variable is associated with different statements at run time, which can hold
different values at run time. Static cursors can only be associated with one run time
query. A cursor variable is reference type(like a pointer in C). Declaring a cursor variable:
TYPE type_name IS REF CURSOR RETURN return_type type_name is the name of the
reference type,return_type is a record type indicating the types of the select list that will
eventually be returned by the cursor variable.
34. What should be the return type for a cursor variable.Can we use a scalar data type as
return type.
The return type for a cursor must be a record type.It can be declared explicitly as a
user-defined or %ROWTYPE can be used. eg TYPE t_studentsref IS REF
CURSOR RETURN students%ROWTYPE
35. How you open and close a cursor variable.Why it is required.
OPEN cursor variable FOR SELECTâŠStatement
CLOSE cursor variable In order to associate a cursor variable with a particular
SELECT statement OPEN syntax is used.In order to free the resources used](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-49-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
28. What will be the result of the following program?
char*g()
{
static char x[1024];
return x;
}
main()
{
char*g1=âFirst Stringâ;
strcpy(g(),g1);
g1=g();
strcpy(g1,âSecond Stringâ);
printf(âAnswer is:%sâ, g());
}
(A) Answer is: First String (B) Answer is: Second String
(C) Run time Error/Core Dump (D) None of these
29. Consider the following program
main()
{
int a[5]={1,3,6,7,0};
int *b;
b=&a[2];
}
The value of b[-1] is
(A) 1 (B) 3 (C) -6 (D) none
30. Given a piece of code
int x[10];
int *ab;
ab=x;
To access the 6th element of the array which of the following is incorrect?
(A) *(x+5) (B) x[5] (C) ab[5] (D) *(*ab+5} .](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-63-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
unsigned int fact(int x)
{
return(x*fact(x-1));
}
A. 24 B. 10 C. 4 D. none
4. Consider the following C program and chose collect answer
#include
void main( )
{
inta[10],k;
for(k=0;k<10;k++)
{
a[k]=k;
}
printf (â%dnâ,k);
}
A. value of k is undefined ; unpredictable answer
B. 10
C. program terminates with run time error
D. 0](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-67-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
4 : int *pia,ia;
5 :float *pafa,fa;
6 :ia=100;
7 :fa=12.05;
8 :*pfa=&ia;
9 :pfa=&ia;
10 :pia=pfa;
11 :fa=(float)*pia;
12 :fa=ia;
13 :}
a. 8 and 9 b. 9 and 10 c. 8 and 10 d. 10 and 11
8. What is the o/p of the follow pgm?
#include
main()
{
char char_arr[5]=âORACLâ;
char c=âEâ;
prinf(â%snâ,strcat(char_arr,c));
}
a:oracle b. oracl c.e d.none](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-70-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
9. consider the following pgm listing
#include
main()
{
int a[3];
int *I;
a[0]=100;a[1]=200;a[2]=300;
I=a;
Printf(â%dnâ, ++*I);
Printf(â%dnâ, *++I);
Printf(â%dnâ, (*I)â);
Printf(â%dnâ, *I);
}
what is the o/p
a. 101,200,200,199 b. 200,201,201,100 c. 101,200,199,199 d. 200,300,200,100
10. which of the following correctly declares âMy_varâ as a pointer to a function that returns an integer
a. int*My_Var(); b. int*(My_Var()); c. int(*)My_Var(); d. int(*My_Var)();
11. what is the memory structure employed by recursive functions in a C pgm?](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-71-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
a. B tree b. Hash table c. Circular list d. Stack
12. Consider the follow pgm listing?
Line 1: #include
2: void main()
3: {
4: int a=1;
5: const int c=2;
6: const int *p1=&c;
7: const int*p2=&a;
8: int *p3=&c;
9: int*p4=&a;
10:}
what are the lines that cause compilation errors?
a.7 b.8 c.6 and 7 d.no errors
13. what will be the o/p
#include
main()
{ inta[3]; int *x; int*y; a[0]=0;a[1]=1;a[2]=2; x=a++; y=a;
printf(â%d %dnâ, x,(++y)); }
a. 0,1 b. 1,1 c. error d. 1,2
what is the procedure for swapping a,b(assume that a,b and tmp are of the same type?](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-72-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
[edit] Test plan identifier
For example: âMasterplan for 3A USB Host Mass Storage Driver TP_3A1.0âł
Some type of unique company generated number to identify this test plan, its level and the level of software that it is
related to. Preferably the test plan level will be the same as the related software level. The number may also identify
whether the test plan is a Masterplan, a Level plan, an integration plan or whichever plan level it represents.This is
to assist in coordinating software and testware versions within configuration management.
Keep in mind that test plans are like other software documentation, they are dynamic in nature and must be kept up
to date. Therefore, they will have revision numbers.
You may want to include authorand contact information including the revision history information as part of either
the identifier section of as part of the introductionâŠ
References
List all documents that support this test plan
Documents that are referenced include:
Project Plan.
System Requirements specifications.
High Level design document.
Detail design document.
Development and Test process standards.
Methodology.
Low level design.
Introduction
State the purpose of the Plan, possibly identifying the level of the plan (master etc.). This is essentially the executive
summary part of the plan.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-102-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
You may want to include any references to other plans, documents or items that contain information relevant to this
project/process.
Identify the objective of the plan or scope of the plan in relation to the Software Project plan that it relates to. Other
items may include, resource and budget constraints,scope ofthe testing effort, how testing relates to other
evaluation activities (Analysis & Reviews), and possible the process to be used for change control and
communication and coordination of key activities.
As this is the âExecutive Summaryâ keep information brief and to the point.
Intention of this project has to be included
[edit] Test items (functions)
These are things you intend to test within the scope of this test plan. Essentially, something you will test,a list of
what is to be tested.This can be developed from the software application inventories as well as other sources of
documentation and information.
This can be controlled on a local Configuration Management (CM) process if you have one. This information
includes version numbers, configuration requirements where needed, (especially if multiple versions of the product
are supported).It may also include key delivery schedule issues for critical elements.
This section can be oriented to the level of the test plan. For higher levels it may be by application or functional
area, for lower levels it may be by program, unit, module or build.
Software risk issues.
Identify what software is to be tested and what the critical areas are, such as:
Delivery of a third party product.
New version of interfacing software.
Ability to use and understand a new package/tool, etc.
Extremely complex functions.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-103-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
Modifications to components with a past history of failure.
Poorly documented modules or change requests.
There are some inherent software risks such as complexity; these need to be identified.
Safety.
Multiple interfaces.
Impacts on Client.
Government regulations and rules.
Anotherkey area of risk is a misunderstanding of the original requirements. This can occur at the management, us er
and developer levels. Be aware of vague or unclear requirements and requirements that cannot be tested.
The past history of defects (bugs)discovered during Unit testing will help identify potential areas within the
software that are risky. If the unit testing discovered a large number of defects or a tendency towards defects in a
particular area of the software, this is an indication of potential future problems. It is the nature of defects to cluster
and clump together. If it was defect ridden earlier, it will most likely continue to be defect prone.
One good approach to define where the risks are is to have several [brainstorming] sessions.
Start with ideas, such as,what worries me about this project/application.
Features to be tested
This is a listing of what is to be tested from the userâs viewpoint of what the systemdoes.This is not a technical
description of the software, but a USERâS view of the functions.
Set the level of risk for each feature. Use a simple rating scale such as High, Medium and Low(H, M, L). These
types of levels are understandable to a User. You should be prepared to discuss why a particular level was chosen.
Sections 4 and 6 are very similar, and the only true difference is the point of view. Section 4 is a technical type
description including version numbers and other technical information and Section 6 is from the Userâs viewpoint.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-104-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
1.1.8 Approach (strategy)
1.1.9 Item pass/fail criteria
1.1.10 Entry & exit criteria
1.1.11 Suspension criteria & resumption requirements
1.1.12 Test deliverables
1.1.13 Remaining test tasks
1.1.14 Environmental needs
1.1.15 Staffing and training needs
1.1.16 Responsibilities
1.1.17 Planning risks and contingencies
1.1.18 Approvals
1.1.19 Glossary
1.2 Regional differences
2 Criticism of the overuse of test plans
3 Test plans in hardware development
4 IEEE 829-1998:
5 See also
6 External links
[edit] Test plans in software development
In software testing,a test plan gives detailed testing information regarding an upcoming testing effort, including](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-112-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
Scope of testing.
Schedule.
Test Deliverables.
Release Criteria.
Risks and Contingencies.
[edit] Test plan template, based on IEEE 829 format
Test Plan Identifier (TPI).
References
Introduction
Test Items
Software Risk Issue
Features to be Tested
Features not to be Tested
Approach
Item Pass/Fail Criteria
Entry & Exit Criteria
Suspension Criteria and Resumption Requirements
Test Deliverables
Remaining Test Tasks
Environmental Needs
Staffing and Training Needs
Responsibilities
Planning Risks and Contingencies](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-113-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
There are some inherent software risks such as complexity; these need to be identified.
Safety.
Multiple interfaces.
Impacts on Client.
Government regulations and rules.
Anotherkey area of risk is a misunderstanding of the original requirements. This can occur at the management, user
and developer levels. Be aware of vague or unclear requirements and requirements that cannot be tested.
The past history of defects (bugs) discovered during Unit testing will help identify potential areas within the
software that are risky. If the unit testing discovered a large number of defects or a tendency towards defects in a
particular area of the software, this is an indication of potential future problems. It is the nature of defects to cluster
and clump together. If it was defect ridden earlier, it will most likely continue to be defect prone.
One good approach to define where the risks are is to have several [brainstorming] sessions.
Start with ideas, such as, what worries me about this project/application.
Features to be tested
This is a listing of what is to be tested from the userâs viewpoint of what the systemdoes.This is not a technical
description of the software, but a USERâS view of the functions.
Set the level of risk for each feature. Use a simple rating scale such as High, Medium and Low(H, M, L). These
types of levels are understandable to a User. You should be prepared to discuss why a particular level was chosen.
Sections 4 and 6 are very similar, and the only true difference is the point of view. Section 4 is a technical type
description including version numbers and other technical information and Section 6 is from the Userâs viewpoint.
Users do not understand technicalsoftware terminology; they understand functions and processes as they relate to
their jobs.
Features not to be tested
This is a listing of what is ânotâ to be tested from both the userâs viewpoint of what the systemdoes and a
configuration management/version control view. This is not a technical description of the software, but a userâs view
of the functions.
Identify why the feature is not to be tested,there can be any number of reasons.
Not to be included in this release of the Software.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-116-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
A specified segment of grouping of features/components must be tested together.
Other information that may be useful in setting the approach are:
MTBF, Mean Time Between Failures â if this is a valid measurement for the test involved and if the data is
available.
SRE, Software Reliability Engineering â if this methodology is in use and if the information is available.
How will meetings and other organizational processes be handled?
[edit] Item pass/fail criteria
Show stopperissues.Specify the criteria to be used to determine whether each test item has passed orfailed. Show
Stopper severity requires definition within each testing context.
Entry & exit criteria
Specify the criteria to be used to start testing and how you know when to stop the testing process.
Suspension criteria & resumption requirements
Suspension criteria specify the criteria to be used to suspend all or a portion of the testing activities while
resumption criteria specify when testing can resume after it has been suspended.
Unavailability of external dependent systems during execution.
When a defect is introduced that cannot allow any further testing.
Critical path deadline is missed so that the client will not accept delivery even if all testing is completed.
A specific holiday shuts down both development and testing.
System Integration Testing in the Integration environment may be resumed underthe following circumstances:
When the external dependent systems become available again.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-118-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
over a short period of time and is tightly controlled. (See beta testing)
· Parallel/Audit Testing: Testing where the user reconciles the output of the new system to the output of
the current system to verify the new system performs the operations correctly.
· Glass Box/Open Box Testing: 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.
· Closed Box Testing: Closed box testing is same as black box testing. A type of testing that considers
only the functionality of the application.
· Bottom-up Testing: 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 purposes.
· Smoke Testing: A random test conducted before the delivery and after complete testing.
Testing Terms
· Bug: A software bug may be defined as a coding error that causes an unexpected defect, fault or flaw.
In other words, if a program does not perform as intended, it is most likely a bug.
· Error: A mismatch between the program and its specification is an error in the program.
· Defect: Defect is the variance from a desired product attribute (it can be a wrong, missing or extra data).
It can be of two types â Defect from the product or a variance from customer/user expectations. It is a
flaw in the software system and has no impact until it affects the user/customer and operational system.
90% of all the defects can be caused by process problems.
· Failure: A defect that causes an error in operation or negatively impacts a user/ customer.
· Quality Assurance: Is oriented towards preventing defects. Quality Assurance ensures all parties
concerned with the project adhere to the process and procedures, standards and templates and test
readiness reviews.
· Quality Control: quality control or quality engineering is a set of measures taken to ensure that
defective products or services are not produced, and that the design meets performance requirements.
· Verification: Verification ensures the product is designed to deliver all functionality to the customer; it
typically involves reviews and meetings to evaluate documents, plans, code, requirements and
specifications; this can be done with checklists, issues lists, walkthroughs and inspection meetings.
· Validation: Validation ensures that functionality, as defined in requirements, is the intended behavior of
the product; validation typically involves actual testing and takes place after verifications are completed.
[/size]
4. Most common software errors
Following are the most common software errors that aid you in software testing. This helps you to identify
errors systematically and increases the efficiency and productivity of software testing.
Types of errors with examples](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-159-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
Like any other process in software testing, the major tasks in test planning are to â Develop Test
Strategy, Critical Success Factors, Define Test Objectives, Identify Needed Test Resources, Plan Test
Environment, Define Test Procedures, Identify Functions To Be Tested, Identify Interfaces With Other
Systems or Components, Write Test Scripts, Define Test Cases, Design Test Data, Build Test Matrix,
Determine Test Schedules, Assemble Information, Finalize the Plan
6. Test Case Development
A test case is a detailed procedure that fully tests a feature or an aspect of a feature. While the test plan
describes what to test, a test case describes how to perform a particular test. You need to develop test
cases for each test listed in the test plan.
General Guidelines
As a tester, the best way to determine the compliance of the software to requirements is by designing
effective test cases that provide a thorough test of a unit. Various test case design techniques enable the
testers to develop effective test cases. Besides, implementing the design techniques, every tester needs
to keep in mind general guidelines that will aid in test case design:
a. The purpose of each test case is to run the test in the simplest way possible. [Suitable techniques -
Specification derived tests, Equivalence partitioning]
b. Concentrate initially on positive testing i.e. the test case should show that the software does what it is
intended to do. [Suitable techniques - Specification derived tests, Equivalence partitioning, State-
transition testing]
c. Existing test cases should be enhanced and further test cases should be designed to show that the
software does not do anything that it is not specified to do i.e. Negative Testing [Suitable techniques -
Error guessing, Boundary value analysis, Internal boundary value testing, State-transition testing]
d. Where appropriate, test cases should be designed to address issues such as performance, safety
requirements and security requirements [Suitable techniques - Specification derived tests]
e. Further test cases can then be added to the unit test specification to achieve specific test coverage
objectives. Once coverage tests have been designed, the test procedure can be developed and the tests
executed [Suitable techniques - Branch testing, Condition testing, Data definition-use testing, State-
transition testing]
Test Case â Sample Structure
The manner in which a test case is depicted varies between organizations. Anyhow, many test case
templates are in the form of a table, for example, a 5-column table with fields:
Test Case ID
Test Case Description
Test Dependency/Setup
Input Data Requirements/Steps
Expected Results
Pass/Fail
Test Case Design Techniques](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-162-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
ïï ï ï ï ï ï ï To unearth & correct defects
ïï ï ï ï ï ï ï To detect defects early & to reduce cost of defect fixing
ïï ï ï ï ï ï ï To avoid user detecting problems
ïï ï ï ï ï ï ï To ensure that product works as users expected it to.
Basic definitions of software testing and
quality assurance
Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Interview Faq's, Manual Testing Basics | Leave a comment
acceptance criteria: The exit criteria that a component or system must satisfy
in order to be accepted by a user, customer, or other authorized entity. [IEEE
610]
acceptance testing: Formal testing with respect to userneeds,requirements, and business processes conducted to
determine whether or not a systemsatisfies the acceptance criteria and to enable the user, customers or other
authorized entity to determine whether or not to accept the system.[After IEEE 610]
accessibility testing: Testing to determine the ease by which users with disabilities can use a component or system.
[Gerrard]
accuracy: The capability of the software product to provide the right or agreed results or effects with the needed
degree of precision. [ISO 9126] See also functionality testing.
actual result: The behavior produced/observed when a component or systemis tested.
ad hoc testing: Testing carried out informally; no formal test preparation takes place, no recognized test design
technique is used, there are no expectations for results and randomness guides the test execution activity.
adaptability: The capability of the software product to be adapted for different specified environments without
applying actions or means other than those provided for this purpose for the software considered. [ISO 9126] See
also portability testing.
agile testing: Testing practice for a project using agile methodologies, such as extreme programming (XP), treating
development as the customer of testing and emphasizing the test-first design paradigm.
alpha testing: Simulated or actual operational testing by potential users/customers or an independent test teamat
the developersâsite, but outside the development organization. Alpha testing is often employed as a form of internal
acceptance testing.
analyzability: The capability of the software product to be diagnosed for deficiencies or causes of failures in the
software, or for the parts to be modified to be identified. [ISO 9126] See also maintainability testing.
anomaly: Any condition that deviates from expectation based on requirements specifications, design documents,
user documents, standards,etc.or from someoneâs perception or experience. Anomalies may be found during, but](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-173-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
not limited to, reviewing, testing,analysis,compilation, or use of software products or applicable documentation.
[IEEE 1044] See also defect, deviation, error, fault, failure, incident, problem.
attractiveness: The capability of the software product to be attractive to the user. [ISO 9126]
audit: An independent evaluation of software products or processes to ascertain compliance to standards,
guidelines, specifications, and/orprocedures based on objective criteria, including documents that specify:
(1) the form or content of the products to be produced
(2) the process by which the products shall be produced
(3) how compliance to standards orguidelines shall be measured. [IEEE 1028]
audit trail: A path by which the original input to a process (e.g. data) can be traced back through the process,taking
the process output as a starting point. This facilitates defect analysis and allows a process audit to be carried out.
[After TMap]
automated testware: Testware used in automated testing,such as tool scripts.
availability: The degree to which a component or system is operational and accessible when required for use. Often
expressed as a percentage.[IEEE 610]
B
back-to-back testing: Testing in which two or more variants of a component or systemare executed with the same
inputs,the outputs compared, and analyzed in cases of discrepancies.[IEEE 610]
baseline: A specification or software product that has been formally reviewed or agreed upon,that thereafter serves
as the basis for further development, and that can be changed only through a formal change control process.[After
IEEE 610]
basic block: A sequence of one or more consecutive executable statements containing no branches.
basis test set: A set of test cases derived from the internal structure or specification to ensure that 100% of a
specified coverage criterion is achieved.
behavior: The response of a component or systemto a set of input values and preconditions.
benchmark test: (1) A standard against which measurements or comparisons can be made. (2) A test that is be used
to compare components or systems to each other or to a standard as in (1). [After IEEE 610]
bespoke software: Software developed specifically for a set of users or customers. The opposite is off-the-shelf
software.
best practice: A superior method or innovative practice that contributes to the improved performance of an
organization under given context, usually recognized as âbestâby other peer organizations.
beta testing: Operational testing by potential and/or existing users/customers at an external site not otherwise
involved with the developers,to determine whether or not a component or systemsatisfies the user/customerneeds
and fits within the business processes.Beta testing is often employed as a form of external acceptance testing in
order to acquired feedback from the market.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-174-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
big-bang testing: A type of integration testing in which software elements, hardware elements, or both are
combined all at once into a component or an overall system, rather than in stages.[After IEEE 610] See also
integration testing.
black box testing: Testing, either functional or non-functional, without reference to the internal structure of the
component or system.
black box test design techniques: Documented procedure to derive and select test cases based on an analysis of the
specification, either functional or non-functional, of a component or system without reference to its internal
structure.
blocked test case:A test case that cannot be executed because the preconditions for its execution are not fulfilled.
bottom-up testing: An incremental approach to integration testing where the lowest level components are tested first,
and then used to facilitate the testing of higher level components.This process is repeated until the component at the
top of the hierarchy is tested.See also integration testing.
boundary value: An input value or output value which is on the edge of an equivalence partition or at the smallest
incremental distance on either side of an edge, for example the minimum or maximum value of a range.
boundary value analysis: A black box test design technique in which test cases are designed based on boundary
values.
boundary value coverage: The percentage of boundary values that have been exercised by a test suite.
branch: A basic block that can be selected for execution based on a program construct in which one of two or more
alternative program paths are available, e.g. case,jump, go to, ifthen- else.
branch coverage: The percentage of branches that have been exercised by a test suite. 100% branch coverage implies
both 100% decision coverage and 100% statement coverage.
branch testing:A white box test design technique in which test cases are designed to execute branches.
business process-based testing:An approach to testing in which test cases are designed based on descriptions and/or
knowledge of business processes.
C
Capability Maturity Model (CMM): A five level staged framework that describes the key elements of an effective
software process.The Capability Maturity Model covers practices for planning, engineering and managing software
development and maintenance. [CMM]
Capability Maturity Model Integration (CMMI): A framework that describes the key elements of an effective
product development and maintenance process.The Capability Maturity Model Integration covers practices for
planning, engineering and managing product development and maintenance. CMMI is the designated successorof
the CMM. [CMMI]](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-175-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
capture/playbacktool: A type of test execution tool where inputs are recorded during manual testing in order to
generate automated test scripts that can be executed later (i.e. replayed). These tools are often used to support
automated regression testing.
CASE: Acronym for Computer Aided Software Engineering.
CAST: Acronym for Computer Aided Software Testing. See also test automation.
cause-effect graph: A graphical representation of inputs and/or stimuli (causes)with their associated outputs
(effects), which can be used to design test cases.
cause-effect graphing: A black box test design technique in which test cases are designed from cause-effect graphs.
[BS 7925/2]
certification: The process ofconfirming that a component,system or person complies with its specified
requirements, e.g. by passing an exam.
changeability: The capability of the software product to enable specified modifications to be implemented. [ISO
9126] See also maintainability.
classification tree method: A black box test design technique in which test cases,described by means of a
classification tree, are designed to execute combinations of representatives of input and/oroutput domains.
[Grochtmann]
code coverage: An analysis method that determines which parts of the software have been executed (covered) by the
test suite and which parts have not been executed, e.g. statement coverage, decision coverage or condition coverage.
co-existence: The capability of the software product to co-exist with other independent software in a common
environment sharing common resources.[ISO 9126] See portability testing.
complexity: The degree to which a component or systemhas a design and/orinternal structure that is difficult to
understand,maintain and verify. See also cyclomatic complexity.
compliance: The capability of the software product to adhere to standards,conventions orregulations in laws and
similar prescriptions. [ISO 9126]
compliance testing:The process oftesting to determine the compliance of component or system.
component: A minimal software item that can be tested in isolation.
component integration testing:Testing performed to expose defects in the interfaces and interaction between
integrated components.
component specification: A description of a componentâs function in terms of its output values for specified input
values under specified conditions,and required non-functional behavior (e.g. resource-utilization).
component testing:The testing of individual software components. [After IEEE 610]
compound condition: Two or more single conditions joined by means of a logical operator (AND, OR or XOR), e.g.
âA>B AND C>1000â.
concurrency testing: Testing to determine how the occurrence of two or more activities within the same interval of
time, achieved either by interleaving the activities or by simultaneous execution, is handled by the component or
system. [After IEEE 610]](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-176-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
condition: A logical expression that can be evaluated as True or False, e.g. A>B. See also test condition.
condition coverage: The percentage of condition outcomes that have been exercised by a test suite.100% condition
coverage requires each single condition in every decision statement to be tested as True and False.
condition determination coverage: The percentage of all single condition outcomes that independently affect a
decision outcome that have been exercised by a test case suite. 100% condition determination coverage implies
100% decision condition coverage.
condition determination testing: A white box test design technique in which test cases are designed to execute single
condition outcomes that independently affect a decision outcome.
condition testing:A white box test design technique in which test cases are designed to execute condition outcomes.
condition outcome: The evaluation of a condition to True or False.
configuration: The composition of a component or systemas defined by the number, nature, and interconnections of
its constituent parts.
configuration auditing: The function to check on the contents of libraries of configuration items, e.g. for standards
compliance. [IEEE 610]
configuration control: An element of configuration management, consisting of the evaluation, co-ordination,
approval or disapproval, and implementation of changes to configuration items after formal establishment of their
configuration identification. [IEEE
610]
configuration identification: An element of configuration management, consisting of selecting the configuration
items for a system and recording their functional and physicalcharacteristics in technical documentation. [IEEE
610]
configuration item: An aggregation of hardware, software or both, that is designated for configuration management
and treated as a single entity in the configuration management process.[IEEE 610]
configuration management: A discipline applying technical and administrative direction and surveillance to: identify
and document the functional and physical characteristics of a configuration item, control changes to those
characteristics, record and report change processing and implementation status,and verify compliance with specified
requirements. [IEEE 610]
consistency:The degree of uniformity, standardization, and freedom from contradiction among the documents or
parts of a component or system. [IEEE 610]
control flow: An abstract representation of all possible sequences ofevents (paths)in the execution through a
component or system.
conversion testing:Testing of software used to convert data from existing systems for use in replacement systems.
COTS: Acronym for Commercial Off-The-Shelf software.
coverage: The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test
suite.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-177-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
coverage analysis: Measurement of achieved coverage to a specified coverage item during test execution referring to
predetermined criteria to determine whether additional testing is required and if so,which test cases are needed.
coverage item: An entity or property used as a basis for test coverage, e.g. equivalence partitions or code statements.
coverage tool: A tool that provides objective measures of what structural elements, e.g. statements,branches have
been exercised by the test suite.
cyclomatic complexity: The number of independent paths through a program. Cyclomatic complexity is defined as:
L â N + 2P, where â L = the number of edges/links in a graph â N = the number of nodes in a graph â P
= the number of disconnected parts of the graph (e.g. a calling graph and a subroutine). [After McCabe]
D
data definition: An executable statement where a variable is assigned a value.
data driven testing: A scripting technique that stores test input and expected results in a table or spreadsheet, so that
a single control script can execute all of the tests in the table. Data driven testing is often used to support the
application of test execution tools such as capture/playbacktools. [Fewster and Graham] See also keyword driven
testing.
data flow: An abstract representation of the sequence and possible changes of the state of data objects,where the
state of an object is any of: creation, usage,or destruction.[Beizer]
data flow analysis: A form of static analysis based on the definition and usage of variables.
data flow coverage: The percentage of definition-use pairs that have been exercised by a test case suite.
data flow test: A white box test design technique in which test cases are designed to execute definition and use pairs
of variables.
debugging:The process of finding, analyzing and removing the causes of failures in software.
debugging tool: A tool used by programmers to reproduce failures, investigate the state of programs and find the
corresponding defect. Debuggers enable programmers to execute programs step by step,to halt a program at any
program statement and to set and examine program variables.
decision: A program point at which the control flow has two or more alternative routes. A node with two or more
links to separate branches.
decision condition coverage: The percentage of all condition outcomes and decision outcomes that have been
exercised by a test suite.100% decision condition coverage implies both 100% condition coverage and 100%
decision coverage.
decision condition testing:A white box test design technique in which test cases are designed to execute condition
outcomes and decision outcomes.
decision coverage: The percentage of decision outcomes that have been exercised by a test suite. 100% decision
coverage implies both 100% branch coverage and 100% statement coverage.
decision table: A table showing combinations of inputs and/or stimuli (causes)with their associated outputs and/or
actions (effects), which can be used to design test cases.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-178-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
decision table testing: A black box test design techniques in which test cases are designed to execute the
combinations of inputs and/orstimuli (causes)shown in a decision table. [Veenendaal]
decision testing:A white box test design technique in which test cases are designed to execute decision outcomes.
decision outcome: The result of a decision (which therefore determines the branches to be taken).
defect: A flaw in a component or systemthat can cause the component or systemto fail to perform its required
function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a
failure of the component or system.
defect density:The number of defects identified in a component or systemdivided by the size of the component or
system(expressed in standard measurement terms, e.g. lines-ofcode, number of classes or function points).
Defect Detection Percentage (DDP): the number of defects found by a test phase,divided by the number found by
that test phase and any other means afterwards.
defect report: A document reporting on any flaw in a component or system that can cause the component or system
to fail to perform its required function. [After IEEE 829]
defect management: The process of recognizing, investigating, taking action and disposing of defects. It involves
recording defects, classifying them and identifying the impact. [After IEEE 1044]
defect masking: An occurrence in which one defect prevents the detection of another.[After IEEE 610]
definition-use pair: The association of the definition of a variable with the use of that variable. Variable uses include
computational (e.g. multiplication) or to direct the execution of a path (âpredicateâ use).
deliverable: Any (work) product that must be delivered to someone other that the (work) productâs author.
design-based testing:An approach to testing in which test cases are designed based on the architecture and/or
detailed design of a component or system (e.g. tests ofinterfaces between components or systems).
desk checking: Testing of software or specification by manual simulation of its execution.
development testing: Formal or informal testing conducted during the implementation of a component or system,
usually in the development environment by developers.[After IEEE 610]
documentation testing:Testing the quality of the documentation, e.g. user guide or installation guide.
domain: The set from which valid input and/or output values can be selected.
driver: A software component or test tool that replaces a component that takes care of the control and/or the calling
of a component or system.[After TMap]
dynamic analysis: The process of evaluating behavior, e.g. memory performance, CPU usage,of a systemor
component during execution. [After IEEE 610]
dynamic comparison: Comparison of actual and expected results, performed while the software is being executed,
for example by a test execution tool.
dynamic testing: Testing that involves the execution of the software of a component or system.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-179-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
E
efficiency: The capability of the software product to provide appropriate performance, relative to the amount of
resources used understated conditions.[ISO 9126]
efficiency testing:The process of testing to determine the efficiency of a software product.
elementary comparison testing: A black box test design techniques in which test cases are designed to execute
combinations of inputs using the concept of condition determination coverage. [TMap]
emulator: A device, computer program, or systemthat accepts the same inputs and produces the same outputs as a
given system. [IEEE 610] See also simulator.
entry criteria: the set of generic and specific conditions for permitting a process to go forward with a defined task,
e.g. test phase.The purpose of entry criteria is to prevent a task from starting which would entail more (wasted)
effort compared to the effort needed to remove the failed entry criteria. [Gilb and Graham]
entry point: The first executable statement within a component.
equivalence partition: A portion of an input or output domain for which the behavior of a component or systemis
assumed to be the same, based on the specification.
equivalence partition coverage: The percentage of equivalence partitions that have been exercised by a test suite.
equivalence partitioning: A black box test design technique in which test cases are designed to execute
representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once.
error: A human action that produces an incorrect result. [After IEEE 610]
error guessing:A test design technique where the experience of the testeris used to anticipate what defects might be
present in the component or system undertest as a result of errors made, and to design tests specifically to expose
them.
error seeding: The process of intentionally adding known defects to those already in the component or system for the
purpose of monitoring the rate of detection and removal, and estimating the number of remaining defects. [IEEE
610]
error tolerance: The ability of a system or component to continue normal operation despite the presence of erroneous
inputs.[After IEEE 610].
exception handling: Behavior of a component or systemin response to erroneous input, from either a human useror
from another component or system,or to an internal failure.
executable statement: A statement which, when compiled, is translated into object code, and which will be executed
procedurally when the program is running and may perform an action on data.
exercised: A program element is said to be exercised by a test case when the input value causes the execution of that
element, such as a statement, decision, or otherstructural element.
exhaustive testing: A test approach in which the test suite comprises all combinations of input values and
preconditions.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-180-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
exit criteria: The set of generic and specific conditions,agreed upon with the stakeholders,for permitting a process
to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when
there are still outstanding parts ofthe task which have not been finished. Exit criteria are used by testing to report
against and to plan when to stop testing.[After Gilb and Graham]
exit point: The last executable statement within a component.
expected result: The behavior predicted by the specification, or anothersource, of the component or systemunder
specified conditions.
exploratory testing:Testing where the tester actively controls the design of the tests as those tests are performed and
uses information gained while testing to design new and better tests.[Bach]
F
fail: A test is deemed to fail if its actual result does not match its expected result.
failure: Actual deviation of the component or systemfrom its expected delivery, service or result. [After Fenton]
failure mode: The physical or functional manifestation of a failure. For example, a systemin failure mode may be
characterized by slow operation, incorrect outputs,or complete termination of execution.
Failure Mode and Effect Analysis (FMEA): A systematic approach to risk identification and analysis of identifying
possible modes of failure and attempting to prevent their occurrence.
failure rate: The ratio of the number of failures of a given category to a given unit of measure, e.g. failures per unit
of time, failures per number of transactions,failures per number of computer runs. [IEEE 610]
fault tolerance: The capability of the software product to maintain a specified level of performance in cases of
software faults (defects) or of infringement of its specified interface. [ISO 9126] See also reliability.
fault tree analysis: A method used to analyze the causes offaults (defects).
feasible path: A path for which a set of input values and preconditions exists which causes it to be executed.
feature: An attribute of a component or system specified or implied by requirements documentation (for example
reliability, usability or design constraints).[After IEEE 1008]
finite state machine: A computational model consisting of a finite number of states and transitions between those
states,possibly with accompanying actions. [IEEE 610]
formal review: A review characterized by documented procedures and requirements, e.g. inspection.
frozen test basis: A test basis document that can only be amended by a formal change control process.See also
baseline.
Function Point Analysis (FPA): Method aiming to measure the size of the functionality of an information system.
The measurement is independent of the technology. This measurement may be used as a basis for the measurement
of productivity, the estimation of the needed resources,and project control.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-181-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
functional integration: An integration approach that combines the components or systems for the purpose of getting
a basic functionality working early. See also integration testing.
functional requirement: A requirement that specifies a function that a component or systemmust perform. [IEEE
610]
functional test design technique: Documented procedure to derive and select test cases based on an analysis of the
specification of the functionality of a component or systemwithout reference to its internal structure.See also black
box test design technique.
functional testing: Testing based on an analysis of the specification of the functionality of a component or system.
See also black box testing.
functionality: The capability of the software product to provide functions which meet stated and implied needs when
the software is used under specified conditions.[ISO 9126]
functionality testing: The process of testing to determine the functionality of a software product.
G
glass box testing: See white box testing.
H
heuristic evaluation: A static usability test technique to determine the compliance of a user interface with recognized
usability principles (the so-called âheuristicsâ).
high level test case: A test case without concrete (implementation level) values for input data and expected results.
horizontal traceability: The tracing of requirements for a test level through the layers of test documentation (e.g. test
plan, test design specification, test case specification and test procedure specification).
I
impact analysis: The assessment of change to the layers of development documentation, test documentation and
components,in order to implement a given change to specified requirements.
incremental development model: A development life cycle where a project is broken into a series of increments,
each of which delivers a portion of the functionality in the overal project requirements. The requirements are
prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this life
cycle model, each subproject follows a âmini V-modelâ with its own design, coding and testing phases.
incremental testing: Testing where components or systems are integrated and tested one or some at a time, until all
the components or systems are integrated and tested.
incident: Any event occurring during testing that requires investigation. [After IEEE 1008]
incident management: The process ofrecognizing, investigating, taking action and disposing of incidents. It involves
recording incidents, classifying them and identifying the impact. [After IEEE 1044]](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-182-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
incident management tool: A tool that facilitates the recording and status tracking of incidents found during testing.
They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of
incidents and provide reporting facilities.
incident report: A document reporting on any event that occurs during the testing which requires investigation.
[After IEEE 829]
independence:Separation of responsibilities, which encourages the accomplishment of objective testing.[After DO-
178b]
infeasible path: A path that cannot be exercised by any set of possible input values.
informal review: A review not based on a formal (documented) procedure.
input: A variable (whether stored within a component or outside)that is read by a component.
input domain: The set from which valid input values can be selected.. See also domain.
input value: An instance of an input. See also input.
inspection: A type of review that relies on visual examination of documents to detect defects, e.g. violations of
development standards and non-conformance to higher level documentation. The most formal review technique and
therefore always based on a documented procedure. [After IEEE 610, IEEE 1028]
installability: The capability of the software product to be installed in a specified environment [ISO 9126]. See also
portability.
installability testing: The process of testing the installability of a software product.See also portability testing.
installation guide: Supplied instructions on any suitable media, which guides the installer through the installation
process.This may be a manual guide, step-by-step procedure,installation wizard, or any other similar process
description.
installation wizard: Supplied software on any suitable media, which leads the installer through the installation
process.It normally runs the installation process,provides feedback on installation results,and prompts for options.
instrumentation: The insertion of additional code into the program in order to collect information about program
behavior during execution.
instrumenter: A software tool used to carry out instrumentation.
intake test:A special instance of a smoke test to decide if the component or systemis ready for detailed and further
testing.An intake test is typically carried out at the start of the test execution phase.
integration: The process of combining components or systems into larger assemblies.
integration testing: Testing performed to expose defects in the interfaces and in the interactions between integrated
components or systems.See also component integration testing, systemintegration testing.
interface testing: An integration test type that is concerned with testing the interfaces between components or
systems.
interoperability: The capability of the software product to interact with one or more specified components or
systems.[After ISO 9126] See also functionality.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-183-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
interoperability testing:The process of testing to determine the interoperability of a software product. See also
functionality testing.
invalid testing: Testing using input values that should be rejected by the component or system. See also error
tolerance.
isolation testing: Testing of individual components in isolation from surrounding components, with surrounding
components being simulated by stubs and drivers, if needed.
K
keyword driven testing: A scripting technique that uses data files to contain not only test data and expected results,
but also keywords related to the application being tested.The keywords are interpreted by special supporting scripts
that are called by the control script for the test.See also data driven testing.
L
LCSAJ: A Linear Code Sequence And Jump, consisting of the following three items (conventionally identified by
line numbers in a source code listing): the start of the linear sequence ofexecutable statements,the end of the linear
sequence,and the target line to which control flow is transferred at the end of the linear sequence.
LCSAJ coverage: The percentage of LCSAJs of a component that have been exercised by a test suite.100% LCSAJ
coverage implies 100% decision coverage.
LCSAJ testing:A white box test design technique in which test cases are designed to execute LCSAJs.
learnability: The capability of the software product to enable the userto learn its application. [ISO 9126] See also
usability.
load test: A test type concerned with measuring the behavior of a component or system with increasing load, e.g.
number of parallel users and/ornumbers of transactions to determine what load can be handled by the component or
system.
low level test case:A test case with concrete (implementation level) values for input data and expected results.
M
maintenance: Modification of a software product after delivery to correct defects, to improve performance or other
attributes,or to adapt the product to a modified environment. [IEEE 1219]
maintenance testing:Testing the changes to an operational systemor the impact of a changed environment to an
operational system.
maintainability: The ease with which a software product can be modified to correct defects, modified to meet new
requirements, modified to make future maintenance easier, or adapted to a changed environment. [ISO 9126]
maintainability testing: The process of testing to determine the maintainability of a software product.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-184-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
management review: A systematic evaluation of software acquisition, supply,development, operation, or
maintenance process,performed by or on behalf of management that monitors progress,determines the status of
plans and schedules,confirms requirements and heir systemallocation, or evaluates the effectiveness of
management approaches to achieve fitness for purpose.[After IEEE 610, IEEE 1028]
maturity: (1) The capability of an organization with respect to the effectiveness and efficiency of its processes and
work practices. See also Capability Maturity Model, Test Maturity Model. (2) The capability of the software product
to avoid failure as a result of defects in the software. [ISO 9126] See also reliability.
measure: The number or category assigned to an attribute of an entity by making a measurement [ISO 14598].
measurement: The process of assigning a number or category to an entity to describe an attribute of that entity. [ISO
14598]
measurement scale: A scale that constrains the type of data analysis that can be performed on it. [ISO 14598]
memory leak: A defect in a programâs dynamic store allocation logic that causes it to fail to reclaim memory after it
has finished using it, eventually causing the program to fail due to lack of memory.
metric: A measurement scale and the method used for measurement. [ISO 14598]
milestone: A point in time in a project at which defined (intermediate)
deliverables and results should be ready.
moderator: The leader and main person responsible for an inspection or other review process.
monitor: A software tool or hardware device that run concurrently with the component or systemunder test and
supervises,records and/oranalyses the behavior of the component or system.[After IEEE 610]
multiple condition coverage: The percentage of combinations of all single
condition outcomes within one statement that have been exercised by a test
suite. 100% multiple condition coverage implies 100% condition determination
coverage.
multiple condition testing:A white box test design technique in which test cases are designed to execute
combinations of single condition outcomes (within one statement).
mutation analysis: A method to determine test suite thoroughness by measuring the extent to which a test suite can
discriminate the program from slight variants (mutants) of the program.
N
N-switch coverage: The percentage of sequences ofN+1 transitions that have been exercised by a test suite. [Chow]
N-switch testing: A form of state transition testing in which test cases are designed to execute all valid sequences of
N+1 transitions.[Chow] See also state transition testing.
negative testing:Tests aimed at showing that a component or systemdoes not work. Negative testing is related to
the testersâattitude rather than a specific test approach or test design technique. [After Beizer].
non-conformity: Non fulfillment of a specified requirement. [ISO 9000]](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-185-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
non-functional requirement: A requirement that does not relate to functionality, but to attributes of such as
reliability, efficiency, usability, maintainability and portability.
non-functional testing:Testing the attributes of a component or system that do not relate to functionality, e.g.
reliability, efficiency, usability, maintainability and portability.
non-functional test design techniques:Methods used to design or select tests for nonfunctionaltesting.
O
off-the-shelf software: A software product that is developed for the general market, i.e. for a large number of
customers, and that is delivered to many customers in identical format.
operability: The capability of the software product to enable the userto operate and control it. [ISO 9126] See also
usability.
operational environment: Hardware and software products installed at usersâ or customersâ sites where the
component or systemunder test will be used.The software may include operating systems,database management
systems,and otherapplications.
operational profile testing: Statistical testing using a model of system operations (short duration tasks)and their
probability of typical use.[Musa]
operational testing: Testing conducted to evaluate a component or system in its operational environment. [IEEE 610]
output:A variable (whether stored within a component or outside)that is written by a component.
output domain: The set from which valid output values can be selected.See also domain.
output value: An instance of an output.See also output.
P
pair programming: A software development approach whereby lines of code (production and/ortest)of a component
are written by two programmers sitting at a single computer. This implicitly means ongoing real-time code reviews
are performed.
pair testing: Two testers work togetherto find defects. Typically, they share one computer and trade control of it
while testing.
Pass: A test is deemed to pass if its actual result matches its expected result.
pass/fail criteria: Decision rules used to determine whether a test item (function) or feature has passed orfailed a
test.[IEEE 829]
path: A sequence of events,e.g. executable statements,of a component or systemfrom an entry point to an exit
point.
path coverage: The percentage of paths that have been exercised by a test suite.100% path coverage implies 100%
LCSAJ coverage.
path sensitizing: Choosing a set of input values to force the execution of a given path.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-186-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
path testing: A white box test design technique in which test cases are designed to execute paths.
performance: The degree to which a system or component accomplishes its designated functions within given
constraints regarding processing time and throughput rate.[After IEEE 610] See efficiency.
performance indicator: A high level metric of effectiveness and/or efficiency used to guide and control progressive
development, e.g. Defect Detection Percentage (DDP) for testing.[CMMI]
performance testing:The process of testing to determine the performance of a software product.See efficiency
testing.
performance testing tool: A tool to support performance testing and that usually has two main facilities: load
generation and test transaction measurement. Load generation can simulate either multiple users or high volumes of
input data. During execution, response time measurements are taken from selected transactions and these are logged.
Performance testing tools normally provide reports based on test logs and graphs of load against response times.
phase test plan: A test plan that typically addresses one test level.
portability: The ease with which the software product can be transferred from one hardware or software environment
to another.[ISO 9126]
portability testing: The process oftesting to determine the portability of a software product.
postcondition:Environmental and state conditions that must be fulfilled after the execution of a test or test
procedure.
post-execution comparison: Comparison of actual and expected results,performed after the software has finished
running.
precondition: Environmental and state conditions that must be fulfilled before the component or system can be
executed with a particular test or test procedure.
Priority: The level of (business)importance assigned to an item, e.g. defect.
process cycle test:A black box test design technique in which test cases are designed toexecute business procedures
and processes.[TMap]
process:A set of interrelated activities, which transform inputs into outputs.[ISO 12207]
project: A project is a unique set of coordinated and controlled activities with start and finish dates undertaken an
objective conforming to specific requirements, including the constraints of time, cost and resources.[ISO 9000]
project test plan: A test plan that typically addresses multiple test levels.
pseudo-random: A series which appears to be random but is in fact generated according to some prearranged
sequence.
Q
quality: The degree to which a component, systemor process meets specified requirements and/oruser/customer
needs and expectations. [After IEEE 610]](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-187-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
quality assurance:Part of quality management focused on providing confidence that quality requirements will be
fulfilled. [ISO 9000]
quality attribute: A feature or characteristic that affects an itemâs quality. [IEEE 610]
quality management: Coordinated activities to direct and control an organization with regard to quality. Direction
and control with regard to quality generally includes the establishment of the quality policy and quality objectives,
quality planning, quality control, quality assurance and quality improvement. [ISO 9000]
R
random testing: A black box test design technique where test cases are selected, possibly using a pseudo-random
generation algorithm, to match an operational profile. This technique can be used for testing non-functional
attributes such as reliability and performance.
recoverability: The capability of the software product to re-establish a specified level of performance and recover
the data directly affected in case of failure. [ISO 9126] See also reliability.
recoverability testing: The process of testing to determine the recoverability of a software product. See also
reliability testing.
regression testing: Testing of a previously tested program following modification to ensure that defects have not
been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed
when the software or its environment is changed.
release note: A document identifying test items, their configuration, current status and otherdelivery information
delivered by development to testing,and possibly other stakeholders,at the start of a test execution phase.[After
IEEE 829]
reliability: The ability of the software product to perform its required functions understated conditions for a
specified period of time, or for a specified number of operations. [ISO 9126]
reliability testing: The process of testing to determine the reliability of a software product.
replaceability: The capability of the software product to be used in place of anotherspecified software product for
the same purpose in the same environment. [ISO 9126] See also portability.
requirement: A condition or capability needed by a userto solve a problem or achieve an objective that must be met
or possessed by a system or system component to satisfy a contract, standard,specification, or other formally
imposed document. [After IEEE 610]
requirements-based testing:An approach to testing in which test cases are designed based on test objectives and test
conditions derived from requirements, e.g. tests that exercise specific functions or probe non-functional attributes
such as reliability or usability.
requirements management tool: A tool that supports the recording of requirements, requirements attributes (e.g.
priority, knowledge responsible)and annotation, and facilitates traceability through layers of requirements and](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-188-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
requirements change management. Some requirements management tools also provide facilities for static analysis,
such as consistency checking and violations to pre-defined requirements rules.
requirements phase:The period of time in the software life cycle during which the equirements for a software
product are defined and documented. [IEEE 610]
resource utilization: The capability of the software product to use appropriate amounts and types of resources,for
example the amounts of main and secondary memory used by the program and the sizes of required temporary or
overflow files, when the software performs its function under stated conditions.[After ISO 9126] See also
efficiency.
resource utilization testing: The process oftesting to determine the resource-utilization of a software product.
result: The consequence/outcome of the execution of a test.It includes outputs to screens,changes to data,reports,
and communication messages sent out.See also actual result, expected result.
resumption criteria: The testing activities that must be repeated when testing is re-started after a suspension. [After
IEEE 829]
re-testing: Testing that runs test cases that failed the last time they were run, in order to verify the success of
corrective actions.
review: An evaluation of a product or project status to ascertain discrepancies from planned results and to
recommend improvements. Examples include management review, informal review, technical review, inspection,
and walkthrough. [After IEEE 1028]
reviewer: The person involved in the review who shall identify and describe anomalies in the product or project
under review. Reviewers can be chosen to represent different viewpoints and roles in the review process.
risk: A factor that could result in future negative consequences; usually expressed as impact and likelihood.
risk analysis: The process of assessing identified risks to estimate their impact and probability of occurrence
(likelihood).
risk-based testing: Testing oriented towards exploring and providing information about product risks. [After
Gerrard]
risk control: The process through which decisions are reached and protective measures are implemented for reducing
risks to, or maintaining risks within, specified levels.
risk identification: The process ofidentifying risks using techniques such as brainstorming, checklists and failure
history.
risk management: Systematic application of procedures and practices to the tasks of identifying, analyzing,
prioritizing, and controlling risk.
robustness:The degree to which a component or system can function correctly in the presence of invalid inputs or
stressfulenvironmental conditions.[IEEE 610] See also errortolerance, fault-tolerance.
root cause:An underlying factor that caused a non-conformance and possibly should be permanently eliminated
through process improvement.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-189-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
S
safety: The capability of the software product to achieve acceptable levels of risk of harm to people, business,
software, property or the environment in a specified context of use. [ISO 9126]
safety testing: The process of testing to determine the safety of a software product.
scalability: The capability of the software product to be upgraded to accommodate increased loads. [After Gerrard]
scalability testing: Testing to determine the scalability of the software product.
scribe: The person who has to record each defect mentioned and any suggestions forimprovement during a review
meeting, on a logging form. The scribe has to make ensure that the logging form is readable and understandable.
scripting language: A programming language in which executable test scripts are written, used by a test execution
tool (e.g. a capture/replay tool).
security: Attributes of software products that bear on its ability to prevent unauthorized access,whether accidental or
deliberate, to programs and data. [ISO 9126]
security testing:Testing to determine the security of the software product.
severity: The degree of impact that a defect has on the development or operation of a component or system. [After
IEEE 610]
simulation: The representation of selected behavioral characteristics of one physical or abstract systemby another
system. [ISO 2382/1]
simulator: A device, computer program or systemused during testing,which behaves or operates like a given system
when provided with a set of controlled inputs. [After IEEE 610, DO178b] See also emulator.
smoke test: A subset ofall defined/planned test cases that coverthe main functionality of a component or system, to
ascertaining that the most crucial functions of a program work, but not bothering with finer details. A daily build and
smoke test is among industry best practices. See also intake test.
software quality: The totality of functionality and features of a software product that bear on its ability to satisfy
stated or implied needs.[After ISO 9126]
specification: A document that specifies, ideally in a complete, precise and verifiable manner, the requirements,
design,behavior, or other characteristics of a component or system, and, often, the procedures for determining
whether these provisions have been satisfied. [After IEEE 610]
specification-based test design technique: See black box test design technique.
specified input: An input for which the specification predicts a result.
stability: The capability of the software product to avoid unexpected effects from modifications in the software.
[ISO 9126] See also maintainability.
state diagram: A diagram that depicts the states that a component or system can assume, and shows the events or
circumstances that cause and/or result from a change from one state to another.[IEEE 610]
state table: A grid showing the resulting transitions for each state combined with each possible event,showing both
valid and invalid transitions.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-190-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
state transition: A transition between two states ofa component or system.
state transition testing:A black box test design technique in which test cases are designed to execute valid and
invalid state transitions.See also N-switch testing.
statement: An entity in a programming language, which is typically the smallest indivisible unit of execution.
statement coverage: The percentage of executable statements that have been exercised by a test suite.
statement testing: A white box test design technique in which test cases are designed toexecute statements.
static analysis: Analysis of software artifacts, e.g. requirements or code, carried out without execution of these
software artifacts.
static analyzer: A tool that carries out static analysis.
static code analysis: Analysis of program source code carried out without execution of that software.
static code analyzer: A tool that carries out static code analysis. The tool checks source code, for certain properties
such as conformance to coding standards,quality metrics or data flow anomalies.
static testing: Testing of a component or system at specification or implementation level without execution of that
software, e.g. reviews or static code analysis.
statistical testing:A test design technique in which a model of the statistical distribution of the input is used to
construct representative test cases.See also operational profile testing.
status accounting:An element of configuration management, consisting of the recording andreporting of information
needed to manage a configuration effectively. This information includes a listing of the approved configuration
identification, the status of proposed changes to the configuration, and the implementation status ofthe approved
changes.[IEEE 610]
Stress testing: Testing conducted to evaluate a systemor component at or beyond the limits of its specified
requirements. [IEEE 610]
structural coverage: Coverage measures based on the internal structure of the component.
structural test design technique: See white box test design technique.
stub:A skeletal or special-purpose implementation of a software component, used to develop or test a component
that calls or is otherwise dependent on it. It replaces a called component. [After IEEE 610]
subpath:A sequence ofexecutable statements within a component.
suspension criteria: The criteria used to (temporarily) stop all or a portion of the testing activities on the test items.
[After IEEE 829]
suitability: The capability of the software product to provide an appropriate set of functions for specified tasks and
user objectives.[ISO 9126] See also functionality.
Software Usability Measurement Inventory (SUMI): A questionnaire based usability test technique to evaluate the
usability, e.g. user-satisfaction,of a component or system. [Veenendaal]
syntaxtesting: A black box test design technique in which test cases are designed based upon the definition of the
input domain and/or output domain.
system: A collection of components organized to accomplish a specific function or set of functions.[IEEE 610]](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-191-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
systemintegration testing:Testing the integration of systems and packages; testing interfaces to external
organizations (e.g. Electronic Data Interchange, Internet).
systemtesting: The process of testing an integrated system to verify that it meets specified requirements. [Hetzel]
T
technical review: A peer group discussion activity that focuses on achieving consensus on the technical approach to
be taken. A technical review is also known as a peer review. [Gilb and Graham, IEEE 1028]
test approach: The implementation of the test strategy for a specific project. It typically includes the decisions made
that follow based on the (test)projectâs goal and the risk assessment carried out, starting points regarding the test
process,the test design techniques to be applied, exit criteria and test types to be performed.
test automation: The use of software to perform or support test activities, e.g. test management, test design,test
execution and results checking.
test basis: All documents from which the requirements of a component or systemcan be inferred. The
documentation on which the test cases are based.If a document can be amended only by way of formal amendment
procedure, then the test basis is called a frozen test basis.[After TMap]
test case: A set of input values, execution preconditions, expected results and execution postconditions, developed
for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with
a specific requirement. [After IEEE 610]
test case specification: A document specifying a set of test cases (objective, inputs, test actions,expected results,and
execution preconditions) for a test item. [After IEEE 829]
test charter: A statement of test objectives,and possibly test ideas. Test charters are amongst other used in
exploratory testing.See also exploratory testing.
test comparator: A test tool to perform automated test comparison.
test comparison: The process of identifying differences between the actual results produced by the component or
systemunder test and the expected results for a test.Test comparison can be performed during test execution
(dynamic comparison) or after test execution.
test condition: An item or event of a component or system that could be verified by one or more test cases,e.g. a
function, transaction, quality attribute, or structural element.
test data: Data that exists (for example, in a database)before a test is executed, and thataffects or is affected by the
component or systemunder test.
test data preparation tool: A type of test tool that enables data to be selected from existing databases orcreated,
generated, manipulated and edited for use in testing.
test design specification: A document specifying the test conditions (coverage items) for a test item, the detailed test
approach and identifying the associated high level test cases.[After IEEE 829]](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-192-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
test design tool: A tool that support the test design activity by generating test inputs from a specification that may be
held in a CASE tool repository, e.g. requirements management tool, or from specified test conditions held in the tool
itself.
test design technique: A method used to derive or select test cases.
test environment: An environment containing hardware, instrumentation, simulators, software tools,and other
support elements needed to conduct a test.[After IEEE 610]
test evaluation report: A document produced at the end of the test process summarizing all testing activities and
results.It also contains an evaluation of the test process and lessons learned.
test execution: The process of running a test by the component or systemunder test,producing actual result(s).
test execution automation: The use of software, e.g. capture/playbacktools, to control the execution of tests,the
comparison of actual results to expected results,the setting up of test preconditions, and othertest control and
reporting functions.
test execution phase:The period of time in a software development life cycle during which the components of a
software product are executed, and the software product is evaluated to determine whether or not requirements have
been satisfied. [IEEE 610]
test execution schedule: A scheme for the execution of test procedures.The test procedures are included in the test
execution schedule in their context and in the order in which they are to be executed.
test execution technique: The method used to perform the actual test execution, either manually or automated.
test execution tool: A type of test tool that is able to execute other software using an automated test script, e.g.
capture/playback. [Fewster and Graham]
test harness:A test environment comprised of stubs and drivers needed to conduct a test.
test infrastructure: The organizational artifacts needed to perform testing,consisting of test environments, test tools,
office environment and procedures.
test item: The individual element to be tested.There usually is one test object and many test items. See also test
object.
test level: A group of test activities that are organized and managed together.A test level is linked to the
responsibilities in a project. Examples of test levels are component test,integration test,system test and acceptance
test.[After TMap]
test log: A chronological record of relevant details about the execution of tests.[IEEE 829]
test logging: The process of recording information about tests executed into a test log.
test manager: The person responsible for testing and evaluating a test object. The individual, who directs, controls,
administers plans and regulates the evaluation of a test object.
test management: The planning, estimating, monitoring and control of test activities, typically carried out by a test
manager.
Test Maturity Model (TMM): A five level staged framework for test process improvement, related to the Capability
Maturity Model (CMM) that describes the key elements of an effective test process.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-193-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
Test Process Improvement (TPI): A continuous framework for test process improvement that describes the key
elements of an effective test process,especially targeted at systemtesting and acceptance testing.
test object: The component or systemto be tested.See also test item.
test objective: A reason or purpose for designing and executing a test.
test oracle: A source to determine expected results to compare with the actual result of the software under test.An
oracle may be the existing system (for a benchmark), a user manual, or an individualâs specialized knowledge, but
should not be the code. [After Adrion]
test performance indicator: A metric, in general high level, indicating to what extent a certain target value or
criterion is met. Often related to test process improvement objectives, e.g. Defect Detection Percentage (DDP).
test phase:A distinct set of test activities collected into a manageable phase of a project, e.g. the execution activities
of a test level. [After Gerrard]
test plan: A document describing the scope,approach, resources and schedule of intended test activities. It identifies
amongst others test items, the features to be tested,the testing tasks,who will do each task, degree of tester
independence, the test environment, the test design techniques and test measurement techniques to be used,and the
rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process
[After IEEE 829]
test planning: The activity of establishing or updating a test plan.
test policy: A high level document describing the principles, approach and major objectives of the organization
regarding testing.
test point analysis (TPA): A formula based test estimation method based on function point analysis. [TMap]
test procedure: See test procedure specification.
test procedure specification: A document specifying a sequence ofactions for the execution of a test.Also known as
test script or manual test script. [After IEEE 829]
test process:The fundamental test process comprises planning, specification, execution, recording and checking for
completion. [BS 7925/2]
test repeatability: An attribute of a test indicating whether the same results are produced each time the test is
executed.
test run: Execution of a test on a specific version of the test object.
test script: Commonly used to refer to a test procedure specification, especially an automated one.
test specification: A document that consists ofa test design specification, test case specification and/ortest
procedure specification.
test strategy:A high-level document defining the test levels to be performed and the testing within those levels for a
programme (one or more projects).
test suite: A set of several test cases for a component or system undertest, where the post condition of one test is
often used as the precondition for the next one.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-194-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
test summary report: A document summarizing testing activities and results.It also contains an evaluation of the
corresponding test items against exit criteria. [After IEEE 829]
test target: A set of exit criteria.
test tool: A software product that supports one or more test activities, such as planning and control, specification,
building initial files and data, test execution and test analysis.[TMap] See also CAST.
test type: A group of test activities aimed at testing a component or system regarding one or more interrelated
quality attributes. A test type is focused on a specific test objective, i.e. reliability test,usability test, regression test
etc., and may take place on one or more test levels or test phases.[After TMap]
testability: The capability of the software product to enable modified software to be tested.[ISO 9126] See also
maintainability.
testability review: A detailed check of the test basis to determine whether the test basis is at an adequate quality
level to act as an input document for the test process.[After TMap]
testable requirements: The degree to which a requirement is stated in terms that permit establishment of test designs
(and subsequently test cases)and execution of tests to determine whether the requirements have been met. [After
IEEE 610]
tester: A technically skilled professionalwho is involved in the testing of a component or system.
testing: The process consisting ofall life cycle activities, both static and dynamic, concerned with planning,
preparation and evaluation of software products and related work products to determine that they satisfy specified
requirements, to demonstrate that they are fit for purpose and to detect defects.
testware: Artifacts produced during the test process required to plan, design,and execute tests,such as
documentation, scripts,inputs, expected results, set-up and clear-up procedures,files, databases,environment, and
any additional software or utilities used in testing.[After Fewster and Graham]
thread testing:A version of component integration testing where the progressive integration of components follows
the implementation of subsets ofthe requirements, as opposed to the integration of components by levels of a
hierarchy.
traceability: The ability to identify related items in documentation and software,
such as requirements with associated tests. See also horizontal traceability,
vertical traceability.
top-down testing: An incremental approach to integration testing where the component at the top of the component
hierarchy is tested first, with lower level components being simulated by stubs.Tested components are then used to
test lower level components.The process is repeated until the lowest level components have been tested.
U
understandability: The capability of the software product to enable the userto understand whetherthe software is
suitable, and how it can be used for particular tasks and conditions of use.[ISO 9126] See also usability.](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-195-320.jpg)
![https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/
unreachable code: Code that cannot be reached and therefore is impossible to execute.
usability: The capability of the software to be understood,learned, used and attractive to the userwhen used under
specified conditions. [ISO 9126]
usability testing: Testing to determine the extent to which the software product is understood, easy to learn, easy to
operate and attractive to the users under specified conditions. [After ISO 9126]
use case testing: A black box test design technique in which test cases are designed to execute userscenarios.
user test:A test whereby real-life users are involved to evaluate the usability of a component or system.
V
V-model: A framework to describe the software development life cycle activities from requirements specification to
maintenance. The V-model illustrates how testing activities can be integrated into each phase of the software
development life cycle.
validation: Confirmation by examination and through provision of objective evidence that the requirements for a
specific intended use or application have been fulfilled. [ISO 9000]
variable: An element of storage in a computer that is accessible by a software program by referring to it by a name.
verification: Confirmation by examination and through the provision of objective evidence that specified
requirements have been fulfilled. [ISO 9000]
vertical traceability: The tracing of requirements through the layers of development documentation to components.
volume testing: Testing where the systemis subjected to large volumes of data. See also resource-utilization testing.
W
walkthrough: A step-by-step presentation by the authorof a document in order to gatherinformation and to establish
a common understanding of its content.[Freedman and Weinberg, IEEE 1028]
white box test design technique: Documented procedure to derive and select test cases based on an analysis of the
internal structure of a component or system.
white box testing: Testing based on an analysis of the internal structure of the component or system.
Wide Band Delphi: An expert based test estimation technique that aims at making an accurate estimation using the
collective wisdom of the team members.
100 Manual Testing Interview FAQâs
Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Interview Faq's, Manual Testing Basics | Leave a comment
Q1. What is verification?](https://image.slidesharecdn.com/testingoverview-150913161454-lva1-app6892/85/Testing-overview-196-320.jpg)
Testing overview
- 1. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Overview Testing Steps Looking at UAT from a high level, there are a few basic steps that need to be undertaken: Step Description Test Strategy Decide how we are going to approach the testing in terms of people, tools, procedures and support Test Scenarios What are the situations we want to test Test Scripts What are the actual inputs we will use? What are the expected results? Test Strategy Why do a Test Strategy? The Test Strategy is the plan for how you are going to approach testing. It is like a project charter that tells the world how you are going to approach the project. You may have it all in your head, and if you are the only person doing the work it might be OK. If however you do not have it all in your head, or if others will be involved, you need to map out the ground rules. Here are some of the things that need to be covered in a Test Strategy. You could use this as a template for your own strategy. Project Name Overview Testing stage Instructions: Identify the type of testing to be undertaken. Example: User Acceptance Testing Scheduled for Example: 01.04.06 to 15.04.06 Location Example: Testing will be carried out in the Test Center on Level X Participants Instructions: Identify who will be involved in the testing. If resources have not been
- 2. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ nominated, outline the skills required. Example: Testing Manager â J. Smith 2 Testers â To be nominated. The skills required are: âą Broad understanding of all the processes carried out by the accounts receivable area. âą Should be familiar with manual processes currently undertaken for reversing payments. âą Preferably spent time dealing with inquiries from customers over the phone âą Etc. we plan to cover the product so as to develop an adequate assessment of quality. A good test strategy is: Specific Practical Justified The purpose of a test strategy is to clarify the major tasks and challenges of the test project. Test Approach and Test Architecture are other terms commonly used to describe what Iâm calling test strategy. Example of a poorly stated (and probably poorly conceived) test strategy: âWe will use black box testing, cause-effect graphing, boundary testing, and white box testing to test this product against its specification.â Test Strategy: Type of Project, Type of Software, when Testing will occur, Critical Success factors, Tradeoffs Test Plan â Why · Identify Risks and Assumptions up front to reduce surprises later. · Communicate objectives to all team members. · Foundation for Test Spec, Test Cases, and ultimately the Bugs we find. Failing to plan = planning to fail. Test Plan â What
- 3. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ · Derived from Test Approach, Requirements, Project Plan, Functional Spec., and Design Spec. · Details out project-specific Test Approach. · Lists general (high level) Test Case areas. · Include testing Risk Assessment. · Include preliminary Test Schedule · Lists Resource requirements. What is test Metrics? Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics, Softw are Testing Basics & Interview FAQ | Tags: Testing Interview Questions, Testing Strategies, What is test Metrics? | Leave a comment What is test Metrics? Test metrics consist of: âąTotal test âąTest run âąTest passed âąTest failed âąTests deferred âąTest passed the first time what is three way traceability matrix? A three way traceability matrix is the document contains the requirements, test cases and defects if any.(mapping of all these). what is the difference between delivarables and Release notes? Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Basics, Interview Faq's,Softw are Testing Basics & Interview FAQ Testing Interview Questions | Leave a comment what is the difference between delivarables and Release notes? Release notes are provided for every new release of the build with fixed bugs. It contains what are all the bugs fixed and what are pending bugs.
- 4. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Deliverables are provided at the end of the testing. Test plan, test cases, defect reports, documented defects which are not fixed etc come under deliverables. what is a testcase and usecase ? Use case is a description of a certain feature of an application in terms of actors ,actions and responses. For example if the user enters valid userid and password and after clicking on login button the system should display home page. Here the user is ACTOR. The operations performed by him are ACTIONS. The Systems display of home page is RESPONSE. Actually using use cases we will write our test cases if any use cases are provided in the SRS. A test case is a set of test inputs,executional conditions,with some expected results developed for validating a particular functionality of AUT. Traceability Matrix,Defect Leakage, Buffer Overflow, Bidirectional Traceability Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Bidirectional Traceability,Buffer Overflow , Defect Leakage, Traceability Matrix | Leave a comment What is Traceability Matrix? Traceability Matrix is a document used for tracking the requirement, Test cases and the defect. This document is prepared to make the clients satisfy that the coverage done is complete as end to end, this document consists of Requirement/Base line doc Ref No., Test case/Condition, and Defects/Bug id. Using this document the person can track the Requirement based on the Defect id. Boundary value testing it is a technique to find whether the application is accepting the expected range of values and rejecting the values which falls out of range. Ex. A user ID text box has to accept alphabet characters (a-z) with length of 4 to 10 characters. BVA is done like this, max value:10 pass; max-1: 9 pass; max+1=11 fail ;min=4 pass;min+1=5 pass;min-1=3 fail; Like wise we check the corner values and come out with a conclusion whether the application is accepting correct range of values. Equivalence testing it is normally used to check the type of the object. Ex. A user ID text box has to accept alphabet characters ( a â z ) with length of 4 to 10 characters. In +ve condition we have test the object by giving alphabets. i.e a-z char only, after that we need to check
- 5. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ whether the object accepts the value, it will pass. In -ve condition we have to test by giving other than alphabets (a-z) i.e A-Z,0-9,blank etc, it will fail. What is Defect Leakage ? Defect leakage occurs at the Customer or the End user side after the application delivery. After the release of the application to the client, if the end user gets any type of defects by using that application then it is called as Defect leakage. This Defect Leakage is also called as Bug Leak. What is Bidirectional Traceability ? Bidirectional Traceability must be implemented from both forward & backward(i.e from requirements to end products and from end products to requirements) When the the requirements are fully managed then traceability should be established between source requirements to its lower level requirements and from lower level requirements to source. This helps us to determine all the source requirements have been completely addressed. What is Buffer Overflow? A buffer overflow occurs when a program or process tries to store more data in a buffer (temporary data storage area) than it was intended to hold. Since buffers are created to contain a finite amount of data, the extra information â which has to go somewhere â can overflow into adjacent buffers, corrupting or overwriting the valid data held in them What is a Memory Leak? A memory leak occurs when a programmer dynamically allocates memory space for a variable of some type, but then fails to free up that space before the program completes. This leaves less free memory for the system to use. Repeated running of the program or function that causes such memory loss can eventually crash the system or result in a denial of service. What is âconfiguration managementâ? Configuration management is a process to control and document any changes made during the life of a project. Revision control, Change Control, and Release Control are important aspects of Configuration Management Explain Peer Review in Software Testing. Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Peer Review in Softw are Testing | Leave a comment It is an alternative form of Testing, where some colleagues were invited to examine your work products for defects and improvement opportunities. Some Peer review approaches are, Inspection â It is a more systematic and rigorous type of peer review. Inspections are more effective at finding defects than are informal reviews.
- 6. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Ex: In Motorolaâs Iridium project nearly 80% of the defects were detected through inspections where only 60% of the defects were detected through informal reviews. Team Reviews â It is a planned and structured approach but less formal and less rigorous comparing to Inspections. Walkthrough â It is an informal review because the work productâs author describes it to some colleagues and asks for suggestions. Walkthroughs are informal because they typically do not follow a defined procedure, do not specify exit criteria, require no management reporting, and generate no metrics. Pair Programming â In Pair Programming, two developers work together on the same program at a single workstation and continuously reviewing their work. Peers Desk check â In Peer Desk check only one person besides the author examines the work product. It is an informal review, where the reviewer can use defect checklists and some analysis methods to increase the effectiveness. SDLC and STLC Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics, Softw are Testing Basics & Interview FAQ | Tags: SDLC and STLC | Leave a comment What is quality assurance? Software QA involves the entire software development PROCESS â monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to âpreventionâ. What is the difference between QA and testing? Testing involves operation of a system or application under controlled conditions and evaluating the results. It is oriented to âdetectionâ. Software QA involves the entire software development PROCESS â monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to âpreventionâ. Describe the difference between validation and verification Verification is done by frequent evaluation and meetings to appraise the documents, policy, code, requirements, and specifications. This is done with the checklists, walkthroughs, and inspection meetings. Validation is done during actual testing and it takes place after all the verifications are being done. What are SDLC and STLC? Explain its different phases. SDLC Requirement phase
- 7. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Designing phase (HLD, DLD (Program spec)) Coding Testing Release Maintenance STLC System Study Test planning Writing Test case or scripts Review the test case Executing test case Bug tracking Report the defect What is Error guessing and Error seeding? Error Guessing is a test case design technique where the tester has to guess what faults might occur and to design the tests to represent them. Error Seeding is the process of adding known faults intentionally in a program for the reason of monitoring the rate of detection & removal and also to estimate the number of faults remaining in the program. What is Cyclometric complexity? Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Cyclometric complexity |Leave a comment What is Cyclometric complexity? The cyclomatic complexity is software metric that provides a quantitative measure of the logical complexity of a program Cyclometic complexity is one of metric which issued to measure the logical complexity of program To calculate CYCLOMETIC COMPLEXITY V (G) =E-N+2 Here Eââââ>NO OF EDGES Nââââ>NO OF NODES
- 8. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ What you need to know about BVT (Build Verification Testing) Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Build Verification Testing,Tips for BVT success | Leave a comment What is BVT? Build Verification test is a set of tests run on every new build to verify that build is testable before it is released to test team for further testing. These test cases are core functionality test cases that ensure application is stable and can be tested thoroughly. Typically BVT process is automated. If BVT fails that build is again get assigned to developer for fix. BVT is also called smoke testing or build acceptance testing (BAT) New Build is checked mainly for two things: ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Build validation ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Build acceptance Some BVT basics: ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï It is a subset of tests that verify main functionalities. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï The Batâs are typically run on daily builds and if the BVT fails the build is rejected and a new build is released after the fixes are done. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï The advantage of BVT is it saves the efforts of a test team to setup and test a build when major functionality is broken. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Design BVTs carefully enough to cover basic functionality. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Typically BVT should not run more than 30 minutes. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï BVT is a type of regression testing, done on each and every new build. BVT primarily checks for the project integrity and checks whether all the modules are integrated properly or not. Module integration testing is very important when different teams develop project modules. I heard many cases of application failure due to improper module integration. Even in worst cases complete project gets scraped due to failure in module integration. What is the main task in build release? Obviously file âcheck inâ i.e. to include all the new and modified project files associated with respective builds. BVT was primarily introduced to check initial build health i.e. to check whether â all the new and modified files are included in release, all file formats are correct, every file version and language, flags associated with each file. These basic checks are worth before build release to test team for testing. You will save time and money by discovering the build flaws at the very beginning using BVT. Which test cases should be included in BVT? This is very tricky decision to take before automating the BVT task. Keep in mind that success of BVT depends on which test cases you include in BVT. Here are some simple tips to include test cases in your BVT automation suite: ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Include only critical test cases in BVT. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï All test cases included in BVT should be stable.
- 9. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï All the test cases should have known expected result. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Make sure all included critical functionality test cases are sufficient for application test coverage. Also do not include modules in BVT, which are not yet stable. For some under-development features you canât predict expected behavior as these modules are unstable and you might know some known failures before testing for these incomplete modules. There is no point using such modules or test cases in BVT. You can make this critical functionality test cases inclusion task simple by communicating with all those involved in project development and testing life cycle. Such process should negotiate BVT test cases, which ultimately ensure BVT success. Set some BVT quality standards and these standards can be met only by analyzing major project features and scenarios. Example: Test cases to be included in BVT for Text editor application (Some sample tests only): 1) Test case for creating text file. 2) Test cases for writing something into text editor 3) Test cases for copy, cut, paste functionality of text editor 4) Test cases for opening, saving, deleting text file. These are some sample test cases, which can be marked as âcriticalâ and for every minor or major changes in application these basic critical test cases should be executed. This task can be easily accomplished by BVT. BVT automation suits needs to be maintained and modified time-to-time. E.g. include test cases in BVT when there are new stable project modules available. What happens when BVT suite run: Say Build verification automation test suite executed after any new build. 1) The result of BVT execution is sent to all the email IDâs associated with that project. 2) The BVT owner (person executing and maintaining the BVT suite) inspects the result of BVT. 3) If BVT fails then BVT owner diagnose the cause of failure. 4) If the failure cause is defect in build, all the relevant information with failure logs is sent to respective developers. 5) Developer on his initial diagnostic replies to team about the failure cause. Whether this is really a bug? And if itâs a bug then what will be his bug-fixing scenario. 6) On bug fix once again BVT test suite is executed and if build passes BVT, the build is passed to test team for further detail functionality, performance and other testes. This process gets repeated for every new build. Why BVT or build fails? BVT breaks sometimes. This doesnât mean that there is always bug in the build. There are some other reasons to build fail like test case coding error, automation suite error, infrastructure error, hardware failures etc. You need to troubleshoot the cause for the BVT break and need to take proper action after diagnosis. Tips for BVT success: 1) Spend considerable time writing BVT test cases scripts.
- 10. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 2) Log as much detailed info as possible to diagnose the BVT pass or fail result. This will help developer team to debug and quickly know the failure cause. 3) Select stable test cases to include in BVT. For new features if new critical test case passes consistently on different configuration then promote this test case in your BVT suite. This will reduce the probability of frequent build failure due to new unstable modules and test cases. 4) Automate BVT process as much as possible. Right from build release process to BVT result â automate everything. 5) Have some penalties for breaking the build some chocolates or team coffee party from developer who breaks the build will do. Conclusion: BVT is nothing but a set of regression test cases that are executed each time for new build. This is also called as smoke test. Build is not assigned to test team unless and until the BVT passes. BVT can be run by developer or tester and BVT result is communicated throughout the team and immediate action is taken to fix the bug if BVT fails. BVT process is typically automated by writing scripts for test cases. Only critical test cases are included in BVT. These test cases should ensure application test coverage. BVT is very effective for daily as well as long term builds. This saves significant time, cost, and resources and after all no frustration of test team for incomplete build. Developers might be doing the unit and integration testing and not necessarily the BVT. BVT is most of the times done by test engineer. Once the build team deploys the test build on the test environments itâs the job of test engineer to perform BVT (sniff, sanity smoke etcâŠ) If you are able to test the application and are executing the test cases, itâs natural that the BVT has been passed. Else you wouldnât have been able to test the application⊠It doesnât matter if the testing is done manually or is automated using any tool. If the build has got a new feature how can you automate it? Following is the process that you might follow: Developer initiates a mail to build team (also marked to test team with the description of what to be tested in the new build) to make the build >> Build team makes the build and deploys it on test machines and replies all asking the test team to continue testing, else if build fails he replies so in the mail >> If the BVT fails tester replies to mail stating that the BVT failed along with the logs whatever are available, else continues testing. Testing Process Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Testing Process | Leave a comment Testing Process as below: 1. Test Requirements: âą Requirement Specification documents âą Functional Specification documents
- 11. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âą Design Specification documents (use cases, etc) âą Use case Documents âą Test Trace-ability Matrix for identifying Test Coverage 2. Test Planning: âą Test Scope, Test Environment âą Different Test phase and Test Methodologies âą Manual and Automation Testing âą Defect Mgmt, Configuration Mgmt, and Risk Mgmt. Etc âą Evaluation & identification â Test, Defect tracking tools 3. Test Environment Setup: âą Test Bed installation and configuration âą Network connectivityâs âą All the Software/ tools Installation and configuration âą Coordination with Vendors and others 4. Test Case Design: âą Test Traceability Matrix and Test coverage âą Test Scenarios Identification & Test Case preparation âą Test data and Test scripts preparation âą Test case reviews and Approval âą Base lining under Configuration Management 5. Test Case Execution and Defect tracking: âą Executing Test cases âą Testing Test Scripts âą Capture, review and analyze Test Results âą Raised the defects and tracking for its closure 6. Test Report and Acceptance: âą Test summary reports âą Test Metrics and process Improvements made âą Build release âą Receiving acceptance Bug life cycle Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Bug Life Cycle | Leave a comment The different states of a bug can be summarized as follows: 1. New 2. Open 3. Assign 4. Test 5. Verified 6. Deferred
- 12. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 7. Reopened 8. Duplicate 9. Rejected and 10. Closed Description of Various Stages: 1. New: When the bug is posted for the first time, its state will be âNEWâ. This means that the bug is not yet approved. 2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as âOPENâ. 3. Assign: Once the lead changes the state as âOPENâ, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to âASSIGNâ. 4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to âTESTâ. It specifies that the bug has been fixed and is released to testing team. 5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software. 6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to âREJECTEDâ. 7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to âDUPLICATEâ. 8. Verified: Once the bug is fixed and the status is changed to âTESTâ, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to âVERIFIEDâ. 9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to âREOPENEDâ. The bug traverses the life cycle once again. 10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to âCLOSEDâ. This state means that the bug is fixed, tested and approved. Example For Bug Priority&Severity Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Bug Priority and Severity |Leave a comment High Priority & Low Severity Bug When on Home page of a website Name of site is wrong, it is low severity bug as it is not going to affect the major functionality but since itâs the home page of the website it may create bad impression on customers. Here it should be High Priority. High Priority & Low Severity
- 13. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ If we want to take a printout of a page or any document then if Printer doesnât allow us take printout, it is a High Priority Bug as it is related to Functionality but since we can take the printout from another Printer or we if can change the configuration then it is Low Severity Bug as we are getting our work done anyways without letting it affected by malfunctioning of Printer Defect severity determines the defect criticality whereas defect priority determines the defect immediacy or urgency of repair 1. High Severity & Low Priority: Suppose there is an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating yearly report. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request. 2. Low Severity & High Priority: Suppose there is a spelling mistake or content issue on the homepage of BT.com website which has daily laks of hits all over UK. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault. 3. High Severity & High Priority: Suppose there is an application which gives some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will hamper the functionality of the application immediately within a week. It should be fixed urgently. 4. Low Severity & Low Priority: Suppose there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority. Sample bug report Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Sample Bug Report | Leave a comment Below sample bug/defect report will give you exact idea of how to report a bug in bug tracking tool. Here is the example scenario that caused a bug: Lets assume in your application under test you want to create a new user with user information, for that you need to logon into the application and navigate to USERS menu > New User, then enter all the details in the âUser formâ like, First Name, Last Name, Age, Address, Phone etc. Once you enter all these information, you need to click on âSAVEâ button in order to save the user. Now you can see a success message saying, âNew User has been created successfullyâ. But when you entered into your application by logging in and navigated to USERS menu > New user, entered all the required information to create new user and clicked on SAVE button. BANG! The application crashed and you got one error page on screen. (Capture this error message window and save as a Microsoft paint file)
- 14. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Now this is the bug scenario and you would like to report this as a BUG in your bug- tracking tool. How will you report this bug effectively? Here is the sample bug report for above mentioned example: (Note that some âbug reportâ fields might differ depending on your bug tracking system) SAMPLE BUG REPORT: Bug Name: Application crash on clicking the SAVE button while creating a new user. Bug ID: (It will be automatically created by the BUG Tracking tool once you save this bug) Area Path: USERS menu > New Users Build Number: Version Number 5.0.1 Severity: HIGH (High/Medium/Low) or 1 Priority: HIGH (High/Medium/Low) or 1 Assigned to: Developer-X Reported By: Your Name Reported On: Date Reason: Defect Status: New/Open/Active (Depends on the Tool you are using) Environment: Windows 2003/SQL Server 2005 Description: Application crash on clicking the SAVE button while creating a new user, hence unable to create a new user in the application. Steps To Reproduce: 1) Logon into the application 2) Navigate to the Users Menu > New User 3) Filled all the user information fields 4) Clicked on âSaveâ button 5) Seen an error page âORA1090 Exception: Insert values ErrorâŠâ 6) See the attached logs for more information (Attach more logs related to bug. IF any) 7) and also see the attached screenshot of the error page. Expected result: On clicking SAVE button, should be prompted to a success message âNew User has been created successfullyâ. (Attach âapplication crashâ screen shot⊠IF any) Save the defect/bug in the BUG TRACKING TOOL. You will get a bug id, which you can use for further bug reference. Default âNew bugâ mail will go to respective developer and the default module owner (Team leader or manager) for further action Website Cookie Testing, Test cases for testing web application cookies?
- 15. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Test cases for testing w eb application cookies, Website Cookie Testing | Leave a comment We will first focus on what exactly cookies are and how they work. It would be easy for you to understand the test cases for testing cookies when you have clear understanding of how cookies work? How cookies stored on hard drive? And how can we edit cookie settings? What is Cookie? Cookie is small information stored in text file on userâs hard drive by web server. This information is later used by web browser to retrieve information from that machine. Generally cookie contains personalized user data or information that is used to communicate between different web pages. Why Cookies are used? Cookies are nothing but the userâs identity and used to track where the user navigated throughout the web site pages. The communication between web browser and web server is stateless. For example if you are accessing domain http://www.example.com/1.html then web browser will simply query to example.com web server for the page 1.html. Next time if you type page as http://www.example.com/2.html then new request is send to example.com web server for sending 2.html page and web server donât know anything about to whom the previous page 1.html served. What if you want the previous history of this user communication with the web server? You need to maintain the user state and interaction between web browser and web server somewhere. This is where cookie comes into picture. Cookies serve the purpose of maintaining the user interactions with web server. How cookies work? The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are two types of HTTP protocol. Stateless HTTP and Stateful HTTP protocol. Stateless HTTP protocol does not keep any record of previously accessed web page history. While Stateful HTTP protocol do keep some history of previous web browser and web server interactions and this protocol is used by cookies to maintain the user interactions. Whenever user visits the site or page that is using cookie, small code inside that HTML page (Generally a call to some language script to write the cookie like cookies in JavaScript, PHP, Perl) writes a text file on users machine called cookie. Here is one example of the code that is used to write cookie and can be placed inside any HTML page: Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; When user visits the same page or domain later time this cookie is read from disk and used to identify the second visit of the same user on that domain.
- 16. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Expiration time is set while writing the cookie. This time is decided by the application that is going to use the cookie. Generally two types of cookies are written on user machine. 1) Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the browser this session cookie gets deleted. Some time session of say 20 minutes can be set to expires the cookie. 2) Persistent cookies: The cookies that are written permanently on user machine and last for months or years. Where cookies are stored? When any web page application writes cookie it get saved in a text file on user hard disk drive. The path where the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet explorer store cookies on pathâC:Documents and SettingsDefault UserCookiesâ Here the âDefault Userâ can be replaced by the current user you logged in as. Like âAdministratorâ, or user name like âVijayâ etc. The cookie path can be easily found by navigating through the browser options. In Mozilla Fire fox browser you can even see the cookies in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy and then âShow cookiesâ button. How cookies are stored? Letâs take example of cookie written by rediff.com on Mozilla Fire fox browser: On Mozilla Fire fox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk. To view this cookie simply click on âShow cookiesâ button mentioned on above path. Click on Rediff.com site under this cookie list. You can see different cookies written by rediff domain with different names. Site: Rediff.com Cookie name: RMID Name: RMID (Name of the cookie) Content: 1d11c8ec44bf49e0⊠(Encrypted content) Domain: .rediff.com Path: / (Any path after the domain name) send For: Any type of connection Expires: Thursday, December 31, 2020 11:59:59 PM Applications where cookies can be used: 1) To implement shopping cart: Cookies are used for maintaining online ordering system. Cookies remember what user wants to buy. What if user adds some products in their shopping cart and if due to some reason user donât want to buy those products this time and closes the browser window? When next time same user visits the purchase page he can see all the products he added in shopping cart in his last visit.
- 17. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 2) Personalized sites: When user visits certain pages they are asked which pages they donât want to visit or display. User options are get stored in cookie and till the user is online, those pages are not shown to him. 3) User tracking: To track number of unique visitors online at particular time. 4) Marketing: Some companies use cookies to display advertisements on user machines. Cookies control these advertisements. When and which advertisement should be shown? What is the interest of the user? Which keywords he searches on the site? All these things can be maintained using cookies. 5) User sessions: Cookies can track user sessions to particular domain using user ID and password. Drawbacks of cookies: 1) Even writing Cookie is a great way to maintain user interaction, if user has set browser options to warn before writing any cookie or disabled the cookies completely then site containing cookie will be completely disabled and can not perform any operation resulting in loss of site traffic. 2) Too many Cookies: If you are writing too many cookies on every page navigation and if user has turned on option to warn before writing cookie, this could turn away user from your site. 3) Security issues: Some times userâs personal information is stored in cookies and if someone hacks the cookie then hacker can get access to your personal information. Even corrupted cookies can be read by different domains and lead to security issues. 4) Sensitive information: Some sites may write and store your sensitive information in cookies, which should not be allowed due to privacy concerns Some Major Test cases for web application cookie testing: The first obvious test case is to test if your application is writing cookies properly on disk. You can use the Cookie Tester application also if you donât have any web application to test but you want to understand the cookie concept for testing. Test cases: 1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie. 2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format. 3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.
- 18. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like âFor smooth functioning of this site make sure that cookies are enabled on your browserâ. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test) 5) Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted. 6) Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behavior of the pages. 7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com canât be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data. 8) Checking the deletion of cookies from your web application page: Some times cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some âaction trackingâ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user. 9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Fire fox, Netscape, Opera etc. 10) If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value says if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.
- 19. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Test Plan Template Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Test Plan Template | Leave a comment Itâs an Index of Test plan only. Each point will help you to elaborate your test plan step by step. Take this as a guideline and develop a full Test plan for your project. Table of Contents: 1. Introduction 1.1. Test Plan Objectives 2. Scope 2.1. Data Entry 2.2. Reports File Transfer 2.3. File Transfer 2.4. Security 3. Test Strategy 3.1. System Test 3.2. Performance Test 3.3. Security Test 3.4. Automated Test 3.5. Stress and Volume Test 3.6. Recovery Test 3.7. Documentation Test 3.8. Beta Test 3.9. User Acceptance Test 4. Environment Requirements 4.1. Data Entry workstations 4.2 MainFrame 5. Test Schedule 6. Control Procedures 6.1 Reviews 6.2 Bug Review meetings 6.3 Change Request 6.4 Defect Reporting 7. Functions to Be Tested 8. Resources and Responsibilities 8.1. Resources 8.2. Responsibilities 9. Deliverables 10. Suspension / Exit Criteria 11. Resumption Criteria 12. Dependencies 12.1 Personnel Dependencies 12.2 Software Dependencies
- 20. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 12.3 Hardware Dependencies 12.3 Test Data & Database 13. Risks 13.1. Schedule 13.2. Technical 13.3. Management 13.4. Personnel 13.5 Requirements 14. Tools 15. Documentation 16. Approvals Difference between test bed and test data? Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Difference betw een test bed and test data | Leave a comment Test Bed consist of test data and other hardware components i.e. its a bigger picture than only software data Test Data are data which have been specifically identified for use in executing test scripts, ( They may form a subset of test bed) Test Bed: Preparation for test execution is called Test Bed, i.e., installing your application (including pre-requisites like IE 6.0, .Net 2.0, IIS, Oracle, creating Windows User with Administrator rights etc), preparing database/schema. That means making sure that the application is READY for test execution. Test Data: On the other hand, test data is the data which is being used in the test execution (Eg, Input needs to be entered while creating a New User, First Name, Last Name, Age, Address, Sex, and Phone Number etc comes under test data Test Data are data which have been specifically identified for use in executing test scripts, and are used to verify the expected results obtained. Ex: Let us consider I have a login screen which I want to automate, parameterize and run 10 iteration, so I have to prepare a set of data of all user id and password before I go for automation to get the expected results. This is call preparation of test data. Test Bed or Test Environment is setting up of the both hardware and software requirements Ex: Assume I have a PDA or handheld device or mobile, I have developed software which can change a format of a song from any format to mp4. After me converting the song, I will get a list of mp4 files as an xml file. I can transfer this file from the computer to the handheld device using USB cable. Now for checking this entire scenario, I have to set up my software environment( data) and also need to setup my hardware ( which is my PDA and my USB connected to my computer).
- 21. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ How to keep your data intact for any test environment? Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Test environment | Leave a comment Many times more than one tester is responsible for testing some builds. In this case more than one tester will be having access to common test data and each tester will try to manipulate that common data according to his/her own needs. Best way to keep your valuable input data collection intact is to keep personal copies of the same data. It may be of any format like inputs to be provided to the application, input files such as word file, and excel file or other photo files. Check if your data is not corrupted: Filing a bug without proper troubleshooting is bad a practice. Before executing any test case on existing data make sure that data is not corrupted and application can read the data source. How to prepare data considering performance test cases? Performance tests require very large data set. Particularly if application fetching or updating data from DB tables then large data volume play important role while testing such application for performance. Sometimes creating data manually will not detect some subtle bugs that may only be caught by actual data created by application under test. If you want real time data, which is impossible to create manually, then ask your manager to make it available from live environment. I generally ask to my manager if he can make live environment data available for testing. This data will be useful to ensure smooth functioning of application for all valid inputs. Take example of my search engine project âstatistics testingâ. To check history of user searches and clicks on advertiser campaigns large data was processed for several years which were practically impossible to manipulate manually for several dates spread over many years. So there is no other option than using live server data backup for testing. (But first make sure your client is allowing you to use this data) What is the ideal test data? Test data can be said to be ideal if for the minimum size of data set all the application errors get identified. Try to prepare test data that will incorporate all application functionality, but not exceeding cost and time constraint for preparing test data and running tests. How to prepare test data that will ensure complete test coverage? Design your test data considering following categories: Test data set examples:
- 22. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 1) No data: Run your test cases on blank or default data. See if proper error messages are generated. 2) Valid data set: Create it to check if application is functioning as per requirements and valid input data is properly saved in database or files. 3) Invalid data set: Prepare invalid data set to check application behavior for negative values, alphanumeric string inputs. 4) Illegal data format: Make one data set of illegal data format. System should not accept data in invalid or illegal format. Also check proper error messages are generated. 5) Boundary Condition data set: Data set containing out of range data. Identify application boundary cases and prepare data set that will cover lower as well as upper boundary conditions. 6) Data set for performance, load and stress testing: This data set should be large in volume. This way creating separate data sets for each test condition will ensure complete test coverage. Conclusion: Preparing proper test data is a core part of âproject test environment setupâ. Tester cannot pass the bug responsibility saying that complete data was not available for testing. Tester should create his/her own test data additional to the existing standard production data. Your test data set should be ideal in terms of cost and time. Use the tips provided in this article to categorize test data to ensure complete functional test cases coverage. Black Box Testing: Types and Techniquesof BBT Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Black box testing, Smoke and Sanity testing, Types and techniques of BBT | Leave a comment Black box testing treats the system as a âblack-boxâ, so it doesnât explicitly use Knowledge of the internal structure or code. Or in other words the Test engineer need not know the internal working of the âBlack boxâ or application. Main focus in black box testing is on functionality of the system as a whole. The term âbehavioral testingâ is also used for black box testing and white box testing is also sometimes called âstructural testingâ. Behavioral test design is slightly different from black-box test design because the use of internal knowledge isnât strictly forbidden, but itâs still discouraged. Each testing method has its own advantages and disadvantages. There are some bugs that cannot be found using only black box or only white box. Majority of the application are tested by black box testing method. We need to cover majority of test cases so that most of the bugs will get discovered by black box testing. Black box testing occurs throughout the software development and testing life cycle i.e. in Unit, Integration, System, Acceptance and regression testing stages. Tools used for Black Box testing: Black box testing tools are mainly record and playback tools. These tools are used for
- 23. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ regression testing that to check whether new build has created any bug in previous working application functionality. These record and playback tools records test cases in the form of some scripts like TSL, VB script, Java script, Perl. Advantages of Black Box Testing - Tester can be non-technical. - Used to verify contradictions in actual system and the specifications. - Test cases can be designed as soon as the functional specifications are complete Disadvantages of Black Box Testing - The test inputs needs to be from large sample space. - It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult - Chances of having unidentified paths during this testing Methods of Black box Testing: Graph Based Testing Methods: Each and every application is build up of some objects. All such objects are identified and graph is prepared. From this object graph each object relationship is identified and test cases written accordingly to discover the errors. Error Guessing: This is purely based on previous experience and judgment of tester. Error Guessing is the art of guessing where errors can be hidden. For this technique there are no specific tools, writing the test cases that cover all the application paths. Boundary Value Analysis: Many systems have tendency to fail on boundary. So testing boundary values of application is important. Boundary Value Analysis (BVA) is a test Functional Testing technique where the extreme boundary values are chosen. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values. Extends equivalence partitioning Test both sides of each boundary Look at output boundaries for test cases too Test min, min-1, max, max+1, typical values BVA techniques: 1. Number of variables For n variables: BVA yields 4n + 1 test case. 2. Kinds of ranges Generalizing ranges depends on the nature or type of variables Advantages of Boundary Value Analysis 1. Robustness Testing â Boundary Value Analysis plus values that go beyond the limits 2. Min â 1, Min, Min +1, Nom, Max -1, Max, Max +1 3. Forces attention to exception handling Limitations of Boundary Value Analysis Boundary value testing is efficient only for variables of fixed values i.e. boundary. Equivalence Partitioning: Equivalence partitioning is a black box testing method that divides the input domain of a program into classes of data from which test cases can be derived.
- 24. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ How this partitioning is performed while testing: 1. If an input condition specifies a range, one valid and one two invalid classes are defined. 2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined. 3. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined. 4. If an input condition is Boolean, one valid and one invalid class is defined. Comparison Testing: Different independent versions of same software are used to compare to each other for testing in this method. Regression Testing: We can conduct the test on a modified build to ensure the bug fix work and occurrence of side effects in that build. Retesting: We can do the test on a build to ensure the correctness of the ââ-modified Sanity and smoke, we use script for Smoke but we donât for Sanity. We use smoke when a product is new and sanity for releases but smoke is used when the changes in the product have greater impact on its functionality. Smoke Test: When a build is received, a smoke test is run to ascertain if the build is stable and it can be considered for further testing. Smoke testing can be done for testing the stability of any interim build. Smoke testing can be executed for platform qualification tests. Sanity testing: Once a new build is obtained with minor revisions, instead of doing a through regression, sanity is performed so as to ascertain the build has indeed rectified the issues and no further issue has been introduced by the fixes. Itâs generally a subset of regression testing and a group of test cases are executed that are related with the changes made to the app. Generally, when multiple cycles of testing are executed, sanity testing may be done during the later cycles after through regression cycles. 1 Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested. A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep. 2 A smoke tests is scriptedâeither using a written set of tests or an automated test A sanity test is usually unscripted. 3 A Smoke tests are designed to touch every part of the application in a cursory way. Itâs is shallow and wide. A Sanity test is used to determine a small section of the application is still working after a minor change. 4 Smoke testing will be conducted to ensure whether the most crucial functions of a program
- 25. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ work, but not bothering with finer details. (Such as build verification). Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. 5 Smoke testing is normal health check up to a build of an application before taking it to testing in depth. Sanity testing is to verify whether requirements are met or not, checking all features breadth-first. Smoke testing don at developer side which means developed application is eligible for testing or not is called smoke testing sanity testing is nothing but testing side test the application whether the application is eligible for further testing is called the sanity testing Here are the differences you can see: SMOKE TESTING: ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï A smoke test is scripted, either using a written set of tests or an automated test ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï A Smoke test is designed to touch every part of the application in a cursory way. Itâs shallow and wide. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details. (Such as build verification). ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Smoke testing is normal health check up to a build of an application before taking it to testing in depth. SANITY TESTING: ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï A sanity test is usually unscripted. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï A Sanity test is used to determine a small section of the application is still working after a minor change. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. ï·ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï Sanity testing is to verify whether requirements are met or not, checking all features breadth-first.
- 26. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ What is the difference between Test Condition and Test Scenario? Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: mr, Test Condition and Test Scenario, Traceability Matrix, Waterfall Model | Leave a comment What is the difference between Test Condition and Test Scenario? Ands 1:- Test condition is the condition which is the Process that you should follow to test an application. Ex: â You Have Login Form. Test Condition 1:- when User Name and Password are valid Then application will move forward. The above one is the test condition which is the basic Condition where that tests process will get pass. Test Scenario:-Test Scenario will tell you the possible Ways of scenarios (ways) that an application can be tested. For above Login Form you have simony ways of testing I.E Positive testing .Negative Testing, B.V.A Like. Explain the waterfall model in detail? Every testing process follow the waterfall model of the Testing process. Test strategy and planning Test design Test environment setup Test execution Defect analysis and tracking Final reporting Waterfall Model: It is a linear sequential model It is very simple model to implement It is the first model. It needs very few resources to implement In this model there is no back tracking. For example if any error occurred an any Stage of software development, it canât be Corrected in that build
- 27. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Water fall model: â This is very simple model. It moves Like water fall from top to down of SDLC. The drawback of This model is ineffectiveness of verification and Validation activities. What is mean by mr? MR means Modification request When ever the changes comes from the client then we call it As Modification request, from that MR business people will Find the impact analysis for particular MR What are bug traceability matrix and its format? Functional specify action name, Number, Design specification Number, Test case number, Test result, Test pass/fail, Defect Number, Defect status. These all columns under traceability matrix format. Difference b/w srs and functional specifications? What are the approaches you follow while integrating the modules Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Difference b/w srs and functional specifications? What are the approaches you follow w hile integrating the modules, SRS and Functional Specifications | Leave a comment SRS specifies the software requirements I.e. requirements to make software Purpose Scope Target users (who will use this system) Customers Developpers Testing people. Like Description of each module General consecrations for all modules Functioonal requirements Navigational requirements Nonfnctional requirements Performence requirements Security requirements
- 28. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Resource requiems Software requirements (operating system) Die-Hard ware Requirements iii.Networking requirements Appendix i.acronys ii.definitionsâŠExt Ands FRS means Functional decomposition of each module. It contains Model screen shots of scenes of each module Different elements of each page And their location, action of each element What is Adhoc testing? Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Adhoc testing? | 1 Comment Hoc testing is a subset of Monkey testing. In this no Formal test cases are used; it is being done due to lack of The time. No testing approach is being used in this Ado Testing, Random Testing, Monkey Testing and Blind Testing are one and same When the time is very short to test the application we will Never follow the test execution with test cases we pick the Test case randomly and execute them to see the functional Flow Difference between Tests Methodology and Testing Techniques? Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Tests Methodology and Testing Techniques | Leave a comment what is difference between Tests Methodology and Testing Techniques? Testing Methodology We begin the testing process by developing a comprehensive Plan to test the general functionality and special features On a variety of platform combinations. Strict quality Control procedures are used. The process verifies that the Application meets the requirements specified in the system Requirements document and are bug free. At the end of each Testing day, the team prepares a summary of completed
- 29. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ and Failed tests. Our programmers address any identified issues, And the application is resubmitted to the testing team until every item is resolved. All changes and retesting are Tracked through spreadsheets available to both the testing And programming teams. Applications are not allowed to Launch until all identified problems are fixed. A report is Prepared at the end of testing to show exactly what was Tested and to list the final outcomes. Our software testing methodology is applied in three Distinct phases: unit testing, system testing, and Acceptance testing. Unit Testing: The programmers conduct unit testing During the development phase. Programmers can test their Specific functionality individually or with other units. However, unit testing is designed to test small pieces of Functionality rather than the system as a whole. This allows The programmers to conduct the first round of testing to eliminate bugs before they reach the testing staff. System Testing: The system is tested as a complete,Integrated system. System testing first occurs in the Development environment but eventually is conducted in the Production environment. Dedicated testers, project managers, Or other key project staff performs system testing . Functionality and performance testing are designed to catch Bugs in the system, unexpected results, or other ways in Which the system does not meet the stated requirements. The Testers create detailed scenarios to test the strength and Limits of the system, trying to break it if possible. Editorial reviews not only correct typographical and Grammatical errors, but also improve the systemâs overall Usability by ensuring that on-screen language is clear and Helpful to users. Accessibility reviews ensure that the System is accessible to users with disabilities. Acceptance Testing: The software is assessed against The requirements defined in the system requirements Document. The user or client conducts the testing in the Production environment. Successful acceptance testing is Required before client approval can be received. Test Strategy The test team worked with the project team members to Formulate a test plan, a schedule, and strategies based on The Small IT Solution scope and identified small business Customer scenarios. The identified customer scenario, for the solution testing,Is a small business of approximately 50 PCs. The customerWould have in place a peer-to-peer network. They may alsoHave a limited number of existing Microsoft servers or otherserver products not developed by Microsoft. The customer Approach
- 30. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ toward migration would be to implement Windows Small Business Server 2003, Standard Edition on new hardware And then migrate existing data and configurations to the new Platform. The development team was expected to have unit tested the Recommendations and configurations provided in the documentation. This includes verifying the service Recommendations and specifying the correct sequence of steps to ensure proper configuration. The deployment topology and Architectural choices, regarding the network and servers, Are assumed to have been validated as best practices by the Solution architect and Microsoft product groups relevant to The solution. The deployment topology, architectural Choices and the validation results of unit testing were Provided before the solution testing began. Tell me 4 test case techniques? Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Test Case Techniques |Leave a comment To design test cases, the following techniques will be used. 1).Boundary Value Analysis(BVA) 2).Equaling Class Partition (ECP) 3).Cause-Effect Graph analysis (CE_Graph) 4).Error Guessing Difference between Smoke and Sanity testing Posted: 02/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Difference betw een Smoke and Sanity testing | Leave a comment Smoke testingisnon-exhaustive softwaretesting,Ascertainingthatthe mostcrucialfunctions ofaprogramWork,but not bothering with finer details. Sanity testing is a cursory testing;it is performed Whenever a cursory testing is sufficient to prove the Application is functioning according to specifications. This levelof testing is a subset ofregressiontesting.It Normally includes a set ofcore testsof basicGUI Functionality to demonstrate connectivity to the database,Application servers,printers,etc.
- 31. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Waterfall Model Posted: 01/06/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Waterfall Model | Leave a comment The waterfall model: Software Development Process: There are various software development approaches defined and designed which are used/employed during development process of software, these approaches are also referred as âSoftware Development Process Modelsâ. Each process model follows a particular life cycle in order to ensure success in process of software development. One such approach/process used in Software Development is âThe Waterfall Modelâ. Water Fall Model ïï ï ï ï ï ï ï The classic software life cycle model. ïï ï ï ï ï ï ï First Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. ïï ï ï ï ï ï ï The whole process of software development is divided into separate process phases. ïï ï ï ï ï ï ï All the phases are cascaded to each other so that second phase is started as and when defined set of goals are achieved for first phase and it is signed off, so the name âWaterfall Modelâ. Also Known as The linear sequential model Waterfall Model Process Flow
- 32. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Testing actually involves two steps: Verification Validation Verification ïï ï ï ï ï ï ï Verification is substantiating that the software has been transformed from one form into another as intended with sufficient accuracy. ïï ï ï ï ï ï ï Verification answers the question âAre we building the software right?â. Validation ïï Validation is substantiating that the software functions with sufficient accuracy with respect to its requirements specification. ïï Validation answers the question âAre we building the right software?â ïï In order to represent the testing activity as an ongoing process, the V&V boxes appear under each product of the Waterfall Model. ïï ï ï ï ï ï ï One important characteristic of the Waterfall Model is the iteration rrows that join the processes together. Another important characteristic of the Waterfall Model is the maintenance arrows which connect the delivered software product to the various other products in the life cycle. ïï ï ï ï ï ï ï Remember that any changes made to the software product after delivery are considered maintenance. ïï ï ï ï ï ï ï A small change such as the correction of a programming error may only require a change in the code of the software. ïï ï ï ï ï ï ï Requirement Analysis & Definition ïï ï ï ï ï ï ï System & Software Design ïï ï ï ï ï ï ï Implementation & Unit Testing ïï ï ï ï ï ï ï Integration & System Testing ïï ï ï ï ï ï ï Operations & Maintenance ïï ï ï ï ï ï ï Requirement Analysis & Definition ïï ï ï ï ï ï ï All possible requirements of the system to be developed are captured in this phase. ïï ï ï ï ï ï ï Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system.
- 33. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ ïï ï ï ï ï ï ï The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. ïï ï ï ï ï ï ï Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model. System & Software Design ïï ï ï ï ï ï ï Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? ïï ï ï ï ï ï ï The requirement specifications from first phase are studied in this phase and system design is prepared. ïï ï ï ï ï ï ï System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. ïï ï ï ï ï ï ï The system design specifications serve as input for the next phase of the model. Implementation & Unit Testing ïï ï ï ï ï ï ï On receiving system design documents, the work is divided in modules/units and actual coding is started. ïï ï ï ï ï ï ï The system is first developed in small programs called units, which are integrated in the next phase. ïï ï ï ï ï ï ï Each unit is developed and tested for its functionality; this is referred to as Unit Testing. ïï ï ï ï ï ï ï Unit testing mainly verifies if the modules/units meet their specifications. Integration & System Testing ïï ï ï ï ï ï ï As specified above, the system is first divided in units which are developed and tested for their functionalities. ïï ï ï ï ï ï ï These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. ïï ï ï ï ï ï ï After successfully testing the software, it is delivered to the customer. Operations & Maintenance ïï ï ï ï ï ï ï This phase of âThe Waterfall Modelâ is virtually never ending phase (Very long). ïï ï ï ï ï ï ï Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system.
- 34. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance. Advantages ïï ï ï ï ï ï ï Testing is inherent to every phase of the waterfall model ïï ï ï ï ï ï ï It is an enforced disciplined approach ïï ï ï ï ï ï ï It is documentation driven, that is, documentation is produced at every stage ïï ï ï ï ï ï ï Great at addressing subtle issues like scalability, reliability ïï ï ï ï ï ï ï Specifications are built into the project ïï ï ï ï ï ï ï Discovery happens early. Projects follow a predictable cycle. Early identification of what will be difficult or expensive about a project allows go/no-go decisions to be made before too much money is spent. ïï ï ï ï ï ï ï Simple and easy to use. ïï ï ï ï ï ï ï Easy to manage due to the rigidity of the model â each phase has specific deliverables and a review process. ïï ï ï ï ï ï ï Phases are processed and completed one at a time. ïï ï ï ï ï ï ï Works well for smaller projects where requirements are very well understood. ïï ï ï ï ï ï ï Minimizes planning overhead since it can be done up front. ïï ï ï ï ï ï ï Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff. Disadvantages The waterfall model is the oldest and the most widely used paradigm. However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely: ïï ï ï ï ï ï ï It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses. ïï ï ï ï ï ï ï As The client usually only has a vague idea of exactly what is required from the software product, this WM has difficulty accommodating the natural uncertainty that exists at the beginning of the project. ïï ï ï ï ï ï ï The customer only sees a working version of the product after it has been coded. This may result in disaster any undetected problems are precipitated to this stage. ïï ï ï ï ï ï ï Relatively high risk of process paralysis ïï ï ï ï ï ï ï Only the final phase produces a non-documentation deliverable. ïï ï ï ï ï ï ï Backing up to address mistakes is difficult
- 35. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ ïï ï ï ï ï ï ï The problems with one phase are never solved completely during that phase and in fact many problems regarding a particular phase arise after the phase is signed off, this results in badly structured system as not all the problems (related to a phase) are solved during the same phase. ïï ï ï ï ï ï ï The project is not partitioned in phases in flexible way. ïï ï ï ï ï ï ï As the requirements of the customer goes on getting added to the list, not all the requirements are fulfilled, this results in development of almost unusable system. These requirements are then met in never version of the system; this increases the cost of system development. Test Cases Example Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Test Cases Example | Leave a comment 1.Test Case for ATM TC 1 :- succesfulcard insertion. TC 2 :- unsuccessfuloperation due to wrong angle card insertion. TC 3:- unsuccesssfuloperation due to invalid account card. TC 4:- successfulentry of pin number. TC 5:- unsuccessfuloperation due to wrong pin number entered 3 times. TC 6:- successfulselection of language. TC 7:- successfulselection of account type. TC 8:- unsuccessfuloperation due to wrong account type selected w/r to that inserted card. TC 9:- successfulselection of withdrawl option. TC 10:- successfulselection of amount. TC 11:- unsuccessfuloperation due to wrong denominations. TC 12:- successfulwithdrawl operation. TC 13:- unsuccessfulwithdrawl operation due to amount greater than possible balance. TC 14:- unsuccefuldue to lack of amount in ATM. TC 15:- un due to amount greater than the day limit. TC 16:- un due to server down. TC 17:- un due to click cancel after insert card. TC 18:- un due to click cancel after insert card and pin no. TC 19:- un due to click cancel after language selection,account type selection,withdrawl selection, enter amount
- 36. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 2. Test cases for Mobile Phone Test Cases for Mobile Phone: 1)Chek whether Battery is inserted into mobile properly 2)Chek Switch on/Switchoff of the Mobile 3)Insert the sim into the phone n chek 4)Add one user with name and phone number in Address book 5)Chek the Incoming call 6)chek the outgoing call 7)send/receive messages for that mobile 8)Chek all the numbers/Characters on the phone working fine by clicking on them.. 9)Remove the userfrom phone book n chek removed properly with name and phone number 10)Chek whether Network working fine.. 11)If its GPRS enabled chek for the connectivity. 3. Test cases for sending a message through mobile phone (assuming all the scenarios) 1.Check for the availability of the Mobile 2.Check the buttons on the mobile 3.Check the mobile is locked or unlocked 4.Check for the unlock of the mobile 5.Select the menu 6.Check for the messages in menu 7.Select the messages 8.Check for the write message in messages menu 9.Select the write message 10.Check the buttons writing alphabets 11.Check for the chars how many u can send
- 37. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 12.Write the message on the write message menu 13.Select the options 14.Select the send 15.Check whether asking for the phone No. of the receiver 16.Select the Search for the receiver Phone No. if Exits 17.Enter the Phone No. of the receiver 18.Select Ok 19.Check for the request send 4.Test cases for Traffic Signal 1.verify if the traffic lights are having three lights(green,yellow,red) 2.verify that the lights turn on in a sequence 3.verify that lights turn on in a sequence based on time specified(greenlight-4.1min,yellowlight10sec,redlight 1 min) 5.verify that only one light glows at a time 6.verify if the speed of the Traffic light can be accelerated as time specified based on the traffic 7.verify if the traffic lights in some spots are sensoractivated. 5. Test case for 2 way switch 1. Check whether two switches are present. 2. Check whether both switches are connected properly. 3. Check power supplies for both switches. 4. Check on/off conditions are working properly. 5. Check whether any electornic applicace connected to the 2-way switches should not get power supply when both switches are either in on state or off state. 6. Check whether any electornic applicace connected to the 2-way switches should get power supply when one switch is in on state and other is in off state or vice versa. 6. Test cases Elevator
- 38. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Some of the use cases would be: 1) Elevator is capable of moving up and down. 2) It is stopping at each floor. 3) It moves exactly to that floor when corresponding floor no is pressed. 4) It moves up when called from upward and down when called from downward. 5) It waits until âcloseâ button is pressed. 6) If anyon steps inbetween the door at the time of closing, door should open. 7) No break points exists 8) More usecases forthe load that the elevator can carry (if required) 7. Test cases Calculator 1 It should have 9 numeric digits. 2 it should give proper output based on the operation. 3 it should not allow charactres. 4 it should run from cell or battery not through power supply. 5 it should be small in size. 6 at least it should perform 4 basic operation such as add,sub.div,mul 8. TestcasesBulb Test cases for bulb Check the bulb is req shap and size Check the bulb is fitted and removed from holder Check the bulb glow req illumunation r not Check the bulb it should glow when we switch on Check the bulb it should off when we switch off
- 39. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Check the bulb material Life of the bulb should meet the reqrmt 9. Test Case for Yahoo Page 1.Testing without entering any username and password 2.Test it only with Username 3.Test it only with password. 4 .User name with wrong password 5. Password with wrong user name 6. Right username and right password 7. Cancel, after entering username and pwd. 8.Enter long username and password that exceeds the set limit of characters. 9.Try copy/paste in the password text box. 10.After successfullsign-out,try âBackâ option from your browser. Check whether it gets you to the âsigned-inâ page. Types and Levels of Testing in Programming Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Types and Levels of Testing in Programming | Leave a comment Types and Levels of Testing in Programming Testing is an important step in software development life cycle. The process of testing takes place at various stages of development in programming. This is a vital step in development life cycle because the process of testing helps to identify the mistakes and sends the program for correction. This process gets repeated at various stages until the final unit or program is found to be complete thus giving a total quality to the development process. The various levels and types of testing found in a software development life cycle are: White Box Testing For doing this testing process the person have to access to the source code of the product to be tested. So it is essential that the person doing this white box testing have some knowledge of the program being tested. Though not necessary it would be more worth if the programmer itself does this white box testing process since this testing process requires the handling of source code.
- 40. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Black Box Testing This is otherwise called as functional testing. In contrary to white box testing here the person who is doing the black box testing need not have the programming knowledge. This is because the person doing the black box testing would access the output or outcomes as the end user would access and would perform thorough functionality testing to check whether the developed module or product behaves in functionality in the way it has to be. Unit Testing This testing is done for each module of the program to ensure the validity of each module. This type of testing is done usually by developers by writing test cases for each scenarios of the module and writing the results occurring in each step for each module. Regression testing We all know that development life cycle is subjected to continuous changes as per the requirements of user. Suppose if there is a change in the existing system which has already been tested it is essential that one has to make sure that this new changes made to the existing system do not affect the existing functionality. For ensuring this regression testing is done. Integration testing By making unit testing for each module as explained above the process of integrated testing as a whole becomes simpler. This is because by correcting mistakes or bugs in each module the integration of all units as a system and testing process becomes easier. So one might think why the integration is testing needed. The answer is simple. It is needed because unit testing as explained test and assures correctness of only each module. But it does not cover the aspects of how the system would behave or what error would be reported when modules are integrated. This is done in the level of integration testing. Smoke Test This is also called as sanity testing. This is mainly used to identify environmental related problems and is performed mostly by test manager. For any application it is always necessary to have the environment first checked for smooth running of the application. So in this testing process the application is run in the environment technically called as dry run and checked to find that the application could run without any problem or abend in between. Alpha Testing The above different testing process described takes place in different stages of development as per the requirement and needs. But a final testing is always made after a full finished product that is before it released to end users and this is called as alpha testing. The alpha testing involves both the white box testing and black box testing thus making alpha testing to be carried out in two phases. Beta Testing This process of testing is carried out to have more validity of the software developed. This takes place after the alpha testing. After the alpha phase also the generally the release is not made fully to all end users. The product is released to a set of people and feedback is got from them to ensure the validity of the product. So here normally the testing is being done by group of end users and therefore this beta testing phase covers black box testing or functionality testing only.
- 41. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Having seen about testing levels and types let us now see how the testing process takes place in general. After getting an idea of what all to be tested by communicating with developers and others in the design phase of the software development life cycle the testing stage carries on parallel. Test plan is made ready during the planning stage of testing. This test plan has details like environment of setting like software, hardware, operating system used, the scope and limitation of testing, test type and so on. In the next phase the test case is prepared which has details of each step for module to be checked, input which can be used for each action are described and recorded for testing. It also has details about what is the expected outcome or expected result of each action .The next phase is the actual testing phase. In this phase the testers make testing based on the test plan and test case made ready and record the output or result resulting from each module. Thus the actual output is recorded .Then a report is made to find the error or defect between expected outcome and actual output in each module in each step. This is sent for rework for developers and testing cycle again continues as above. It does not mean that the system released is bug free or error free hundred percent. This is because no real system could have null percentage error. But an important point to bear in mind is that a system developed is a quality system only if the system could run for a period of time after its release without error and after this time period only minimal errors are reported. For achieving this testing phase plays an essential role in software development life cycle. SQL PLUS Testing FAQs Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: SQL PLUS Testing FAQs |Leave a comment SQL PLUS STATEMENTS 1. What are the types of SQL Statement ? Data Definition Language : CREATE,ALTER,DROP,TRUNCATE,REVOKE,NO AUDIT & COMMIT. Data Manipulation Language : INSERT,UPublish PostPDATE,DELETE,LOCK TABLE,EXPLAIN PLAN & SELECT. Transactional Control : COMMIT & ROLLBACK Session Control : ALTERSESSION & SET ROLE System Control : ALTER SYSTEM. 2. What is a transaction ? Transaction is logical unit between two commits and commit and rollback.
- 42. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 3. What is difference between TRUNCATE & DELETE ? TRUNCATE commits after deleting entire table i.e., can not be rolled back. Database triggers do not fire on TRUNCATE DELETE allows the filtered deletion. Deleted records can be rolled back or committed. Database triggers fire on DELETE. 4. What is a join ? Explain the different types of joins ? Join is a query which retrieves related columns or rows from multiple tables. Self Join â Joining the table with itself. Equi Join â Joining two tables by equating two common columns. Non-Equi Join â Joining two tables by equating two common columns. Outer Join â Joining two tables in such a way that query can also retrive rows that do not have corresponding join value in the other table. 5. What is the Subquery ? Subquery is a query whose return values are used in filtering conditions of the main query. 6. What is correlated sub-query ? Correlated sub_query is a sub_query which has reference to the main query. 7. Explain Connect by Prior ? Retrives rows in hierarchical order. e.g. select empno, ename from emp where. 8. Difference between SUBSTR and INSTR ? INSTR (String1,String2(n,(m)), INSTR returns the position of the mth occurrence of the string 2 in string1. The search begins from nth position of string1. SUBSTR (String1 n,m) SUBSTR returns a character string of size m in string1, starting from nth postion of string1. 9. Explain UNION,MINUS,UNION ALL, INTERSECT ? INTERSECT returns all distinct rows selected by both queries. MINUS â returns all distinct rows selected by the first query but not by the second.
- 43. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ UNION â returns all distinct rows selected by either query UNION ALL â returns all rows selected by either query,including all duplicates. 10. What is ROWID ? ROWID is a pseudo column attached to each row of a table. It is 18 character long, blockno, rownumber are the components of ROWID. 11. What is the fastest way of accessing a row in a table ? Using ROWID. CONSTRAINTS 12. What is an Integrity Constraint ? Integrity constraint is a rule that restricts values to a column in a table. 13. What is Referential Integrity ? Maintaining data integrity through a set of rules that restrict the values of one or more columns of the tables based on the values of primary key or unique key of the referenced table. 14. What are the usage of SAVEPOINTS ? SAVEPOINTS are used to subdivide a transaction into smaller parts. It enables rolling back part of a transaction. Maximum of five save points are allowed. 15. What is ON DELETE CASCADE ? When ON DELETE CASCADE is specified ORACLE maintains referential integrity by automatically removing dependent foreign key values if a referenced primary or unique key value is removed. 16. What are the data types allowed in a table ? CHAR,VARCHAR2,NUMBER,DATE,RAW,LONG and LONG RAW. 17. What is difference between CHAR and VARCHAR2 ? What is the maximum SIZE allowed for each type ? CHAR pads blank spaces to the maximum length. VARCHAR2 does not pad blank spaces. For CHAR it is 255 and 2000 for VARCHAR2. 18. How many LONG columns are allowed in a table ? Is it possible to use LONG columns in WHERE clause or ORDER BY ?
- 44. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Only one LONG columns is allowed. It is not possible to use LONG column in WHERE or ORDER BY clause. 19. What are the pre requisites ? I. to modify datatype of a column ? ii. to add a column with NOT NULL constraint ? To Modify the datatype of a column the column must be empty. to add a column with NOT NULL constrain, the table must be empty. 20. Where the integrity constrints are stored in Data Dictionary ? The integrity constraints are stored in USER_CONSTRAINTS. 21. How will you a activate/deactivate integrity constraints ? The integrity constraints can be enabled or disabled by ALTER TABLE ENABLE constraint/DISABLE constraint. 22. If an unique key constraint on DATE column is created, will it validate the rows that are inserted with SYSDATE ? It wonât, Because SYSDATE format contains time attached with it. 23. What is a database link ? Database Link is a named path through which a remote database can be accessed. 24. How to access the current value and next value from a sequence ? Is it possible to access the current value in a session before accessing next value ? Sequence name CURRVAL, Sequence name NEXTVAL. It is not possible. Only if you access next value in the session, current value can be accessed. 25. What is CYCLE/NO CYCLE in a Sequence ? CYCLE specifies that the sequence continues to generate values after reaching either maximum or minimum value. After pan ascending sequence reaches its maximum value, it generates its minimum value. After a descending sequence reaches its minimum, it generates its maximum. NO CYCLE specifies that the sequence cannot generate more values after reaching its maximum or minimum value. 26. What are the advantages of VIEW ?
- 45. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ To protect some of the columns of a table from other users. To hide complexity of a query. To hide complexity of calculations. 27. Can a view be updated/inserted/deleted? If Yes under what conditions ? A View can be updated/deleted/inserted if it has only one base table if the view is based on columns from one or more tables then insert, update and delete is not possible. 28.If a View on a single base table is manipulated will the changes be reflected on the base table ? If changes are made to the tables which are base tables of a view will the changes be reference on the view. 1. Difference between group functions and single row functions. Group Function Single Row Function 1. A group function operates 2. A single row function on many rows returns one and result for one row. returns single result. Not allowed in Pl/sql procedural Allowed in Pl/Sql Procedural statements statements. eg SUM(),AVG,MIN,MAX etc eg UPPER,LOWER,CHR⊠2. Difference between DECODE and TRANSLATE DECODE is value by value TRANSLATE is character by character replacement. replacement. Ex SELECT DECODE(âABCâ,âAâ,1,âBâ,2,âABCâ,3) eg SELECT from dual; o/p 3 TRANSLATE(âABCGHâ, âABCDEFGHIJâ, 1234567899) FROM DUAL; o/p 12378 (DECODE command is used to bring IF,THEN,ELSE logic to SQL.It tests for the IF values(s) and then aplies THEN value(s) when true, the ELSE value(s) if not.) 3. Difference between TRUNCATE and DELETE TRUNCATE deletes much faster than DELETE Truncate Delete It is a DDL statement It is a DML statement
- 46. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ It is a one way trip,cannot One can Rollback ROLLBACK Doesnât have selective features (where clause) Has Doesnât fire database triggers Does It requires disabling of referential Does not require constraints. 4. What is a CO-RELATED SUBQUERY A CO-RELATED SUBQUERY is one that has a correlation name as table or view designator in the FROM clause of the outer query and the same correlation name as a qualifier of a search condition in the WHERE clause of the subquery. eg SELECT field1 from table1 X WHERE field2>(select avg(field2) from table1 Y where field1=X.field1); (The subquery in a correlated subquery is revaluated for every row of the table or view named in the outer query.) 5. What are various joins used while writing SUBQUERIES Self join-Its a join foreign key of a table references the same table. Outer JoinâIts a join condition used where One can query all the rows of one of the tables in the join condition even though they donât satisfy the join condition. Equi-joinâIts a join condition that retrieves rows from one or more tables in which one or more columns in one table are equal to one or more columns in the second table. 6. What are various constraints used in SQL NULL ,NOT NULL ,CHECK ,DEFAULT 7. What are different Oracle database objects TABLES ,VIEWS ,INDEXES ,SYNONYMS ,SEQUENCES ,TABLESPACES etc 8. What is difference between Rename and Alias Rename is a permanent name given to a table or column whereas Alias is a temporary name given to a table or column which do not exist once the SQL statement is executed. 9. What is a view
- 47. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ A view is stored procedure based on one or more tables, itâs a virtual table. What are various privileges that a user can grant to another user SELECT ,CONNECT ,RESOURCES 10. What is difference between UNIQUE and PRIMARY KEY constraints A table can have only one PRIMARY KEY whereas there can be any number ofUNIQUE keys. The columns that compose PK are automatically define NOT NULL, whereas a column that compose a UNIQUE is not automatically defined to be mandatory must also specify the column is NOT NULL. 11. Can a primary key contain more than one columns ? yes 12. How you will avoid duplicating records in a query By using DISTINCT 13. What is difference between SQL and SQL*PLUS SQL*PLUS is a command line tool where as SQL and PL/SQL language interface and reporting tool. Its a command line tool that allows user to type SQL commands to be executed directly against an Oracle database. SQL is a language used to query the relational database(DML,DCL,DDL). SQL*PLUS commands are used to format query result, Set options, Edit SQL commands and PL/SQL. 14. Which datatype is used for storing graphics and images LONG RAW data type is used for storing BLOBâs (binary large objects). 15. How will you delete duplicating rows from a base table DELETE FROM table_name A WHERE rowid>(SELECT min(rowid) from table_name B where B.table_no=A.table_no); CREATE TABLE new_table AS SELECT DISTINCT * FROM old_table; DROP old_table RENAME new_table TO old_table DELETE FROM table_name A WHERE rowid NOT IN (SELECT MAX(ROWID) FROMtable_name GROUP BY column_name) 16. What is difference between SUBSTR and INSTR SUBSTR returns a specified portion of a string eg SUBSTR(âBCDEFâ,4) output BCDE INSTR provides character position in which a pattern is found in a string. eg INSTR(âABC-DC-Fâ,â-â,2) output 7 (2nd occurence of â-â) 17. There is a string â120000 12 0 .125âČ ,how you will find the position of the decimal place INSTR(â120000 12 0 .125âČ,1,â.â) output 13 18. There is a â%â sign in one field of a column. What will be the query to find it. ? ââ Should be used before â%â. 19. When you use WHERE clause and when you use HAVING clause HAVING clause is used when you want to specify a condition for a group function and it
- 48. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ is written after GROUP BY clause The WHERE clause is used when you want to specify a condition for columns, single row functions except group functions and it is written before GROUP BY clause if it is used. 20. Which is more faster â IN or EXISTS EXISTS is more faster than IN because EXISTS returns a Boolean value whereas IN returns a value. 21. What is a OUTER JOIN Outer JoinâIts a join condition used where you can query all the rows of one of the tables in the join condition even though they donât satisfy the join condition. 22. How you will avoid your query from using indexes SELECT * FROM emp Where emp_no+â â=12345; i.e you have to concatenate the column name with space within codes in the where condition. SELECT /*+ FULL(a) */ ename, emp_no from emp where emp_no=1234; i.e using HINTS 23. What is a pseudo column. Give some examples It is a column that is not an actual column in the table. eg USER, UID, SYSDATE, ROWNUM, ROWID, NULL, AND LEVEL. 24. Suppose customer table is there having different columns like customer no, payments.What will be the query to select top three max payments. SELECT customer_no, payments from customer C1 WHERE 3<=(SELECT COUNT(*) from customer C2 WHERE C1.payment <= C2.payment) 25. What is the purpose of a cluster. Oracle does not allow a user to specifically locate tables, since that is a part of the function of the RDBMS. However, for the purpose of increasing performance, oracle allows a developer to create a CLUSTER. A CLUSTER provides a means for storing data from different tables together for faster retrieval than if the table placement were left to the RDBMS. 26. What is a cursor. ? Oracle uses work area to execute SQL statements and store processing information PL/SQL construct called a cursor lets you name a work area and access its stored info A cursor is a mechanism used to fetch more than one row in a Pl/SQl block. 27. Difference between an implicit & an explicit cursor. PL/SQL declares a cursor implicitly for all SQL data manipulation statements, including quries that return only one row. However,queries that return more than one row you must declare an explicit cursor or use a cursor FOR loop. Explicit cursor is a cursor in which the cursor name is explicitly assigned to a SELECT statement via the CURSORâŠIS statement. An implicit cursor is used for all SQL statements Declare, Open, Fetch, Close. An explicit cursors are used to process multirow SELECT statements An implicit cursor is used to process INSERT, UPDATE, DELETE and single row SELECT. .INTO statements,
- 49. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 28. What are cursor attributes %ROWCOUNT , %NOTFOUND , %FOUND ,%ISOPEN 29. What is a cursor for loop. Cursor For Loop is a loop where oracle implicitly declares a loop variable, the loop index that of the same record type as the cursorâs record. 30. Difference between NO DATA FOUND and %NOTFOUND NO DATA FOUND is an exception raised only for the SELECTâŠ.INTO statements hen the where clause of the querydoes not match any rows. When the where clause of the explicit cursor does not match any rows the %NOTFOUND attribute is set to TRUE instead. 31. What a SELECT FOR UPDATE cursor represent. SELECTâŠâŠFROMâŠâŠFORâŠâŠUPDATE[OF column-reference][NOWAIT] The processing done in a fetch loop modifies the rows that have been retrieved by the cursor. A convenient way of modifying the rows is done by a method with two parts: the FOR UPDATE clause in the cursor declaration, WHERE CURRENT OF CLAUSE in an UPDATE or declaration statement. 32. What âWHERE CURRENT OF â clause does in a cursor. LOOP SELECT num_credits INTO v_numcredits FROM classes WHERE dept=123 and course=101; UPDATE students SET current_credits=current_credits+v_numcredits WHERE CURRENT OF X; END LOOP; COMMIT; END; 33. What is use of a cursor variable? How it is defined. A cursor variable is associated with different statements at run time, which can hold different values at run time. Static cursors can only be associated with one run time query. A cursor variable is reference type(like a pointer in C). Declaring a cursor variable: TYPE type_name IS REF CURSOR RETURN return_type type_name is the name of the reference type,return_type is a record type indicating the types of the select list that will eventually be returned by the cursor variable. 34. What should be the return type for a cursor variable.Can we use a scalar data type as return type. The return type for a cursor must be a record type.It can be declared explicitly as a user-defined or %ROWTYPE can be used. eg TYPE t_studentsref IS REF CURSOR RETURN students%ROWTYPE 35. How you open and close a cursor variable.Why it is required. OPEN cursor variable FOR SELECTâŠStatement CLOSE cursor variable In order to associate a cursor variable with a particular SELECT statement OPEN syntax is used.In order to free the resources used
- 50. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ for the query CLOSE statement is used. 36. How you were passing cursor variables in PL/SQL 2.2. In PL/SQL 2.2 cursor variables cannot be declared in a package.This is because the storage for a cursor variable has to be allocated using Pro*C or OCI with version 2.2,the only means of passing a cursor variable to a PL/SQL block is via bind variable or a procedure parameter. 37. Can cursor variables be stored in PL/SQL tables.If yes how.If not why. No, a cursor variable points a row which cannot be stored in a two-dimensional PL/SQL table. 38. Difference between procedure and function. Functions are named PL/SQL blocks that return a value and can be called with arguments procedure a named block that can be called with parameter. A procedure all is a PL/SQL statement by itself, while a Function call is called as part of an expression. 39. What are different modes of parameters used in functions and procedures. IN , OUT , INOUT 40. What is difference between a formal and an actual parameter The variables declared in the procedure and which are passed, as arguments are called actual, the parameters in the procedure declaration. Actual parameters contain the values that are passed to a procedure and receive results. Formal parameters are the placeholders for the values of actual parameters 41. Can the default values be assigned to actual parameters. Yes 42. Can a function take OUT parameters.If not why. No.A function has to return a value,an OUT parameter cannot return a value. 43. What is syntax for dropping a procedure and a function .Are these operations possible. Drop Procedure procedure_name , Drop Function function_name 44. What are ORACLE PRECOMPILERS. Using ORACLE PRECOMPILERS ,SQL statements and PL/SQL blocks can be contained inside 3GL programs written in C,C++,COBOL,PASCAL, FORTRAN,PL/1 AND ADA. The Precompilers are known as Pro*C,Pro*Cobol,⊠This form of PL/SQL is known as embedded pl/sql,the language in which pl/sql is embedded is known as the host language. The prcompiler translates the embedded SQL and pl/sql ststements into calls to the precompiler runtime library.The output must be compiled and linked with this library to creater an executable. 45. What is OCI. What are its uses. Oracle Call Interface is a method of accesing database from a 3GL program. UsesâNo precompiler is required,PL/SQL blocks are executed like other DMLstatements. The OCI library provides -functions to parse SQL statemets , -bind input variables , -bind output variables , -execute statements , -fetch the results
- 51. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 46. Difference between database triggers and form triggers. a) Data base trigger(DBT) fires when a DML operation is performed on a data base table.Form trigger(FT) Fires when user presses a key or navigates between fields on the screen b) Can be row level or statement level No distinction between row level and statement level.c) Can manipulate data stored in Oracle tables via SQL Can manipulate data in Oracle tables as well as variables in forms. d) Can be fired from any session executing the triggering DML statements. Can be fired only from the form that define the trigger. e) Can cause other database triggers to fire.Can cause other database triggers to fire,but not other form triggers. 47. What is an UTL_FILE.What are different procedures and functions associated with it. UTL_FILE is a package that adds the ability to read and write to operating system files Procedures associated with it are FCLOSE, FCLOSE_ALL and 5 procedures to output data to a file PUT, PUT_LINE, NEW_LINE, PUTF, FFLUSH.PUT, FFLUSH.PUT_LINE,FFLUSH.NEW_LINE. Functions associated with it are FOPEN, ISOPEN. 48. Can you use a commit statement within a database trigger. No 49. What is the maximum buffer size that can be specified using the DBMS_OUTPUT.ENABLE function? 1,000,000 BASISCS OF PL/SQL 1. What is PL/SQL ? PL/SQL is a procedural language that has both interactive SQL and procedural programming language constructs such as iteration, conditional branching. 2. What is the basic structure of PL/SQL ? PL/SQL uses block structure as its basic structure. Anonymous blocks or nested blocks can be used in PL/SQL. 3. What are the components of a PL/SQL block ? A set of related declarations and procedural statements is called block. 4. What are the components of a PL/SQL Block ? Declarative part, Executable part and Execption part. Datatypes PL/SQL
- 52. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 5. What are the datatypes a available in PL/SQL ? Some scalar data types such as NUMBER, VARCHAR2, DATE, CHAR, LONG, BOOLEAN. Some composite data types such as RECORD & TABLE. 6. What are % TYPE and % ROWTYPE ? What are the advantages of using these over datatypes? % TYPE provides the data type of a variable or a database column to that variable. % ROWTYPE provides the record type that represents a entire row of a table or view or columns selected in the cursor. The advantages are : I. Need not know about variableâs data type ii. If the database definition of a column in a table changes, the data type of a variable changes accordingly. 7. What is difference between % ROWTYPE and TYPE RECORD ? % ROWTYPE is to be used whenever query returns a entire row of a table or view. TYPE rec RECORD is to be used whenever query returns columns of different table or views and variables. E.g. TYPE r_emp is RECORD (eno emp.empno% type,ename emp ename %type ); e_rec emp% ROWTYPE cursor c1 is select empno,deptno from emp; e_rec c1 %ROWTYPE. 8. What is PL/SQL table ? Objects of type TABLE are called âPL/SQL tablesâ, which are modelled as (but not the same as) database tables, PL/SQL tables use a primary PL/SQL tables can have one column and a primary key. CURSORS 9. What is a cursor ? Why Cursor is required ? Cursor is a named private SQL area from where information can be accessed. Cursors are required to process rows individually for queries returning multiple rows. 10. Explain the two type of Cursors ?
- 53. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ There are two types of cursors, Implict Cursor and Explicit Cursor. PL/SQL uses Implict Cursors for queries. User defined cursors are called Explicit Cursors. They can be declared and used. 11. What are the PL/SQL Statements used in cursor processing ? DECLARE CURSOR cursor name, OPEN cursor name, FETCH cursor name INTO or Record types, CLOSE cursor name. 12. What are the cursor attributes used in PL/SQL ? %ISOPEN â to check whether cursor is open or not % ROWCOUNT â number of rows featched/updated/deleted. % FOUND â to check whether cursor has fetched any row. True if rows are featched. % NOT FOUND â to check whether cursor has featched any row. True if no rows are featched. These attributes are proceded with SQL for Implict Cursors and with Cursor name for Explict Cursors. 13. What is a cursor for loop ? Cursor for loop implicitly declares %ROWTYPE as loop index,opens a cursor, fetches rows of values from active set into fields in the record and closes when all the records have been processed. eg. FOR emp_rec IN C1 LOOP salary_total := salary_total +emp_rec sal; END LOOP; 14. What will happen after commit statement ? Cursor C1 is Select empno, ename from emp; Begin open C1; loop Fetch C1 into eno.ename; Exit When C1 %notfound;ââ commit; end loop; end; The cursor having query as SELECT âŠ. FOR UPDATE gets closed after COMMIT/ROLLBACK.
- 54. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ The cursor having query as SELECTâŠ. does not get closed even after COMMIT/ROLLBACK. 15. Explain the usage of WHERE CURRENT OF clause in cursors ? WHERE CURRENT OF clause in an UPDATE,DELETE statement refers to the latest row fetched from a cursor. DATABASE TRIGGERS 16. What is a database trigger ? Name some usages of database trigger ? Database trigger is stored PL/SQL program unit associated with a specific database table. Usages are Audit data modificateions, Log events transparently, Enforce complex business rules Derive column values automatically, Implement complex security authorizations. Maintain replicate tables. 17. How many types of database triggers can be specified on a table ? What are they ? Insert Update Delete Before Row o.k. o.k. o.k. After Row o.k. o.k. o.k. Before Statement o.k. o.k. o.k. After Statement o.k. o.k. o.k. If FOR EACH ROW clause is specified, then the trigger for each Row affected by the statement. If WHEN clause is specified, the trigger fires according to the retruned boolean value. 18. Is it possible to use Transaction control Statements such a ROLLBACK or COMMIT in Database Trigger ? Why ? It is not possible. As triggers are defined for each table, if you use COMMIT of ROLLBACK in a trigger, it affects logical transaction processing. 19. What are two virtual tables available during database trigger execution ? The table columns are referred as OLD.column_name and NEW.column_name. For triggers related to INSERT only NEW.column_name values only available. For triggers related to UPDATE only OLD.column_name NEW.column_name values only available. For triggers related to DELETE only OLD.column_name values only available.
- 55. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 20. What happens if a procedure that updates a column of table X is called in a database trigger of the same table ? Mutation of table occurs. 21. Write the order of precedence for validation of a column in a table ? I. done using Database triggers. ii. done using Integarity Constraints. I & ii. EXCEPTION : 22. What is an Exception ? What are types of Exception ? Exception is the error handling part of PL/SQL block. The types are Predefined and user_defined. Some of Predefined execptions are. CURSOR_ALREADY_OPEN DUP_VAL_ON_INDEX NO_DATA_FOUND TOO_MANY_ROWS INVALID_CURSOR INVALID_NUMBER LOGON_DENIED NOT_LOGGED_ON PROGRAM-ERROR STORAGE_ERROR TIMEOUT_ON_RESOURCE VALUE_ERROR ZERO_DIVIDE OTHERS. 23. What is Pragma EXECPTION_INIT ? Explain the usage ? The PRAGMA EXECPTION_INIT tells the complier to associate an exception with an oracle error. To get an error message of a specific oracle error. e.g. PRAGMA EXCEPTION_INIT (exception name, oracle error number) 24. What is Raise_application_error ? Raise_application_error is a procedure of package DBMS_STANDARD which allows to issue an user_defined error messages from stored sub-program or database trigger.
- 56. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 25. What are the return values of functions SQLCODE and SQLERRM ? SQLCODE returns the latest code of the error that has occured. SQLERRM returns the relevant error message of the SQLCODE. 26. Where the Pre_defined_exceptions are stored ? In the standard package. Procedures, Functions & Packages ; 27. What is a stored procedure ? A stored procedure is a sequence of statements that perform specific function. 28. What is difference between a PROCEDURE & FUNCTION ? A FUNCTION is alway returns a value using the return statement. A PROCEDURE may return one or more values through parameters or may not return at all. 29. What are advantages fo Stored Procedures / Extensibility,Modularity, Reusability, Maintainability and one time compilation. 30. What are the modes of parameters that can be passed to a procedure ? IN,OUT,IN-OUT parameters. 31. What are the two parts of a procedure ? Procedure Specification and Procedure Body. 32. Give the structure of the procedure ? PROCEDURE name (parameter listâŠ..) is local variable declarations BEGIN Executable statements. Exception. exception handlers end; 33. Give the structure of the function ?
- 57. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ FUNCTION name (argument list âŠ..) Return datatype is local variable declarations Begin executable statements Exception execution handlers End; 34. Explain how procedures and functions are called in a PL/SQL block ? Function is called as part of an expression. sal := calculate_sal (âa822âČ); procedure is called as a PL/SQL statement calculate_bonus (âA822âČ); 35. What is Overloading of procedures ? The Same procedure name is repeated with parameters of different datatypes and parameters in different positions, varying number of parameters is called overloading of procedures. e.g. DBMS_OUTPUT put_line 36. What is a package ? What are the advantages of packages ? Package is a database object that groups logically related procedures. The advantages of packages are Modularity, Easier Applicaton Design, Information. Hiding,. reusability and Better Performance. 37.What are two parts of package ? The two parts of package are PACKAGE SPECIFICATION & PACKAGE BODY. Package Specification contains declarations that are global to the packages and local to the schema. Package Body contains actual procedures and local declaration of the procedures and cursor declarations. 38. What is difference between a Cursor declared in a procedure and Cursor declared in a package specification ? A cursor declared in a package specification is global and can be accessed by other procedures or procedures in a package. A cursor declared in a procedure is local to the procedure that can not be accessed by other procedures.
- 58. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 39. How packaged procedures and functions are called from the following? a. Stored procedure or anonymous block b. an application program such a PRC *C, PRO* COBOL c. SQL *PLUS a. PACKAGE NAME.PROCEDURE NAME (parameters); variable := PACKAGE NAME.FUNCTION NAME (arguments); EXEC SQL EXECUTE b. BEGIN PACKAGE NAME.PROCEDURE NAME (parameters) variable := PACKAGE NAME.FUNCTION NAME (arguments); END; END EXEC; c. EXECUTE PACKAGE NAME.PROCEDURE if the procedures does not have any out/in-out parameters. A function can not be called. 40. Name the tables where characteristics of Package, procedure and functions are stored ? User_objects, User_Source and User_error.
- 59. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Oracle 1. Three beauty pageant finalists-Cindy, Amy and Linda-The winner was musician. The one who was not last or first was a math major. The one who came in third had black hair. Linda had red hair. Amy had no musical abilities. Who was first? (A) Cindy (B) Amy (C) Linda (D) None of these 2. Two twins have certain peculiar characteristics. One of them always lies on Monday, Wednesday, Friday. The other always lies on Tuesdays, Thursday and Saturdays. On the other days they tell the truth. You are given a conversation. Person A- today is Sunday, my name is Anil Person B-today is Tuesday, my name is Bill What day is today? (A) Sunday (B) Tuesday (C) Monday (D) Thursday 3. The difference of a number and its reciprocal is 1/2.The sum of their squares is (A) 9/4 (B) 4/5 (C) 5/3 (D) 7/4 4. The difference of a number and its square is 870.What is the number? (A) 42 (B) 29 (C) 30 (D) 32 5. A trader has 100 Kg of wheat, part of which he sells at 5% profit and the rest at 20% profit. He gains 15% on the whole. Find how much is sold at 5% profit? (A) 60 (B) 50 (C) 66.66 (D) 33.3 6. Which of the following points are collinear? (A) (3,5) (4,6) (2,7) (B) (3,5) (4,7) (2,3) (C) (4,5) (4,6) (2,7) (D) (6,7) (7,8) (2,7) 7. A man leaves office daily at 7pm.a driver with car comes from his home to pick him from office and bring back home. One day he gets free at 5.30 and instead of waiting for driver he starts walking towards home. In the way he meets the car and returns home on car. He reaches home 20 minutes earlier than
- 60. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ usual. In how much time does the man reach home usually? (A) 1 hr 20 min (B) 1 hr (C) 1 hr 10 min (D) 55 min 8. If m:n = 2:3,the value of 3m+5n/6m-n is (A) 7/3 (B) 3/7 (C) 5/3 (D) 3/5 9. A dog taken four leaps for every five leaps of hare but three leaps of the dog is equal to four leaps of the hare. Compare speed? (A) 12:16 (B) 19:20 (C) 16:15 (D) 10:12 10. A watch ticks 90 times in 95 seconds. And another watch ticks 315 times in 323 secs. If they start together, how many times will they tick together in first hour? (A) 100 times (B) 101 times (C) 99 times (D) 102 times 11. The purpose of defining an index is (A) Enhance Sorting Performance (B) Enhance Searching Performance (C) Achieve Normalization (D) All of the above 12. A transaction does not necessarily need to be (A) Consistent (B) Repeatable (C) Atomic (D) Isolated 13. To group users based on common access permission one should use (A) User Groups (B) Roles (C) Grants (D) None of the above 14. PL/SQL uses which of the following (A) No Binding (B) Early Binding (C) Late Binding (D) Deferred Binding 15. Which of the constraint can be defined at the table level as well as at the column level (A) Unique (B) Not Null (C) Check (D) All the above 16. To change the default date format in a SQLPLUS Session you have to (A) Set the new format in the DATE_FORMAT key in the windows Registry. (B) Alter session to set NLS_DATE-FORMAT. (C) Change the Config.ora File for the date base. (D) Change the User Profile USER-DATE-FORMAT. 17. Which of the following is not necessarily an advantages of using a package rather than independent stored procedure in data base. (A) Better performance. (B) Optimized memory usage. (C) Simplified Security implementation. (D) Encapsulation.
- 61. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 18. Integrity constrains are not checked at the time of (A) DCL Statements. (B) DML Statements. (C) DDL Statements. (D) It is checked all the above cases. 19. Roll Back segment is not used in case of a (A) DCL Statements. (B) DML Statements. (C) DDL Statements. (D) all of the above. 20. An Arc relationship is applicable when (A) One child table has multiple parent relation, but for anyone instance of a child record only one of the relations is applicable. (B) One column of a table is related to another column of the same table. (C) A child table is dependent on columns other than the primary key columns of the parent table. (D) None of the above. 21. What is true about the following C functions? (A) Need not return any value. (B) Should always return an integer. (C) Should always return a float. (D) Should always return more than one value. 22. enum number { a=-1, b=4, c,d,e,} what is the value of e? (A) 7 (B) 4 (C) 5 (D) 3 23. Which of the following about automatic variables within a function is correct? (A) Its type must be declared before using the variable. (B) They are local. (C) They are not initialized to zero. (D) They are global. 24. Consider the following program segment int n, sum=5; switch(n) { case 2:sum=sum-2; case 3:sum*=5; break; default:sum=0; } if n=2, what is the value of the sum? (A) 0 (B) 15 (C) 3 (D) None of these. 25. Which of the following is not an infinite loop? (A) x=0; (B) # define TRUE 0âŠ. do{ While(TRUE){âŠ.} /*x unaltered within the loop*/ (C) for(;;) {âŠ.}
- 62. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âŠ.} While(x==0); (D) While(1) {âŠ.} 26. Output of the following program is main() { int i=0; for(i=0;i<20;i++) { switch(i){ case 0: i+=5; case 1: i+=2; case 5: i+=5; default: i+=4; break; } } } (A) 5,9,13,17 (B) 12,17,22 (C) 16,21 (D) syntax error. 27. What does the following function print? func(int i) { if(i%2) return 0; else return 1; } main() { int i=3; i=func(i); i=func(i); printf(â%dâ,i); } (A) 3 (B) 1 (C) 0 (D) 2
- 63. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 28. What will be the result of the following program? char*g() { static char x[1024]; return x; } main() { char*g1=âFirst Stringâ; strcpy(g(),g1); g1=g(); strcpy(g1,âSecond Stringâ); printf(âAnswer is:%sâ, g()); } (A) Answer is: First String (B) Answer is: Second String (C) Run time Error/Core Dump (D) None of these 29. Consider the following program main() { int a[5]={1,3,6,7,0}; int *b; b=&a[2]; } The value of b[-1] is (A) 1 (B) 3 (C) -6 (D) none 30. Given a piece of code int x[10]; int *ab; ab=x; To access the 6th element of the array which of the following is incorrect? (A) *(x+5) (B) x[5] (C) ab[5] (D) *(*ab+5} .
- 64. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Oracle2 This is the oracle paper held on July 13 2003 at NITK Surathkal. The test has 2 sections : 30 technical and 30 aptitude and 60 min time. Technical section: its very easy any one can answer 25 qns without preperation. some are 1. how compiler treats variables of recursive functions 2. what is orthogonalmatrix? 3. given two tables and asked 2 qns on those table , one is on join and anotheris on NOT IN 4. given some qns on pointers( pretty easy) 5. given five qns on data structures like , lifo, fifo 6. qtn on primary key 7. how NULL in sql is treated? 8. given a doubly linked list and asked r->left->right->data ans: r->data 9:explain const char *ptr and char *const ptr remaining i didn`t remember aptiude 15 quant apti from rs agrval 15 verbal apti, in this 4 are odd word out
- 65. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ and 4 are sentese ordering when jumbled senteses given and 4 are reasoning Model Questions From the Exam conducted by Oracle Bangalore in 2002. 1. What is the output of the following program? #include #include void main( ) { int a=5,b=7; printf(â%dnâ,ba); } A. 1.4 B. 1.0 C. 1 D. 0 2. What is the output of the following program listing? #include void main ( ) { int x,y: y=5; x=func(y++);
- 66. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ printf(â%snâ, (x==5)?âtrueâ;âfalseâ); } int func(int z) { if (z== 6) return 5; else return 6; } A True B false C either a or b D neither a nor b 3. What is the output of the following progarm? #include main( ) { int x,y=10; x=4; y=fact(x); printf(â%dnâ,y); }
- 67. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ unsigned int fact(int x) { return(x*fact(x-1)); } A. 24 B. 10 C. 4 D. none 4. Consider the following C program and chose collect answer #include void main( ) { inta[10],k; for(k=0;k<10;k++) { a[k]=k; } printf (â%dnâ,k); } A. value of k is undefined ; unpredictable answer B. 10 C. program terminates with run time error D. 0
- 68. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 5. Consider the prog and select answer #include void main ( ) { int k=4,j=0: switch (k) { case 3; j=300; case 4: j=400: case 5: j=500; } printf (â%dnâ,j); } A. 300 B. 400 C. 500 D. 0 6. Consider the following statements: Statement 1 A union is an object consisting of a sequence of named members of various types Statement 2 A structure is a object that contains at different times, any one of the several members of various types Statement 3 C is a compiled as well as an interpretted language Statement 4
- 69. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ It is impossible to declare a structure or union containing an instance of itself A. all the statements are correct B. except 4 all are correct C. statemnt 3 is only correct D. statement 1,3 are incorrect either 2 or 4 is correct 7. consider the following program listing and select the output #include main ( ) { int a=010,sum=0,tracker: for(tracker=0;tracker<=a;tracker++) sum+=tracker; printf(â %dnâ,sum); } A. 55 B. 36 C. 28 D. n 8.Spot the line numbers , that are valid according to the ANSI C standards? Line 1: #include Line 2: void main() Line 3: {
- 70. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 4 : int *pia,ia; 5 :float *pafa,fa; 6 :ia=100; 7 :fa=12.05; 8 :*pfa=&ia; 9 :pfa=&ia; 10 :pia=pfa; 11 :fa=(float)*pia; 12 :fa=ia; 13 :} a. 8 and 9 b. 9 and 10 c. 8 and 10 d. 10 and 11 8. What is the o/p of the follow pgm? #include main() { char char_arr[5]=âORACLâ; char c=âEâ; prinf(â%snâ,strcat(char_arr,c)); } a:oracle b. oracl c.e d.none
- 71. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 9. consider the following pgm listing #include main() { int a[3]; int *I; a[0]=100;a[1]=200;a[2]=300; I=a; Printf(â%dnâ, ++*I); Printf(â%dnâ, *++I); Printf(â%dnâ, (*I)â); Printf(â%dnâ, *I); } what is the o/p a. 101,200,200,199 b. 200,201,201,100 c. 101,200,199,199 d. 200,300,200,100 10. which of the following correctly declares âMy_varâ as a pointer to a function that returns an integer a. int*My_Var(); b. int*(My_Var()); c. int(*)My_Var(); d. int(*My_Var)(); 11. what is the memory structure employed by recursive functions in a C pgm?
- 72. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ a. B tree b. Hash table c. Circular list d. Stack 12. Consider the follow pgm listing? Line 1: #include 2: void main() 3: { 4: int a=1; 5: const int c=2; 6: const int *p1=&c; 7: const int*p2=&a; 8: int *p3=&c; 9: int*p4=&a; 10:} what are the lines that cause compilation errors? a.7 b.8 c.6 and 7 d.no errors 13. what will be the o/p #include main() { inta[3]; int *x; int*y; a[0]=0;a[1]=1;a[2]=2; x=a++; y=a; printf(â%d %dnâ, x,(++y)); } a. 0,1 b. 1,1 c. error d. 1,2 what is the procedure for swapping a,b(assume that a,b and tmp are of the same type?
- 73. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ a. tmp=a; a=b;b=temp; b. a=a+b;b=a-b;a=a-b; c. a=a-b;b=a+b;a=b-a; d. all of the above Tracebility Matrix Chart Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Tracebility Matrix Chart |Leave a comment ORIGINATOR: DATE: PROJECT CODE: PROJECT: SLNO Input document name & number PMP Version BRD version FSD version TS version Code Version Others (Specify) version Review Date Reviewerâs Name 1. 2. 3. 4. 5.
- 74. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ SL NO Functionality Reference Ref. In TS Document Unit Test Case Ref. Assembly Test Case Ref. System Test Case Ref. 1. 2. 3. 4. 5. Web Testing Basics Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Web Testing Basics | Leave a comment Letâs have first web testing checklist. 1) Functionality Testing 2) Usabilitytesting 3) Interface testing 4) Compatibilitytesting 5) Performance testing 6) Security testing 1) Functionality Testing: Test for â all the links in web pages,database connection, forms used in the web pages for submitting or getting information from user,Cookie testing. Check all the links: o Test the outgoing links from all the pages from specific domain under test. o Test all internal links. o Test links jumping on the same pages. o Test links used to send the email to admin or other users from web pages. o Test to check if there are any orphan pages. o Lastly in link checking, check for broken links in all above-mentioned links.
- 75. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Test forms in all pages: Forms are the integral part of any web site. Forms are used to get information from users and to keep interaction with them.So what should be checked on these forms? o First check all the validations on each field. o Check for the default values of fields. o Wrong inputs to the fields in the forms. o Options to create forms ifany, form delete, view or modifythe forms. Letâs take example of the search engine projectcurrentlyI am working on, In this projectwe have advertiser and affiliate signup steps.Each sign up step is differentbut dependenton other steps.So sign up flow should get executed correctly. There are different field validations like email Ids,User financial info validations. All these validations should getchecked in manual or automated web testing. Cookies testing: Cookies are small files stored on user machine.These are basicallyused to maintain the session mainlylogin sessions. Testthe application by enabling or disabling the cookies in your browser options.Testifthe cookies are encrypted before writing to user machine. If you are testing the session cookies (i.e.cookies expire after the sessions ends) check for login sessions and user stats after session end.Check effect on application securityby deleting the cookies.(I will soon write separate article on cookie testing) Validate your HTML/CSS: If you are optimizing your site for Search engines then HTML/CSS validation is very important. Mainly validate the site for HTML syntax errors.Check if site is crawlable to differentsearch engines. Database testing: Data consistencyis very important in web application. Check for data integrity and errors while you edit, delete, modify the forms or do any DB related functionality. Check if all the database queries are executing correctly, data is retrieved correctly and also updated correctly. More on database testing could be load on DB, we will address this in web load or performance testing below. 2) Usability Testing: Test for navigation: Navigation means how the user surfs the web pages,differentcontrols like buttons, boxes or how user using the links on the pages to surfdifferent pages. Usabilitytesting includes: Web site should be easyto use. Instructions should be provided clearly.Check if the provided instructions are correct means whether theysatisfy purpose. Main menu should be provided on each page.It should be consistent. Contentchecking: Contentshould be logical and easyto understand. Check for spelling errors.Use ofdark colors annoys users and should notbe used in site theme. You can follow some standards thatare used for web page and content building. These are common accepted standards like as Imentioned above aboutannoying colors,fonts,frames etc. Contentshould be meaningful. All the anchor text links should be working properly.Images should be placed properly with proper sizes.
- 76. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ These are some basic standards thatshould be followed in web development. Your task is to validate all for UI testing Other user information for user help: Like search option,sitemap, help files etc.Sitemap should be presentwith all the links in web sites with proper tree view of navigation. Check for all links on the sitemap. âSearch in the siteâ option will help users to find content pages they are looking for easilyand quickly. These are all optional items and ifpresentshould be validated. 3) Interface Testing: The main interfaces are: Web server and application server interface Application server and Database server interface. Check if all the interactions between these servers are executed properly. Errors are handled properly. If database or web server returns any error message for any query by application server then application server should catch and displaythese error messages appropriatelyto users.Check whathappens ifuser interrupts any transaction in- between? Check whathappens ifconnection to web server is resetin between? 4) Compatibility Testing: Compatibilityof your web site is very important testing aspect.See which compatibilitytestto be executed: o Browser compatibility o Operating system compatibility o Mobile browsing o Printing options Browser compatibility: In my web-testing career Ihave experienced this as mostinfluencing parton web site testing. Some applications are very dependenton browsers. Differentbrowsers have differentconfigurations and settings that your web page should be compatible with.Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing securitychecks or validations then give more stress on browser compatibilitytesting of your web application. Test web application on differentbrowsers like Internetexplorer, Firefox, Netscape navigator, AOL, Safari, Opera browsers with differentversions. OS compatibility: Some functionalityin your web application is maynot be compatible with all operating systems.All new technologies used in web development like graphics designs,interface calls like differentAPIâs may not be available in all Operating Systems. Test your web application on differentoperating systems like Windows,Unix,MAC, Linux, Solaris with differentOS flavors. Mobile browsing: This is new technology age.So in future Mobile browsing will rock.Testyour web pages on mobile browsers. Compatibilityissues maybe there on mobile.
- 77. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Printing options: If you are giving page-printing options then make sure fonts,page alignment, page graphics getting printed properly. Pages should be fitto paper size or as per the size mentioned in printing option. 5) Performance testing: Web application should sustain to heavy load.Web performance testing should include: Web Load Testing Web Stress Testing Test application performance on differentinternetconnection speed. In web load testing testif many users are accessing or requesting the same page.Can system sustain in peak load times? Site should handle manysimultaneous user requests,large inputdata from users,Simultaneous connection to DB, heavy load on specific pages etc. Stress testing:Generallystress means stretching the system beyond its specification limits.Web stress testing is performed to break the site by giving stress and checked how system reacts to stress and how system recovers from crashes. Stress is generallygiven on input fields,login and sign up areas. In web performance testing web site functionalityon different operating systems,differenthardware platforms is checked for software,hardware memoryleakage errors, 6) Security Testing: Following are some testcases for web securitytesting: o Test by pasting internal url directly into browser address bar withoutlogin.Internal pages should notopen. o If you are logged in using username and password and browsing internal pages then try changing url options directly. I.e. If you are checking some publisher site statistics with publisher site ID= 123. Try directly changing the url site ID parameter to different site ID which is not related to logged in user.Access should denied for this user to view others stats. o Try some invalid inputs in inputfields like login username,password,inputtext boxes.Check the system reaction on all invalid inputs. o Web directories or files should notbe accessible directlyunless given download option. o Test the CAPTCHA for automates scripts logins. o Test if SSL is used for securitymeasures. If used proper message should getdisplayed when user switch from non-secure http:// pages to secure https:// pages and vice versa. o All transactions, error messages,securitybreach attempts should getlogged in log files somewhere on web server. What you need to know about BVT (Build Verification Testing)
- 78. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: BVT (Build Verification Testing) | Leave a comment What is BVT? Build Verification testis a set of tests run on every new build to verify that build is testable before it is released to test team for further testing.These test cases are core functionality testcases thatensure application is stable and can be tested thoroughly. Typically BVT process is automated. IfBVT fails that build is again getassigned to developer for fix. BVT is also called smoke testing or build acceptance testing (BAT) New Build is checked mainly for two things: o Build validation o Build acceptance Some BVT basics: o It is a subsetoftests that verify main functionalities. o The BVTâs are typically run on daily builds and ifthe BVT fails the build is rejected and a new build is released after the fixes are done. o The advantage of BVT is it saves the efforts of a testteam to setup and testa build when major functionalityis broken. o Design BVTs carefully enough to cover basic functionality. o Typically BVT should notrun more than 30 minutes. o BVT is a type of regression testing, done on each and every new build. BVT primarilychecks for the project integrity and checks whether all the modules are integrated properlyor not. Module integration testing is very important when different teams develop projectmodules. Iheard manycases of application failure due to improper module integration. Even in worstcases complete projectgets scraped due to failure in module integration. What is the main task in build release? Obviously file âcheck inâ i.e. to include all the new and modified projectfiles associated with respective builds.BVT was primarilyintroduced to check initial build health i.e. to check whether â all the new and modified files are included in release,all file formats are correct, every file version and language,flags associated with each file. These basic checks are worth before build release to testteam for testing. You will save time and money by discovering the build flaws at the very beginning using BVT. Which test cases should be included in BVT? This is very tricky decision to take before automating the BVT task. Keep in mind thatsuccess ofBVT depends on which test cases you include in BVT. Here are some simple tips to include test cases in your BVT automation suite: o Include only critical testcases in BVT. o All testcases included in BVT should be stable. o All the testcases should have known expected result. o Make sure all included critical functionalitytest cases are sufficientfor application testcoverage.
- 79. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Also do not includes modules in BVT, which are not yet stable. For some under-development features you canât predictexpected behavior as these modules are unstable and you mightknow some known failures before testing for these incomplete modules.There is no pointusing such modules or testcases in BVT. You can make this critical functionality test cases inclusion task simple bycommunicating with all those involved in projectdevelopment and testing life cycle. Such process should negotiate BVT test cases,which ultimatelyensure BVT success.Setsome BVT quality standards and these standards can be metonly by analyzing major project features and scenarios. Example: Test cases to be included in BVT for Text editor application (Some sample tests only): 1) Test case for creating text file. 2) Test cases for writing something into text editor 3) Test case for copy, cut, paste functionality of text editor 4) Test case for opening,saving,deleting text file. These are some sample testcases,which can be marked as âcriticalâ and for every minor or major changes in application these basic critical testcases should be executed. This task can be easilyaccomplished byBVT. BVT automation suits needs to be maintained and modified time-to-time.E.g.include testcases in BVT when there are new stable projectmodules available. What happens when BVT suite run: Say Build verification automation testsuite executed after any new build. 1) The resultof BVT execution is sent to all the email IDâs associated with thatproject. 2) The BVT owner (person executing and maintaining the BVT suite) inspects the resultofBVT. 3) If BVT fails then BVT owner diagnose the cause offailure. 4) If the failure cause is defectin build,all the relevant information with failure logs is sentto respective developers. 5) Developer on his initial diagnostic replies to team aboutthe failure cause.Whether this is really a bug? And if itâs a bug then what will be his bug-fixing scenario. 6) On bug fix once again BVT test suite is executed and if build passes BVT, the build is passed to testteam for further detail functionality, performance and other testes. This process gets repeated for every new build. Why BVT or build fails? BVT breaks sometimes.This doesnâtmean thatthere is always bug in the build.There are some other reasons to build fail like testcase coding error, automation suite error,infrastructure error,hardware failures etc. You need to troubleshoot the cause for the BVT break and need to take proper action after diagnosis. Tips for BVT success: 1) Spend considerable time writing BVT test cases scripts. 2) Log as much detailed info as possible to diagnose the BVT pass or fail result.This will help developer team to debug and quickly know the failure cause. 3) Select stable testcases to include in BVT. For new features if new critical test case passes consistentlyon different configuration then promote this testcase in your BVT suite.This will reduce the probability of frequent build failure due to new unstable modules and testcases. 4) Automate BVT process as much as possible. Rightfrom build release process to BVT resultâ automate
- 80. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ everything. 5) Have some penalties for breaking the build Some chocolates or team coffee party from developer who breaks the build will do. Conclusion: BVT is nothing buta set of regression testcases thatare executed each time for new build.This is also called as smoke test.Build is not assigned to testteam unless and until the BVT passes. BVT can be run by developer or tester and BVT resultis communicated throughoutthe team and immediate action is taken to fix the bug if BVT fails. BVT process is typicallyautomated by writing scripts for testcases.Only critical testcases are included in BVT. These testcases should ensure application testcoverage.BVT is very effective for daily as well as long term builds. This saves significant time,cost,resources and after all no frustration of test team for incomplete build. If you have some experience in BVT process then please share it with our readers in comments below. Website Cookie Testing, Test cases for testing web application cookies? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Test cases for testing w eb application cookies, Website Cookie Testing | Leave a comment What is Cookie? Cookie is small information stored in text file on userâs hard drive by web server. This information is later used by web browser to retrieve information from thatmachine. Generallycookie contains personalized user data or information that is used to communicate between different web pages. Why Cookies are used? Cookies are nothing butthe userâs identityand used to track where the user navigated throughout the web site pages.The communication between web browser and web server is stateless. For example if you are accessing domain http://www.example.com/1.html then web browser will simplyquery to example.com web server for the page 1.html. Next time if you type page ashttp://www.example.com/2.html then new request is send to example.com web server for sending 2.html page and web server donâtknow anything about to whom the previous page 1.html served. What if you want the previous history of this user communication with the web server? You need to maintain the user state and interaction between web browser and web server somewhere. This is where cookie comes into picture. Cookies serve the purpose ofmaintaining the user interactions with web server. How cookies work? The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are two types of HTTP protocol.Stateless HTTP and Stateful HTTP protocol.Stateless HTTP protocol does notkeep any record of previouslyaccessed web page history.While Stateful HTTP protocol do keep some historyof previous web browser and web server interactions and this protocol is used by cookies to maintain the user interactions.
- 81. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Whenever user visits the site or page that is using cookie,small code inside thatHTML page (Generally a call to some language scriptto write the cookie like cookies in JAVAScript, PHP, Perl) writes a text file on users machine called cookie. Here is one example of the code that is used to write cookie and can be placed inside anyHTML page: Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; When user visits the same page or domain later time this cookie is read from disk and used to identify the second visit of the same user on that domain. Expiration time is setwhile writing the cookie.This time is decided by the application thatis going to use the cookie. Generally two types of cookies are written on user machine. 1) Session cookies: This cookie is active till the browser thatinvoked the cookie is open.When we close the browser this session cookie gets deleted. Some time session ofsay20 minutes can be setto expire the cookie. 2) Persistent cookies: The cookies that are written permanentlyon user machine and lasts for months or years. Where cookies are stored? When any web page application writes cookie itget saved in a text file on user hard disk drive. The path where the cookies getstored depends on the browser.Differentbrowsers store cookie in differentpaths.E.g. Internet explorer store cookies on path âC:Documents and SettingsDefault UserCookiesâ Here the âDefault Userâ can be replaced by the current user you logged in as. Like âAdministratorâ, or user name like âVijayâ etc. The cookie path can be easilyfound by navigating through the browser options. In Mozilla Firefox browser you can even see the cookies in browser options itself.Open the Mozila browser, click on Tools->Options->Privacyand then âShow cookiesâ button. How cookies are stored? Lets take example of cookie written by rediff.com on Mozilla Firefox browser: On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk.To view this cookie simplyclick on âShow cookiesâ button mentioned on above path. Click on Rediff.com site under this cookie list.You can see different cookies written by rediff domain with different names. Site: Rediff.com Cookie name:RMID Name: RMID (Name of the cookie) Content: 1d11c8ec44bf49e0⊠(Encrypted content) Domain: .rediff.com Path: / (Any path after the domain name) Send For: Any type of connection Expires: Thursday, December 31,2020 11:59:59 PM Applications where cookies can be used: 1) To implement shopping cart: Cookies are used for maintaining online ordering system.Cookies remember whatuser wants to buy. What if user adds some products in their shopping cartand if due to some reason user donâtwantto buy those products this time
- 82. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ and closes the browser window? When next time same user visits the purchase page he can see all the products he added in shopping cartin his lastvisit. 2) Personalized sites: When user visits certain pages they are asked which pages theydonâtwant to visit or display. User options are get stored in cookie and till the user is online,those pages are notshown to him. 3) User tracking: To track number ofunique visitors online atparticular time. 4) Marketing: Some companies use cookies to displayadvertisements on user machines.Cookies control these advertisements. When and which advertisement should be shown? Whatis the interestof the user? Which keywords he searches on the site? All these things can be maintained using cookies. 5) User sessions: Cookies can track user sessions to particular domain using user ID and password. Drawbacks of cookies: 1) Even writing Cookie is a great way to maintain user interaction, ifuser has setbrowser options to warn before writing any cookie or disabled the cookies completelythen site containing cookie will be completelydisabled and can not perform any operation resulting in loss ofsite traffic. 2) Too many Cookies: If you are writing too many cookies on every page navigation and if user has turned on option to warn before writing cookie,this could turn away user from your site. 3) Security issues: Some times users personal information is stored in cookies and ifsomeone hack the cookie then hacker can get access to your personal information. Even corrupted cookies can be read by differentdomains and lead to security issues. 4) Sensitive information: Some sites maywrite and store your sensitive information in cookies,which should notbe allowed due to privacy concerns. This should be enough to know whatcookies are.If you want more cookie info see Cookie Central page. Some Major Test cases for web application cookie testing: The first obvious testcase is to test if your application is writing cookies properlyon disk.You can use theCookie Tester application also if you donât have any web application to test but you wantto understand the cookie concept for testing. Test cases: 1) As a Cookie privacy policy make sure from your design documents thatno personal or sensitive data is stored in the cookie. 2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format. 3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoyusers if browser is prompting for cookies more often and this could resultin loss ofsite traffic and eventually loss ofbusiness.
- 83. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies.Then try to access the web site under test. Navigate through the site.See if appropriate messages are displayed to user like âFor smooth functioning ofthis site make sure that cookies are enabled on your browserâ. There should notbe any page crash due to disabling the cookies.(Please make sure that you close all browsers,delete all previouslywritten cookies before performing this test) 5) Accepts/Reject some cookies: The bestway to check web site functionality is,not to acceptall cookies. If you are writing 10 cookies in your web application then randomlyacceptsome cookies sayaccept 5 and reject 5 cookies. For executing this test case you can setbrowser options to promptwhenever cookie is being written to disk.On this promptwindow you can either accept or rejectcookie. Try to access major functionalityof web site.See if pages are getting crashed or data is getting corrupted. 6) Delete cookie: Allow site to write the cookies and then close all browsers and manuallydelete all cookies for web site under test. Access the web pages and check the behavior of the pages. 7) Corrupt the cookies: Corrupting cookie is easy.You know where cookies are stored.Manually edit the cookie in notepad and change the parameters to some vague values.Like alter the cookie content, Name ofthe cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should nothappen in case ofyour web site cookies.Note that the cookies written by one domain sayrediff.com canâtbe accessed byother domain sayyahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data. 8 ) Checking the deletion of cookies from your webapplication page: Some times cookie written by domain say rediff.com may be deleted by same domain butby different page under that domain. This is the general case if you are testing some âaction trackingâ web portal.Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs byuser the cookie written on disk get deleted to avoid multiple action logging from same cookie.Check ifreaching to your action or purchase page deletes the cookie properlyand no more invalid actions or purchase getlogged from same user. 9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properlyon different browsers as intended and site works properlyusing these cookies.You can test your web application on Major used browsers like Internetexplorer (Various versions), Mozilla Firefox, Netscape, Opera etc. 10) If your web application is using cookies tomaintain the logging state of any user then log in to your web application using some username and password.In many cases you can see the logged in user ID parameter directly in browser address bar.Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter.The proper access message should be displayed to user and user should notbe able to see other users account. These are some Major test cases to be considered while testing website cookies.You can write multiple testcases from these test cases byperforming various combinations. If you have some differentapplication scenario,you can mention your testcases in comments below.
- 84. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Installation Testing Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Installation Testing | Leave a comment Have you performed software installation testing? How was the experience? Well, Installation testing (Implementation Testing) is quite interesting part of software testing life cycle. Installation testing is like introducing a guest in your home. The new guest should be properly introduced to all the family members in order to feel him comfortable. Installation of new software is also quite like above example. If your installation is successful on the new system then customer will be definitely happy but what if things are completely opposite. If installation fails then our program will not work on that system not only this but can leave userâs system badly damaged. User might require to reinstall the full operating system. In above case will you make any impression on user? Definitely not! Your first impression to make a loyal customer is ruined due to incomplete installation testing. What you need to do for a good first impression? Test the installer appropriately with combination of both manual and automated processes on different machines with different configuration. Major concerned of installation testing is Time! It requires lot of time to even execute a single test case. If you are going to test a big application installer then think about time required to perform such a many test cases on different configurations. We will see different methods to perform manual installer testing and some basic guideline for automating the installation process. To start installation testing first decide on how many different system configurations you want to test the installation. Prepare one basic hard disk drive. Format this HDD with most common or default file system, install most common operating system (Windows) on this HDD. Install some basic required components on this HDD. Each time create images of this base HDD and you can create other configurations on this base drive. Make one set of each configuration like Operating system and file format to be used for further testing.
- 85. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ How we can use automation in this process? Well make some systems dedicated for creating basic images (use softwareâs like Norton Ghost for creating exact images of operating system quickly) of base configuration. This will save your tremendous time in each test case. For example if time to install one OS with basic configuration is say 1 hour then for each test case on fresh OS you will require 1+ hour. But creating image of OS will hardly require 5 to 10 minutes and you will save approximately 40 to 50 minutes! You can use one operating system with multiple attempts of installation of installer. Each time uninstalling the application and preparing the base state for next test case. Be careful here that your uninstallation program should be tested before and should be working fine. Installation testing tips with some broad test cases: 1) Use flow diagrams to perform installation testing. Flow diagrams simplify our task. See example flow diagram for basic installation testing test case.
- 86. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Add some more test cases on this basic flow chart Such as if our application is not the first release then try to add different logical installation paths. 2) If you have previously installed compact basic version of application then in next test case install the full application version on the same path as used for compact version. 3) If you are using flow diagram to test different files to be written on disk while installation then use the same flow diagram in reverse order to test uninstallation of all the installed files on disk. 4) Use flow diagrams to automate the testing efforts. It will be very easy to convert diagrams into automated scripts.
- 87. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 5) Test the installer scripts used for checking the required disk space. If installer is prompting required disk space 1MB, then make sure exactly 1MB is used or whether more disk space utilized during installation. If yes flag this as error. 6) Test disk space requirement on different file system format. Like FAT16 will require more space than efficient NTFS or FAT32 file systems. 7) If possible set a dedicated system for only creating disk images. As said above this will save your testing time. 8 ) Use distributed testing environment in order to carry out installation testing. Distributed environment simply save your time and you can effectively manage all the different test cases from a single machine. The good approach for this is to create a master machine, which will drive different slave machines on network. You can start installation simultaneously on different machine from the master system. 9) Try to automate the routine to test the number of files to be written on disk. You can maintain this file list to be written on disk in and excel sheet and can give this list as a input to automated script that will check each and every path to verify the correct installation. 10) Use softwareâs available freely in market to verify registry changes on successful installation. Verify the registry changes with your expected change list after installation. 11) Forcefully break the installation process in between. See the behavior of system and whether system recovers to its original state without any issues. You can test this âbreak of installationâ on every installation step. 12) Disk space checking: This is the crucial checking in the installation-testing scenario. You can choose different manual and automated methods to do this checking. In manual methods you can check free disk space available on drive before installation and disk space reported by installer script to check whether installer is calculating and reporting disk space accurately. Check the disk space after the installation to verify accurate usage of installation disk space. Run various combination of disk space availability by using some tools to automatically making disk space full while installation. Check system behavior on low disk space conditions while installation. 13) As you check installation you can test for uninstallation also. Before each new iteration of installation make sure that all the files written to disk are removed after uninstallation. Some times uninstallation routine removes files from only last upgraded installation keeping the old version files untouched. Also check for rebooting option after uninstallation manually and forcefully not to reboot. I have addressed many areas of manual as well as automated installation testing procedure. Still there are many areas you need to focus on depending on the complexity of your software under installation. These not addressed important tasks includes installation over the network,
- 88. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ online installation, patch installation, Database checking on Installation, Shared DLL installation and uninstallation etc. Hope this article will be a basic guideline to those having trouble to start with software installation testing both manually or in automation. Important testing Checklist Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Important testing Checklist |Leave a comment Software Testingis the Process of Systematically Runninga Software System Or Program To uncover errors or defects Software Testing in Organizations aiming for SEI Level 3 +: âąAn acknowledged competitive advantage contributing to business success âąMoved from ad hoc to an engineering discipline âąCarrier for faster product delivery, with version controlled test plans and test cases âąLed to reliability prediction through defect metrics âąFocussed on defect elimination at the stage of defect induction itself Testing Phases: âą âUnit Testing âIntegration Testing âSystem Testing âAcceptance Testing All Test Plans and Test Cases shall be Reviewed and Approved before Testing starts. Unit Testing âLowest-level component test âKey foundation for later levels of testing âDetects 65% â 75% of all bugs âStand-alone test âEnsures the conformance to each unit in DDD
- 89. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Integration Testing âAn incremental series of tests of combinations or subassemblies of selected components in an overall system âIntegration testing is incremental in that successively larger and more complex combinations of components are tested in sequence, proceeding from the unit level to eventually the full-integrated system âEnsures the conformance to each module in HLDD System Testing âHighest level of application functionality testing performed by the systems group âEnsures the conformance to the Functional Requirements as specified in the SRS Acceptance Testing âIndependent test performed by the users or QA prior to accepting the delivered system âEnsures the conformance to the Functional Requirements as specified in the URD Testing Activities âąTest Case Design âąReview of Test Case Design âąTesting âąRecording Testing Results âąReview and Sign-Off of Testing Results âąDefect Reporting Testing Documents and Records Documents (SCIs) Test Plan for the Project Test Cases Documents Records Test Report Defect Log Review Reports Unit Test Plan (UTP)
- 90. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âąPlan for the entire Unit Testing in the project âąâąIdentifies the Units/Sub-units covered during Unit Testing âąEach feature in the DDD mapped to a Unit Test Case ID âąTo be prepared at DDD phase itself âąThe test cases are designed and documented âąReferences to the Test Case document(s) shall be given in UTP âąDeliverables at Unit Testing Phase shall be identified in UTP âąResources required shall be mentioned in Project Plan âąSchedules shall be planned Testing coverage shall be identified in the UTP: âąPath Coverage âąStatement Coverage âąDecision (Logic/Branch) Coverage âąCondition Coverage âąDecision/Condition Coverage âąMultiple-Condition Coverage âąFunctionality testing âąUser interface testing âąRegression testing Unit Testing Coverage Path Coverage âTest cases will be written to cover all the possible paths of control flow through the program. Statement Coverage âTest cases will be written such that every statement in the program is executed at least once Decision (Logic/Branch) Coverage âTest Cases will be written such that each decision has a true or false outcome at least once. Condition Coverage âTest Cases will be written such that each condition in a decision takes on all possible outcomes at least once. Decision/Condition Coverage
- 91. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âTest Cases will be written such that each condition in a decision takes on all possible outcomes at least once, each decision takes on all possible outcomes at least once, and each point of entry is invoked at least once. Multiple-Condition Coverage âTest Cases will be written such that all possible combinations of condition outcomes in each decision, and all points of entry, are invoked at least once. Integration Test Plan (ITP) âąPlan for the entire Integration Testing in the project âą âąIdentifies the Modules/Sub-Modules covered during Integration Testing âąEach component of HLDD mapped to a Integration Test Case ID âąRecommended to prepare at HLD phase itself âąThe test cases are designed and documented âąReferences to the Test Case document(s) shall be given in ITP âąDeliverables at Integration Testing Phase shall be identified in ITP âąResources required shall be mentioned in Project Plan âąSchedules shall be planned Testing coverage shall be identified in the ITP: âąFunctionality Testing âąUser interface testing âąDependency (API) testing âąSmoke testing âąCapacity and volume testing âąError / disaster handling and recovery âąConcurrent execution testing âąEquivalence partitioning âąBoundary-value analysis âąCause-effect graphing âąError guessing Equivalence Partitioning âąThe test cases are partitioned into equivalence classes such that âeach test case should invoke as many different input conditions as possible in order to minimize the total number of test cases necessary âif one test case in an equivalence class detects an error, all other test cases in the equivalence class would be expected to find the same error Boundary-value analysis
- 92. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âTest cases explore boundary conditions âTest cases consider input conditions as well as output conditions Cause-effect graphing âTechnique to identify test cases by translating the specifications into Boolean logic network. âThis is a systematic method of generating test cases representing combinations of conditions Error guessing âThe test cases are written both by intuition and experience to uncover certain probable type of errors âThe test case design is by the knack of âsmelling outâ errors System Test Plan (STP) âąPlan for the entire System Testing in the project âą âąIdentifies the features covered during System Testing âąEach feature in the SRS mapped to a System Test Case ID âąRecommended to prepare at SRS phase itself âąThe test cases are designed and documented âąReferences to the Test Case document(s) shall be given in STP âąDeliverables at System Testing Phase shall be identified in STP âąResources required shall be mentioned in Project Plan âąSchedules shall be planned âąFunctionality Testing âąUser interface testing âąUsability testing âąVolume Testing âąStress Testing âąSecurity Testing âąPerformance Testing âąInstallation and upgrade testing âąStandards conformance testing âąConfiguration testing âąNetwork and distributed environment testing âąForward / backward compatibility testing âąReliability Testing âąError / disaster handling and recovery testing âąServiceability Testing âąDocumentation testing
- 93. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âąProcedure testing âąLocalization testing Acceptance Test Plan (ATP) âąPlan for the entire Acceptance Testing in the project âą âąIdentifies the features covered during Acceptance Testing âąEach feature in the URD mapped to a Acceptance Test Case ID âąRecommended to prepare at URD phase itself âąThe test cases are designed and documented âąReferences to the Test Case document(s) shall be given in ATP âąDeliverables at Acceptance Testing Phase shall be identified in ATP âąResources required shall be mentioned in Project Plan âąSchedules shall be planned âąAlpha Test âąBeta Test âąAll the tests covered under system testing can be repeated as per user requirements Terminology Functionality Testing âFunctionality testing is the determination of whether each functionality mentioned in SRS is actually implemented. The objective is to ensure that all the functional requirements as documented in the SRS are accomplished. User Interface Testing âFocus is on testing the user interface, navigation and negative user behavior Concurrent Execution Testing âFocus is on testing with simple usage, standard usage and boundary situations Volume Testing âVolume Testing is to ensure that the software ï·can handle the volume of data as specified in the SRS ï·does not crash with heavy volumes of data, but gives an appropriate message and/or makes a clean exit. âExample: ï·A compiler would be fed an absurdly large source program to compile Stress Testing
- 94. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âExecutes the software in a manner that demands resources in abnormal quantity, frequency and volume and verifies that the system either performs normally, or displays message regarding the limitations of the system Usability Testing âUsability testing is an attempt to uncover the software usability problems involving the human-factor âExample: âąAre the error messages meaningful, easy to understand? âąSecurity Testing âAttempts to verify that protection mechanism built into a system will in fact protect it from improper penetration âExample: âąa database management systemâs data security mechanisms âąPerformance Testing âTests the run-time performance of software within the context of an integrated system âExample: âąthe response times under certain configuration conditions. Installation and Upgrade Testing âFocus is on testing whether the user would be install and upgrade the system Configuration Testing âConfiguration testing includes either or both of the following: âątesting the software with the different possible hardware configurations âątesting each possible configuration of the software Network and Distributed Environment Testing âFocus is on testing the product in the required network and distributed environment Dependency (API) Testing âFocus is on testing the API calls made by the system to other systems Localization Testing âFocus is on testing problems associated with multiple languages support, conversion and also hardware aspects Reliability Testing âThe various software testing processes have the goal to test the software reliability. The âReliability Testingâ which is a part of System Testing encompasses the testing of any specific reliability factors that are stated explicitly in the SRS
- 95. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Error / Disaster Handling and Recovery Testing âForces the software to fail in a variety of ways and verifies that the system recovers and resumes processing Serviceability Testing âServiceability testing covers the serviceability or maintainability characteristics of the software âExample: âąservice aids to be provided with the system, e.g., storage-dump programs, diagnostic programs âąthe maintenance procedures for the system Documentation Testing âDocumentation testing is concerned with the accuracy of the user documentation. This involves âąReview of the user documentation for accuracy and clarity âąTesting the examples illustrated in the user documentation by preparing test cases on the basis of these examples and testing the system Smoke Testing âFocus is on testing the system releases as it is being built to uncover critical and showstopper errors Configuration Testing âConfiguration testing includes either or both of the following: âątesting the software with the different possible hardware configurations âątesting each possible configuration of the software Procedure Testing âIf the software forms a part of a large and not completely automated system, the interfaces of the developed software with the other components in the larger system shall be tested. These may include procedures to be followed by ï·The human operator ï·Database administrator ï·Terminal user âThese procedures are to be tested as part of System testing âąStandards Conformance Testing âFocus is on testing whether the product conforms to prescribed and published standards âąAlpha Test âWithin a vendor, the last level of internal test prior to a limited beta release âąBeta Test
- 96. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âThe vendorâs equivalent of a pilot test (usually with a greater number of participating sites than for a pilot) âąAlpha Test âWithin a vendor, the last level of internal test prior to a limited beta release âąBeta Test âThe vendorâs equivalent of a pilot test (usually with a greater number of participating sites than for a pilot) âąEquivalence Test âA test using only a small sample of all possible test conditions, but ones which are chosen to uncover almost as many defects as an exhaustive test would have uncovered â The key question is : âąWhat subset of all possible test cases has the highest probability of detecting the most errors ? Regression Testing: Comprehensive re-test of an entire system : âąafter system delivery, when a modification has been made, or âąbefore delivery and at the end of system test , after all test cases have been passed, but not passed together against the final version of the system product Regression Testing: âąRegression testing requires that a regression test bed (comprehensive set of re-usable system test cases) be available throughout the useful life of the delivered system âąFunctional acceptance tests form the core of this regression test bed. Regression Testing: âąThe regression test must be maintained, to keep it aligned with the system as the system itself evolves . This maintenance may not be a trivial effort. âąIf a careful determination is made that only portions or subsystems will be affected by a particular change (i.e., the subsystems are decoupled and insulated), then only a partial regression re-test of the affected portions is absolutely necessary Regression Testing: âąIf errors are detected during on-going system operation, then test case(s) should be added to the existing regression test bed to detect any possible further re-occurrences of the error or related errors âąThe additional effort to build a regression test facility is relatively minor if it is done during system development : the attitude should be that test cases
- 97. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ are designed and organized to have an on-going life after system delivery, not one-time throw-aways âąThe decision to perform any particular regression test is based on an analysis of the specific risks and costs Regression Testing: âąRegression tests are more manageable and cost-effective they are coordinated with scheduled releases, versus a piece-meal approach to system modification âąFull regression testing should always be performed when the overall system architecture has been affected âąA guideline for setting the boundaries of regression testing: include any interdependent, integrated applications; exclude tangential applications. âą Assessing Test Effectiveness âąTechniques that provide means to assess the effectiveness, coverage and robustness of a set of test cases: âError Seeding âMutation Analysis Note : These techniques are talked about more than they are practiced. Many people see them as somewhat impractical because they can be difficult to apply well. Error Seeding Approach: Inject a small number of representative defects into the baseline product, and measure the percentage that are uncovered by test strategy variations Purpose: Determine the effectiveness of the test planning and execution, and predict (by extrapolation) how many real defects remain hidden in the product Example : No. found % Total defects Seeded defects 21 75% 8 (actual) Actual defects 241 75% 321(projected) Estimated Unfound defects : 81 Mutation Analysis Approach:
- 98. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Create numerous (minor) variations of the baseline system or program. Then test each variation with the original, unchanged set of test cases, and determine how many of the tests behave as if the product was not changed Purpose: Mutations which do not test differently from the baseline product are carefully examined, to determine whether in fact the tests are inadequate How can we write a good test case? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: good test case, Testing Interview Questions | Leave a comment How can we write a good test case? Essentially a test case is a document that carries a Test Case ID no, title, type of test being conducted,Input,Action or Event to be performed, expected output and whether the Test Case has achieved the desired Output(Yes No) Basically Test cases are based on the Test Plan, which includes each module and what to be tested in each module. Further each action in the module is further divided into testable components from where the Test Cases are derived. Since the test case handles a single event at a time normally, as long as it reflects its relation to the Test plan, it can be called as a good test case.It does not matter whether the event passes orfails, as long as the component to be tested is addressed and can be related to in the Test Plan, the Test Case can be called a good Test Case unique-test-case-id: Test Case Title Purpose: Short sentence or two about the aspect of the system is being tested. If this gets too long, break the test case up or put more information into the feature descriptions. Prereq: Assumptions that must be met before the test case can be run. E.g., âlogged inâ, âguest login allowedâ, âuser testuser existsâ. Test Data: List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each combination of values. These values are written in set notation, one per line. E.g.: loginID = {Valid loginID, invalid loginID, valid email, invalid email, empty} password = {valid, invalid, empty} Steps: Steps to carry out the test. See step formating rules below. 1. visit LoginPage 2. enter userID
- 99. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 3. enter password 4. click login 5. see the terms of use page 6. click agree radio button at page bottom 7. click submit button 8. see PersonalPage 9. verify that welcome message is correct username test plan is a systematic approach to testing a systemsuch as a machine or software. The plan typically contains a detailed understanding ofwhat the eventualworkflow will be. Software Testing Portal Contents 1 Test plans in software development 1.1 Test plan template, based on IEEE 829 format 1.1.1 Test plan identifier 1.1.2 References 1.1.3 Introduction 1.1.4 Test items (functions) 1.1.5 Software risk issues. 1.1.6 Features to be tested 1.1.7 Features not to be tested 1.1.8 Approach (strategy) 1.1.9 Item pass/fail criteria 1.1.10 Entry & exit criteria 1.1.11 Suspension criteria & resumption requirements 1.1.12 Test deliverables
- 100. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 1.1.13 Remaining test tasks 1.1.14 Environmental needs 1.1.15 Staffing and training needs 1.1.16 Responsibilities 1.1.17 Planning risks and contingencies 1.1.18 Approvals 1.1.19 Glossary 1.2 Regional differences 2 Criticism of the overuse of test plans 3 Test plans in hardware development 4 IEEE 829-1998: 5 See also 6 External links Test plans in software development In software testing,a test plan gives detailed testing information regarding an upcoming testing effort, including Scope of testing. Schedule. Test Deliverables. Release Criteria. Risks and Contingencies.
- 101. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Test plan template, based on IEEE 829 format Test Plan Identifier (TPI). References Introduction Test Items Software Risk Issue Features to be Tested Features not to be Tested Approach Item Pass/Fail Criteria Entry & Exit Criteria Suspension Criteria and Resumption Requirements Test Deliverables Remaining Test Tasks Environmental Needs Staffing and Training Needs Responsibilities Planning Risks and Contingencies Approvals
- 102. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ [edit] Test plan identifier For example: âMasterplan for 3A USB Host Mass Storage Driver TP_3A1.0âł Some type of unique company generated number to identify this test plan, its level and the level of software that it is related to. Preferably the test plan level will be the same as the related software level. The number may also identify whether the test plan is a Masterplan, a Level plan, an integration plan or whichever plan level it represents.This is to assist in coordinating software and testware versions within configuration management. Keep in mind that test plans are like other software documentation, they are dynamic in nature and must be kept up to date. Therefore, they will have revision numbers. You may want to include authorand contact information including the revision history information as part of either the identifier section of as part of the introduction⊠References List all documents that support this test plan Documents that are referenced include: Project Plan. System Requirements specifications. High Level design document. Detail design document. Development and Test process standards. Methodology. Low level design. Introduction State the purpose of the Plan, possibly identifying the level of the plan (master etc.). This is essentially the executive summary part of the plan.
- 103. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ You may want to include any references to other plans, documents or items that contain information relevant to this project/process. Identify the objective of the plan or scope of the plan in relation to the Software Project plan that it relates to. Other items may include, resource and budget constraints,scope ofthe testing effort, how testing relates to other evaluation activities (Analysis & Reviews), and possible the process to be used for change control and communication and coordination of key activities. As this is the âExecutive Summaryâ keep information brief and to the point. Intention of this project has to be included [edit] Test items (functions) These are things you intend to test within the scope of this test plan. Essentially, something you will test,a list of what is to be tested.This can be developed from the software application inventories as well as other sources of documentation and information. This can be controlled on a local Configuration Management (CM) process if you have one. This information includes version numbers, configuration requirements where needed, (especially if multiple versions of the product are supported).It may also include key delivery schedule issues for critical elements. This section can be oriented to the level of the test plan. For higher levels it may be by application or functional area, for lower levels it may be by program, unit, module or build. Software risk issues. Identify what software is to be tested and what the critical areas are, such as: Delivery of a third party product. New version of interfacing software. Ability to use and understand a new package/tool, etc. Extremely complex functions.
- 104. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Modifications to components with a past history of failure. Poorly documented modules or change requests. There are some inherent software risks such as complexity; these need to be identified. Safety. Multiple interfaces. Impacts on Client. Government regulations and rules. Anotherkey area of risk is a misunderstanding of the original requirements. This can occur at the management, us er and developer levels. Be aware of vague or unclear requirements and requirements that cannot be tested. The past history of defects (bugs)discovered during Unit testing will help identify potential areas within the software that are risky. If the unit testing discovered a large number of defects or a tendency towards defects in a particular area of the software, this is an indication of potential future problems. It is the nature of defects to cluster and clump together. If it was defect ridden earlier, it will most likely continue to be defect prone. One good approach to define where the risks are is to have several [brainstorming] sessions. Start with ideas, such as,what worries me about this project/application. Features to be tested This is a listing of what is to be tested from the userâs viewpoint of what the systemdoes.This is not a technical description of the software, but a USERâS view of the functions. Set the level of risk for each feature. Use a simple rating scale such as High, Medium and Low(H, M, L). These types of levels are understandable to a User. You should be prepared to discuss why a particular level was chosen. Sections 4 and 6 are very similar, and the only true difference is the point of view. Section 4 is a technical type description including version numbers and other technical information and Section 6 is from the Userâs viewpoint.
- 105. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Users do not understand technicalsoftware terminology; they understand functions and processes as they relate to their jobs. Features not to be tested This is a listing of what is ânotâ to be tested from both the userâs viewpoint of what the systemdoes and a configuration management/version control view. This is not a technical description of the software, but a userâs view of the functions. Identify why the feature is not to be tested,there can be any number of reasons. Not to be included in this release of the Software. Low risk, has been used before and was considered stable. Will be released but not tested or documented as a functional part of the release of this version of the software. Sections 6 and 7 are directly related to Sections 5 and 17. What will and will not be tested are directly affected by the levels of acceptable risk within the project, and what does not get tested affects the level of risk of the project. Approach (strategy) This is your overall test strategy for this test plan; it should be appropriate to the level of the plan (master, acceptance,etc.) and should be in agreement with all higher and lower levels of plans. Overall rules and processes should be identified. It is important to have instruction as to what is necessary in a test plan before trying to create oneâs own strategy.Make sure that you are apprenticed in this area before trying to teach yours elf this important step in engineering. Are any special tools to be used and what are they? Will the tool require special training? What metrics will be collected? Which level is each metric to be collected at? How is Configuration Management to be handled? How many different configurations will be tested?
- 106. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Hardware Software Combinations of HW, SW and other vendor packages What levels of regression testing will be done and how much at each test level? Will regression testing be based on severity of defects detected? How will elements in the requirements and design that do not make sense orare untestable be processed? If this is a master test plan the overall project testing approach and coverage requirements must also be identified. Specify if there are special requirements for the testing. Only the full component will be tested. A specified segment of grouping of features/components must be tested together. Other information that may be useful in setting the approach are: MTBF, Mean Time Between Failures â if this is a valid measurement for the test involved and if the data is available. SRE, Software Reliability Engineering â if this methodology is in use and if the information is available. How will meetings and other organizational processes be handled? Item pass/fail criteria Show stopperissues.Specify the criteria to be used to determine whether each test item has passed orfailed. Show Stopper severity requires definition within each testing context. Entry & exit criteria Specify the criteria to be used to start testing and how you know when to stop the testing process.
- 107. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Suspension criteria & resumption requirements Suspension criteria specify the criteria to be used to suspend all or a portion of the testing activities while resumption criteria specify when testing can resume after it has been suspended. Unavailability of external dependent systems during execution. When a defect is introduced that cannot allow any further testing. Critical path deadline is missed so that the client will not accept delivery even if all testing is completed. A specific holiday shuts down both development and testing. System Integration Testing in the Integration environment may be resumed underthe following circumstances: When the external dependent systems become available again. When a fix is successfully implemented and the Testing Team is notified to continue testing. The contract is renegotiated with the client to extend delivery. The holiday period ends. Suspension criteria assumes that testing cannot go forward and that going backward is also not possible.A failed build would not suffice as you could generally continue to use the previous build. Most major or critical defects would also not constituted suspension criteria as other areas of the systemcould continue to be tested. Test deliverables List documents, reports,charts, that will be presented to stakeholders on a regular basis during testing and when testing has been completed. Remaining test tasks If this is a multi-phase process orif the application is to be released in increments there may be parts of the application that this plan does not address.These areas need to be identified to avoid any confusion should defects be reported back on those future functions.This will also allow the users and testers to avoid incomplete functions and prevent waste of resources chasing non-defects.
- 108. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ If the project is being developed as a multi-party process,this plan may only cover a portion of the total functions/features.This status needs to be identified so that those other areas have plans developed for them and to avoid wasting resources tracking defects that do not relate to this plan. When a third party is developing the software, this section may contain descriptions of those test tasks belonging to both the internal groups and the external groups.. Environmental needs Are there any special requirements for this test plan, such as: Special hardware such as simulators, static generators etc. How will test data be provided. Are there special collection requirements or specific ranges of data that must be provided? How much testing will be done on each component of a multi-part feature? Special power requirements. An environment where there is more feedback than needs improvement and meets expectations Specific versions of other supporting software. Restricted use of the systemduring testing. Staffing and training needs Training on the application/system. Training for any test tools to be used. The Test Items and Responsibilities sections affect this section. What is to be tested and who is responsible for the testing and training.
- 109. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Responsibilities Who is in charge? Donât leave people in charge of the test plan who have never done anything resembling a test plan before; This is vital, they will learn nothing from it and the test will fail. This issue includes all areas of the plan. Here are some examples: Setting risks. Selecting features to be tested and not tested. Setting overall strategy for this level of plan. Ensuring all required elements are in place for testing. Providing for resolution of scheduling conflicts, especially, if testing is done on the production system. Who provides the required training? Who makes the critical go/no go decisions for items not covered in the test plans? Who is responsible for this risk. Planning risks and contingencies What are the overall risks to the project with an emphasis on the testing process? Lack of personnelresources when testing is to begin. Lack of availability of required hardware, software, data or tools. Late delivery of the software, hardware or tools. Delays in training on the application and/ortools. Changes to the original requirements or designs. Complexities involved in testing the applications
- 110. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Specify what will be done for various events,for example: Requirements definition will be complete by January 1, 20XX, and, if the requirements change after that date,the following actions will be taken: The test schedule and development schedule will move out an appropriate number of days.This rarely occurs,as most projects tend to have fixed delivery dates. The number of tests performed will be reduced. The number of acceptable defects will be increased. These two items could lower the overall quality of the delivered product. Resources will be added to the test team. The test team will work overtime (this could affect team morale). The scope of the plan may be changed. There may be some optimization of resources.This should be avoided, if possible,for obvious reasons. Management is usually reluctant to accept scenarios such as the one above even though they have seen it happen in the past. The important thing to remember is that,if you do nothing at all, the usualresult is that testing is cut back or omitted completely, neither of which should be an acceptable option. Approvals Who can approve the process as complete and allow the project to proceed to the next level (depending on the level of the plan)? At the master test plan level, this may be all involved parties. When determining the approval process,keep in mind who the audience is: The audience for a unit test level plan is different from that of an integration, systemor master level plan. The levels and type of knowledge at the various levels will be different as well. Programmers are very technical but may not have a clear understanding of the overall business process driving the project. Users may have varying levels of business acumen and very little technical skills.
- 111. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Always be wary of users who claim high levels of technical skills and programmers that claim to fully understand the business process.These types ofindividuals can cause more harm than good if they do not have the skills they believe they possess. Glossary Used to define terms and acronyms used in the document, and testing in general, to eliminate confusion and promote consistent communications. Changes Made by AbhishekMenon Regional differences There are often localized differences in the use of this term. In some locations, test plan can mean all of the tests that need to be run. Purists would suggest that a collection of tests or test cases is a Test suite. Some locations would consider what is described above as a test strategy.This usage is generally localized to the Indian market. Some state that a test strategy creation precedes the test plan creation test plan is a systematic approach to testing a systemsuch as a machine or software. The plan typically contains a detailed understanding of what the ev entual workflow will be. Software Testing Portal Contents 1 Test plans in software development 1.1 Test plan template, based on IEEE 829 format 1.1.1 Test plan identifier 1.1.2 References 1.1.3 Introduction 1.1.4 Test items (functions) 1.1.5 Software risk issues. 1.1.6 Features to be tested 1.1.7 Features not to be tested
- 112. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 1.1.8 Approach (strategy) 1.1.9 Item pass/fail criteria 1.1.10 Entry & exit criteria 1.1.11 Suspension criteria & resumption requirements 1.1.12 Test deliverables 1.1.13 Remaining test tasks 1.1.14 Environmental needs 1.1.15 Staffing and training needs 1.1.16 Responsibilities 1.1.17 Planning risks and contingencies 1.1.18 Approvals 1.1.19 Glossary 1.2 Regional differences 2 Criticism of the overuse of test plans 3 Test plans in hardware development 4 IEEE 829-1998: 5 See also 6 External links [edit] Test plans in software development In software testing,a test plan gives detailed testing information regarding an upcoming testing effort, including
- 113. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Scope of testing. Schedule. Test Deliverables. Release Criteria. Risks and Contingencies. [edit] Test plan template, based on IEEE 829 format Test Plan Identifier (TPI). References Introduction Test Items Software Risk Issue Features to be Tested Features not to be Tested Approach Item Pass/Fail Criteria Entry & Exit Criteria Suspension Criteria and Resumption Requirements Test Deliverables Remaining Test Tasks Environmental Needs Staffing and Training Needs Responsibilities Planning Risks and Contingencies
- 114. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Approvals Test plan identifier For example: âMaster plan for 3A USB Host Mass Storage Driver TP_3A1.0âł Some type of unique company generated number to identify this test plan, its level and the level of software that it is related to. Preferably the test plan level will be the same as the related software level. The number may also identify whether the test plan is a Masterplan, a Level plan, an integration plan or whichever plan level it represents.This is to assist in coordinating software and testware versions within configuration management. Keep in mind that test plans are like other software documentation, they are dynamic in nature and must be kept up to date. Therefore, they will have revision numbers. You may want to include authorand contact information including the revision history information as part of either the identifier section of as part of the introduction⊠References List all documents that support this test plan Documents that are referenced include: Project Plan. System Requirements specifications. High Level design document. Detail design document. Development and Test process standards. Methodology. Low level design. Introduction
- 115. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ State the purpose of the Plan, possibly identifying the level of the plan (master etc.). This is essentially the executive summary part of the plan. You may want to include any references to otherplans, documents or items that contain information relevant to this project/process. Identify the objective of the plan or scope of the plan in relation to the Software Project plan that it relates to. Other items may include, resource and budget constraints,scope ofthe testing effort, how testing relates to other evaluation activities (Analysis & Reviews), and possible the process to be used for change control and communication and coordination of key activities. As this is the âExecutive Summaryâ keep information brief and to the point. Intention of this project has to be included Test items (functions) These are things you intend to test within the scope of this test plan. Essentially, something you will test,a list of what is to be tested.This can be developed from the software application inventories as well as other sources of documentation and information. This can be controlled on a local Configuration Management (CM) process if you have one. This information includes version numbers, configuration requirements where needed, (especially if multiple versions of the product are supported).It may also include key delivery schedule issues for critical elements. This section can be oriented to the level of the test plan. For higher levels it may be by application or functional area, for lower levels it may be by program, unit, module or build. Software risk issues. Identify what software is to be tested and what the critical areas are, such as: Delivery of a third party product. New version of interfacing software. Ability to use and understand a new package/tool, etc. Extremely complex functions. Modifications to components with a past history of failure. Poorly documented modules or change requests.
- 116. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ There are some inherent software risks such as complexity; these need to be identified. Safety. Multiple interfaces. Impacts on Client. Government regulations and rules. Anotherkey area of risk is a misunderstanding of the original requirements. This can occur at the management, user and developer levels. Be aware of vague or unclear requirements and requirements that cannot be tested. The past history of defects (bugs) discovered during Unit testing will help identify potential areas within the software that are risky. If the unit testing discovered a large number of defects or a tendency towards defects in a particular area of the software, this is an indication of potential future problems. It is the nature of defects to cluster and clump together. If it was defect ridden earlier, it will most likely continue to be defect prone. One good approach to define where the risks are is to have several [brainstorming] sessions. Start with ideas, such as, what worries me about this project/application. Features to be tested This is a listing of what is to be tested from the userâs viewpoint of what the systemdoes.This is not a technical description of the software, but a USERâS view of the functions. Set the level of risk for each feature. Use a simple rating scale such as High, Medium and Low(H, M, L). These types of levels are understandable to a User. You should be prepared to discuss why a particular level was chosen. Sections 4 and 6 are very similar, and the only true difference is the point of view. Section 4 is a technical type description including version numbers and other technical information and Section 6 is from the Userâs viewpoint. Users do not understand technicalsoftware terminology; they understand functions and processes as they relate to their jobs. Features not to be tested This is a listing of what is ânotâ to be tested from both the userâs viewpoint of what the systemdoes and a configuration management/version control view. This is not a technical description of the software, but a userâs view of the functions. Identify why the feature is not to be tested,there can be any number of reasons. Not to be included in this release of the Software.
- 117. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Low risk, has been used before and was considered stable. Will be released but not tested or documented as a functional part of the release of this version of the software. Sections 6 and 7 are directly related to Sections 5 and 17. What will and will not be tested are directly affected by the levels of acceptable risk within the project, and what does not get tested affects the level of risk of the project. Approach (strategy) This is your overall test strategy for this test plan; it should be appropriate to the level of the plan (master, acceptance,etc.) and should be in agreement with all higher and lower levels of plans. Overall rules and processes should be identified. It is important to have instruction as to what is necessary in a test plan before trying to create oneâs own strategy.Make sure that you are apprenticed in this area before trying to teach yourself this important step in engineering. Are any special tools to be used and what are they? Will the tool require special training? What metrics will be collected? Which level is each metric to be collected at? How is Configuration Management to be handled? How many different configurations will be tested? Hardware Software Combinations of HW, SW and other vendor packages What levels of regression testing will be done and how much at each test level? Will regression testing be based on severity of defects detected? How will elements in the requirements and design that do not make sense orare untestable be processed? If this is a master test plan the overall project testing approach and coverage requirements must also be identified. Specify if there are special requirements for the testing. Only the full component will be tested.
- 118. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ A specified segment of grouping of features/components must be tested together. Other information that may be useful in setting the approach are: MTBF, Mean Time Between Failures â if this is a valid measurement for the test involved and if the data is available. SRE, Software Reliability Engineering â if this methodology is in use and if the information is available. How will meetings and other organizational processes be handled? [edit] Item pass/fail criteria Show stopperissues.Specify the criteria to be used to determine whether each test item has passed orfailed. Show Stopper severity requires definition within each testing context. Entry & exit criteria Specify the criteria to be used to start testing and how you know when to stop the testing process. Suspension criteria & resumption requirements Suspension criteria specify the criteria to be used to suspend all or a portion of the testing activities while resumption criteria specify when testing can resume after it has been suspended. Unavailability of external dependent systems during execution. When a defect is introduced that cannot allow any further testing. Critical path deadline is missed so that the client will not accept delivery even if all testing is completed. A specific holiday shuts down both development and testing. System Integration Testing in the Integration environment may be resumed underthe following circumstances: When the external dependent systems become available again.
- 119. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ When a fix is successfully implemented and the Testing Team is notified to continue testing. The contract is renegotiated with the client to extend delivery. The holiday period ends. Suspension criteria assumes that testing cannot go forward and that going backward is also not possible.A failed build would not suffice as you could generally continue to use the previous build. Most major or critical d efects would also not constituted suspension criteria as other areas of the systemcould continue to be tested. Test deliverables List documents, reports,charts, that will be presented to stakeholders on a regular basis during testing and when testing has been completed. Remaining test tasks If this is a multi-phase process orif the application is to be released in increments there may be parts of the application that this plan does not address.These areas need to be identified to avoid any confus ion should defects be reported back on those future functions.This will also allow the users and testers to avoid incomplete functions and prevent waste of resources chasing non-defects. If the project is being developed as a multi-party process,this plan may only cover a portion of the total functions/features.This status needs to be identified so that those other areas have plans developed for them and to avoid wasting resources tracking defects that do not relate to this plan. When a third party is developing the software, this section may contain descriptions of those test tasks belonging to both the internal groups and the external groups.. Environmental needs Are there any special requirements for this test plan, such as: Special hardware such as simulators, static generators etc.
- 120. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ How will test data be provided. Are there special collection requirements or specific ranges of data that must be provided? How much testing will be done on each component of a multi-part feature? Special power requirements. An environment where there is more feedback than needs improvement and meets expectations Specific versions of other supporting software. Restricted use of the systemduring testing. Staffing and training needs Training on the application/system. Training for any test tools to be used. The Test Items and Responsibilities sections affect this section. What is to be tested and who is responsible for the testing and training. Responsibilities Who is in charge? Donât leave people in charge of the test plan who have never done anything resembling a test plan before; This is vital, they will learn nothing from it and the test will fail. This issue includes all areas of the plan. Here are some examples: Setting risks. Selecting features to be tested and not tested. Setting overall strategy for this level of plan. Ensuring all required elements are in place for testing. Providing for resolution of scheduling conflicts, especially, if testing is done on the production system. Who provides the required training? Who makes the critical go/no go decisions for items not covered in the test plans? Who is responsible for this risk.
- 121. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Planning risks and contingencies What are the overall risks to the project with an emphasis on the testing process? Lack of personnel resources when testing is to begin. Lack of availability of required hardware, software, data or tools. Late delivery of the software, hardware or tools. Delays in training on the application and/ortools. Changes to the original requirements or designs. Complexities involved in testing the applications Specify what will be done for various events,for example: Requirements definition will be complete by January 1, 20XX, and, if the requirements change after that date, the following actions will be taken: The test schedule and development schedule will move out an appropriate number of days.This rarely occurs, as most projects tend to have fixed delivery dates. The number of tests performed will be reduced. The number of acceptable defects will be increased. These two items could lower the overall quality of the delivered product. Resources will be added to the test team. The test team will work overtime (this could affect team morale). The scope of the plan may be changed. There may be some optimization of resources.This should be avoided, if possible,for obvious reasons. Management is usually reluctant to accept scenarios such as the one above even though they have seen it happen in the past. The important thing to remember is that, if you do nothing at all, the usual result is that testing is cut back or omitted completely, neither of which should be an acceptable option.
- 122. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Approvals Who can approve the process as complete and allow the project to proceed to the next level (depending on the level of the plan)? At the master test plan level, this may be all involved parties. When determining the approval process,keep in mind who the audience is: The audience for a unit test level plan is different from that of an integration, systemor master level plan. The levels and type of knowledge at the various levels will be different as well. Programmers are very technical but may not have a clear understanding of the overall business process driving the project. Users may have varying levels of business acumen and very little technical skills. Always be wary of users who claim high levels of technical skills and programmers that claim to fully understand the business process.These types ofindividuals can cause more harm than good if they do not have the skills they believe they possess. Glossary Used to define terms and acronyms used in the document, and testing in general, to eliminate confusion and promote consistent communications. Regional differences There are often localized differences in the use of this term. In some locations, test plan can mean all of the tests that need to be run. Purists would suggest that a collection of tests or test cases is a Test suite. Some locations would consider what is described above as a test strategy.This usage is generally localized to the Indian market. Some state that a test strategy creation precedes the test plan creation 100 Manual Testing Interview FAQâs Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: inter, Interview Faq's,Manual Testing Basics | Leave a comment Q1. What is verification?
- 123. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ A: Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, and walkthroughs and inspection meetings. You CAN learn to do verification, with little or no outside help. Get CAN get free information. Click on a link! Q2. What is validation? A: Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed. Q3. What is a walkthrough? A: A walkthrough is an informal meeting for evaluation or informational purposes. A walkthrough is also a process at an abstract level. Itâs the process of inspecting software code by following paths through the code (as determined by input conditions and choices made along the way). The purpose of code walkthroughs is to ensure the code fits the purpose. Walkthroughs also offer opportunities to assess an individualâs or teamâs competency. Q4. What is an inspection? A: An inspection is a formal meeting, more formalized than a walkthrough and typically consists of 3- 10 people including a moderator, reader (the author of whatever is being reviewed) and a recorder (to make notes in the document). The subject of the inspection is typically a document, such as a requirements document or a test plan. The purpose of an inspection is to find problems and see what is missing, not to fix anything. The result of the meeting should be documented in a written report. Attendees should prepare for this type of meeting by reading through the document, before the meeting starts; most problems are found during this preparation. Preparation for inspections is difficult, but is one of the most cost-effective methods of ensuring quality, since bug prevention is more cost effective than bug detection. Q5. What is quality? A: Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable. However, quality is a subjective term. Quality depends on who the customer is and their overall influence in the scheme of things. Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organizationâs management, test engineers, testers, salespeople, software engineers, stockholders and accountants. Each type of customer will have his or her own slant on quality. The accounting department might define quality in terms of profits, while an end-user might define quality as user friendly and bug free. Q6. What is good code? A: A good code is code that works, is free of bugs and is readable and maintainable. Organizations usually have coding standards all developers should adhere to, but every programmer and software
- 124. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ engineer has different ideas about what is best and what are too many or too few rules. We need to keep in mind that excessive use of rules can stifle both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems and enforce standards. Q7. What is good design? A: Design could mean too many things, but often refers to functional design or internal design. Good functional design is indicated by software functionality can be traced back to customer and end-user requirements. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable and maintainable; is robust with sufficient error handling and status logging capability; and works correctly when implemented. Q8. What is software life cycle? A: Software life cycle begins when a software product is first conceived and ends when it is no longer in use. It includes phases like initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, re-testing and phase-out. Q9. Why are there so many software bugs? A: Generally speaking, there are bugs in software because of unclear requirements, software complexity, programming errors, changes in requirements, errors made in bug tracking, time pressure, poorly documented code and/or bugs in tools used in software development. There are unclear software requirements because there is miscommunication as to what the software should or shouldnât do. Software complexity. All of the followings contribute to the exponential growth in software and system complexity: Windows interfaces, client-server and distributed applications, data communications, enormous relational databases and the sheer size of applications. Programming errors occur because programmers and software engineers, like everyone else, can make mistakes. As to changing requirements, in some fast-changing business environments, continuously modified requirements are a fact of life. Sometimes customers do not understand the effects of changes, or understand them but request them anyway. And the changes require redesign of the software, rescheduling of resources and some of the work already completed have to be redone or discarded and hardware requirements can be effected, too. Bug tracking can result in errors because the complexity of keeping track of changes can result in errors, too. Time pressures can cause problems, because scheduling of software projects is not easy and it often requires a lot of guesswork and when deadlines loom and the crunch comes, mistakes will be made. Code documentation is tough to maintain and it is also tough to modify code that is poorly documented. The result is bugs. Sometimes there is no incentive for programmers and software
- 125. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ engineers to document their code and write clearly documented, understandable code. Sometimes developers get kudos for quickly turning out code or programmers and software engineers feel they cannot have job security if everyone can understand the code they write, or they believe if the code was hard to write, it should be hard to read. Software development tools, including visual tools, class libraries, compilers, scripting tools, can introduce their own bugs. Other times the tools are poorly documented, which can create additional bugs. Q10. How do you introduce a new software QA process? A: It depends on the size of the organization and the risks involved. For large organizations with high- risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required. Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and testable. Q11. Give me five common problems that occur during software development. A: Poorly written requirements, unrealistic schedules, inadequate testing, and adding new features after development is underway and poor communication. Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems. The schedule is unrealistic if too much work is crammed in too little time. Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes. Itâs extremely common that new features are added after development is underway. Miscommunication either means the developers donât know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed. Q12. Do automated testing tools make testing easier? A: Yes and no. For larger projects, or ongoing long-term projects, they can be valuable. But for small projects, the time needed to learn and implement them is usually not worthwhile. A common type of automated tool is the record/playback type. For example, a test engineer clicks through all combinations of menu choices, dialog box choices, buttons, etc. in a GUI and has an automated testing tool record and log the results. The recording is typically in the form of text, based on a scripting language that the testing tool can interpret. If a change is made (e.g. new buttons are added, or some underlying code in the application is changed), the application is then re-tested by just playing back the recorded actions and compared to the logged results in order to check effects of
- 126. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ the change. One problem with such 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. You CAN learn to use automated testing tools, with little or no outside help. Get CAN get free information. Click on a link! Q13. Give me five solutions to problems that occur during software development. A: Solid requirements, realistic schedules, adequate testing, firm requirements and good communication. Ensure the requirements are solid, clear, complete, detailed, cohesive, attainable and testable. All players should agree to requirements. Use prototypes to help nail down requirements. Have schedules that are realistic. Allow adequate time for planning, design, testing, bug fixing, re- testing, changes and documentation. Personnel should be able to complete the project without burning out. Do testing that is adequate. Start testing early on, re-test after fixes or changes, and plan for sufficient time for both testing and bug fixing. Avoid new features. Stick to initial requirements as much as possible. Be prepared to defend design against changes and additions, once development has begun and be prepared to explain consequences. If changes are necessary, ensure theyâre adequately reflected in related schedule changes. Use prototypes early on so customersâ expectations are clarified and customers can see what to expect; this will minimize changes later on. Communicate. Require walkthroughs and inspections when appropriate; make extensive use of e-mail, networked bug-tracking tools, and tools of change management. Ensure documentation is available and up-to-date. Use documentation that is electronic, not paper. Promote teamwork and cooperation. Q14. What makes a good test engineer? A: Rob Davis is a good test engineer because he Has a âtest to breakâ attitude, Takes the point of view of the customer, Has a strong desire for quality, Has an attention to detail, Heâs also Tactful and diplomatic and Has well a communication skill, both oral and written. And he Has previous software development experience, too. Good test engineers have a âtest to breakâ attitude. We, good test engineers, take the point of view of the customer; have a strong desire for quality and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers and an ability to communicate with both technical and non-technical people. Previous software development experience is also helpful as
- 127. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ it provides a deeper understanding of the software development process gives the test engineer an appreciation for the developersâ point of view and reduces the learning curve in automated test tool programming. Q15. What makes a good QA engineer? A: The same qualities a good test engineer has are useful for a QA engineer. Additionally, Rob Davis understands the entire software development process and how it fits into the business approach and the goals of the organization. Rob Davisâ communication skills and the ability to understand various sides of issues are important. 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. Q16. What makes a good resume? A: On the subject of resumes, there seems to be an unending discussion of whether you should or shouldnât have a one-page resume. The followings are some of the comments I have personally heard: âWell, Joe Blow (car salesman) said I should have a one-page resume.â âWell, I read a book and it said you should have a one page resume.â âI canât really go into what I really did because if I did, itâd take more than one page on my resume.â âGosh, I wish I could put my job at IBM on my resume but if I did itâd make my resume more than one page, and I was told to never make the resume more than one page long.â âIâm confused, should my resume be more than one page? I feel like it should, but I donât want to break the rules.â Or, hereâs another comment, âPeople just donât read resumes that are longer than one page.â I have heard some more, but we can start with these. So whatâs the answer? There is no scientific answer about whether a one-page resume is right or wrong. It all depends on who you are and how much experience you have. The first thing to look at here is the purpose of a resume. The purpose of a resume is to get you an interview. If the resume is getting you interviews, then it is considered to be a good resume. If the resume isnât getting you interviews, then you should change it. The biggest mistake you can make on your resume is to make it hard to read. Why? Because, for one, scanners donât like odd resumes. Small fonts can make your resume harder to read. Some candidates use a 7-point font so they can get the resume onto one page. Big mistake. Two, resume readers do not like eye strain either. If the resume is mechanically challenging, they just throw it aside for one that is easier on the eyes. Three, there are lots of resumes out there these days, and that is also part of the problem. Four, in light of the current scanning scenario, more than one page is not a deterrent because many will scan your resume into their database. Once the resume is in there and searchable, you have accomplished one of the goals of resume distribution. Five, resume readers donât like to guess and most wonât call you to clarify what is on your resume. Generally speaking, your resume should tell your story. If youâre a college graduate looking for your first job, a one-page resume is just fine. If you have a longer story, the resume needs to be longer. Please put your experience on the resume so resume readers can tell when and for whom you did
- 128. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ what. Short resumes â for people long on experience â are not appropriate. The real audience for these short resumes is people with short attention spans and low IQ. I assure you that when your resume gets into the right hands, it will be read thoroughly. Q17. What makes a good QA/Test Manager? A: QA/Test Managers are familiar with the software development process; able to maintain enthusiasm of their team and promote a positive atmosphere; able to promote teamwork to increase productivity; able to promote cooperation between Software and Test/QA Engineers, have the people skills needed to promote improvements in QA processes, have the ability to withstand pressures and say *no* to other managers when quality is insufficient or QA processes are not being adhered to; able to communicate with technical and non-technical people; as well as able to run meetings and keep them focused. Q18. What is the role of documentation in QA? A: Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible. Q19. What about requirements? A: Requirement specifications are important and one of the most reliable methods of insuring problems in a complex software project is to have poorly documented requirement specifications. Requirements are the details describing an applicationâs externally perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable and testable. A non-testable requirement would be, for example, âuser-friendlyâ, which is too subjective. A testable requirement would be something such as, âthe product shall allow the user to enter their previously-assigned password to access the applicationâ. Care should be taken to involve all of a projectâs significant customers in the requirements process. Customers could be in-house or external and could include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, future software maintenance engineers, salespeople and anyone who could later derail the project. If his/her expectations arenât met, they should be included as a customer, if possible. In some organizations, requirements may end up in high-level project plans, functional specification documents, design documents, or other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by test engineers in order to properly plan and execute tests. Without such documentation there will be no clear-cut way to determine if a software application is performing correctly. You CAN learn to capture requirements, with little or no outside help. Get CAN get free information. Click on a link! Q20. What is a test plan?
- 129. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 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 none outside the test group will be able to read it. Q21. What is a test case? A: A test case is a document that describes an input, action, or event and its expected result, in order to determine if a feature of an application is working correctly. A test case should contain particulars such as a⊠Test case identifier; Test case name; Objective; Test conditions/setup; Input data requirements/steps, and Expected results. Please note, the process of developing test cases can help find problems in the requirements or design of an application, since it requires you to completely think through the operation of the application. For this reason, it is useful to prepare test cases early in the development cycle, if possible. Q22. What should be done after a bug is found? A: 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. Q23. What is configuration management? A: Configuration management (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. Rob Davis has had experience with a full range of CM tools and concepts. Rob Davis can easily adapt to your software tool and process needs. Q24. What if the software is so buggy it canât be tested at all?
- 130. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ A: In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem. Q25. How do you know when to stop testing? A: 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. Common factors in deciding when to stop are⊠Deadlines, e.g. release deadlines, testing deadlines; Test cases completed with certain percentage passed; Test budget has been depleted; Coverage of code, functionality, or requirements reaches a specified point; Bug rate falls below a certain level; or Beta or alpha testing period ends. Q26. What if there isnât enough time for thorough testing? A: Since itâs rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions: · Which functionality is most important to the projectâs intended purpose? · Which functionality is most visible to the user? · Which functionality has the largest safety impact? · Which functionality has the largest financial impact on users? · Which aspects of the application are most important to the customer? · Which aspects of the application can be tested early in the development cycle? · Which parts of the code are most complex and thus most subject to errors? · Which parts of the application were developed in rush or panic mode? · Which aspects of similar/related previous projects caused problems? · Which aspects of similar/related previous projects had large maintenance expenses? · Which parts of the requirements and design are unclear or poorly thought out? · What do the developers think are the highest-risk aspects of the application? · What kinds of problems would cause the worst publicity? · What kinds of problems would cause the most customer service complaints?
- 131. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ · What kinds of tests could easily cover multiple functionalities? · Which tests will have the best high-risk-coverage to time-required ratio? Q27. What if the project isnât big enough to justify extensive testing? A: Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the considerations listed under âWhat if there isnât enough time for thorough testing?â do apply. The test engineer then should do âad hocâ testing, or write up a limited test plan based on the risk analysis. Q28. What can be done if requirements are changing continuously? A: Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the applicationâs initial design allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to⊠· Ensure the code is well commented and well documented; this makes changes easier for the developers. · Use rapid prototyping whenever possible; this will help customers feel sure of their requirements and minimize changes. · In the projectâs initial schedule, allow for some extra time to commensurate with probable changes. · Move new requirements to a âPhase 2âČ version of an application and use the original requirements for the âPhase 1âČ version. · Negotiate to allow only easily implemented new requirements into the project; move more difficult, new requirements into future versions of the application. · Ensure customers and management understands scheduling impacts, inherent risks and costs of significant requirements changes. Then let management or the customers decide if the changes are warranted; after all, thatâs their job. · Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes. · Design some flexibility into automated test scripts; · Focus initial automated testing on application aspects that are most likely to remain unchanged; · Devote appropriate effort to risk analysis of changes, in order to minimize regression-testing needs; · Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test cases, or set up only higher-level generic-type test plans; · Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails.
- 132. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Q29. What if the application has functionality that wasnât in the requirements? A: It may take serious effort to determine if an application has significant unexpected or hidden functionality, which it would indicate deeper problems in the software development process. If the functionality isnât necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer. If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only affects areas, such as minor improvements in the user interface, it may not be a significant risk. Q30. How can software QA processes be implemented without stifling productivity? A: Implement QA processes slowly over time. Use consensus to reach agreement on processes and adjust and experiment as an organization grows and matures. Productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection. Panics and burnout will decrease and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings and promote training as part of the QA process. However, no one, especially talented technical types, like bureaucracy and in the short run things may slow down a bit. A typical scenario would be that more days of planning and development will be needed, but less time will be required for late-night bug fixing and calming of irate customers. Q34. What is software quality assurance? A: Software Quality Assurance, when Rob Davis does it, is oriented to *prevention*. It involves the entire software development process. Prevention is monitoring and improving the process, making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with. Software Testing, when performed by Rob Davis, is also oriented to *detection*. Testing involves the operation of a system or application under controlled conditions and evaluating the results. Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes theyâre the combined responsibility of one group or individual. Also common are project teams, which include a mix of test engineers, testers and developers who work closely together, with overall QA processes monitored by project managers. It depends on what best fits your organizationâs size and business structure. Rob Davis can provide QA and/or Software QA. This document details some aspects of how he can provide software testing/QA service. Q35. What is quality assurance? A: Quality Assurance ensures all parties concerned with the project adhere to the process and procedures, standards and templates and test readiness reviews.
- 133. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Rob Davisâ QA service depends on the customers and projects. A lot will depend on team leads or managers, feedback to developers and communications among customers, managers, developersâ test engineers and testers. Q36. Process and procedures â why follow them? A: Detailed and well-written processes and procedures ensure the correct steps are being executed to facilitate a successful completion of a task. They also ensure a process is repeatable. Once Rob Davis has learned and reviewed customerâs business processes and procedures, he will follow them. He will also recommend improvements and/or additions. Q37. Standards and templates â what is supposed to be in a document? A: 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 Rob Davis has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions. Q38. What are the different levels of testing? A: Rob Davis has expertise in testing at all testing levels listed below. At each test level, he documents the results. Each level of testing is either considered black or white box testing. Q39. What is black box testing? A: Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing are based on requirements and functionality. Q40. What is white box testing? A: White box testing is based on knowledge of the internal logic of an applicationâs code. Tests are based on coverage of code statements, branches, paths and conditions. Q41. What is unit testing? A: Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Unit testing is performed after the expected test results are met or differences are explainable/acceptable. Q42. What is parallel/audit testing? A: Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly. Q43. What is functional testing? A: Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers *should* perform functional testing. Q44. What is usability testing?
- 134. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ A: Usability testing is testing for âuser-friendlinessâ. Clearly this is subjective and depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions and other techniques can be used. Programmers and developers are usually not appropriate as usability testers. Q45. What is incremental integration testing? A: Incremental integration testing is continuous testing of an application as new functionality is recommended. This may require that various aspects of an applicationâs functionality are independent enough to work separately, before all parts of the program are completed, or that test drivers are developed as needed. This type of testing may be performed by programmers, software engineers, or test engineers. Q46. What is integration testing? A: 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. Q47. What is system testing? A: System testing is black box testing, performed by the Test Team, and at the start of the system testing the complete system is configured in a controlled environment. The purpose of system testing is to validate an applicationâs accuracy and completeness in performing the functions as designed. System testing simulates real life scenarios that occur in a âsimulated real lifeâ test environment and test all functions of the system that are required in real life. System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input. Upon completion of integration testing, system testing is started. Before system testing, all unit and integration test results are reviewed by Software QA to ensure all problems have been resolved. For a higher level of testing it is important to understand unresolved problems that originate at unit and integration test levels. You CAN learn system testing, with little or no outside help. Get CAN get free information. Click on a link! Q48. What is end-to-end testing? A: Similar to system testing, the *macro* end of the test scale is testing a complete application in a situation that mimics real world use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system. Q49. What is regression testing? A: The objective of regression testing is to ensure the software remains intact. A baseline set of data and scripts is maintained and executed to verify changes introduced during the release have not
- 135. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âundoneâ any previous code. Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level. Q50. What is sanity testing? A: Sanity testing is performed whenever cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc. Q51. What is performance testing? A: Although performance testing is described as a part of system testing, it can be regarded as a distinct level of testing. Performance testing verifies loads, volumes and response times, as defined by requirements. Q52. What is load testing? A: Load testing is testing an application under heavy loads, such as the testing of a web site under a range of loads to determine at what point the system response time will degrade or fail. Q53. What is installation testing? A: Installation testing is testing full, partial, upgrade, or install/uninstall processes. The installation test for a release is conducted with the objective of demonstrating production readiness. This test includes the inventory of configuration items, performed by the applicationâs System Administration, the evaluation of data readiness, and dynamic tests focused on basic system functionality. When necessary, a sanity test is performed, following installation testing. Q54. What is security/penetration testing? A: Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques. Q55. What is recovery/error testing? A: Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems. Q56. What is compatibility testing? A: Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network environment. Q57. What is comparison testing? A: Comparison testing is testing that compares software weaknesses and strengths to those of competitorsâ products. Q58. What is acceptance testing?
- 136. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ A: Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production. The acceptance test is the responsibility of the client/customer or project manager; however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria. Q59. What is alpha testing? A: Alpha testing is testing of an application when development is nearing completion. Minor design changes can still be made as a result of alpha testing. Alpha testing is typically performed by a group that is independent of the design team, but still within the company, e.g. in-house software test engineers, or software QA engineers. Q60. What is beta testing? A: Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers. Q61. What testing roles are standard on most testing projects? A: Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Lead, Test/QA Manager, System Administrator, Database Administrator, Technical Analyst, Test Build Manager and Test Configuration Manager. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager. You CAN get a job in testing. Click on a link! Q62. What is a Test/QA Team Lead? A: The Test/QA Team Lead coordinates the testing activity, communicates testing status to management and manages the test team. Q63. 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. We also⊠· Speed up the work of the development staff; · Reduce your organizationâs risk of legal liability; · Give you the evidence that your software is correct and operates properly; · Improve problem tracking and reporting; · Maximize the value of your software; · Maximize the value of the devices that use it; · Assure the successful launch of your product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down;
- 137. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ · Help the work of your development staff, so the development team can devote its time to build up your product; · Promote continual improvement; · Provide documentation required by FDA, FAA, other regulatory agencies and your customers; · Save money by discovering defects âearlyâ in the design process, before failures occur in production, or in the field; · Save the reputation of your company by discovering bugs and design flaws; before bugs and design flaws damage the reputation of your company. Q64. What is a Test Build Manager? A: Test Build Managers deliver current software versions to the test environment, install the applicationâs software and apply software patches, to the both application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Test Build Manager. Q65. What is a System Administrator? A: Test Build Managers, System Administrators, Database Administrators deliver current software versions to the test environment, install the applicationâs software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a System Administrator. Q66. What is a Database Administrator? A: Test Build Managers, System Administrators and Database Administrators deliver current software versions to the test environment, install the applicationâs software and apply software patches, to the both application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Database Administrator. Q67. What is a Technical Analyst? A: Technical Analysts perform test assessments and validate system/functional test requirements. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Technical Analyst. Q68. What is a Test Configuration Manager? A: Test Configuration Managers maintain test environments, scripts, software and test data. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Test Configuration Manager. Q69. What is a test schedule? A: The test schedule is a schedule that identifies all tasks required for a successful testing effort, a schedule of all test activities and resource requirements.
- 138. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Q70. What is software testing methodology? A: One software testing methodology is the use a three step process of⊠1. Creating a test strategy; 2. Creating a test plan/design; and 3. Executing tests. This methodology can be used and molded to your organizationâs needs. Rob Davis believes that using this methodology is important in the development and in ongoing maintenance of his customersâ applications. Q71. What is the general testing process? A: The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests. Q72. How do you create a test strategy? A: The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, and the test environment, a list of related tasks, pass/fail criteria and risk assessment. Inputs for this process: · A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data. · A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules. · Testing methodology. This is based on known standards. · Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents. · Requirements that the system can not provide, e.g. system limitations. Outputs for this process: · An approved and signed off test strategy document, test plan, including test cases. · Testing issues requiring resolution. Usually this requires additional negotiation at the project management level. Q73. How do you create a test plan/design? A: Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speakingâŠ
- 139. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application. Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases. It is the test team that, with assistance of developers and clients, develops test cases and scenarios for integration and system testing. Test scenarios are executed through the use of test procedures or scripts. Test procedures or scripts define a series of steps necessary to perform one or more test scenarios. Test procedures or scripts include the specific data that will be used for testing the process or transaction. Test procedures or scripts may cover multiple test scenarios. Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope. Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment. Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing. A pretest meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release. Inputs for this process: Approved Test Strategy Document. Test tools, or automated test tools, if applicable. Previously developed scripts, if applicable. Test documentation problems uncovered as a result of testing. A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code and software complexity data. Outputs for this process: Approved documents of test scenarios, test cases, test conditions and test data. Reports of software design issues, given to software developers for correction. Q74. How do you execute tests? A: Execution of tests is completed by following the test documents in a methodical manner. As each test procedure is performed, an entry is recorded in a test execution log to note the execution of the procedure and whether or not the test procedure uncovered any defects. Checkpoint meetings are
- 140. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ held throughout the execution phase. Checkpoint meetings are held daily, if required, to address and discuss testing issues, status and activities. The output from the execution of test procedures is known as test results. Test results are evaluated by test engineers to determine whether the expected results have been obtained. All discrepancies/anomalies are logged and discussed with the software team lead, hardware test lead, programmers, software engineers and documented for further investigation and resolution. Every company has a different process for logging and reporting bugs/defects uncovered during testing. A pass/fail criteria is used to determine the severity of a problem, and results are recorded in a test summary report. The severity of a problem, found during system testing, is defined in accordance to the customerâs risk assessment and recorded in their selected tracking tool. Proposed fixes are delivered to the testing environment, based on the severity of the problem. Fixes are regression tested and flawless fixes are migrated to a new baseline. Following completion of the test, members of the test team prepare a summary report. The summary report is reviewed by the Project Manager, Software QA Manager and/or Test Team Lead. After a particular level of testing has been certified, it is the responsibility of the Configuration Manager to coordinate the migration of the release software components to the next test level, as documented in the Configuration Management Plan. The software is only migrated to the production environment after the Project Managerâs formal acceptance. The test team reviews test document problems identified during testing, and update documents where appropriate. Inputs for this process: Approved test documents, e.g. Test Plan, Test Cases, Test Procedures. Test tools, including automated test tools, if applicable. Developed scripts. Changes to the design, i.e. Change Request Documents. Test data. Availability of the test team and project team. General and Detailed Design Documents, i.e. Requirements Document, Software Design Document. A software that has been migrated to the test environment, i.e. unit tested code, via the Configuration/Build Manager. Test Readiness Document. Document Updates. Outputs for this process: Log and summary of the test results. Usually this is part of the Test Report. This needs to be approved and signed-off with revised testing deliverables. Changes to the code, also known as test fixes.
- 141. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Test document problems uncovered as a result of testing. Examples are Requirements document and Design Document problems. Reports on software design issues, given to software developers for correction. Examples are bug reports on code issues. Formal record of test incidents, usually part of problem tracking. Base-lined package, also known as tested source and object code, ready for migration to the next level. Q75. 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. Q76. 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
- 142. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 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. It 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 denials of service tools. Q77. 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. You CAN learn load testing, with little or no outside help. Get CAN get free information. Click on a link! Q79. 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. You CAN learn testing, with little or no outside help. Get CAN get free information. Click on a link! Q80. 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. Q81. 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. Q82. 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. Q83. 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
- 143. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ there are no defects. You CAN learn software testing, with little or no outside help. Get CAN get free information. Click on a link! Q84. What is automated testing? A: Automated testing is a formally specified and controlled method of formal testing approach. Q85. 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 us, the software QA staff, for additional testing in an environment that is similar to the intended use. Q86. 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. Q87. 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. Q88. 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. You CAN learn clear box testing, with little or no outside help. Get CAN get free information. Click on a link! Q89. 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. Q90. What is ad hoc testing? A: Ad hoc testing is a testing approach; it is the least formal testing approach. 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.
- 144. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 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, or 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, or 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, or 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 purposes. 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!
- 145. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 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. 40 Testing Interview Questions Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Interview Faq's, Manual Testing Basics | Leave a comment Whatâs Ad Hoc Testing ? A testing where the tester tries to break the software by randomly trying functionality of software. Whatâs the Accessibility Testing ? Testing that determines if software will be usable by people with disabilities. Whatâs the Alpha Testing ? The Alpha Testing is conducted at the developer sites and in a controlled environment by the end user of the software Whatâs the Beta Testing ? Testing the application after the installation at the client place. What is Component Testing ? Testing of individual software components (Unit Testing). Whatâs Compatibility Testing ? In Compatibility testing we can test that software is compatible with other elements of system. What is Concurrency Testing ? Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores. What is Conformance Testing ? The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard. What is Context Driven Testing ?
- 146. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ The context-driven school of software testing is flavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now. What is Data Driven Testing ? Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing. What is Conversion Testing ? Testing of programs or procedures used to convert data from existing systems for use in replacement systems. What is Dependency Testing ? Examines an applicationâs requirements for pre-existing software, initial states and configuration in order to maintain proper functionality. What is Depth Testing ? A test that exercises a feature of a product in full detail. What is Dynamic Testing ? Testing software through executing it. See also Static Testing. What is Endurance Testing ? Checks for memory leaks or other problems that may occur with prolonged execution. What is End-to-End testing ? Testing a complete application environment in a situation that mimics real- world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate. What is Exhaustive Testing ? Testing which covers all combinations of input values and preconditions for an element of the software under test. What is Gorilla Testing ? Testing one particular module, functionality heavily. What is Installation Testing ? Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.
- 147. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ What is Localization Testing ? This term refers to making software specifically designed for a specific locality. What is Loop Testing ? A white box testing technique that exercises program loops. What is Mutation Testing ? Mutation testing is a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (âbugsâ) and retesting with the original test data/cases to determine if the âbugsâ are detected. Proper implementation requires large computational resources What is Monkey Testing ? Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out. What is Positive Testing ? Testing aimed at showing software works. Also known as âtest to passâ. See also Negative Testing. What is Negative Testing ? Testing aimed at showing software does not work. Also known as âtest to failâ. See also Positive Testing. What is Path Testing ? Testing in which all paths in the program source code are tested at least once. What is Performance Testing ? Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as âLoad Testingâ. What is Ramp Testing ? Continuously raising an input signal until the system breaks down. What is Recovery Testing ? Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions. What is the Re-testing testing ? Retesting- Again testing the functionality of the application. What is the Regression testing ? Regression- Check that change in code have not effected the working functionality
- 148. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ What is Sanity Testing ? Brief test of major functional elements of a piece of software to determine if its basically operational. What is Scalability Testing ? Performance testing focused on ensuring the application under test gracefully handles increases in work load. What is Security Testing ? Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level. What is Stress Testing ? Stress testing is a form of testing that is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. What is Smoke Testing ? A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire. What is Soak Testing ? Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed. Whatâs the Usability testing ? Usability testing is for user friendliness. Whatâs the User acceptance testing ? User acceptance testing is determining if software is satisfactory to an end-user or customer. Whatâs the Volume Testing ? We can perform the Volume testing, where the system is subjected to large volume of data
- 149. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ As a manager what process did you adopt to define testing policy? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Manual Testing Basics |Leave a comment Below are the important steps to define testing policy in general. But it can change according to how you implemented in your organization. Letâs understand in detail the below steps of implementing a testing policy in an organization. Definition: â The first thing any organization need to do is define one unique definition for testing within organization. So that every one is on the same mind set. How to achieve: â How are we going to achieve our objective?. Is there going to be a testing committee, will there be compulsory test plans which needs to be executed etc etc. Evaluate: â After testing is implemented in project how do we evaluate the same. Are we going to derive metrics of defect per phase, per programmer etc etc. Finally itâs important to let know every one how testing has added value to the project. Standards : â Finally what are the standards we want to achieve by testing. For instance we can define saying that more than 20 defects per KLOC will be considered below standard and code review should be done for the same. Figure: Does Increase in testing always mean good to the project? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Manual Testing Basics |Leave a comment No increase in testing does not mean always good for the product, company or the project. In real test scenarios from 100% test plans only 20% test plans are critical from business angle. Running those critical test plans will assure that the testing is proper rather than running the full 100% test plans again and again. Below is the graph which explains the impact of under testing and over testing. If you under test a system your number of defect will increase, but on the contrary if you over test a system your cost of testing will increase. Even if your defects come down your cost of testing has shooted up.
- 150. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ What is the difference between Verification and Validation? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: Verification and Validation | 1 Comment Verification is a review with out actually executing the process while validation is checking the product with actual execution. For instance code review and syntax check is verification while actually running the product and checking the results is validation. What is the difference between Defect and Failure? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: difference betw een Defect and Failure | Leave a comment Define Defect? Defect is a variance from a normal flow When a defect reaches the end customer it is termed as failure and if the defect is detected internally and resolved itâs called as a defect. There are mainly three categories of defect:- Wrong: â The requirements have been implemented incorrectly. This defect is a variance from the given specification. Missing: â There is a requirement given by the customer and is not done. This is a variance from specification, an indication that the specification was not implemented, or a requirement of the customer was noted properly. Extra: â A requirement incorporated into the product that was not given by the end customer. This is always a variance from specifications, but may be an attribute desired by the user of the product. However, it is considered a defect because itâs a variance from the existing requirements. Figure: What is the difference between white box, black box and gray box testing? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Tags: black box and gray box testing, w hite box | Leave a comment
- 151. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Black box testing is a testing strategy which is based solely on the requirements and specifications. Black box testing requires no knowledge of the internal paths, structure, or implementation of the software under test. White box testing is a testing strategy which is based on the internal paths, code structure, and implementation of the software under test. White box testing generally requires detailed programming skills. There is one more type of testing is called gray box testing. In this we look into the âboxâ under test just long enough to understand how it has been implemented. Then we close up the box and use our knowledge to choose more effective black box tests. Below figure shows how both the types of testers view an accounting application during testing. In case of black box tester they view in terms of pure accounting application. While in terms of White box testing the tester know about the internal structure of the application. In most scenarios white box testing is done by developers as they know the internals of the application. In Black box testing we check the overall functionality of the application while in white box we do code reviews , view the architecture , remove bad code practices and component level testing. Beginner Guide For Software Testing Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Interview Faq's, Manual Testing Basics | Leave a comment Software Life Cycle The software life cycle typically includes the following: requirements analysis, design, coding, testing, installation and maintenance. In between, there can be a requirement to provide Operations and support activities for the product. Requirements Analysis. Software organizations provide solutions to customer requirements by developing appropriate software that best suits their specifications. Thus, the life of software starts with origin of requirements. Very often, these requirements are vague, emergent and always subject to change. Analysis is performed to â To conduct in depth analysis of the proposed project, To evaluate for technical feasibility, To discover how to partition the system, To identify which areas of the requirements need to be elaborated from the customer, To identify the impact of changes to the requirements, To identify which requirements should be allocated to which components. Design and Specifications. The outcome of requirements analysis is the requirements specification. Using this, the overall design for the intended software is developed. Activities in this phase - Perform Architectural Design for the software, Design Database (If applicable), Design User Interfaces, Select or Develop Algorithms (If Applicable), Perform Detailed Design.
- 152. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Coding. The development process tends to run iteratively through these phases rather than linearly; several models (spiral, waterfall etc.) have been proposed to describe this process. Activities in this phase â Create Test Data, Create Source, Generate Object Code, Create Operating Documentation, Plan Integration, Perform Integration. Testing. The process of using the developed system with the intent to find errors. Defects/flaws/bugs found at this stage will be sent back to the developer for a fix and have to be re-tested. This phase is iterative as long as the bugs are fixed to meet the requirements. Activities in this phase â Plan Verification and Validation, Execute Verification and validation Tasks, Collect and Analyze Metric Data, Plan Testing, Develop Test Requirements, Execute Tests. Installation. The so developed and tested software will finally need to be installed at the client place. Careful planning has to be done to avoid problems to the user after installation is done. Activities in this phase â Plan Installation, Distribution of Software, Installation of Software, Accept Software in Operational Environment. Operation and Support. Support activities are usually performed by the organization that developed the software. Both the parties usually decide on these activities before the system is developed. Activities in this phase â Operate the System, Provide Technical Assistance and Consulting, Maintain Support Request Log. Maintenance. The process does not stop once it is completely implemented and installed at user place; this phase undertakes development of new features, enhancements etc. Activities in this phase â Reapplying Software Life Cycle. Various Life Cycle Models The way you approach a particular application for testing greatly depends on the life cycle model it follows. This is because, each life cycle model places emphasis on different aspects of the software i.e. certain models provide good scope and time for testing whereas some others donât. So, the number of test cases developed, features covered, time spent on each issue depends on the life cycle model the application follows. No matter what the life cycle model is, every application undergoes the same phases described above as its life cycle. Following are a few software life cycle models, their advantages and disadvantages. Waterfall Model Strengths: âąEmphasizes completion of one phase before moving on âąEmphasises early planning, customer input, and design âąEmphasises testing as an integral part of the life cycle âąProvides quality gates at each life cycle phase Weakness: âąDepends on capturing and freezing requirements early in the life cycle âąDepends on separating requirements from design âąFeedback is only from testing phase to any previous stage
- 153. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âąNot feasible in some organizations âąEmphasises products rather than processes Prototyping Model Strengths: âąRequirements can be set earlier and more reliably âąRequirements can be communicated more clearly and completelybetween developers and clients âąRequirements and design options can be investigated quickly and with low cost âąMore requirements and design faults are caught early Weakness: âąRequires a prototyping tool and expertise in using it â a cost for the development organisation âąThe prototype may become the production system Spiral Model Strengths: âąIt promotes reuse of existing software in early stages of development âąAllows quality objectives to be formulated during development âąProvides preparation for eventual evolution of the software product âąEliminates errors and unattractive alternatives early. âąIt balances resource expenditure. âąDoesnât involve separate approaches for software development and software maintenance. âąProvides a viable framework for integrated Hardware-software system development. Weakness: âąThis process needs or usually associated with Rapid Application Development, which is very difficult practically. âąThe process is more difficult to manage and needs a very different approach as opposed to the waterfall model (Waterfall model has management techniques like GANTT charts to assess) Software Testing Life Cycle Software Testing Life Cycle consist of six (generic) phases: 1) Planning, 2) Analysis, 3) Design, 4) Construction, 5) Testing Cycles, 6) Final Testing and Implementation and 7) Post Implementation. Each phase in the life cycle is described with the respective activities. Planning. Planning High Level Test plan, QA plan (quality goals), identify â reporting procedures, problem classification, acceptance criteria, databases for testing, measurement criteria (defect quantities/severity level and defect origin), project metrics and finally begin the schedule for project testing. Also, plan to maintain all test cases (manual or automated) in a database. Analysis. Involves activities that â develop functional validation based on Business Requirements (writing test cases basing on these details), develop test case format (time estimates and priority assignments), develop test cycles (matrices and timelines), identify test cases to be automated (if applicable), define area of stress and performance testing, plan the test cycles required for the project and regression testing, define procedures for data maintenance (backup, restore, validation), review documentation.
- 154. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Design. Activities in the design phase â Revise test plan based on changes, revise test cycle matrices and timelines, verify that test plan and cases are in a database or requisite, continue to write test cases and add new ones based on changes, develop Risk Assessment Criteria, formalize details for Stress and Performance testing, finalize test cycles (number of test case per cycle based on time estimates per test case and priority), finalize the Test Plan, (estimate resources to support development in unit testing). Construction (Unit Testing Phase). Complete all plans, complete Test Cycle matrices and timelines, complete all test cases (manual), begin Stress and Performance testing, test the automated testing system and fix bugs, (support development in unit testing), run QA acceptance test suite to certify software is ready to turn over to QA. Test Cycle(s) / Bug Fixes (Re-Testing/System Testing Phase). Run the test cases (front and back end), bug reporting, verification, revise/add test cases as required. Final Testing and Implementation (Code Freeze Phase). Execution of all front end test cases â manual and automated, execution of all back end test cases â manual and automated, execute all Stress and Performance tests, provide on-going defect tracking metrics, provide on-going complexity and design metrics, update estimates for test cases and test plans, document test cycles, regression testing, and update accordingly. Post Implementation. Post implementation evaluation meeting can be conducted to review entire project. Activities in this phase â Prepare final Defect Report and associated metrics, identify strategies to prevent similar problems in future project, automation team â 1) Review test cases to evaluate other cases to be automated for regression testing, 2) Clean up automated test cases and variables, and 3) Review process of integrating results from automated testing in with results from manual testing. What is a bug? Why do bugs occur? A software bug may be defined as a coding error that causes an unexpected defect, fault, flaw, or imperfection in a computer program. In other words, if a program does not perform as intended, it is most likely a bug. There are bugs in software due to unclear or constantly changing requirements, software complexity, programming errors, timelines, errors in bug tracking, communication gap, documentation errors, deviation from standards etc. · Unclear software requirements are due to miscommunication as to what the software should or shouldnât do. In many occasions, the customer may not be completely clear as to how the product should ultimately function. This is especially true when the software is a developed for a completely new product. Such cases usually lead to a lot of misinterpretations from any or both sides. · Constantly changing software requirements cause a lot of confusion and pressure both on the development and testing teams. Often, a new feature added or existing feature removed can be linked to the other modules or components in the software. Overlooking such issues causes bugs. · Also, fixing a bug in one part/component of the software might arise another in a different or same component. Lack of foresight in anticipating such issues can cause serious problems and increase in bug count. This is one of the major issues because of which bugs occur since developers are very often
- 155. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ subject to pressure related to timelines; frequently changing requirements, increase in the number of bugs etc. · Designing and re-designing, UI interfaces, integration of modules, database management all these add to the complexity of the software and the system as a whole. · Fundamental problems with software design and architecture can cause problems in programming. Developed software is prone to error as programmers can make mistakes too. As a tester you can check for, data reference/declaration errors, control flow errors, parameter errors, input/output errors etc. · Rescheduling of resources, re-doing or discarding already completed work, changes in hardware/software requirements can affect the software too. Assigning a new developer to the project in midway can cause bugs. This is possible if proper coding standards have not been followed, improper code documentation, ineffective knowledge transfer etc. Discarding a portion of the existing code might just leave its trail behind in other parts of the software; overlooking or not eliminating such code can cause bugs. Serious bugs can especially occur with larger projects, as it gets tougher to identify the problem area. · Programmers usually tend to rush as the deadline approaches closer. This is the time when most of the bugs occur. It is possible that you will be able to spot bugs of all types and severity. · Complexity in keeping track of all the bugs can again cause bugs by itself. This gets harder when a bug has a very complex life cycle i.e. when the number of times it has been closed, re-opened, not accepted, ignored etc goes on increasing. Bug Life Cycle Bug Life Cycle starts with an unintentional software bug/behavior and ends when the assigned developer fixes the bug. A bug when found should be communicated and assigned to a developer that can fix it. Once fixed, the problem area should be re-tested. Also, confirmation should be made to verify if the fix did not create problems elsewhere. In most of the cases, the life cycle gets very complicated and difficult to track making it imperative to have a bug/defect tracking system in place. See Chapter 7 â Defect Tracking Following are the different phases of a Bug Life Cycle: Open: A bug is in Open state when a tester identifies a problem area Accepted: The bug is then assigned to a developer for a fix. The developer then accepts if valid. Not Accepted/Wonât fix: If the developer considers the bug as low level or does not accept it as a bug, thus pushing it into Not Accepted/Wonât fix state. Such bugs will be assigned to the project manager who will decide if the bug needs a fix. If it needs, then assigns it back to the developer, and if it doesnât, then assigns it back to the tester who will have to close the bug. Pending: A bug accepted by the developer may not be fixed immediately. In such cases, it can be put under Pending state. Fixed: Programmer will fix the bug and resolves it as Fixed. Close: The fixed bug will be assigned to the tester who will put it in the Close state. Re-Open: Fixed bugs can be re-opened by the testers in case the fix produces problems elsewhere.
- 156. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Cost of fixing bugs Costs are logarithmic; they increase in size tenfold as the time increases. A bug found and fixed during the early stages â requirements or product spec stage can be fixed by a brief interaction with the concerned and might cost next to nothing. During coding, a swiftly spotted mistake may take only very less effort to fix. During integration testing, it costs the paperwork of a bug report and a formally documented fix, as well as the delay and expense of a re-test. During system testing it costs even more time and may delay delivery. Finally, during operations it may cause anything from a nuisance to a system failure, possibly with catastrophic as an aircraft or an emergency service. When can testing be stopped/reduced? It is difficult to determine when exactly to stop testing. Here are a few common factors that help you decide when you can stop or reduce testing: · Deadlines (release deadlines, testing deadlines, etc.) · Test cases completed with certain percentage passed · Test budget depleted · Coverage of code/functionality/requirements reaches a specified point · Bug rate falls below a certain level · Beta or alpha testing period ends 3. Software Testing Levels, Types, Terms and Definitions Testing Levels and Types There are basically three levels of testing i.e. Unit Testing, Integration Testing and System Testing. Various types of testing come under these levels. Unit Testing To verify a single program or a section of a single program Integration Testing To verify interaction between system components Prerequisite: unit testing completed on all components that compose a system System Testing To verify and validate behaviors of the entire system against the original system objectives Software testing is a process that identifies the correctness, completeness, and quality of software. Following is a list of various types of software testing and their definitions in a random order: · Formal Testing: Performed by test engineers · Informal Testing: Performed by the developers · Manual Testing: That part of software testing that requires human input, analysis, or evaluation. · Automated Testing: Software testing that utilizes a variety of tools to automate the testing process. Automated testing still requires a skilled quality assurance professional with knowledge of the automation tools and the software being tested to set up the test cases.
- 157. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ · Black box Testing: Testing software without any knowledge of the back-end of the system, structure or language of the module being tested. Black box test cases are written from a definitive source document, such as a specification or requirements document. · White box Testing: Testing in which the software tester has knowledge of the back-end, structure and language of the software, or at least its purpose. · Unit Testing: Unit testing is the process of testing a particular complied program, i.e., a window, a report, an interface, etc. independently as a stand-alone component/program. The types and degrees of unit tests can vary among modified and newly created programs. Unit testing is mostly performed by the programmers who are also responsible for the creation of the necessary unit test data. · Incremental Testing: Incremental testing is partial testing of an incomplete product. The goal of incremental testing is to provide an early feedback to software developers. · System Testing: System testing is a form of black box testing. The purpose of system testing is to validate an applicationâs accuracy and completeness in performing the functions as designed. · Integration Testing: Testing two or more modules or functions together with the intent of finding interface defects between the modules/functions. · System Integration Testing: Testing of software components that have been distributed across multiple platforms (e.g., client, web server, application server, and database server) to produce failures caused by system integration defects (i.e. defects involving distribution and back-office integration). · Functional Testing: Verifying that a module functions as stated in the specification and establishing confidence that a program does what it is supposed to do. · End-to-end Testing: Similar to system testing â testing a complete application in a situation that mimics real world use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system. · Sanity Testing: Sanity testing is performed whenever cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes testing basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc. · Regression Testing: Testing with the intent of determining if bug fixes have been successful and have not created any new problems. · Acceptance Testing: Testing the system with the intent of confirming readiness of the product and customer acceptance. Also known as User Acceptance Testing. · Adhoc Testing: Testing without a formal test plan or outside of a test plan. With some projects this type of testing is carried out as an addition to formal testing. Sometimes, if testing occurs very late in the development cycle, this will be the only kind of testing that can be performed â usually done by skilled testers. Sometimes ad hoc testing is referred to as exploratory testing. · Configuration Testing: Testing to determine how well the product works with a broad range of hardware/peripheral equipment configurations as well as on different operating systems and software. · Load Testing: Testing with the intent of determining how well the product handles competition for system resources. The competition may come in the form of network traffic, CPU utilization or memory
- 158. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ allocation. · Stress Testing: Testing done to evaluate the behavior when the system is pushed beyond the breaking point. The goal is to expose the weak links and to determine if the system manages to recover gracefully. · Performance Testing: Testing with the intent of determining how efficiently a product handles a variety of events. Automated test tools geared specifically to test and fine-tune performance are used most often for this type of testing. · Usability Testing: Usability testing is testing for âuser-friendlinessâ. A way to evaluate and measure how users interact with a software product or site. Tasks are given to users and observations are made. · Installation Testing: Testing with the intent of determining if the product is compatible with a variety of platforms and how easily it installs. · Recovery/Error Testing: Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems. · Security Testing: Testing of database and network software in order to keep company data and resources secure from mistaken/accidental users, hackers, and other malevolent attackers. · Penetration Testing: Penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques. · Compatibility Testing: Testing used to determine whether other system software components such as browsers, utilities, and competing software will conflict with the software being tested. · Exploratory Testing: Any testing in which the tester dynamically changes what theyâre doing for test execution, based on information they learn as theyâre executing their tests. · Comparison Testing: Testing that compares software weaknesses and strengths to those of competitorsâ products. · Alpha Testing: Testing after code is mostly complete or contains most of the functionality and prior to reaching customers. Sometimes a selected group of users are involved. More often this testing will be performed in-house or by an outside testing firm in close cooperation with the software engineering department. · Beta Testing: Testing after the product is code complete. Betas are often widely distributed or even distributed to the public at large. · Gamma Testing: Gamma testing is testing of software that has all the required features, but it did not go through all the in-house quality checks. · Mutation Testing: A method to determine to test thoroughness by measuring the extent to which the test cases can discriminate the program from slight variants of the program. · Independent Verification and Validation (IV&V): The process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and doesnât fail in an unacceptable manner. The individual or group doing this work is not part of the group or organization that developed the software. · Pilot Testing: Testing that involves the users just before actual release to ensure that users become familiar with the release contents and ultimately accept it. Typically involves many users, is conducted
- 159. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ over a short period of time and is tightly controlled. (See beta testing) · Parallel/Audit Testing: Testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly. · Glass Box/Open Box Testing: 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. · Closed Box Testing: Closed box testing is same as black box testing. A type of testing that considers only the functionality of the application. · Bottom-up Testing: 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 purposes. · Smoke Testing: A random test conducted before the delivery and after complete testing. Testing Terms · Bug: A software bug may be defined as a coding error that causes an unexpected defect, fault or flaw. In other words, if a program does not perform as intended, it is most likely a bug. · Error: A mismatch between the program and its specification is an error in the program. · Defect: Defect is the variance from a desired product attribute (it can be a wrong, missing or extra data). It can be of two types â Defect from the product or a variance from customer/user expectations. It is a flaw in the software system and has no impact until it affects the user/customer and operational system. 90% of all the defects can be caused by process problems. · Failure: A defect that causes an error in operation or negatively impacts a user/ customer. · Quality Assurance: Is oriented towards preventing defects. Quality Assurance ensures all parties concerned with the project adhere to the process and procedures, standards and templates and test readiness reviews. · Quality Control: quality control or quality engineering is a set of measures taken to ensure that defective products or services are not produced, and that the design meets performance requirements. · Verification: Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, walkthroughs and inspection meetings. · Validation: Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed. [/size] 4. Most common software errors Following are the most common software errors that aid you in software testing. This helps you to identify errors systematically and increases the efficiency and productivity of software testing. Types of errors with examples
- 160. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ · User Interface Errors: Missing/Wrong Functions, Doesnât do what the user expects, Missing information, Misleading, Confusing information, Wrong content in Help text, Inappropriate error messages. Performance issues â Poor responsiveness, Canât redirect output, Inappropriate use of key board · Error Handling: Inadequate â protection against corrupted data, tests of user input, version control; Ignores â overflow, data comparison, Error recovery â aborting errors, recovery from hardware problems. · Boundary related errors: Boundaries in loop, space, time, memory, mishandling of cases outside boundary. · Calculation errors: Bad Logic, Bad Arithmetic, Outdated constants, Calculation errors, Incorrect conversion from one data representation to another, Wrong formula, Incorrect approximation. · Initial and Later states: Failure to â set data item to zero, to initialize a loop-control variable, or re- initialize a pointer, to clear a string or flag, Incorrect initialization. · Control flow errors: Wrong returning state assumed, Exception handling based exits, Stack underflow/overflow, Failure to block or un-block interrupts, Comparison sometimes yields wrong result, Missing/wrong default, Data Type errors. · Errors in Handling or Interpreting Data: Un-terminated null strings, Overwriting a file after an error exit or user abort. · Race Conditions: Assumption that one event or task finished before another begins, Resource races, Tasks starts before its prerequisites are met, Messages cross or donât arrive in the order sent. · Load Conditions: Required resources are not available, No available large memory area, Low priority tasks not put off, Doesnât erase old files from mass storage, Doesnât return unused memory. · Hardware: Wrong Device, Device unavailable, Underutilizing device intelligence, Misunderstood status or return code, Wrong operation or instruction codes. · Source, Version and ID Control: No Title or version ID, Failure to update multiple copies of data or program files. · Testing Errors: Failure to notice/report a problem, Failure to use the most promising test case, Corrupted data files, Misinterpreted specifications or documentation, Failure to make it clear how to reproduce the problem, Failure to check for unresolved problems just before release, Failure to verify fixes, Failure to provide summary report. 5. The Test Planning Process What is a Test Strategy? What are its Components? Test Policy â A document characterizing the organizationâs philosophy towards software testing. Test Strategy â A high-level document defining the test phases to be performed and the testing within those phases for a programme. It defines the process to be followed in each project. This sets the standards for the processes, documents, activities etc. that should be followed for each project. For example, if a product is given for testing, you should decide if it is better to use black-box testing or white-box testing and if you decide to use both, when will you apply each and to which part of the software? All these details need to be specified in the Test Strategy.
- 161. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Project Test Plan â a document defining the test phases to be performed and the testing within those phases for a particular project. A Test Strategy should cover more than one project and should address the following issues: An approach to testing high risk areas first, Planning for testing, How to improve the process based on previous testing, Environments/data used, Test management â Configuration management, Problem management, What Metrics are followed, Will the tests be automated and if so which tools will be used, What are the Testing Stages and Testing Methods, Post Testing Review process, Templates. Test planning needs to start as soon as the project requirements are known. The first document that needs to be produced then is the Test Strategy/Testing Approach that sets the high level approach for testing and covers all the other elements mentioned above. Test Planning â Sample Structure Once the approach is understood, a detailed test plan can be written. Usually, this test plan can be written in different styles. Test plans can completely differ from project to project in the same organization. IEEE SOFTWARE TEST DOCUMENTATION Std 829-1998 â TEST PLAN Purpose To describe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with this plan. OUTLINE A test plan shall have the following structure: · Test plan identifier. A unique identifier assign to the test plan. · Introduction: Summarized the software items and features to be tested and the need for them to be included. · Test items: Identify the test items, their transmittal media which impact their · Features to be tested · Features not to be tested · Approach · Item pass/fail criteria · Suspension criteria and resumption requirements · Test deliverables · Testing tasks · Environmental needs · Responsibilities · Staffing and training needs · Schedule · Risks and contingencies · Approvals Major Test Planning Tasks
- 162. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Like any other process in software testing, the major tasks in test planning are to â Develop Test Strategy, Critical Success Factors, Define Test Objectives, Identify Needed Test Resources, Plan Test Environment, Define Test Procedures, Identify Functions To Be Tested, Identify Interfaces With Other Systems or Components, Write Test Scripts, Define Test Cases, Design Test Data, Build Test Matrix, Determine Test Schedules, Assemble Information, Finalize the Plan 6. Test Case Development A test case is a detailed procedure that fully tests a feature or an aspect of a feature. While the test plan describes what to test, a test case describes how to perform a particular test. You need to develop test cases for each test listed in the test plan. General Guidelines As a tester, the best way to determine the compliance of the software to requirements is by designing effective test cases that provide a thorough test of a unit. Various test case design techniques enable the testers to develop effective test cases. Besides, implementing the design techniques, every tester needs to keep in mind general guidelines that will aid in test case design: a. The purpose of each test case is to run the test in the simplest way possible. [Suitable techniques - Specification derived tests, Equivalence partitioning] b. Concentrate initially on positive testing i.e. the test case should show that the software does what it is intended to do. [Suitable techniques - Specification derived tests, Equivalence partitioning, State- transition testing] c. Existing test cases should be enhanced and further test cases should be designed to show that the software does not do anything that it is not specified to do i.e. Negative Testing [Suitable techniques - Error guessing, Boundary value analysis, Internal boundary value testing, State-transition testing] d. Where appropriate, test cases should be designed to address issues such as performance, safety requirements and security requirements [Suitable techniques - Specification derived tests] e. Further test cases can then be added to the unit test specification to achieve specific test coverage objectives. Once coverage tests have been designed, the test procedure can be developed and the tests executed [Suitable techniques - Branch testing, Condition testing, Data definition-use testing, State- transition testing] Test Case â Sample Structure The manner in which a test case is depicted varies between organizations. Anyhow, many test case templates are in the form of a table, for example, a 5-column table with fields: Test Case ID Test Case Description Test Dependency/Setup Input Data Requirements/Steps Expected Results Pass/Fail Test Case Design Techniques
- 163. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ The test case design techniques are broadly grouped into two categories: Black box techniques, White box techniques and other techniques that do not fall under either category. Black Box (Functional) - Specification derived tests - Equivalence partitioning - Boundary Value Analysis - State-Transition Testing White Box (Structural) - Branch Testing - Condition Testing - Data Definition â Use Testing - Internal boundary value testing Other- Error guessing Specification Derived Tests As the name suggests, test cases are designed by walking through the relevant specifications. It is a positive test case design technique. Equivalence Partitioning Equivalence partitioning is the process of taking all of the possible test values and placing them into classes (partitions or groups). Test cases should be designed to test one value from each class. Thereby, it uses fewest test cases to cover the maximum input requirements. For example, if a program accepts integer values only from 1 to 10. The possible test cases for such a program would be the range of all integers. In such a program, all integers upto to 0 and above 10 will cause an error. So, it is reasonable to assume that if 11 will fail, all values above it will fail and vice versa. If an input condition is a range of values, let one valid equivalence class be the range (0 or 10 in this example). Let the values below and above the range be two respective invalid equivalence values (i.e. -1 and 11). Therefore, the above three partition values can be used as test cases for the above example. Boundary Value Analysis This is a selection technique where the test data are chosen to lie along the boundaries of the input domain or the output range. This technique is often called as stress testing and incorporates a degree of negative testing in the test design by anticipating that errors will occur at or around the partition boundaries. For example, a field is required to accept amounts of money between $0 and $10. As a tester, you need to check if it means upto and including $10 and $9.99 and if $10 is acceptable. So, the boundary values are $0, $0.01, $9.99 and $10. Now, the following tests can be executed. A negative value should be rejected, 0 should be accepted (this is on the boundary), $0.01 and $9.99 should be accepted, null and $10 should be rejected. In this way, it uses the same concept of partitions as equivalence partitioning.
- 164. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ State Transition Testing As the name suggests, test cases are designed to test the transition between the states by creating the events that cause the transition. Branch Testing In branch testing, test cases are designed to exercise control flow branches or decision points in a unit. This is usually aimed at achieving a target level of Decision Coverage. Branch Coverage, need to test both branches of IF and ELSE. All branches and compound conditions (e.g. loops and array handling) within the branch should be exercised at least once. Condition Testing The object of condition testing is to design test cases to show that the individual components of logical conditions and combinations of the individual components are correct. Test cases are designed to test the individual elements of logical expressions, both within branch conditions and within other expressions in a unit. Data Definition â Use Testing Data definition-use testing designs test cases to test pairs of data definitions and uses. Data definition is anywhere that the value of a data item is set. Data use is anywhere that a data item is read or used. The objective is to create test cases that will drive execution through paths between specific definitions and uses. Internal Boundary Value Testing In many cases, partitions and their boundaries can be identified from a functional specification for a unit, as described under equivalence partitioning and boundary value analysis above. However, a unit may also have internal boundary values that can only be identified from a structural specification. Error Guessing It is a test case design technique where the testers use their experience to guess the possible errors that might occur and design test cases accordingly to uncover them. Using any or a combination of the above described test case design techniques; you can develop effective test cases. What is a Use Case? A use case describes the systemâs behavior under various conditions as it responds to a request from one of the users. The user initiates an interaction with the system to accomplish some goal. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. The use case collects together those different scenarios. Use cases are popular largely because they tell coherent stories about how the system will behave in use. The users of the system get to see just what this new system will be and get to react early. 7. Defect Tracking What is a defect?
- 165. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ As discussed earlier, defect is the variance from a desired product attribute (it can be a wrong, missing or extra data). It can be of two types â Defect from the product or a variance from customer/user expectations. It is a flaw in the software system and has no impact until it affects the user/customer and operational system. What are the defect categories? With the knowledge of testing so far gained, you can now be able to categorize the defects you have found. Defects can be categorized into different types basing on the core issues they address. Some defects address security or database issues while others may refer to functionality or UI issues. Security Defects: Application security defects generally involve improper handling of data sent from the user to the application. These defects are the most severe and given highest priority for a fix. Examples: - Authentication: Accepting an invalid username/password - Authorization: Accessibility to pages though permission not given Data Quality/Database Defects: Deals with improper handling of data in the database. Examples: - Values not deleted/inserted into the database properly - Improper/wrong/null values inserted in place of the actual values Critical Functionality Defects: The occurrence of these bugs hampers the crucial functionality of the application. Examples:- Exceptions Functionality Defects: These defects affect the functionality of the application. Examples: - All Javascript errors - Buttons like Save, Delete, Cancel not performing their intended functions - A missing functionality (or) a feature not functioning the way it is intended to - Continuous execution of loops User Interface Defects: As the name suggests, the bugs deal with problems related to UI are usually considered less severe. Examples: - Improper error/warning/UI messages - Spelling mistakes - Alignment problems How is a defect reported? Once the test cases are developed using the appropriate techniques, they are executed which is when the bugs occur. It is very important that these bugs be reported as soon as possible because, the earlier you report a bug, the more time remains in the schedule to get it fixed. Simple example is that you report a wrong functionality documented in the Help file a few months before the product release, the chances that it will be fixed are very high. If you report the same bug few hours
- 166. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ before the release, the odds are that it wont be fixed. The bug is still the same though you report it few months or few hours before the release, but what matters is the time. It is not just enough to find the bugs; these should also be reported/communicated clearly and efficiently, not to mention the number of people who will be reading the defect. Defect tracking tools (also known as bug tracking tools, issue tracking tools or problem trackers) greatly aid the testers in reporting and tracking the bugs found in software applications. They provide a means of consolidating a key element of project information in one place. Project managers can then see which bugs have been fixed, which are outstanding and how long it is taking to fix defects. Senior management can use reports to understand the state of the development process. How descriptive should your bug/defect report be? You should provide enough detail while reporting the bug keeping in mind the people who will use it â test lead, developer, project manager, other testers, new testers assigned etc. This means that the report you will write should be concise, straight and clear. Following are the details your report should contain: - Bug Title - Bug identifier (number, ID, etc.) - The application name or identifier and version - The function, module, feature, object, screen, etc. where the bug occurred - Environment (OS, Browser and its version) - Bug Type or Category/Severity/Priority o Bug Category: Security, Database, Functionality (Critical/General), UI o Bug Severity: Severity with which the bug affects the application â Very High, High, Medium, Low, Very Low o Bug Priority: Recommended priority to be given for a fix of this bug â P0, P1, P2, P3, P4, P5 (P0- Highest, P5-Lowest) - Bug status (Open, Pending, Fixed, Closed, Re-Open) - Test case name/number/identifier - Bug description - Steps to Reproduce - Actual Result - Tester Comments What does the tester do when the defect is fixed? Once the reported defect is fixed, the tester needs to re-test to confirm the fix. This is usually done by executing the possible scenarios where the bug can occur. Once retesting is completed, the fix can be confirmed and the bug can be closed. This marks the end of the bug life cycle. 8. Types of Test Reports The documents outlined in the IEEE Standard of Software Test Documentation covers test planning, test specification, and test reporting. Test reporting covers four document types:
- 167. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 1. A Test Item Transmittal Report identifies the test items being transmitted for testing from the development to the testing group in the event that a formal beginning of test execution is desired Details to be included in the report â Purpose, Outline, Transmittal-Report Identifier, Transmitted Items, Location, Status, and Approvals. 2. A Test Log is used by the test team to record what occurred during test execution Details to be included in the report â Purpose, Outline, Test-Log Identifier, Description, Activity and Event Entries, Execution Description, Procedure Results, Environmental Information, Anomalous Events, Incident-Report Identifiers 3. A Test Incident report describes any event that occurs during the test execution that requires further investigation Details to be included in the report â Purpose, Outline, Test-Incident-Report Identifier, Summary, Impact 4. A test summary report summarizes the testing activities associated with one or more test-design specifications Details to be included in the report â Purpose, Outline, Test-Summary-Report Identifier, Summary, Variances, Comprehensiveness Assessment, Summary of Results, Summary of Activities, and Approvals 9. Software Test Automation Automating testing is no different from a programmer using a coding language to write programs to automate any manual process. One of the problems with testing large systems is that it can go beyond the scope of small test teams. Because only a small number of testers are available the coverage and depth of testing provided are inadequate for the task at hand. Expanding the test team beyond a certain size also becomes problematic with increase in work over head. Feasible way to avoid this without introducing a loss of quality is through appropriate use of tools that can expand individualâs capacity enormously while maintaining the focus (depth) of testing upon the critical elements. Consider the following factors that help determine the use of automated testing tools: · Examine your current testing process and determine where it needs to be adjusted for using automated test tools. · Be prepared to make changes in the current ways you perform testing. · Involve people who will be using the tool to help design the automated testing process. · Create a set of evaluation criteria for functions that you will want to consider when using the automated test tool. These criteria may include the following: o Test repeatability o Criticality/risk of applications o Operational simplicity o Ease of automation o Level of documentation of the function (requirements, etc.) · Examine your existing set of test cases and test scripts to see which ones are most applicable for test
- 168. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ automation. · Train people in basic test-planning skills. Approaches to Automation There are three broad options in Test Automation: Full Manual Reliance on manual testing Responsive and flexible Inconsistent Low implementation cost High repetitive cost Required for automation High skill requirements Partial Automation Redundancy possible but requires duplication of effort Flexible Consistent Automates repetitive tasks and high return tasks Full Automation Reliance on automated testing Relatively inflexible Very consistent High implementation cost Economies of scale in repetition, regression etc Low skill requirements Fully manual testing has the benefit of being relatively cheap and effective. But as quality of the product improves the additional cost for finding further bugs becomes more expensive. Large scale manual testing also implies large scale testing teams with the related costs of space, overhead and infrastructure. Manual testing is also far more responsive and flexible than automated testing but is prone to tester error through fatigue. Fully automated testing is very consistent and allows the repetitions of similar tests at very little marginal cost. The setup and purchase costs of such automation are very high however and maintenance can be equally expensive. Automation is also relatively inflexible and requires rework in order to adapt to changing requirements. Partial Automation incorporates automation only where the most benefits can be achieved. The advantage is that it targets specifically the tasks for automation and thus achieves the most benefit from them. It also retains a large component of manual testing which maintains the test teams flexibility and offers redundancy by backing up automation with manual testing. The disadvantage is that it obviously does not provide as extensive benefits as either extreme solution. Choosing the right tool
- 169. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ · Take time to define the tool requirements in terms of technology, process, applications, people skills, and organization. · During tool evaluation, prioritize which test types are the most critical to your success and judge the candidate tools on those criteria. · Understand the tools and their trade-offs. You may need to use a multi-tool solution to get higher levels of test-type coverage. For example, you will need to combine the capture/play-back tool with a load-test tool to cover your performance test cases. · Involve potential users in the definition of tool requirements and evaluation criteria. · Build an evaluation scorecard to compare each toolâs performance against a common set of criteria. Rank the criteria in terms of relative importance to the organization. Top Ten Challenges of Software Test Automation 1. Buying the Wrong Tool 2. Inadequate Test Team Organization 3. Lack of Management Support 4. Incomplete Coverage of Test Types by the selected tool 5. Inadequate Tool Training 6. Difficulty using the tool 7. Lack of a Basic Test Process or Understanding of What to Test 8. Lack of Configuration Management Processes 9. Lack of Tool Compatibility and Interoperability 10. Lack of Tool Availability 10. Introduction To Software Standards Capability Maturity Model - Developed by the software community in 1986 with leadership from the SEI. The CMM describes the principles and practices underlying software process maturity. It is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The focus is on identifying key process areas and the exemplary practices that may comprise a disciplined software process. What makes up the CMM? The CMM is organized into five maturity levels: · Initial · Repeatable · Defined · Manageable · Optimizing Except for Level 1, each maturity level decomposes into several key process areas that indicate the areas an organization should focus on to improve its software process. Level 1 â Initial Level: Disciplined process, Standard, Consistent process, Predictable process, Continuously Improving process
- 170. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Level 2 â Repeatable: Key practice areas â Requirements management, Software project planning, Software project tracking & oversight, Software subcontract management, Software quality assurance, Software configuration management Level 3 â Defined: Key practice areas â Organization process focus, Organization process definition, Training program, Integrated software management, Software product engineering, Intergroup coordination, Peer reviews Level 4 â Manageable: Key practice areas â Quantitative Process Management, Software Quality Management Level 5 â Optimizing: Key practice areas â Defect prevention, Technology change management, Process change management Six Sigma Six Sigma is a quality management program to achieve âsix sigmaâ levels of quality. It was pioneered by Motorola in the mid-1980s and has spread to many other manufacturing companies, notably General Electric Corporation (GE). Six Sigma is a rigorous and disciplined methodology that uses data and statistical analysis to measure and improve a companyâs operational performance by identifying and eliminating âdefectsâ from manufacturing to transactional and from product to service. Commonly defined as 3.4 defects per million opportunities, Six Sigma can be defined and understood at three distinct levels: metric, methodology and philosophy⊠Training Sigma processes are executed by Six Sigma Green Belts and Six Sigma Black Belts, and are overseen by Six Sigma Master Black Belts. ISO ISO â International Organization for Standardization is a network of the national standards institutes of 150 countries, on the basis of one member per country, with a Central Secretariat in Geneva, Switzerland, that coordinates the system. ISO is a non-governmental organization. ISO has developed over 13, 000 International Standards on a variety of subjects. 11. Software Testing Certifications Certification Information for Software QA and Test Engineers CSQE â ASQ (American Society for Quality)âs program for CSQE (Certified Software Quality Engineer) â information on requirements, outline of required âBody of Knowledgeâ, listing of study references and more. CSQA/CSTE â QAI (Quality Assurance Institute)âs program for CSQA (Certified Software Quality Analyst) and CSTE (Certified Software Test Engineer) certifications. ISEB Software Testing Certifications â The British Computer Society maintains a program of 2 levels of certifications -ISEB Foundation Certificate, Practitioner Certificate. ISTQB Certified Tester - The International Software Testing Qualifications Board is a part of the European Organization for Quality â Software Group, based in Germany. The certifications are based on experience, a training course and test. Two levels are available: Foundation and Advanced.
- 171. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 12. Facts about Software Engineering Following are some facts that can help you gain a better insight into the realities of Software Engineering. 1. The best programmers are up to 28 times better than the worst programmers. 2. New tools/techniques cause an initial LOSS of productivity/quality. 3. The answer to a feasibility study is almost always âyesâ. 4. A May 2002 report prepared for the National Institute of Standards and Technologies (NIST)(1) estimates the annual cost of software defects in the United States as $59.5 billion. 5. Reusable components are three times as hard to build 6. For every 25% increase in problem complexity, there is a 100% increase in solution complexity. 7. 80% of software work is intellectual. A fair amount of it is creative. Little of it is clerical. 8. Requirements errors are the most expensive to fix during production. 9. Missing requirements are the hardest requirement errors to correct. 10. Error-removal is the most time-consuming phase of the life cycle. 11. Software is usually tested at best at the 55-60% (branch) coverage level. 12. 100% coverage is still far from enough. 13. Rigorous inspections can remove up to 90% of errors before the first test case is run. 14. Maintenance typically consumes 40-80% of software costs. It is probably the most important life cycle phase of software. 15. Enhancements represent roughly 60% of maintenance costs. 16. There is no single best approach to software error removal. 13. References - Software Engineering â Roger S Pressman - Software Testing â Ron Patton - Effective Methods of Software Testing â William E. Perry - Articles by James A Whittaker Defect Tracking Tools http://testingfaqs.org/t-track.html List of defect tracking tools. Both commercial and freeware tools are included. Hyperlinks for Certifications CSQE â http://www.asq.org/cert/types/csqe/index.html CSQA/CSTE â http://www.softwarecertifications.com/ ISEB Software Testing Certifications â http://www.bcs.org/BCS/Products/Qualifications/ISEB/Areas/SoftTest/ ISTQB Certified Tester â http://www.isqi.org/isqi/eng/cert/ct/ Testing Techniques
- 172. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Interview Faq's, Manual Testing Basics | Leave a comment o Black Box Testing o White Box Testing o Regression Testing o These principles & techniques can be applied to any type of testing. Black Box Testing Testing of a function without knowing internal structure of the program. White Box Testing Testing of a function with knowing internal structure of the program. Regression Testing To ensure that the code changes have not had an adverse affect to the other modules or on existing functions. Functional Testing ïï ï ï ï ï ï ï Study SRS ïï ï ï ï ï ï ï Identify Unit Functions ïï ï ï ï ï ï ï For each unit function ï·ï ï ï ï ï ï ï ï ï Take each input function ï·ï ï ï ï ï ï ï ï ï Identify Equivalence class ï·ï ï ï ï ï ï ï ï ï Form Test cases ï·ï ï ï ï ï ï ï ï ï Form Test cases for boundary values ï·ï ï ï ï ï ï ï ï ï From Test cases for Error Guessing ïï ï ï ï ï ï ï Form Unit function v/s Test cases, Cross Reference Matrix ïï ï ï ï ï ï ï Find the coverage What makes a good Software QA engineer? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Leave a comment The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see âwhatâs missingâ is important for inspections and reviews. ï·ï ï ï ï ï ï ï ï ï Testing ïï ï ï ï ï ï ï An examination of the behavior of a program by executing on sample data sets. ïï ï ï ï ï ï ï Testing comprises of set of activities to detect defects in a produced material.
- 173. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ ïï ï ï ï ï ï ï To unearth & correct defects ïï ï ï ï ï ï ï To detect defects early & to reduce cost of defect fixing ïï ï ï ï ï ï ï To avoid user detecting problems ïï ï ï ï ï ï ï To ensure that product works as users expected it to. Basic definitions of software testing and quality assurance Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Interview Faq's, Manual Testing Basics | Leave a comment acceptance criteria: The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE 610] acceptance testing: Formal testing with respect to userneeds,requirements, and business processes conducted to determine whether or not a systemsatisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.[After IEEE 610] accessibility testing: Testing to determine the ease by which users with disabilities can use a component or system. [Gerrard] accuracy: The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [ISO 9126] See also functionality testing. actual result: The behavior produced/observed when a component or systemis tested. ad hoc testing: Testing carried out informally; no formal test preparation takes place, no recognized test design technique is used, there are no expectations for results and randomness guides the test execution activity. adaptability: The capability of the software product to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the software considered. [ISO 9126] See also portability testing. agile testing: Testing practice for a project using agile methodologies, such as extreme programming (XP), treating development as the customer of testing and emphasizing the test-first design paradigm. alpha testing: Simulated or actual operational testing by potential users/customers or an independent test teamat the developersâsite, but outside the development organization. Alpha testing is often employed as a form of internal acceptance testing. analyzability: The capability of the software product to be diagnosed for deficiencies or causes of failures in the software, or for the parts to be modified to be identified. [ISO 9126] See also maintainability testing. anomaly: Any condition that deviates from expectation based on requirements specifications, design documents, user documents, standards,etc.or from someoneâs perception or experience. Anomalies may be found during, but
- 174. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ not limited to, reviewing, testing,analysis,compilation, or use of software products or applicable documentation. [IEEE 1044] See also defect, deviation, error, fault, failure, incident, problem. attractiveness: The capability of the software product to be attractive to the user. [ISO 9126] audit: An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/orprocedures based on objective criteria, including documents that specify: (1) the form or content of the products to be produced (2) the process by which the products shall be produced (3) how compliance to standards orguidelines shall be measured. [IEEE 1028] audit trail: A path by which the original input to a process (e.g. data) can be traced back through the process,taking the process output as a starting point. This facilitates defect analysis and allows a process audit to be carried out. [After TMap] automated testware: Testware used in automated testing,such as tool scripts. availability: The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage.[IEEE 610] B back-to-back testing: Testing in which two or more variants of a component or systemare executed with the same inputs,the outputs compared, and analyzed in cases of discrepancies.[IEEE 610] baseline: A specification or software product that has been formally reviewed or agreed upon,that thereafter serves as the basis for further development, and that can be changed only through a formal change control process.[After IEEE 610] basic block: A sequence of one or more consecutive executable statements containing no branches. basis test set: A set of test cases derived from the internal structure or specification to ensure that 100% of a specified coverage criterion is achieved. behavior: The response of a component or systemto a set of input values and preconditions. benchmark test: (1) A standard against which measurements or comparisons can be made. (2) A test that is be used to compare components or systems to each other or to a standard as in (1). [After IEEE 610] bespoke software: Software developed specifically for a set of users or customers. The opposite is off-the-shelf software. best practice: A superior method or innovative practice that contributes to the improved performance of an organization under given context, usually recognized as âbestâby other peer organizations. beta testing: Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers,to determine whether or not a component or systemsatisfies the user/customerneeds and fits within the business processes.Beta testing is often employed as a form of external acceptance testing in order to acquired feedback from the market.
- 175. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ big-bang testing: A type of integration testing in which software elements, hardware elements, or both are combined all at once into a component or an overall system, rather than in stages.[After IEEE 610] See also integration testing. black box testing: Testing, either functional or non-functional, without reference to the internal structure of the component or system. black box test design techniques: Documented procedure to derive and select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure. blocked test case:A test case that cannot be executed because the preconditions for its execution are not fulfilled. bottom-up testing: An incremental approach to integration testing where the lowest level components are tested first, and then used to facilitate the testing of higher level components.This process is repeated until the component at the top of the hierarchy is tested.See also integration testing. boundary value: An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge, for example the minimum or maximum value of a range. boundary value analysis: A black box test design technique in which test cases are designed based on boundary values. boundary value coverage: The percentage of boundary values that have been exercised by a test suite. branch: A basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths are available, e.g. case,jump, go to, ifthen- else. branch coverage: The percentage of branches that have been exercised by a test suite. 100% branch coverage implies both 100% decision coverage and 100% statement coverage. branch testing:A white box test design technique in which test cases are designed to execute branches. business process-based testing:An approach to testing in which test cases are designed based on descriptions and/or knowledge of business processes. C Capability Maturity Model (CMM): A five level staged framework that describes the key elements of an effective software process.The Capability Maturity Model covers practices for planning, engineering and managing software development and maintenance. [CMM] Capability Maturity Model Integration (CMMI): A framework that describes the key elements of an effective product development and maintenance process.The Capability Maturity Model Integration covers practices for planning, engineering and managing product development and maintenance. CMMI is the designated successorof the CMM. [CMMI]
- 176. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ capture/playbacktool: A type of test execution tool where inputs are recorded during manual testing in order to generate automated test scripts that can be executed later (i.e. replayed). These tools are often used to support automated regression testing. CASE: Acronym for Computer Aided Software Engineering. CAST: Acronym for Computer Aided Software Testing. See also test automation. cause-effect graph: A graphical representation of inputs and/or stimuli (causes)with their associated outputs (effects), which can be used to design test cases. cause-effect graphing: A black box test design technique in which test cases are designed from cause-effect graphs. [BS 7925/2] certification: The process ofconfirming that a component,system or person complies with its specified requirements, e.g. by passing an exam. changeability: The capability of the software product to enable specified modifications to be implemented. [ISO 9126] See also maintainability. classification tree method: A black box test design technique in which test cases,described by means of a classification tree, are designed to execute combinations of representatives of input and/oroutput domains. [Grochtmann] code coverage: An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed, e.g. statement coverage, decision coverage or condition coverage. co-existence: The capability of the software product to co-exist with other independent software in a common environment sharing common resources.[ISO 9126] See portability testing. complexity: The degree to which a component or systemhas a design and/orinternal structure that is difficult to understand,maintain and verify. See also cyclomatic complexity. compliance: The capability of the software product to adhere to standards,conventions orregulations in laws and similar prescriptions. [ISO 9126] compliance testing:The process oftesting to determine the compliance of component or system. component: A minimal software item that can be tested in isolation. component integration testing:Testing performed to expose defects in the interfaces and interaction between integrated components. component specification: A description of a componentâs function in terms of its output values for specified input values under specified conditions,and required non-functional behavior (e.g. resource-utilization). component testing:The testing of individual software components. [After IEEE 610] compound condition: Two or more single conditions joined by means of a logical operator (AND, OR or XOR), e.g. âA>B AND C>1000â. concurrency testing: Testing to determine how the occurrence of two or more activities within the same interval of time, achieved either by interleaving the activities or by simultaneous execution, is handled by the component or system. [After IEEE 610]
- 177. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ condition: A logical expression that can be evaluated as True or False, e.g. A>B. See also test condition. condition coverage: The percentage of condition outcomes that have been exercised by a test suite.100% condition coverage requires each single condition in every decision statement to be tested as True and False. condition determination coverage: The percentage of all single condition outcomes that independently affect a decision outcome that have been exercised by a test case suite. 100% condition determination coverage implies 100% decision condition coverage. condition determination testing: A white box test design technique in which test cases are designed to execute single condition outcomes that independently affect a decision outcome. condition testing:A white box test design technique in which test cases are designed to execute condition outcomes. condition outcome: The evaluation of a condition to True or False. configuration: The composition of a component or systemas defined by the number, nature, and interconnections of its constituent parts. configuration auditing: The function to check on the contents of libraries of configuration items, e.g. for standards compliance. [IEEE 610] configuration control: An element of configuration management, consisting of the evaluation, co-ordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification. [IEEE 610] configuration identification: An element of configuration management, consisting of selecting the configuration items for a system and recording their functional and physicalcharacteristics in technical documentation. [IEEE 610] configuration item: An aggregation of hardware, software or both, that is designated for configuration management and treated as a single entity in the configuration management process.[IEEE 610] configuration management: A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status,and verify compliance with specified requirements. [IEEE 610] consistency:The degree of uniformity, standardization, and freedom from contradiction among the documents or parts of a component or system. [IEEE 610] control flow: An abstract representation of all possible sequences ofevents (paths)in the execution through a component or system. conversion testing:Testing of software used to convert data from existing systems for use in replacement systems. COTS: Acronym for Commercial Off-The-Shelf software. coverage: The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite.
- 178. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ coverage analysis: Measurement of achieved coverage to a specified coverage item during test execution referring to predetermined criteria to determine whether additional testing is required and if so,which test cases are needed. coverage item: An entity or property used as a basis for test coverage, e.g. equivalence partitions or code statements. coverage tool: A tool that provides objective measures of what structural elements, e.g. statements,branches have been exercised by the test suite. cyclomatic complexity: The number of independent paths through a program. Cyclomatic complexity is defined as: L â N + 2P, where â L = the number of edges/links in a graph â N = the number of nodes in a graph â P = the number of disconnected parts of the graph (e.g. a calling graph and a subroutine). [After McCabe] D data definition: An executable statement where a variable is assigned a value. data driven testing: A scripting technique that stores test input and expected results in a table or spreadsheet, so that a single control script can execute all of the tests in the table. Data driven testing is often used to support the application of test execution tools such as capture/playbacktools. [Fewster and Graham] See also keyword driven testing. data flow: An abstract representation of the sequence and possible changes of the state of data objects,where the state of an object is any of: creation, usage,or destruction.[Beizer] data flow analysis: A form of static analysis based on the definition and usage of variables. data flow coverage: The percentage of definition-use pairs that have been exercised by a test case suite. data flow test: A white box test design technique in which test cases are designed to execute definition and use pairs of variables. debugging:The process of finding, analyzing and removing the causes of failures in software. debugging tool: A tool used by programmers to reproduce failures, investigate the state of programs and find the corresponding defect. Debuggers enable programmers to execute programs step by step,to halt a program at any program statement and to set and examine program variables. decision: A program point at which the control flow has two or more alternative routes. A node with two or more links to separate branches. decision condition coverage: The percentage of all condition outcomes and decision outcomes that have been exercised by a test suite.100% decision condition coverage implies both 100% condition coverage and 100% decision coverage. decision condition testing:A white box test design technique in which test cases are designed to execute condition outcomes and decision outcomes. decision coverage: The percentage of decision outcomes that have been exercised by a test suite. 100% decision coverage implies both 100% branch coverage and 100% statement coverage. decision table: A table showing combinations of inputs and/or stimuli (causes)with their associated outputs and/or actions (effects), which can be used to design test cases.
- 179. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ decision table testing: A black box test design techniques in which test cases are designed to execute the combinations of inputs and/orstimuli (causes)shown in a decision table. [Veenendaal] decision testing:A white box test design technique in which test cases are designed to execute decision outcomes. decision outcome: The result of a decision (which therefore determines the branches to be taken). defect: A flaw in a component or systemthat can cause the component or systemto fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system. defect density:The number of defects identified in a component or systemdivided by the size of the component or system(expressed in standard measurement terms, e.g. lines-ofcode, number of classes or function points). Defect Detection Percentage (DDP): the number of defects found by a test phase,divided by the number found by that test phase and any other means afterwards. defect report: A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function. [After IEEE 829] defect management: The process of recognizing, investigating, taking action and disposing of defects. It involves recording defects, classifying them and identifying the impact. [After IEEE 1044] defect masking: An occurrence in which one defect prevents the detection of another.[After IEEE 610] definition-use pair: The association of the definition of a variable with the use of that variable. Variable uses include computational (e.g. multiplication) or to direct the execution of a path (âpredicateâ use). deliverable: Any (work) product that must be delivered to someone other that the (work) productâs author. design-based testing:An approach to testing in which test cases are designed based on the architecture and/or detailed design of a component or system (e.g. tests ofinterfaces between components or systems). desk checking: Testing of software or specification by manual simulation of its execution. development testing: Formal or informal testing conducted during the implementation of a component or system, usually in the development environment by developers.[After IEEE 610] documentation testing:Testing the quality of the documentation, e.g. user guide or installation guide. domain: The set from which valid input and/or output values can be selected. driver: A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system.[After TMap] dynamic analysis: The process of evaluating behavior, e.g. memory performance, CPU usage,of a systemor component during execution. [After IEEE 610] dynamic comparison: Comparison of actual and expected results, performed while the software is being executed, for example by a test execution tool. dynamic testing: Testing that involves the execution of the software of a component or system.
- 180. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ E efficiency: The capability of the software product to provide appropriate performance, relative to the amount of resources used understated conditions.[ISO 9126] efficiency testing:The process of testing to determine the efficiency of a software product. elementary comparison testing: A black box test design techniques in which test cases are designed to execute combinations of inputs using the concept of condition determination coverage. [TMap] emulator: A device, computer program, or systemthat accepts the same inputs and produces the same outputs as a given system. [IEEE 610] See also simulator. entry criteria: the set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase.The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria. [Gilb and Graham] entry point: The first executable statement within a component. equivalence partition: A portion of an input or output domain for which the behavior of a component or systemis assumed to be the same, based on the specification. equivalence partition coverage: The percentage of equivalence partitions that have been exercised by a test suite. equivalence partitioning: A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once. error: A human action that produces an incorrect result. [After IEEE 610] error guessing:A test design technique where the experience of the testeris used to anticipate what defects might be present in the component or system undertest as a result of errors made, and to design tests specifically to expose them. error seeding: The process of intentionally adding known defects to those already in the component or system for the purpose of monitoring the rate of detection and removal, and estimating the number of remaining defects. [IEEE 610] error tolerance: The ability of a system or component to continue normal operation despite the presence of erroneous inputs.[After IEEE 610]. exception handling: Behavior of a component or systemin response to erroneous input, from either a human useror from another component or system,or to an internal failure. executable statement: A statement which, when compiled, is translated into object code, and which will be executed procedurally when the program is running and may perform an action on data. exercised: A program element is said to be exercised by a test case when the input value causes the execution of that element, such as a statement, decision, or otherstructural element. exhaustive testing: A test approach in which the test suite comprises all combinations of input values and preconditions.
- 181. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ exit criteria: The set of generic and specific conditions,agreed upon with the stakeholders,for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts ofthe task which have not been finished. Exit criteria are used by testing to report against and to plan when to stop testing.[After Gilb and Graham] exit point: The last executable statement within a component. expected result: The behavior predicted by the specification, or anothersource, of the component or systemunder specified conditions. exploratory testing:Testing where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests.[Bach] F fail: A test is deemed to fail if its actual result does not match its expected result. failure: Actual deviation of the component or systemfrom its expected delivery, service or result. [After Fenton] failure mode: The physical or functional manifestation of a failure. For example, a systemin failure mode may be characterized by slow operation, incorrect outputs,or complete termination of execution. Failure Mode and Effect Analysis (FMEA): A systematic approach to risk identification and analysis of identifying possible modes of failure and attempting to prevent their occurrence. failure rate: The ratio of the number of failures of a given category to a given unit of measure, e.g. failures per unit of time, failures per number of transactions,failures per number of computer runs. [IEEE 610] fault tolerance: The capability of the software product to maintain a specified level of performance in cases of software faults (defects) or of infringement of its specified interface. [ISO 9126] See also reliability. fault tree analysis: A method used to analyze the causes offaults (defects). feasible path: A path for which a set of input values and preconditions exists which causes it to be executed. feature: An attribute of a component or system specified or implied by requirements documentation (for example reliability, usability or design constraints).[After IEEE 1008] finite state machine: A computational model consisting of a finite number of states and transitions between those states,possibly with accompanying actions. [IEEE 610] formal review: A review characterized by documented procedures and requirements, e.g. inspection. frozen test basis: A test basis document that can only be amended by a formal change control process.See also baseline. Function Point Analysis (FPA): Method aiming to measure the size of the functionality of an information system. The measurement is independent of the technology. This measurement may be used as a basis for the measurement of productivity, the estimation of the needed resources,and project control.
- 182. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ functional integration: An integration approach that combines the components or systems for the purpose of getting a basic functionality working early. See also integration testing. functional requirement: A requirement that specifies a function that a component or systemmust perform. [IEEE 610] functional test design technique: Documented procedure to derive and select test cases based on an analysis of the specification of the functionality of a component or systemwithout reference to its internal structure.See also black box test design technique. functional testing: Testing based on an analysis of the specification of the functionality of a component or system. See also black box testing. functionality: The capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions.[ISO 9126] functionality testing: The process of testing to determine the functionality of a software product. G glass box testing: See white box testing. H heuristic evaluation: A static usability test technique to determine the compliance of a user interface with recognized usability principles (the so-called âheuristicsâ). high level test case: A test case without concrete (implementation level) values for input data and expected results. horizontal traceability: The tracing of requirements for a test level through the layers of test documentation (e.g. test plan, test design specification, test case specification and test procedure specification). I impact analysis: The assessment of change to the layers of development documentation, test documentation and components,in order to implement a given change to specified requirements. incremental development model: A development life cycle where a project is broken into a series of increments, each of which delivers a portion of the functionality in the overal project requirements. The requirements are prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this life cycle model, each subproject follows a âmini V-modelâ with its own design, coding and testing phases. incremental testing: Testing where components or systems are integrated and tested one or some at a time, until all the components or systems are integrated and tested. incident: Any event occurring during testing that requires investigation. [After IEEE 1008] incident management: The process ofrecognizing, investigating, taking action and disposing of incidents. It involves recording incidents, classifying them and identifying the impact. [After IEEE 1044]
- 183. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ incident management tool: A tool that facilitates the recording and status tracking of incidents found during testing. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of incidents and provide reporting facilities. incident report: A document reporting on any event that occurs during the testing which requires investigation. [After IEEE 829] independence:Separation of responsibilities, which encourages the accomplishment of objective testing.[After DO- 178b] infeasible path: A path that cannot be exercised by any set of possible input values. informal review: A review not based on a formal (documented) procedure. input: A variable (whether stored within a component or outside)that is read by a component. input domain: The set from which valid input values can be selected.. See also domain. input value: An instance of an input. See also input. inspection: A type of review that relies on visual examination of documents to detect defects, e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a documented procedure. [After IEEE 610, IEEE 1028] installability: The capability of the software product to be installed in a specified environment [ISO 9126]. See also portability. installability testing: The process of testing the installability of a software product.See also portability testing. installation guide: Supplied instructions on any suitable media, which guides the installer through the installation process.This may be a manual guide, step-by-step procedure,installation wizard, or any other similar process description. installation wizard: Supplied software on any suitable media, which leads the installer through the installation process.It normally runs the installation process,provides feedback on installation results,and prompts for options. instrumentation: The insertion of additional code into the program in order to collect information about program behavior during execution. instrumenter: A software tool used to carry out instrumentation. intake test:A special instance of a smoke test to decide if the component or systemis ready for detailed and further testing.An intake test is typically carried out at the start of the test execution phase. integration: The process of combining components or systems into larger assemblies. integration testing: Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.See also component integration testing, systemintegration testing. interface testing: An integration test type that is concerned with testing the interfaces between components or systems. interoperability: The capability of the software product to interact with one or more specified components or systems.[After ISO 9126] See also functionality.
- 184. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ interoperability testing:The process of testing to determine the interoperability of a software product. See also functionality testing. invalid testing: Testing using input values that should be rejected by the component or system. See also error tolerance. isolation testing: Testing of individual components in isolation from surrounding components, with surrounding components being simulated by stubs and drivers, if needed. K keyword driven testing: A scripting technique that uses data files to contain not only test data and expected results, but also keywords related to the application being tested.The keywords are interpreted by special supporting scripts that are called by the control script for the test.See also data driven testing. L LCSAJ: A Linear Code Sequence And Jump, consisting of the following three items (conventionally identified by line numbers in a source code listing): the start of the linear sequence ofexecutable statements,the end of the linear sequence,and the target line to which control flow is transferred at the end of the linear sequence. LCSAJ coverage: The percentage of LCSAJs of a component that have been exercised by a test suite.100% LCSAJ coverage implies 100% decision coverage. LCSAJ testing:A white box test design technique in which test cases are designed to execute LCSAJs. learnability: The capability of the software product to enable the userto learn its application. [ISO 9126] See also usability. load test: A test type concerned with measuring the behavior of a component or system with increasing load, e.g. number of parallel users and/ornumbers of transactions to determine what load can be handled by the component or system. low level test case:A test case with concrete (implementation level) values for input data and expected results. M maintenance: Modification of a software product after delivery to correct defects, to improve performance or other attributes,or to adapt the product to a modified environment. [IEEE 1219] maintenance testing:Testing the changes to an operational systemor the impact of a changed environment to an operational system. maintainability: The ease with which a software product can be modified to correct defects, modified to meet new requirements, modified to make future maintenance easier, or adapted to a changed environment. [ISO 9126] maintainability testing: The process of testing to determine the maintainability of a software product.
- 185. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ management review: A systematic evaluation of software acquisition, supply,development, operation, or maintenance process,performed by or on behalf of management that monitors progress,determines the status of plans and schedules,confirms requirements and heir systemallocation, or evaluates the effectiveness of management approaches to achieve fitness for purpose.[After IEEE 610, IEEE 1028] maturity: (1) The capability of an organization with respect to the effectiveness and efficiency of its processes and work practices. See also Capability Maturity Model, Test Maturity Model. (2) The capability of the software product to avoid failure as a result of defects in the software. [ISO 9126] See also reliability. measure: The number or category assigned to an attribute of an entity by making a measurement [ISO 14598]. measurement: The process of assigning a number or category to an entity to describe an attribute of that entity. [ISO 14598] measurement scale: A scale that constrains the type of data analysis that can be performed on it. [ISO 14598] memory leak: A defect in a programâs dynamic store allocation logic that causes it to fail to reclaim memory after it has finished using it, eventually causing the program to fail due to lack of memory. metric: A measurement scale and the method used for measurement. [ISO 14598] milestone: A point in time in a project at which defined (intermediate) deliverables and results should be ready. moderator: The leader and main person responsible for an inspection or other review process. monitor: A software tool or hardware device that run concurrently with the component or systemunder test and supervises,records and/oranalyses the behavior of the component or system.[After IEEE 610] multiple condition coverage: The percentage of combinations of all single condition outcomes within one statement that have been exercised by a test suite. 100% multiple condition coverage implies 100% condition determination coverage. multiple condition testing:A white box test design technique in which test cases are designed to execute combinations of single condition outcomes (within one statement). mutation analysis: A method to determine test suite thoroughness by measuring the extent to which a test suite can discriminate the program from slight variants (mutants) of the program. N N-switch coverage: The percentage of sequences ofN+1 transitions that have been exercised by a test suite. [Chow] N-switch testing: A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 transitions.[Chow] See also state transition testing. negative testing:Tests aimed at showing that a component or systemdoes not work. Negative testing is related to the testersâattitude rather than a specific test approach or test design technique. [After Beizer]. non-conformity: Non fulfillment of a specified requirement. [ISO 9000]
- 186. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ non-functional requirement: A requirement that does not relate to functionality, but to attributes of such as reliability, efficiency, usability, maintainability and portability. non-functional testing:Testing the attributes of a component or system that do not relate to functionality, e.g. reliability, efficiency, usability, maintainability and portability. non-functional test design techniques:Methods used to design or select tests for nonfunctionaltesting. O off-the-shelf software: A software product that is developed for the general market, i.e. for a large number of customers, and that is delivered to many customers in identical format. operability: The capability of the software product to enable the userto operate and control it. [ISO 9126] See also usability. operational environment: Hardware and software products installed at usersâ or customersâ sites where the component or systemunder test will be used.The software may include operating systems,database management systems,and otherapplications. operational profile testing: Statistical testing using a model of system operations (short duration tasks)and their probability of typical use.[Musa] operational testing: Testing conducted to evaluate a component or system in its operational environment. [IEEE 610] output:A variable (whether stored within a component or outside)that is written by a component. output domain: The set from which valid output values can be selected.See also domain. output value: An instance of an output.See also output. P pair programming: A software development approach whereby lines of code (production and/ortest)of a component are written by two programmers sitting at a single computer. This implicitly means ongoing real-time code reviews are performed. pair testing: Two testers work togetherto find defects. Typically, they share one computer and trade control of it while testing. Pass: A test is deemed to pass if its actual result matches its expected result. pass/fail criteria: Decision rules used to determine whether a test item (function) or feature has passed orfailed a test.[IEEE 829] path: A sequence of events,e.g. executable statements,of a component or systemfrom an entry point to an exit point. path coverage: The percentage of paths that have been exercised by a test suite.100% path coverage implies 100% LCSAJ coverage. path sensitizing: Choosing a set of input values to force the execution of a given path.
- 187. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ path testing: A white box test design technique in which test cases are designed to execute paths. performance: The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput rate.[After IEEE 610] See efficiency. performance indicator: A high level metric of effectiveness and/or efficiency used to guide and control progressive development, e.g. Defect Detection Percentage (DDP) for testing.[CMMI] performance testing:The process of testing to determine the performance of a software product.See efficiency testing. performance testing tool: A tool to support performance testing and that usually has two main facilities: load generation and test transaction measurement. Load generation can simulate either multiple users or high volumes of input data. During execution, response time measurements are taken from selected transactions and these are logged. Performance testing tools normally provide reports based on test logs and graphs of load against response times. phase test plan: A test plan that typically addresses one test level. portability: The ease with which the software product can be transferred from one hardware or software environment to another.[ISO 9126] portability testing: The process oftesting to determine the portability of a software product. postcondition:Environmental and state conditions that must be fulfilled after the execution of a test or test procedure. post-execution comparison: Comparison of actual and expected results,performed after the software has finished running. precondition: Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure. Priority: The level of (business)importance assigned to an item, e.g. defect. process cycle test:A black box test design technique in which test cases are designed toexecute business procedures and processes.[TMap] process:A set of interrelated activities, which transform inputs into outputs.[ISO 12207] project: A project is a unique set of coordinated and controlled activities with start and finish dates undertaken an objective conforming to specific requirements, including the constraints of time, cost and resources.[ISO 9000] project test plan: A test plan that typically addresses multiple test levels. pseudo-random: A series which appears to be random but is in fact generated according to some prearranged sequence. Q quality: The degree to which a component, systemor process meets specified requirements and/oruser/customer needs and expectations. [After IEEE 610]
- 188. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ quality assurance:Part of quality management focused on providing confidence that quality requirements will be fulfilled. [ISO 9000] quality attribute: A feature or characteristic that affects an itemâs quality. [IEEE 610] quality management: Coordinated activities to direct and control an organization with regard to quality. Direction and control with regard to quality generally includes the establishment of the quality policy and quality objectives, quality planning, quality control, quality assurance and quality improvement. [ISO 9000] R random testing: A black box test design technique where test cases are selected, possibly using a pseudo-random generation algorithm, to match an operational profile. This technique can be used for testing non-functional attributes such as reliability and performance. recoverability: The capability of the software product to re-establish a specified level of performance and recover the data directly affected in case of failure. [ISO 9126] See also reliability. recoverability testing: The process of testing to determine the recoverability of a software product. See also reliability testing. regression testing: Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed. release note: A document identifying test items, their configuration, current status and otherdelivery information delivered by development to testing,and possibly other stakeholders,at the start of a test execution phase.[After IEEE 829] reliability: The ability of the software product to perform its required functions understated conditions for a specified period of time, or for a specified number of operations. [ISO 9126] reliability testing: The process of testing to determine the reliability of a software product. replaceability: The capability of the software product to be used in place of anotherspecified software product for the same purpose in the same environment. [ISO 9126] See also portability. requirement: A condition or capability needed by a userto solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard,specification, or other formally imposed document. [After IEEE 610] requirements-based testing:An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements, e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability. requirements management tool: A tool that supports the recording of requirements, requirements attributes (e.g. priority, knowledge responsible)and annotation, and facilitates traceability through layers of requirements and
- 189. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ requirements change management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and violations to pre-defined requirements rules. requirements phase:The period of time in the software life cycle during which the equirements for a software product are defined and documented. [IEEE 610] resource utilization: The capability of the software product to use appropriate amounts and types of resources,for example the amounts of main and secondary memory used by the program and the sizes of required temporary or overflow files, when the software performs its function under stated conditions.[After ISO 9126] See also efficiency. resource utilization testing: The process oftesting to determine the resource-utilization of a software product. result: The consequence/outcome of the execution of a test.It includes outputs to screens,changes to data,reports, and communication messages sent out.See also actual result, expected result. resumption criteria: The testing activities that must be repeated when testing is re-started after a suspension. [After IEEE 829] re-testing: Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions. review: An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review, informal review, technical review, inspection, and walkthrough. [After IEEE 1028] reviewer: The person involved in the review who shall identify and describe anomalies in the product or project under review. Reviewers can be chosen to represent different viewpoints and roles in the review process. risk: A factor that could result in future negative consequences; usually expressed as impact and likelihood. risk analysis: The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood). risk-based testing: Testing oriented towards exploring and providing information about product risks. [After Gerrard] risk control: The process through which decisions are reached and protective measures are implemented for reducing risks to, or maintaining risks within, specified levels. risk identification: The process ofidentifying risks using techniques such as brainstorming, checklists and failure history. risk management: Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risk. robustness:The degree to which a component or system can function correctly in the presence of invalid inputs or stressfulenvironmental conditions.[IEEE 610] See also errortolerance, fault-tolerance. root cause:An underlying factor that caused a non-conformance and possibly should be permanently eliminated through process improvement.
- 190. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ S safety: The capability of the software product to achieve acceptable levels of risk of harm to people, business, software, property or the environment in a specified context of use. [ISO 9126] safety testing: The process of testing to determine the safety of a software product. scalability: The capability of the software product to be upgraded to accommodate increased loads. [After Gerrard] scalability testing: Testing to determine the scalability of the software product. scribe: The person who has to record each defect mentioned and any suggestions forimprovement during a review meeting, on a logging form. The scribe has to make ensure that the logging form is readable and understandable. scripting language: A programming language in which executable test scripts are written, used by a test execution tool (e.g. a capture/replay tool). security: Attributes of software products that bear on its ability to prevent unauthorized access,whether accidental or deliberate, to programs and data. [ISO 9126] security testing:Testing to determine the security of the software product. severity: The degree of impact that a defect has on the development or operation of a component or system. [After IEEE 610] simulation: The representation of selected behavioral characteristics of one physical or abstract systemby another system. [ISO 2382/1] simulator: A device, computer program or systemused during testing,which behaves or operates like a given system when provided with a set of controlled inputs. [After IEEE 610, DO178b] See also emulator. smoke test: A subset ofall defined/planned test cases that coverthe main functionality of a component or system, to ascertaining that the most crucial functions of a program work, but not bothering with finer details. A daily build and smoke test is among industry best practices. See also intake test. software quality: The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs.[After ISO 9126] specification: A document that specifies, ideally in a complete, precise and verifiable manner, the requirements, design,behavior, or other characteristics of a component or system, and, often, the procedures for determining whether these provisions have been satisfied. [After IEEE 610] specification-based test design technique: See black box test design technique. specified input: An input for which the specification predicts a result. stability: The capability of the software product to avoid unexpected effects from modifications in the software. [ISO 9126] See also maintainability. state diagram: A diagram that depicts the states that a component or system can assume, and shows the events or circumstances that cause and/or result from a change from one state to another.[IEEE 610] state table: A grid showing the resulting transitions for each state combined with each possible event,showing both valid and invalid transitions.
- 191. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ state transition: A transition between two states ofa component or system. state transition testing:A black box test design technique in which test cases are designed to execute valid and invalid state transitions.See also N-switch testing. statement: An entity in a programming language, which is typically the smallest indivisible unit of execution. statement coverage: The percentage of executable statements that have been exercised by a test suite. statement testing: A white box test design technique in which test cases are designed toexecute statements. static analysis: Analysis of software artifacts, e.g. requirements or code, carried out without execution of these software artifacts. static analyzer: A tool that carries out static analysis. static code analysis: Analysis of program source code carried out without execution of that software. static code analyzer: A tool that carries out static code analysis. The tool checks source code, for certain properties such as conformance to coding standards,quality metrics or data flow anomalies. static testing: Testing of a component or system at specification or implementation level without execution of that software, e.g. reviews or static code analysis. statistical testing:A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases.See also operational profile testing. status accounting:An element of configuration management, consisting of the recording andreporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status ofthe approved changes.[IEEE 610] Stress testing: Testing conducted to evaluate a systemor component at or beyond the limits of its specified requirements. [IEEE 610] structural coverage: Coverage measures based on the internal structure of the component. structural test design technique: See white box test design technique. stub:A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component. [After IEEE 610] subpath:A sequence ofexecutable statements within a component. suspension criteria: The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. [After IEEE 829] suitability: The capability of the software product to provide an appropriate set of functions for specified tasks and user objectives.[ISO 9126] See also functionality. Software Usability Measurement Inventory (SUMI): A questionnaire based usability test technique to evaluate the usability, e.g. user-satisfaction,of a component or system. [Veenendaal] syntaxtesting: A black box test design technique in which test cases are designed based upon the definition of the input domain and/or output domain. system: A collection of components organized to accomplish a specific function or set of functions.[IEEE 610]
- 192. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ systemintegration testing:Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet). systemtesting: The process of testing an integrated system to verify that it meets specified requirements. [Hetzel] T technical review: A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken. A technical review is also known as a peer review. [Gilb and Graham, IEEE 1028] test approach: The implementation of the test strategy for a specific project. It typically includes the decisions made that follow based on the (test)projectâs goal and the risk assessment carried out, starting points regarding the test process,the test design techniques to be applied, exit criteria and test types to be performed. test automation: The use of software to perform or support test activities, e.g. test management, test design,test execution and results checking. test basis: All documents from which the requirements of a component or systemcan be inferred. The documentation on which the test cases are based.If a document can be amended only by way of formal amendment procedure, then the test basis is called a frozen test basis.[After TMap] test case: A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. [After IEEE 610] test case specification: A document specifying a set of test cases (objective, inputs, test actions,expected results,and execution preconditions) for a test item. [After IEEE 829] test charter: A statement of test objectives,and possibly test ideas. Test charters are amongst other used in exploratory testing.See also exploratory testing. test comparator: A test tool to perform automated test comparison. test comparison: The process of identifying differences between the actual results produced by the component or systemunder test and the expected results for a test.Test comparison can be performed during test execution (dynamic comparison) or after test execution. test condition: An item or event of a component or system that could be verified by one or more test cases,e.g. a function, transaction, quality attribute, or structural element. test data: Data that exists (for example, in a database)before a test is executed, and thataffects or is affected by the component or systemunder test. test data preparation tool: A type of test tool that enables data to be selected from existing databases orcreated, generated, manipulated and edited for use in testing. test design specification: A document specifying the test conditions (coverage items) for a test item, the detailed test approach and identifying the associated high level test cases.[After IEEE 829]
- 193. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ test design tool: A tool that support the test design activity by generating test inputs from a specification that may be held in a CASE tool repository, e.g. requirements management tool, or from specified test conditions held in the tool itself. test design technique: A method used to derive or select test cases. test environment: An environment containing hardware, instrumentation, simulators, software tools,and other support elements needed to conduct a test.[After IEEE 610] test evaluation report: A document produced at the end of the test process summarizing all testing activities and results.It also contains an evaluation of the test process and lessons learned. test execution: The process of running a test by the component or systemunder test,producing actual result(s). test execution automation: The use of software, e.g. capture/playbacktools, to control the execution of tests,the comparison of actual results to expected results,the setting up of test preconditions, and othertest control and reporting functions. test execution phase:The period of time in a software development life cycle during which the components of a software product are executed, and the software product is evaluated to determine whether or not requirements have been satisfied. [IEEE 610] test execution schedule: A scheme for the execution of test procedures.The test procedures are included in the test execution schedule in their context and in the order in which they are to be executed. test execution technique: The method used to perform the actual test execution, either manually or automated. test execution tool: A type of test tool that is able to execute other software using an automated test script, e.g. capture/playback. [Fewster and Graham] test harness:A test environment comprised of stubs and drivers needed to conduct a test. test infrastructure: The organizational artifacts needed to perform testing,consisting of test environments, test tools, office environment and procedures. test item: The individual element to be tested.There usually is one test object and many test items. See also test object. test level: A group of test activities that are organized and managed together.A test level is linked to the responsibilities in a project. Examples of test levels are component test,integration test,system test and acceptance test.[After TMap] test log: A chronological record of relevant details about the execution of tests.[IEEE 829] test logging: The process of recording information about tests executed into a test log. test manager: The person responsible for testing and evaluating a test object. The individual, who directs, controls, administers plans and regulates the evaluation of a test object. test management: The planning, estimating, monitoring and control of test activities, typically carried out by a test manager. Test Maturity Model (TMM): A five level staged framework for test process improvement, related to the Capability Maturity Model (CMM) that describes the key elements of an effective test process.
- 194. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Test Process Improvement (TPI): A continuous framework for test process improvement that describes the key elements of an effective test process,especially targeted at systemtesting and acceptance testing. test object: The component or systemto be tested.See also test item. test objective: A reason or purpose for designing and executing a test. test oracle: A source to determine expected results to compare with the actual result of the software under test.An oracle may be the existing system (for a benchmark), a user manual, or an individualâs specialized knowledge, but should not be the code. [After Adrion] test performance indicator: A metric, in general high level, indicating to what extent a certain target value or criterion is met. Often related to test process improvement objectives, e.g. Defect Detection Percentage (DDP). test phase:A distinct set of test activities collected into a manageable phase of a project, e.g. the execution activities of a test level. [After Gerrard] test plan: A document describing the scope,approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested,the testing tasks,who will do each task, degree of tester independence, the test environment, the test design techniques and test measurement techniques to be used,and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process [After IEEE 829] test planning: The activity of establishing or updating a test plan. test policy: A high level document describing the principles, approach and major objectives of the organization regarding testing. test point analysis (TPA): A formula based test estimation method based on function point analysis. [TMap] test procedure: See test procedure specification. test procedure specification: A document specifying a sequence ofactions for the execution of a test.Also known as test script or manual test script. [After IEEE 829] test process:The fundamental test process comprises planning, specification, execution, recording and checking for completion. [BS 7925/2] test repeatability: An attribute of a test indicating whether the same results are produced each time the test is executed. test run: Execution of a test on a specific version of the test object. test script: Commonly used to refer to a test procedure specification, especially an automated one. test specification: A document that consists ofa test design specification, test case specification and/ortest procedure specification. test strategy:A high-level document defining the test levels to be performed and the testing within those levels for a programme (one or more projects). test suite: A set of several test cases for a component or system undertest, where the post condition of one test is often used as the precondition for the next one.
- 195. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ test summary report: A document summarizing testing activities and results.It also contains an evaluation of the corresponding test items against exit criteria. [After IEEE 829] test target: A set of exit criteria. test tool: A software product that supports one or more test activities, such as planning and control, specification, building initial files and data, test execution and test analysis.[TMap] See also CAST. test type: A group of test activities aimed at testing a component or system regarding one or more interrelated quality attributes. A test type is focused on a specific test objective, i.e. reliability test,usability test, regression test etc., and may take place on one or more test levels or test phases.[After TMap] testability: The capability of the software product to enable modified software to be tested.[ISO 9126] See also maintainability. testability review: A detailed check of the test basis to determine whether the test basis is at an adequate quality level to act as an input document for the test process.[After TMap] testable requirements: The degree to which a requirement is stated in terms that permit establishment of test designs (and subsequently test cases)and execution of tests to determine whether the requirements have been met. [After IEEE 610] tester: A technically skilled professionalwho is involved in the testing of a component or system. testing: The process consisting ofall life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects. testware: Artifacts produced during the test process required to plan, design,and execute tests,such as documentation, scripts,inputs, expected results, set-up and clear-up procedures,files, databases,environment, and any additional software or utilities used in testing.[After Fewster and Graham] thread testing:A version of component integration testing where the progressive integration of components follows the implementation of subsets ofthe requirements, as opposed to the integration of components by levels of a hierarchy. traceability: The ability to identify related items in documentation and software, such as requirements with associated tests. See also horizontal traceability, vertical traceability. top-down testing: An incremental approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs.Tested components are then used to test lower level components.The process is repeated until the lowest level components have been tested. U understandability: The capability of the software product to enable the userto understand whetherthe software is suitable, and how it can be used for particular tasks and conditions of use.[ISO 9126] See also usability.
- 196. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ unreachable code: Code that cannot be reached and therefore is impossible to execute. usability: The capability of the software to be understood,learned, used and attractive to the userwhen used under specified conditions. [ISO 9126] usability testing: Testing to determine the extent to which the software product is understood, easy to learn, easy to operate and attractive to the users under specified conditions. [After ISO 9126] use case testing: A black box test design technique in which test cases are designed to execute userscenarios. user test:A test whereby real-life users are involved to evaluate the usability of a component or system. V V-model: A framework to describe the software development life cycle activities from requirements specification to maintenance. The V-model illustrates how testing activities can be integrated into each phase of the software development life cycle. validation: Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled. [ISO 9000] variable: An element of storage in a computer that is accessible by a software program by referring to it by a name. verification: Confirmation by examination and through the provision of objective evidence that specified requirements have been fulfilled. [ISO 9000] vertical traceability: The tracing of requirements through the layers of development documentation to components. volume testing: Testing where the systemis subjected to large volumes of data. See also resource-utilization testing. W walkthrough: A step-by-step presentation by the authorof a document in order to gatherinformation and to establish a common understanding of its content.[Freedman and Weinberg, IEEE 1028] white box test design technique: Documented procedure to derive and select test cases based on an analysis of the internal structure of a component or system. white box testing: Testing based on an analysis of the internal structure of the component or system. Wide Band Delphi: An expert based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members. 100 Manual Testing Interview FAQâs Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Interview Faq's, Manual Testing Basics | Leave a comment Q1. What is verification?
- 197. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ A: Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, and walkthroughs and inspection meetings. You CAN learn to do verification, with little or no outside help. Get CAN get free information. Click on a link! Q2. What is validation? A: Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed. Q3. What is a walkthrough? A: A walkthrough is an informal meeting for evaluation or informational purposes. A walkthrough is also a process at an abstract level. Itâs the process of inspecting software code by following paths through the code (as determined by input conditions and choices made along the way). The purpose of code walkthroughs is to ensure the code fits the purpose. Walkthroughs also offer opportunities to assess an individualâs or teamâs competency. Q4. What is an inspection? A: An inspection is a formal meeting, more formalized than a walkthrough and typically consists of 3- 10 people including a moderator, reader (the author of whatever is being reviewed) and a recorder (to make notes in the document). The subject of the inspection is typically a document, such as a requirements document or a test plan. The purpose of an inspection is to find problems and see what is missing, not to fix anything. The result of the meeting should be documented in a written report. Attendees should prepare for this type of meeting by reading through the document, before the meeting starts; most problems are found during this preparation. Preparation for inspections is difficult, but is one of the most cost-effective methods of ensuring quality, since bug prevention is more cost effective than bug detection. Q5. What is quality? A: Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable. However, quality is a subjective term. Quality depends on who the customer is and their overall influence in the scheme of things. Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organizationâs management, test engineers, testers, salespeople, software engineers, stockholders and accountants. Each type of customer will have his or her own slant on quality. The accounting department might define quality in terms of profits, while an end-user might define quality as user friendly and bug free. Q6. What is good code? A: A good code is code that works, is free of bugs and is readable and maintainable. Organizations usually have coding standards all developers should adhere to, but every programmer and software
- 198. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ engineer has different ideas about what is best and what are too many or too few rules. We need to keep in mind that excessive use of rules can stifle both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems and enforce standards. Q7. What is good design? A: Design could mean too many things, but often refers to functional design or internal design. Good functional design is indicated by software functionality can be traced back to customer and end-user requirements. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable and maintainable; is robust with sufficient error handling and status logging capability; and works correctly when implemented. Q8. What is software life cycle? A: Software life cycle begins when a software product is first conceived and ends when it is no longer in use. It includes phases like initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, re-testing and phase-out. Q9. Why are there so many software bugs? A: Generally speaking, there are bugs in software because of unclear requirements, software complexity, programming errors, changes in requirements, errors made in bug tracking, time pressure, poorly documented code and/or bugs in tools used in software development. There are unclear software requirements because there is miscommunication as to what the software should or shouldnât do. Software complexity. All of the followings contribute to the exponential growth in software and system complexity: Windows interfaces, client-server and distributed applications, data communications, enormous relational databases and the sheer size of applications. Programming errors occur because programmers and software engineers, like everyone else, can make mistakes. As to changing requirements, in some fast-changing business environments, continuously modified requirements are a fact of life. Sometimes customers do not understand the effects of changes, or understand them but request them anyway. And the changes require redesign of the software, rescheduling of resources and some of the work already completed have to be redone or discarded and hardware requirements can be effected, too. Bug tracking can result in errors because the complexity of keeping track of changes can result in errors, too. Time pressures can cause problems, because scheduling of software projects is not easy and it often requires a lot of guesswork and when deadlines loom and the crunch comes, mistakes will be made. Code documentation is tough to maintain and it is also tough to modify code that is poorly documented. The result is bugs. Sometimes there is no incentive for programmers and software
- 199. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ engineers to document their code and write clearly documented, understandable code. Sometimes developers get kudos for quickly turning out code or programmers and software engineers feel they cannot have job security if everyone can understand the code they write, or they believe if the code was hard to write, it should be hard to read. Software development tools, including visual tools, class libraries, compilers, scripting tools, can introduce their own bugs. Other times the tools are poorly documented, which can create additional bugs. Q10. How do you introduce a new software QA process? A: It depends on the size of the organization and the risks involved. For large organizations with high- risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required. Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and testable. Q11. Give me five common problems that occur during software development. A: Poorly written requirements, unrealistic schedules, inadequate testing, and adding new features after development is underway and poor communication. Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems. The schedule is unrealistic if too much work is crammed in too little time. Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes. Itâs extremely common that new features are added after development is underway. Miscommunication either means the developers donât know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed. Q12. Do automated testing tools make testing easier? A: Yes and no. For larger projects, or ongoing long-term projects, they can be valuable. But for small projects, the time needed to learn and implement them is usually not worthwhile. A common type of automated tool is the record/playback type. For example, a test engineer clicks through all combinations of menu choices, dialog box choices, buttons, etc. in a GUI and has an automated testing tool record and log the results. The recording is typically in the form of text, based on a scripting language that the testing tool can interpret. If a change is made (e.g. new buttons are added, or some underlying code in the application is changed), the application is then re-tested by just playing back the recorded actions and compared to the logged results in order to check effects of
- 200. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ the change. One problem with such 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. You CAN learn to use automated testing tools, with little or no outside help. Get CAN get free information. Click on a link! Q13. Give me five solutions to problems that occur during software development. A: Solid requirements, realistic schedules, adequate testing, firm requirements and good communication. Ensure the requirements are solid, clear, complete, detailed, cohesive, attainable and testable. All players should agree to requirements. Use prototypes to help nail down requirements. Have schedules that are realistic. Allow adequate time for planning, design, testing, bug fixing, re- testing, changes and documentation. Personnel should be able to complete the project without burning out. Do testing that is adequate. Start testing early on, re-test after fixes or changes, and plan for sufficient time for both testing and bug fixing. Avoid new features. Stick to initial requirements as much as possible. Be prepared to defend design against changes and additions, once development has begun and be prepared to explain consequences. If changes are necessary, ensure theyâre adequately reflected in related schedule changes. Use prototypes early on so customersâ expectations are clarified and customers can see what to expect; this will minimize changes later on. Communicate. Require walkthroughs and inspections when appropriate; make extensive use of e-mail, networked bug-tracking tools, and tools of change management. Ensure documentation is available and up-to-date. Use documentation that is electronic, not paper. Promote teamwork and cooperation. Q14. What makes a good test engineer? A: Rob Davis is a good test engineer because he Has a âtest to breakâ attitude, Takes the point of view of the customer, Has a strong desire for quality, Has an attention to detail, Heâs also Tactful and diplomatic and Has well a communication skill, both oral and written. And he Has previous software development experience, too. Good test engineers have a âtest to breakâ attitude. We, good test engineers, take the point of view of the customer; have a strong desire for quality and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers and an ability to communicate with both technical and non-technical people. Previous software development experience is also helpful as
- 201. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ it provides a deeper understanding of the software development process gives the test engineer an appreciation for the developersâ point of view and reduces the learning curve in automated test tool programming. Q15. What makes a good QA engineer? A: The same qualities a good test engineer has are useful for a QA engineer. Additionally, Rob Davis understands the entire software development process and how it fits into the business approach and the goals of the organization. Rob Davisâ communication skills and the ability to understand various sides of issues are important. 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. Q16. What makes a good resume? A: On the subject of resumes, there seems to be an unending discussion of whether you should or shouldnât have a one-page resume. The followings are some of the comments I have personally heard: âWell, Joe Blow (car salesman) said I should have a one-page resume.â âWell, I read a book and it said you should have a one page resume.â âI canât really go into what I really did because if I did, itâd take more than one page on my resume.â âGosh, I wish I could put my job at IBM on my resume but if I did itâd make my resume more than one page, and I was told to never make the resume more than one page long.â âIâm confused, should my resume be more than one page? I feel like it should, but I donât want to break the rules.â Or, hereâs another comment, âPeople just donât read resumes that are longer than one page.â I have heard some more, but we can start with these. So whatâs the answer? There is no scientific answer about whether a one-page resume is right or wrong. It all depends on who you are and how much experience you have. The first thing to look at here is the purpose of a resume. The purpose of a resume is to get you an interview. If the resume is getting you interviews, then it is considered to be a good resume. If the resume isnât getting you interviews, then you should change it. The biggest mistake you can make on your resume is to make it hard to read. Why? Because, for one, scanners donât like odd resumes. Small fonts can make your resume harder to read. Some candidates use a 7-point font so they can get the resume onto one page. Big mistake. Two, resume readers do not like eye strain either. If the resume is mechanically challenging, they just throw it aside for one that is easier on the eyes. Three, there are lots of resumes out there these days, and that is also part of the problem. Four, in light of the current scanning scenario, more than one page is not a deterrent because many will scan your resume into their database. Once the resume is in there and searchable, you have accomplished one of the goals of resume distribution. Five, resume readers donât like to guess and most wonât call you to clarify what is on your resume. Generally speaking, your resume should tell your story. If youâre a college graduate looking for your first job, a one-page resume is just fine. If you have a longer story, the resume needs to be longer. Please put your experience on the resume so resume readers can tell when and for whom you did
- 202. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ what. Short resumes â for people long on experience â are not appropriate. The real audience for these short resumes is people with short attention spans and low IQ. I assure you that when your resume gets into the right hands, it will be read thoroughly. Q17. What makes a good QA/Test Manager? A: QA/Test Managers are familiar with the software development process; able to maintain enthusiasm of their team and promote a positive atmosphere; able to promote teamwork to increase productivity; able to promote cooperation between Software and Test/QA Engineers, have the people skills needed to promote improvements in QA processes, have the ability to withstand pressures and say *no* to other managers when quality is insufficient or QA processes are not being adhered to; able to communicate with technical and non-technical people; as well as able to run meetings and keep them focused. Q18. What is the role of documentation in QA? A: Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible. Q19. What about requirements? A: Requirement specifications are important and one of the most reliable methods of insuring problems in a complex software project is to have poorly documented requirement specifications. Requirements are the details describing an applicationâs externally perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable and testable. A non-testable requirement would be, for example, âuser-friendlyâ, which is too subjective. A testable requirement would be something such as, âthe product shall allow the user to enter their previously-assigned password to access the applicationâ. Care should be taken to involve all of a projectâs significant customers in the requirements process. Customers could be in-house or external and could include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, future software maintenance engineers, salespeople and anyone who could later derail the project. If his/her expectations arenât met, they should be included as a customer, if possible. In some organizations, requirements may end up in high-level project plans, functional specification documents, design documents, or other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by test engineers in order to properly plan and execute tests. Without such documentation there will be no clear-cut way to determine if a software application is performing correctly. You CAN learn to capture requirements, with little or no outside help. Get CAN get free information. Click on a link! Q20. What is a test plan?
- 203. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 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 none outside the test group will be able to read it. Q21. What is a test case? A: A test case is a document that describes an input, action, or event and its expected result, in order to determine if a feature of an application is working correctly. A test case should contain particulars such as a⊠Test case identifier; Test case name; Objective; Test conditions/setup; Input data requirements/steps, and Expected results. Please note, the process of developing test cases can help find problems in the requirements or design of an application, since it requires you to completely think through the operation of the application. For this reason, it is useful to prepare test cases early in the development cycle, if possible. Q22. What should be done after a bug is found? A: 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. Q23. What is configuration management? A: Configuration management (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. Rob Davis has had experience with a full range of CM tools and concepts. Rob Davis can easily adapt to your software tool and process needs. Q24. What if the software is so buggy it canât be tested at all?
- 204. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ A: In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem. Q25. How do you know when to stop testing? A: 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. Common factors in deciding when to stop are⊠Deadlines, e.g. release deadlines, testing deadlines; Test cases completed with certain percentage passed; Test budget has been depleted; Coverage of code, functionality, or requirements reaches a specified point; Bug rate falls below a certain level; or Beta or alpha testing period ends. Q26. What if there isnât enough time for thorough testing? A: Since itâs rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions: · Which functionality is most important to the projectâs intended purpose? · Which functionality is most visible to the user? · Which functionality has the largest safety impact? · Which functionality has the largest financial impact on users? · Which aspects of the application are most important to the customer? · Which aspects of the application can be tested early in the development cycle? · Which parts of the code are most complex and thus most subject to errors? · Which parts of the application were developed in rush or panic mode? · Which aspects of similar/related previous projects caused problems? · Which aspects of similar/related previous projects had large maintenance expenses? · Which parts of the requirements and design are unclear or poorly thought out? · What do the developers think are the highest-risk aspects of the application? · What kinds of problems would cause the worst publicity? · What kinds of problems would cause the most customer service complaints?
- 205. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ · What kinds of tests could easily cover multiple functionalities? · Which tests will have the best high-risk-coverage to time-required ratio? Q27. What if the project isnât big enough to justify extensive testing? A: Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the considerations listed under âWhat if there isnât enough time for thorough testing?â do apply. The test engineer then should do âad hocâ testing, or write up a limited test plan based on the risk analysis. Q28. What can be done if requirements are changing continuously? A: Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the applicationâs initial design allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to⊠· Ensure the code is well commented and well documented; this makes changes easier for the developers. · Use rapid prototyping whenever possible; this will help customers feel sure of their requirements and minimize changes. · In the projectâs initial schedule, allow for some extra time to commensurate with probable changes. · Move new requirements to a âPhase 2âČ version of an application and use the original requirements for the âPhase 1âČ version. · Negotiate to allow only easily implemented new requirements into the project; move more difficult, new requirements into future versions of the application. · Ensure customers and management understands scheduling impacts, inherent risks and costs of significant requirements changes. Then let management or the customers decide if the changes are warranted; after all, thatâs their job. · Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes. · Design some flexibility into automated test scripts; · Focus initial automated testing on application aspects that are most likely to remain unchanged; · Devote appropriate effort to risk analysis of changes, in order to minimize regression-testing needs; · Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test cases, or set up only higher-level generic-type test plans; · Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails.
- 206. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Q29. What if the application has functionality that wasnât in the requirements? A: It may take serious effort to determine if an application has significant unexpected or hidden functionality, which it would indicate deeper problems in the software development process. If the functionality isnât necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer. If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only affects areas, such as minor improvements in the user interface, it may not be a significant risk. Q30. How can software QA processes be implemented without stifling productivity? A: Implement QA processes slowly over time. Use consensus to reach agreement on processes and adjust and experiment as an organization grows and matures. Productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection. Panics and burnout will decrease and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings and promote training as part of the QA process. However, no one, especially talented technical types, like bureaucracy and in the short run things may slow down a bit. A typical scenario would be that more days of planning and development will be needed, but less time will be required for late-night bug fixing and calming of irate customers. Q34. What is software quality assurance? A: Software Quality Assurance, when Rob Davis does it, is oriented to *prevention*. It involves the entire software development process. Prevention is monitoring and improving the process, making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with. Software Testing, when performed by Rob Davis, is also oriented to *detection*. Testing involves the operation of a system or application under controlled conditions and evaluating the results. Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes theyâre the combined responsibility of one group or individual. Also common are project teams, which include a mix of test engineers, testers and developers who work closely together, with overall QA processes monitored by project managers. It depends on what best fits your organizationâs size and business structure. Rob Davis can provide QA and/or Software QA. This document details some aspects of how he can provide software testing/QA service. Q35. What is quality assurance? A: Quality Assurance ensures all parties concerned with the project adhere to the process and procedures, standards and templates and test readiness reviews.
- 207. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Rob Davisâ QA service depends on the customers and projects. A lot will depend on team leads or managers, feedback to developers and communications among customers, managers, developersâ test engineers and testers. Q36. Process and procedures â why follow them? A: Detailed and well-written processes and procedures ensure the correct steps are being executed to facilitate a successful completion of a task. They also ensure a process is repeatable. Once Rob Davis has learned and reviewed customerâs business processes and procedures, he will follow them. He will also recommend improvements and/or additions. Q37. Standards and templates â what is supposed to be in a document? A: 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 Rob Davis has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions. Q38. What are the different levels of testing? A: Rob Davis has expertise in testing at all testing levels listed below. At each test level, he documents the results. Each level of testing is either considered black or white box testing. Q39. What is black box testing? A: Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing are based on requirements and functionality. Q40. What is white box testing? A: White box testing is based on knowledge of the internal logic of an applicationâs code. Tests are based on coverage of code statements, branches, paths and conditions. Q41. What is unit testing? A: Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Unit testing is performed after the expected test results are met or differences are explainable/acceptable. Q42. What is parallel/audit testing? A: Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly. Q43. What is functional testing? A: Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers *should* perform functional testing. Q44. What is usability testing?
- 208. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ A: Usability testing is testing for âuser-friendlinessâ. Clearly this is subjective and depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions and other techniques can be used. Programmers and developers are usually not appropriate as usability testers. Q45. What is incremental integration testing? A: Incremental integration testing is continuous testing of an application as new functionality is recommended. This may require that various aspects of an applicationâs functionality are independent enough to work separately, before all parts of the program are completed, or that test drivers are developed as needed. This type of testing may be performed by programmers, software engineers, or test engineers. Q46. What is integration testing? A: 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. Q47. What is system testing? A: System testing is black box testing, performed by the Test Team, and at the start of the system testing the complete system is configured in a controlled environment. The purpose of system testing is to validate an applicationâs accuracy and completeness in performing the functions as designed. System testing simulates real life scenarios that occur in a âsimulated real lifeâ test environment and test all functions of the system that are required in real life. System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input. Upon completion of integration testing, system testing is started. Before system testing, all unit and integration test results are reviewed by Software QA to ensure all problems have been resolved. For a higher level of testing it is important to understand unresolved problems that originate at unit and integration test levels. You CAN learn system testing, with little or no outside help. Get CAN get free information. Click on a link! Q48. What is end-to-end testing? A: Similar to system testing, the *macro* end of the test scale is testing a complete application in a situation that mimics real world use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system. Q49. What is regression testing? A: The objective of regression testing is to ensure the software remains intact. A baseline set of data and scripts is maintained and executed to verify changes introduced during the release have not
- 209. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ âundoneâ any previous code. Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level. Q50. What is sanity testing? A: Sanity testing is performed whenever cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc. Q51. What is performance testing? A: Although performance testing is described as a part of system testing, it can be regarded as a distinct level of testing. Performance testing verifies loads, volumes and response times, as defined by requirements. Q52. What is load testing? A: Load testing is testing an application under heavy loads, such as the testing of a web site under a range of loads to determine at what point the system response time will degrade or fail. Q53. What is installation testing? A: Installation testing is testing full, partial, upgrade, or install/uninstall processes. The installation test for a release is conducted with the objective of demonstrating production readiness. This test includes the inventory of configuration items, performed by the applicationâs System Administration, the evaluation of data readiness, and dynamic tests focused on basic system functionality. When necessary, a sanity test is performed, following installation testing. Q54. What is security/penetration testing? A: Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques. Q55. What is recovery/error testing? A: Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems. Q56. What is compatibility testing? A: Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network environment. Q57. What is comparison testing? A: Comparison testing is testing that compares software weaknesses and strengths to those of competitorsâ products. Q58. What is acceptance testing?
- 210. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ A: Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production. The acceptance test is the responsibility of the client/customer or project manager; however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria. Q59. What is alpha testing? A: Alpha testing is testing of an application when development is nearing completion. Minor design changes can still be made as a result of alpha testing. Alpha testing is typically performed by a group that is independent of the design team, but still within the company, e.g. in-house software test engineers, or software QA engineers. Q60. What is beta testing? A: Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers. Q61. What testing roles are standard on most testing projects? A: Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Lead, Test/QA Manager, System Administrator, Database Administrator, Technical Analyst, Test Build Manager and Test Configuration Manager. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager. You CAN get a job in testing. Click on a link! Q62. What is a Test/QA Team Lead? A: The Test/QA Team Lead coordinates the testing activity, communicates testing status to management and manages the test team. Q63. 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. We also⊠· Speed up the work of the development staff; · Reduce your organizationâs risk of legal liability; · Give you the evidence that your software is correct and operates properly; · Improve problem tracking and reporting; · Maximize the value of your software; · Maximize the value of the devices that use it; · Assure the successful launch of your product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down;
- 211. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ · Help the work of your development staff, so the development team can devote its time to build up your product; · Promote continual improvement; · Provide documentation required by FDA, FAA, other regulatory agencies and your customers; · Save money by discovering defects âearlyâ in the design process, before failures occur in production, or in the field; · Save the reputation of your company by discovering bugs and design flaws; before bugs and design flaws damage the reputation of your company. Q64. What is a Test Build Manager? A: Test Build Managers deliver current software versions to the test environment, install the applicationâs software and apply software patches, to the both application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Test Build Manager. Q65. What is a System Administrator? A: Test Build Managers, System Administrators, Database Administrators deliver current software versions to the test environment, install the applicationâs software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a System Administrator. Q66. What is a Database Administrator? A: Test Build Managers, System Administrators and Database Administrators deliver current software versions to the test environment, install the applicationâs software and apply software patches, to the both application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Database Administrator. Q67. What is a Technical Analyst? A: Technical Analysts perform test assessments and validate system/functional test requirements. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Technical Analyst. Q68. What is a Test Configuration Manager? A: Test Configuration Managers maintain test environments, scripts, software and test data. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Test Configuration Manager. Q69. What is a test schedule? A: The test schedule is a schedule that identifies all tasks required for a successful testing effort, a schedule of all test activities and resource requirements.
- 212. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Q70. What is software testing methodology? A: One software testing methodology is the use a three step process of⊠1. Creating a test strategy; 2. Creating a test plan/design; and 3. Executing tests. This methodology can be used and molded to your organizationâs needs. Rob Davis believes that using this methodology is important in the development and in ongoing maintenance of his customersâ applications. Q71. What is the general testing process? A: The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests. Q72. How do you create a test strategy? A: The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, and the test environment, a list of related tasks, pass/fail criteria and risk assessment. Inputs for this process: · A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data. · A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules. · Testing methodology. This is based on known standards. · Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents. · Requirements that the system can not provide, e.g. system limitations. Outputs for this process: · An approved and signed off test strategy document, test plan, including test cases. · Testing issues requiring resolution. Usually this requires additional negotiation at the project management level. Q73. How do you create a test plan/design? A: Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speakingâŠ
- 213. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application. Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases. It is the test team that, with assistance of developers and clients, develops test cases and scenarios for integration and system testing. Test scenarios are executed through the use of test procedures or scripts. Test procedures or scripts define a series of steps necessary to perform one or more test scenarios. Test procedures or scripts include the specific data that will be used for testing the process or transaction. Test procedures or scripts may cover multiple test scenarios. Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope. Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment. Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing. A pretest meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release. Inputs for this process: Approved Test Strategy Document. Test tools, or automated test tools, if applicable. Previously developed scripts, if applicable. Test documentation problems uncovered as a result of testing. A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code and software complexity data. Outputs for this process: Approved documents of test scenarios, test cases, test conditions and test data. Reports of software design issues, given to software developers for correction. Q74. How do you execute tests? A: Execution of tests is completed by following the test documents in a methodical manner. As each test procedure is performed, an entry is recorded in a test execution log to note the execution of the procedure and whether or not the test procedure uncovered any defects. Checkpoint meetings are
- 214. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ held throughout the execution phase. Checkpoint meetings are held daily, if required, to address and discuss testing issues, status and activities. The output from the execution of test procedures is known as test results. Test results are evaluated by test engineers to determine whether the expected results have been obtained. All discrepancies/anomalies are logged and discussed with the software team lead, hardware test lead, programmers, software engineers and documented for further investigation and resolution. Every company has a different process for logging and reporting bugs/defects uncovered during testing. A pass/fail criteria is used to determine the severity of a problem, and results are recorded in a test summary report. The severity of a problem, found during system testing, is defined in accordance to the customerâs risk assessment and recorded in their selected tracking tool. Proposed fixes are delivered to the testing environment, based on the severity of the problem. Fixes are regression tested and flawless fixes are migrated to a new baseline. Following completion of the test, members of the test team prepare a summary report. The summary report is reviewed by the Project Manager, Software QA Manager and/or Test Team Lead. After a particular level of testing has been certified, it is the responsibility of the Configuration Manager to coordinate the migration of the release software components to the next test level, as documented in the Configuration Management Plan. The software is only migrated to the production environment after the Project Managerâs formal acceptance. The test team reviews test document problems identified during testing, and update documents where appropriate. Inputs for this process: Approved test documents, e.g. Test Plan, Test Cases, Test Procedures. Test tools, including automated test tools, if applicable. Developed scripts. Changes to the design, i.e. Change Request Documents. Test data. Availability of the test team and project team. General and Detailed Design Documents, i.e. Requirements Document, Software Design Document. A software that has been migrated to the test environment, i.e. unit tested code, via the Configuration/Build Manager. Test Readiness Document. Document Updates. Outputs for this process: Log and summary of the test results. Usually this is part of the Test Report. This needs to be approved and signed-off with revised testing deliverables. Changes to the code, also known as test fixes.
- 215. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Test document problems uncovered as a result of testing. Examples are Requirements document and Design Document problems. Reports on software design issues, given to software developers for correction. Examples are bug reports on code issues. Formal record of test incidents, usually part of problem tracking. Base-lined package, also known as tested source and object code, ready for migration to the next level. Q75. 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. Q76. 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
- 216. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 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. It 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 denials of service tools. Q77. 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. You CAN learn load testing, with little or no outside help. Get CAN get free information. Click on a link! Q79. 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. You CAN learn testing, with little or no outside help. Get CAN get free information. Click on a link! Q80. 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. Q81. 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. Q82. 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. Q83. 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
- 217. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ there are no defects. You CAN learn software testing, with little or no outside help. Get CAN get free information. Click on a link! Q84. What is automated testing? A: Automated testing is a formally specified and controlled method of formal testing approach. Q85. 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 us, the software QA staff, for additional testing in an environment that is similar to the intended use. Q86. 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. Q87. 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. Q88. 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. You CAN learn clear box testing, with little or no outside help. Get CAN get free information. Click on a link! Q89. 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. Q90. What is ad hoc testing? A: Ad hoc testing is a testing approach; it is the least formal testing approach. 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.
- 218. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 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, or 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, or 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, or 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 purposes. 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!
- 219. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ 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. 40 Testing Interview Questions Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Interview Faq's, Manual Testing Basics | Leave a comment Whatâs Ad Hoc Testing ? A testing where the tester tries to break the software by randomly trying functionality of software. Whatâs the Accessibility Testing ? Testing that determines if software will be usable by people with disabilities. Whatâs the Alpha Testing ? The Alpha Testing is conducted at the developer sites and in a controlled environment by the end user of the software Whatâs the Beta Testing ? Testing the application after the installation at the client place. What is Component Testing ? Testing of individual software components (Unit Testing). Whatâs Compatibility Testing ? In Compatibility testing we can test that software is compatible with other elements of system. What is Concurrency Testing ? Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores. What is Conformance Testing ? The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard. What is Context Driven Testing ?
- 220. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ The context-driven school of software testing is flavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now. What is Data Driven Testing ? Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing. What is Conversion Testing ? Testing of programs or procedures used to convert data from existing systems for use in replacement systems. What is Dependency Testing ? Examines an applicationâs requirements for pre-existing software, initial states and configuration in order to maintain proper functionality. What is Depth Testing ? A test that exercises a feature of a product in full detail. What is Dynamic Testing ? Testing software through executing it. See also Static Testing. What is Endurance Testing ? Checks for memory leaks or other problems that may occur with prolonged execution. What is End-to-End testing ? Testing a complete application environment in a situation that mimics real- world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate. What is Exhaustive Testing ? Testing which covers all combinations of input values and preconditions for an element of the software under test. What is Gorilla Testing ? Testing one particular module, functionality heavily. What is Installation Testing ? Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.
- 221. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ What is Localization Testing ? This term refers to making software specifically designed for a specific locality. What is Loop Testing ? A white box testing technique that exercises program loops. What is Mutation Testing ? Mutation testing is a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (âbugsâ) and retesting with the original test data/cases to determine if the âbugsâ are detected. Proper implementation requires large computational resources What is Monkey Testing ? Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out. What is Positive Testing ? Testing aimed at showing software works. Also known as âtest to passâ. See also Negative Testing. What is Negative Testing ? Testing aimed at showing software does not work. Also known as âtest to failâ. See also Positive Testing. What is Path Testing ? Testing in which all paths in the program source code are tested at least once. What is Performance Testing ? Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as âLoad Testingâ. What is Ramp Testing ? Continuously raising an input signal until the system breaks down. What is Recovery Testing ? Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions. What is the Re-testing testing ? Retesting- Again testing the functionality of the application. What is the Regression testing ? Regression- Check that change in code have not effected the working functionality
- 222. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ What is Sanity Testing ? Brief test of major functional elements of a piece of software to determine if its basically operational. What is Scalability Testing ? Performance testing focused on ensuring the application under test gracefully handles increases in work load. What is Security Testing ? Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level. What is Stress Testing ? Stress testing is a form of testing that is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. What is Smoke Testing ? A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire. What is Soak Testing ? Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed. Whatâs the Usability testing ? Usability testing is for user friendliness. Whatâs the User acceptance testing ? User acceptance testing is determining if software is satisfactory to an end-user or customer. Whatâs the Volume Testing ? We can perform the Volume testing, where the system is subjected to large volume of data
- 223. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ As a manager what process did you adopt to define testing policy? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Leave a comment Below are the important steps to define testing policy in general. But it can change according to how you implemented in your organization. Letâs understand in detail the below steps of implementing a testing policy in an organization. Definition: â The first thing any organization need to do is define one unique definition for testing within organization. So that every one is on the same mind set. How to achieve: â How are we going to achieve our objective?. Is there going to be a testing committee, will there be compulsory test plans which needs to be executed etc etc. Evaluate: â After testing is implemented in project how do we evaluate the same. Are we going to derive metrics of defect per phase, per programmer etc etc. Finally itâs important to let know every one how testing has added value to the project. Standards : â Finally what are the standards we want to achieve by testing. For instance we can define saying that more than 20 defects per KLOC will be considered below standard and code review should be done for the same. Figure: Does Increase in testing always mean good to the project? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Leave a comment No increase in testing does not mean always good for the product, company or the project. In real test scenarios from 100% test plans only 20% test plans are critical from business angle. Running those critical test plans will assure that the testing is proper rather than running the full 100% test plans again and again. Below is the graph which explains the impact of under testing and over testing. If you under test a system your number of defect will increase, but on the contrary if you over test a system your cost of testing will increase. Even if your defects come down your cost of testing has shooted up. What is the difference between Verification and Validation? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Leave a comment
- 224. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ Verification is a review with out actually executing the process while validation is checking the product with actual execution. For instance code review and syntax check is verification while actually running the product and checking the results is validation. What is the difference between Defect and Failure? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Leave a comment Define Defect? Defect is a variance from a normal flow When a defect reaches the end customer it is termed as failure and if the defect is detected internally and resolved itâs called as a defect. There are mainly three categories of defect:- Wrong: â The requirements have been implemented incorrectly. This defect is a variance from the given specification. Missing: â There is a requirement given by the customer and is not done. This is a variance from specification, an indication that the specification was not implemented, or a requirement of the customer was noted properly. Extra: â A requirement incorporated into the product that was not given by the end customer. This is always a variance from specifications, but may be an attribute desired by the user of the product. However, it is considered a defect because itâs a variance from the existing requirements. Figure: What is the difference between white box, black box and gray box testing?? Posted: 30/05/2009 | Author: Ganesh Raman | Filed under: Manual Testing Basics | Leave a comment Black box testing is a testing strategy which is based solely on the requirements and specifications. Black box testing requires no knowledge of the internal paths, structure, or implementation of the software under test. White box testing is a testing strategy which is based on the internal paths, code structure, and implementation of the software under test. White box testing generally requires detailed programming skills.
- 225. https://softwaretestinginterviewfaqs.wordpress.com/category/manual-testing-basics/ There is one more type of testing is called gray box testing. In this we look into the âboxâ under test just long enough to understand how it has been implemented. Then we close up the box and use our knowledge to choose more effective black box tests. Below figure shows how both the types of testers view an accounting application during testing. In case of black box tester they view in terms of pure accounting application. While in terms of White box testing the tester know about the internal structure of the application. In most scenarios white box testing is done by developers as they know the internals of the application. In Black box testing we check the overall functionality of the application while in white box we do code reviews , view the architecture , remove bad code practices and component level testing.