2

What Is Regression Testing? Regression Testing The idea behind regression testing is simple. We know that changes to an existing system often cause other things to break.

To detect when this happens, we keep a set of tests (the Regression Test Set, or the RTS for short) containing tests of important things that used to work okay. We run the RTS after each set of changes to make sure that these things still work. That's it.

The problem is to do regression testing correctly, so that it solves more problems than it creates.

Benefits of Regression Testing There are lots of benefits to doing regression testing. (1) It increases our chances of detecting bugs caused by changes to an application (2) It can also detect undesirable side effects caused by changing the operating environment. For example, hardware changes, or upgrades to system software such as the operating system or the database management system

The Big Questions After A Change To The System: 1. Did the change work? 2. Did it break anything else? 3. Is the RTS still okay? 1-The first question is almost always easy. We simply test whatever the change is supposed to do, 2- "Did It Break Anything Else ". (a) what's broken, and (b) how would we know that? Answer: run the Regression Test Set (RTS). 3-"Is the RTS still okay?", is often overlooked, but it's one of the things that can get you in trouble.

Summary:

Regression testing means rerunning tests of things that used to that a change didn't break something else The set of tests used is called the Regression Test Set, or RTS It's enormously helpful when you change an application, change and during integration of pieces. Regression testing is a simple concept, but it needs to be done in the real world.

work to make sure for short the environment, just right to work

Difference between White box n Black box? Blackbox testing:

Testing is based on behaviour of the application . what it does/ produces etc. Also in black box testing testers does not require code language

White box testing Testing is based on internal structure of the application. So in white box testing testers requires code language

More example read this: if u feel easy or leave it as this much is enough to get the basic of this. http://www.webappsec.org/lists/websecurity/archive/200805/msg00025.html

*Black box testing is the act of verifying that a software Specification, without reference to the internal workings (functioning) of the code to verify the spec.

*Black Box testing is also very strong at identifying errors of omission and unintended/surprising emergent behaviours

4. White Box testing is the act of verifying the internal workings of a piece of software with reference to structure and/or down to the algorithmic(functioning) level. There are many different types of testing that fall under "White Box" testing. (e.g "structural verification")

White Box testing is primarily focused on verifying that the design structure follows an expected or ideal structure, and that the implemented algorithms perform the units of work that they are planned too. White Box testing is very strong at identifying errors of commission.

OTHER TESTINGS

1. "Vuln test" aka vulnerability (WEAKNESS) testing == subset of Black Box testing. Most commonly means to locate the artifacts of exploitable conditions & behaviors in software. False positive prone without human analysis, due to the fact the artifacts are often behavioral inference, and may not in fact indicate a security defect at all.

http://www.aptest.com/glossary.html Acceptance Testing: Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria. Ad Hoc Testing: A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. Automated Testing: Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing. The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.