Black box testing Internal system design is not considered in this type of testing.

Tests are
based on requirements and functionality.
White box testing This testing is based on knowledge of the internal logic of an applications
code. Also known as Glass box Testing. Internal software and code working should be known for
this type of testing. Tests are based on coverage of code statements, branches, paths, conditions.
Unit testing Testing of individual software components or modules. Typically done by the
programmer and not by testers, as it requires detailed knowledge of the internal program design
and code. may require developing test driver modules or test harnesses.
Incremental integration tests Bottom up approach for testing i.e continuous testing of an
application as new functionality is added; Application functionality and modules should be
independent enough to test separately. Done by programmers or by testers.
Integration testing Testing of integrated modules to verify combined functionality after
integration. Modules are typically code modules, individual applications, client and server
applications on a network, etc. This type of testing is especially relevant to client/server and
distributed systems.
Functional testing This type of testing ignores the internal parts and focus on the output is
as per requirement or not. Black-box type testing geared to functional requirements of an
application.
System testing Entire system is tested as per the requirements. Black-box type testing that is
based on overall requirements specifications, covers all combined parts of a system.
End-to-end testing Similar to system testing, involves testing of 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.
Sanity testing Testing to determine if a new software version is performing well enough to
accept it for a major testing effort. If application is crashing for initial use then system is not
stable enough for further testing and build or application is assigned to fix.
Regression testing Testing the application as a whole for the modification in any module or
functionality. Difficult to cover all the system in regression testing so typically automation tools
are used for these testing types.
Acceptance testing -Normally this type of testing is done to verify if system meets the
customer specified requirements. User or customer do this testing to determine whether to
accept application.

Load testing Its a performance testing to check system behavior under load. Testing an
application under heavy loads, such as testing of a web site under a range of loads to determine at
what point the systems response time degrades or fails.
Stress testing System is stressed beyond its specifications to check how and when it fails.
Performed under heavy load like putting large number beyond storage capacity, complex
database queries, continuous input to system or database load.
Performance testing Term often used interchangeably with stress and load testing. To
check whether system meets performance requirements. Used different performance and load
tools to do this.
Usability testing User-friendliness check. Application flow is tested, Can new user
understand the application easily, Proper help documented whenever user stuck at any point.
Basically system navigation is checked in this testing.
Install/uninstall testing Tested for full, partial, or upgrade install/uninstall processes on
different operating systems under different hardware, software environment.
For More practice you can also automated software for different platform,
List of GUI testing tools
Name

Testing system requirement

QF-Test
Ranorex

Windows, Linux
Windows, iOS, Android

Rational Functional

Windows, Linux

System under test requirement

Java/Swing/SWT/Eclipse, JavaFX
web, GUI, mobile
Windows, Swing, .NET

Tester
For more practise tools visit this link : List of GUI testing tools

To be a great software tester, you need to develop following 16 characteristics

within you:
1. Be Skeptical Dont believe that the build given by developers is bug free or quality outcome.
Question everything. Accept the build only if you test and find it defect free. Dont believe anyone
whatever be the designation they hold, just apply your knowledge and try to find errors. You need
to follow this till the last testing cycle.
2. Dont Compromise on Quality Dont compromise after certain testing stages. There is no
limit for testing until you produce a quality product. Quality is the word made by software testers

to achieve more effective testing. Compromising at any level leads to defective product, so dont
do that at any situation.
3.Ensure End User Satisfaction Always think what can make end user happy. How they can
use the product with ease. Dont stop by testing the standard requirements. End user can be
happy only when you provide an error free product.
4. Think from Users Perspective Every product is developed for customers. Customers may
or may not be technical persons. If you dont consider the scenarios from their perspective you
will miss many important bugs. So put yourself in their shoes. Know your end users first. Their
age, education even the location can matter most while using the product. Make sure to prepare
your test scenarios and test data accordingly. After all project is said to be successful only if end
user is able to use the application successfully.
5. Prioritize Tests First identify important tests and then prioritize execution based on test
importance. Never ever execute test cases sequentially without deciding priority. This will ensure
all your important test cases get executed early and you wont cut down on these at the last stage
of release cycle due to time pressure. Also consider the defect history while estimating test
efforts. In most cases defect count at the beginning is more and goes on reducing at the end of the
test cycle.
6. Never Promise 100% Coverage Saying 100% coverage on paper is easy but practically it is
impossible. So never promise to anyone including clients about total test coverage. In business
there is a philosophy Under promise and over deliver. So dont goal for 100% coverage but
focus on quality of your tests.
7. Be Open to Suggestions Listen to everyone even though you are an authority on the project
having in depth project knowledge. There is always scope for improvements and getting
suggestions from fellow software testers is a good idea. Everyones feedback to improve the
quality of the project would certainly help to release a bug free software.
8. Start Early Dont wait until you get your first build for testing. Start analyzing requirements,
preparing test cases, test plan and test strategy documents in early design phase. Starting early to
test helps to visualize complete project scope and hence planning can be done accordingly. Most
of the defects can be detected in early design and analysis phase saving huge time and money.
Early requirement analysis will also help you to question the design decisions.
9. Identify and Manage Risks Risks are associated with every project. Risk management is a
three step process. Risk identification, analysis and mitigation. Incorporate risk driven testing
process. Priorities software testing based on risk evaluation.
10. Do Market Research Dont think that your responsibility is just to validate software
against the set of requirements. Be proactive, do your product market research and provide
suggestions to improve it. This research will also help you understand your product and its
market.
11. Develop Good Analyzing Skill This is must for requirement analysis but even further this
could be helpful for understanding customer feedback while defining test strategy. Question
everything around you. This will trigger the analysis process and it will help you resolve many
complex problems.
12. Focus on Negative Side as Well Testers should have test to break attitude. Concentrating
on only positive side will almost certainly create many security issues in your application. You
should be hacker of your project to keep other hackers away from it. Negative testing is equally
important. So cover a good chunk of your test cases based on negative scenarios.

13. Be a Good Judge of Your Product Judge usually thinks whether it is right or wrong.
Judge listens to both the sides. Same is applicable for testing. As a software tester if you think
something as right, try to prove it why it is not wrong and then only accept it. You must have
valid reason for all your decisions.
14. Learn to Negotiate Testers have to negotiate with everyone in all stages of project life
cycle. Especially negotiation with developers is more important. Developers can do anything to
prove that their code is correct and the defect logged by testers is not valid. It requires great skills
to convince developers about the defect and get it resolved. Though some software testers think
this is not our task but explaining the true impact of any issue is very helpful for developers to
quickly understand the overall scenario and its implications. This requires years of practice but
once you learn to negotiate you will gain more respect.
15. Stop the Blame Game Its common to blame others for any defects which are not caught in
testing. This is even more common when the testers responsibilities are not defined concretely.
But in any situation never blame anyone. If an error occurs, first try to resolve it rather than
finding someone to blame. As a human everybody makes mistake, so try to avoid blaming others.
Work as a team to build team spirit.
16. Finally, Be a Good Observer Observe things happening around you. Keep track of all
major and minor things on your project. Observe the way of developing the code, types of
testing and its objective. Observe and understand test progress and make necessary changes if it
is off the track in terms of schedule or testing activities. This skill will essential help you to keep
yourself updated and ready with course of action for any situation.
Try to implement above 16 steps in your day-to-day testing activities. Practicing these steps
will make you to excel in testing filed. Remember testing is not only a challenging job but it
is a creative job too. Love your job and you will become the leader in your filed!

What is your reasoning based on?

As I said, we need to have some evaluation rules. Such rules typically involve an expectation and
a decision criteria. Although sometimes its enough to point to problematic inconsistencies.
Sources of expectations might be

[Doh!] Business requirements (never come absolutely detailed, often become

quickly outdated, typically contain internal inconsistencies) - written and said,
emailed and sketched on a whiteboard.
Specification (sometimes this term is used interchangeably with business reqs; more
commonly means more thorough version of them, enriched with details about the
technologies and implementation) - written and said, emailed and sketched on a
whiteboard.

User manuals, guides, training materials, and so on. Obviously, theyre intended to
tell the customers how to use and what to expect from the product - which is worth
to explore with testing.

Other claims - might be marketing materials, a promotion posted by your company,

even promises publicly made by the CEO last month.

This is not a complete list, just some general and the most common sources.
Lets get some action!
(Lets assume that the program is intended for these arithmetic calculations - add, subtract,
divide, multiply. Knowing the purpose of the product is critically important! What if this
program is intended for training in black box testing? - Then each bug would be actually a
valuable feature to discover.)
Below you can see a mindmap of test ideas I quickly put together (this is not a complete list, by
the way). Since theres no actual app to explore some of the ideas are in a form of general guesses.
While testing, I use just learned information to generate new test ideas and to explore further.
(Click the image to see full size)

These test ideas would turn up as in the following sample:

Try natural, integer, and floating point inputs to explore the format of supported
values.
o Note: you may have a requirement explicitly stating the supported format,
but that doesnt necessarily mean that the app wont do something odd when
given other formats. So test it out!

Explore the boundaries of the numbers. 255? 65535? Or 2147483647? Dont forget
the lower boundary, whether its zero or 2147483647.

Of course, if youre dealing with Real number format make sure to try the respective
boundary numbers.
Speaking of zero. Whenever and wherever a function does any calculations, make
sure to try it for each input. Zero is a special case, and division by zero is a classic
error.

It matters not only what data you input but how you do that. So try
o Using keyboard and mouse
o

Typing and pasting

Editing existing values and removing the content of the fields

Input in different order

Input with interruptions and repetitions

Also explore for any other behavior, and, when discovered, investigate it.

Where to stop?
Even with this simple example were ending up with a considerably high number of tests. It
seems like testing wont ever run of ideas. And this is normal.
To manage your black box testing, you need to employ set of other techniques:

Prioritize your coverage by the importance of the functions you test

Prioritize your coverage by the importance of the problems you target

Prioritize your coverage by the likelihood of the potential risks

Time box your testing sessions and track the budget of your available time

I feel like the answer went pretty far but I also feel that theres so much to tell.
I only want to recommend one of the best online courses on Black Box Software Testing. You can
self-train for free (all materials are downloadable) or sign up for a class for a very affordable
price.

What is black box testing?

Lets take a look at this

(image credit: samples at Arithmetic Operations on two numbers)

This is a box that takes some input and gives you some output. You dont know
whats going on inside.
In fact, you dont even know all the inputs and outputs of your black box, your
system under test. (image credit: Cem Kaner, The Ongoing Revolution in Software
Testing)

Interact, Observe, Evaluate

Because we dont have a direct knowledge or control over whats inside we can only
try to interact with it and observe the behavior.
As we gather our observations, we also need some evaluation rule(s) to make a
judgment - is there a potential problem?
Note that a perception of a problem will be different for different people. Therefore
testing, being a service, must not rely solely on the testers perception of the problem.
What is your reasoning based on?
As I said, we need to have some evaluation rules. Such rules typically involve an
expectation and a decision criteria. Although sometimes its enough to point to
problematic inconsistencies.
Sources of expectations might be

[Doh!] Business requirements (never come absolutely detailed, often

become quickly outdated, typically contain internal inconsistencies) written and said, emailed and sketched on a whiteboard.
Specification (sometimes this term is used interchangeably with business
reqs; more commonly means more thorough version of them, enriched
with details about the technologies and implementation) - written and
said, emailed and sketched on a whiteboard.
User manuals, guides, training materials, and so on. Obviously, theyre
intended to tell the customers how to use and what to expect from the
product - which is worth to explore with testing.
Other claims - might be marketing materials, a promotion posted by your
company, even promises publicly made by the CEO last month.

This is not a complete list, just some general and the most common sources.
Lets get some action!
(Lets assume that the program is intended for these arithmetic calculations - add,
subtract, divide, multiply. Knowing the purpose of the product
is critically important! What if this program is intended for training in black box
testing? - Then each bug would be actually a valuable feature to discover.)
Below you can see a mindmap of test ideas I quickly put together (this is not a
complete list, by the way). Since theres no actual app to explore some of the ideas
are in a form of general guesses. While testing, I use just learned information to
generate new test ideas and to explore further.
(Click the image to see full size)

These test ideas would turn up as in the following sample:

Try natural, integer, and floating point inputs to explore the format of
supported values.
o Note: you may have a requirement explicitly stating the supported
format, but that doesnt necessarily mean that the app wont do
something odd when given other formats. So test it out!
Explore the boundaries of the numbers. 255? 65535? Or 2147483647?
Dont forget the lower boundary, whether its zero or 2147483647.
Of course, if youre dealing with Real number format make sure to try the
respective boundary numbers.
Speaking of zero. Whenever and wherever a function does any
calculations, make sure to try it for each input. Zero is a special case, and
division by zero is a classic error.
It matters not only what data you input but how you do that. So try
o Using keyboard and mouse
o Typing and pasting

o Editing existing values and removing the content of the fields

o Input in different order
o Input with interruptions and repetitions
Also explore for any other behavior, and, when discovered, investigate it.
Where to stop?
Even with this simple example were ending up with a considerably high number of
tests. It seems like testing wont ever run of ideas. And this is normal.
To manage your black box testing, you need to employ set of other techniques:

Prioritize your coverage by the importance of the functions you test

Prioritize your coverage by the importance of the problems you target
Prioritize your coverage by the likelihood of the potential risks
Time box your testing sessions and track the budget of your available time

If you enjoyed this answer on Black Box testing, you may like my answer on White
Boxtesting with the same sample application: Albert Gareev's answer to What is
white box testing?
Black box testing is a software testing techniques in which functionality of the
software under test is tested without looking at the internal code structure,
implementation details and knowledge of internal paths of the software.This type of
testing is based entirely on the software requirements and specifications.
Black box testing Steps:
1. Initially requirements and specifications of the system are examined.
2. Tester chooses valid inputs to check whether SUT processes them
correctly .
3. Tester determines expected outputs for all those inputs.
4. Software tester constructs test cases with the selected inputs.
5. The test cases are executed.
6. Software tester compares the actual outputs with the expected outputs.
7. Defects if any are fixed and re-tested.
We provides the best Manual & Automated Software Testing Service.
Black Box Testing is also known as functional testing. Well it is software
testingtechnique whereby the tester doesnt know the internal workings of the item
being tested. It means that in a black box test on a software design the tester only
knows the inputs and what the expected results should be. Software tester doesnt
ever inspect the programming code and doesnt require any further knowledge of the
program other than its specifications.
There are some benefits of this kind of software testing:

The test is done from the viewpoint of the user, not the designer
The tester doesnt require knowledge of any special programming
languages

The test is impartial because the designer and the tester are independent
of each other
Test cases can be designed as soon as the specifications are complete
There are some disadvantages of this kind of testing:

The Test Cases are complex to design

The test can be redundant if the software designer has already run a Test
Case
It is unreal to test every possible input stream; the reason is it would take a lot of
time; consequently, many program paths go unchecked.
Black-box testing is a method of software testing that examines the functionality of
an application without peering into its internal structures or workings.
This method of test can be applied to virtually every level of software testing: unit,
integration, system and acceptance.
Black Box Testing, also known as Behavioral Testing, is a Software testing method in
which the internal structure/ design/ implementation of the item being tested is not
known to the tester.
These tests can be functional or non-functional, though usually functional.
Example:A tester, without knowledge of the internal structures of a website, tests the web
pages by using a browser; providing inputs (clicks, keystrokes) and verifying the
outputs against the expected outcome.
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
Tests are done from a users point of view and will help in exposing
discrepancies in the specifications.
Tester need not know programming languages or how the software has
been implemented.
Tests can be conducted by a body independent from the developers,
allowing for an objective perspective and the avoidance of developer-bias.
Test cases can be designed as soon as the 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

Only a small number of possible inputs can be tested and many program
paths will be left untested.
Without clear specifications, which are the situation in many projects,
test cases will be difficult to design.
Tests can be redundant if the software designer/ developer has already
run a test case.
Ever wondered why a soothsayer closes the eyes when foretelling events?
So is almost the case in Black Box Testing.
For further information, feel free to drop us a line anytime
at support@qltech.com.au or Tweet us: @QLTechAustralia. You can also visit us QL
Tech or follow our blog for recent tech-tips,guides and tutorials!
Functional testing (also known as black-box testing) is the process of verifying that a
system or system component adheres to the specification that defines its
requirements. Functional testing can be performed at the system level or the unit
level. To perform functional testing, you typically create a set of input/outcome
relationships that verify whether each specification requirement is implemented
correctly. At least one test case should be created for each entry in the specification
document; preferably, these test cases should test the various boundary conditions
for each entry. After the test suite is ready, you execute the test cases and verify
whether the correct outcomes are produced.
For more information about black box testing I would check out this link
(http://www.wrox.com/WileyCDA/Sec...) as well as Parasofts website by clicking on
the link below. (Disclaimer I work for Parasoft)
Blackbox testing deals primarily with front-end tests of the system's functionality.
The user conducting the test may use test cases, wherein several tasks are done with
the system UI and are validated against expected results. These tests has no reference
to backend components such as : source code, database services and underlying
system architecture
Black Box Testing, also known as Behavior Testing, is an application testing
strategy the interior structure/ design/ execution of the item being examined is not
known to the specialist.
Read more Update for Testing;http://crbtech.in/Testing
Black-box testing examines the functionality of an application without knowing its
internal structures or workings. Most common type of black-box testing is functional
testing. A simple example would be testing the login page of a web application - you
can test whether a user can login or not using valid credentials without any
knowledge of how the code is written, how the database is set up, etc.
Black box testing is the Software testing method which is used to test the software
without knowing the internal structure of code or program.
Carried out by testers
Implementation Knowledge is not required
Programming Knowledge is not required

Testing is applicable on higher levels of testing like System Testing,

Acceptance testing.
Means functional test or external testing.

Black Box testing is primarily concentrated on the functionality of the system under
test. The main aim of this testing to check on what functionality is performing by
the system under test. Black Box testing can be started based on Requirement
Specifications documents. The Functional testing, Behavior testing, Close box testing
is carried out under Black Box testing, so there is no required of the programming
knowledge.
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 not 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. For this testing, test groups are often used, "Test groups are
sometimes called professional idiots...people who are good at designing incorrect
data." 1 Also, do to the nature of black box testing, the test planning can begin as
soon as the specifications are written. The opposite of this would be glass box testing,
where test data are derived from direct examination of the code to be tested. For
glass box testing, the test cases cannot be determined until the code has actually been
written. Both of these testing techniques have advantages and disadvantages, but
when combined, they help to ensure thorough testing of the product.
Advantages of Black Box Testing
more effective on larger units of code than glass box testing
tester needs no knowledge of implementation, including specific programming
languages
tester and programmer are independent of each other
tests are done from a user's point of view
will help to expose any ambiguities or inconsistencies in the specifications
test cases can be designed as soon as the specifications are complete
Disadvantages of Black Box Testing
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 .

What is checklist-based testing?

20 September 2016
We normally use Test Checklist when we dont have enough time on Test Preparation Phase to
prepare Test Case.
So we come up with the Test Checklist which is smaller version of Test Case where you only
define which Cases/Scenarios those are need to be tested without putting plenty of information
into them.
During Test, you just mark the test result pass/fail for each checklist item and then testing is
done.
Test Checklist would be suitable for Application which is not complex and quite easy to
understand.
If you are working with complex application and very specific prerequisites, test data, test steps,
post conditions are required for each test - you would need to create proper Test Cases.