black-box testing
Black-box testing is only testing as if the software itself
is a black box.
This is one of the most common forms of testing-and really
how to describe an entire category of testing black-box testing.
When you perform black box testing, you only care about
input and output. You do not care how the actual output is derived.
You do not know anything about the code or how it works,
it's just for one set of inputs into the software, set the output to be
produced.
Most testing is done in this fashion because most contain.
It either works or not.
white-box testing
Real white-box testing is when you understand some of the
internals of the system, and may have access to the actual source code, which
you use to inform your test and what you are targeting.
White box testing is pretty much the opposite of black-box
testing.
With the white-box testing, you have at least some idea of
what's going on in the software.
Often, unit testing is called white-box testing, but I do
not agree. Unit testing does not test at all.
Example:
If you look at the code that performs complex calculations
for some accounting software, and you see that there is a piece of code that
performs a set of calculations for values above a certain amount and a set of
calculations for each of the other values, you are more able to make the test
targeting both scenarios.
With a black-box testing, you have no way of knowing these
two conditions exist, so you would be very unlikely to test for both of them
unless you are just lucky.
acceptance test
The basic idea of acceptance testing is that you have some
tests that examine the actual requirements or expectations of the customers,
and other tests are run against the system as a whole.
Sometimes called user acceptance testing (short: UAT).
Sometimes called system testing.
This kind of testing can test the functionality of the
system or could test the usefulness or both.
The idea is that the test acceptance testing what to expect
versus what actually happened.
automated testing
Automated testing is any testing in which the execution of
the test and verification results automatically.
So, you may automate testing of web applications by running
scripts that open a web page, enter some data, push a few buttons and then
check out some of the results on the page.
You can also automate testing the API to write a script that
calls the API with data and then check the results that are returned.
More testing is moving towards automated testing for
manually walk through repetitive test cases can be tedious, error-prone and
expensive-especially in Agile environments where the same set of tests may need
to be run every two weeks or so to verify nothing was broken.
regression testing
This brings us to regression testing, which is basically
testing is done to verify that the system still works the way it was before.
The purpose of regression testing is to make sure the
software is not deterioration in function.
It is very important to the Agile development methodology in
which software is developed gradually, and there is a constant potential that
add new features to solve existing ones.
most tests are automated regression tests.
In fact, you really can make the argument that all the
automated test regression test because the whole purpose of automating the test
is that it can run multiple times.
functional testing
Functional testing is another broad term used in the testing
world to refer to testing activity where what is being tested is the actual
function of the system.
This may seem obvious.
But, it turns out you can test all sorts of things that are
not related functions, such as performance, usability, robustness, security,
scalability-I could go on and on, believe me.
Thus, functional testing is a type of test where you are
really concerned about the system doing what should be done from a functional
perspective.
If I put into this input and pressing this button, I get the
expected output of this?
I do not care how long it takes. I do not care if the screen
flashes red and the computer starts to smoke, I get my results?
exploratory testing
I want to make fun of testing exploration and called it
"testing lazy-ass."
It really makes the testers when I do that.
But, there must be some legitimacy to the idea of
exploration testing and maybe I am a little too harsh and judgmental.
The idea behind the test exploration-when done correctly, is
that you have some guidelines and a basic plan that will test your application
area and how you are going to test them.
Then, you go on without the actual test cases and explore
the apps, looking for things that may be incorrect or unexpected behavior.
Often, exploratory testing sessions are recorded, so that if
an error is found, the problem can be reproduced by retracing the steps taken
by the tester exploration.
While I'm normally not a big advocate of this kind of
testing, I have to admit its benefits, such as exploratory testing can uncover
any bugs often rational test cases would never designed to exploit.
Another form of testing
Indeed we have only scratched the surface of all types and
classifications of the different tests.
Many other forms of testing available, including:
Load Test How to Conduct an application under heavy load
Performance Testing Performance-applications based on
specific scenarios
Test-recovery recovery from error conditions or hardware
problems
Security Testing-The security system
stress testing
usability testing
accessibility testing
the list goes on and on.
Conclusion: we are the best software
testing company in USA region who are have hands on experience doing all
kind of software tests for the web and mobile application which you have for
the business. Today its very common to check the software before its launch and
after the launch.
Also see our : tech support company in usa
Also see our : tech support company in usa
