Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1


Ratings: (0)|Views: 401|Likes:
Published by api-3822363

More info:

Published by: api-3822363 on Oct 18, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





Testing Document
Software Testing Engineer
Black box
Black-box Testing treats the system as a "black-box", so it doesn't use knowledge of
the internal structure explicitly. It is usually described as focusing on testing
functional requirements. Synonyms for black box include: behavioral, functional,
opaque-box, and closed-box. Black Box Testing is testing without knowledge of the

internal workings of the item being tested. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but has no idea how the program actually arrives at those outputs

It is because of this that black box testing can be considered testing with respect to the specifications; no other knowledge of the program is necessary. For this reason, the tester and the programmer can be independent of one another, avoiding programmer bias toward his own work.

The so-called ``functionality testing'' is central to most testing exercises. Its primary objective is to assess whether the program does what it is supposed to do, i.e. it should meet user specified requirements. There are different approaches to functionality testing. One is the testing of each program feature or function in sequence. The other is to test module by module, i.e. each function where it is called first.

More effective on larger units of code than glass box testing
Tester needs no knowledge of implementation, including specific programming
Tester and programmer are independent of each other
Tests are done from a user's point of view
Test cases can be designed as soon as the specifications are complete
Only a small number of possible inputs can actually be tested, to test every
possible input stream would take nearly forever
Without clear and concise specifications, test cases are hard to design
There may be unnecessary repetition of test inputs if the tester is not
informed of test cases the programmer has already tried
May leave many program paths untested
Cannot be directed toward specific segments of code which may be very
complex (and therefore more error prone)
Most testing related research has been directed toward glass box testing
1 of 26
Testing Document
Software Testing Engineer
Techniques in Black Box
Black box testing attempts to derive sets of inputs that will fully exercise all the
functional requirements of a system. It is not analternative to white box
testing. This type of testing attempts to find errors in the following categories:
Incorrect or missing functions,
Interface errors,
Errors in data structures or external database access,
Performance errors, and
Initialization and termination errors.
For inputranges bounded bya andb, test cases should include valuesa and
b and just above and just below aand bre sp e ct i ve l y.

If an input condition specifies a number of values, test cases should be developed to exercise the minimum and maximum numbers and values just above and below these limits.

Apply guidelines 1 and 2 to the output.
If internal data structures have prescribed boundaries, a test case should be
designed to exercise the data structure at its boundary.
Cause-Effect Graphing Techniques
Cause-effect graphing is a technique that provides a concise representation of logical
conditions and corresponding actions. There are four steps:
Causes (input conditions) and effects (actions) are listed for a module and an
identifier is assigned to each.
A cause-effect graph is developed.
The graph is converted to a decision table.
Decision table rules are converted to test cases.
Black Box Manual Testing

SQA team members upon receipt of the Development builds, walk through the GUI and either update existing hard copy of the product Roadmaps, or create new hard copy. This is then passed on to the Tools engineer to automate for new builds and regression testing. Defects are entered into the bugs tracking database, for investigation and resolution.

Features & Functions - SQA test engineers, swearing on the team definition,

exercise the product features and functions accordingly. Defects in feature/function capability are entered into the defect tracking system and are communicated to the team. Features are expected to perform as expected and their functionality should be oriented toward ease of use and clarity of objective.

2 of 26
Testing Document
Software Testing Engineer
Tests are planned around new features and regression tests are exercised to validate

Existing features and functions are enabled and performing in a manner consistent with prior releases. SQA using the exploratory testing method manually tests and then plans more exhaustive testing and automation. Regression tests are exercised which consist of using developed test cases against the product to validate field input, boundary conditions and so on... Automated tests developed for prior releases are also used for regression testing.

Installation - Product is installed on each of the supported operating systems in

either default, flat file configuration, or with one of the supported databases. Every operating system and database, supported by the product, is tested, though not in all possible combinations. SQA is committed to executing, during the development life cycle, the combinations most frequently used by the customers. Clean and upgrade installations are the minimum requirements.

Documentation - All documentation, which is reviewed by Development prior to
Alpha, is reviewed by the SQA

Team prior to Beta. SQA not only verifies technical accuracy, clarity and completeness, they also provide editorial input on consistency, style and typographical errors.

Functionality Testing
Functional testing is validating an application or web site, conforms to its
specifications and correctly performs all its required functions.

This entails a series of tests, which perform a feature-by-feature validation of behavior, using a wide range of normal and erroneous input data. This can involve testing of the product's user interface, database management, security, installation, networking, etc

The purpose of functionality testing is to reveal issues concerning the product\u2019s
functionality and conformance to user requirement.

The first step in functionality testing is to become familiar with the program itself, and with the program\u2019s desired behavior. For this the tester should have clear idea about the documentation such as the program\u2019s functional specification or user manual. Once a program\u2019s expected functionality has been defined, test cases or test procedures can be created that exercise the program in order to test actual behavior against expected behavior. Testing the program\u2019s functionality then involves the execution of any test cases that have been created. Certain portions of a functionality testing effort can also be automated, depends on several factors, and should be discussed with a qualified engineer.

1. Range checking- minimum and maximum values should not be exceeded

(invalid values should not be accepted)
2. Check whether numeric fields accept only numeric values
3. Check \u2018online Help\u2019 feature (including buttons to open Help feature)
4. Check \u2018Print\u2019 feature

3 of 26

Activity (16)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
vbe2004 liked this
namratavohra18 liked this
RentzRo liked this
eshu0123456789 liked this
kprgroup liked this
preetu1 liked this
swetha_ramya liked this
learner2k liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->