I saw a list from the book i've been reading.

Testing Types

Testing gets broken into two types: black box and glass box (also sometimes called white box):

• Black box. The idea behind this type of testing is that if the code is in a black box, you can't see the inside machinations of how it works. You see only how you are able to use it as an end user.

• Glass box (or white box). The idea here is that if the code is inside a glass box, you can see the internals of the code and poke at the weak points of the functions because you understand how the internals are put together.

The testing process gets further granularized into unit testing, integration testing, functional testing, system testing, end-to-end testing, regression testing, and more. The delimitations between these types of testing are often fuzzy, but can be used to indicate activities and assign ownership. The following list defines some of the more common types of testing you engage in:

• Unit testing. Developers create the code-small discrete functions. Once they add more functions, they need to go back and test to verify that the functions interact as a unit the way they anticipated and designed for. This process is the unit testing, testing individual atomic units to ensure that they work as expected.

• Integration testing. A thorough developer carries the idea of unit testing into testing how their new units work together with related units, integrating them and checking their connections. This usually expands to include testers, who perform the remainder of this sort of integration testing.

• Smoke testing, build verification tests (BVTs), check-in tests (CITs). The real challenge starts in integration as features that are stable are integrated with new functionality. When code is passed to the test team, it is often verified first through smoke tests, build verification tests (BVTs), check-in tests (CITs) or other quick-and-dirty validations of the program's main functions. Such tests are also performed to ensure that the same base level of functionality that was available yesterday is still available today after the latest check-ins.

• Functional testing. Putting more of the stable small functions together allows testers to perform functional testing, testing a complete function from the user's point of view (as opposed to a code-based single function). In the online bookstore example I use throughout this text, functional testing may mean trying to perform user functions such as logging on or logging off.

• System testing. Putting the functions together allows the tester to verify the entire system in system testing. This may mean testing pieces of every component available.

• End-to-end testing. These tests are usually similar to system testing, but involve a clear user scenario that is being followed to test a user's complete interaction with the system.

• Sanity testing. Initial tests to determine if the area or entire product is stable enough to put more time and effort into testing.

• Regression testing. Retesting areas after fixes or functional additions to ensure that previously fixed bugs have not reappeared and new bugs have not been introduced (often performed by running the same test case as before or through automation).

• Acceptance testing. Final test pass based on specifications, customer agreement, or other such particulars.

• Load testing. Testing the software under heavy usage to determine performance degradation or failures.

• Stress testing. Testing specific functions while the system is running under high loads; helps determine the mean time to failure and performance metrics.

• Performance testing. Determines how much time or cost is associated with certain actions of functions. (How long will a customer have to wait for a particular action to complete? How long does the code spend in a particular function?)

• Usability testing. Testing the ability of the software to be used by the identified customer base.

• Install/uninstall testing. Testing how product components download, don't download, and work on various platforms, client or server, as well as how easily they can be removed.

• Recovery testing. Evaluating how well and how fast the system can bounce back from a crash or other failure.

• Compatibility testing. Determining the primary and secondary supported environments (OS, platform, browser, and so on) and the levels of support/behavior/functionality provided on each.

• Exploratory testing. A creative approach to learning and evaluating the software; usually informally introduces a tester to the environment.

• User acceptance testing. Determining if the software is satisfactory to a customer (usually not performed in shrinkwrapped development efforts).

• Alpha testing. Initial incorporation of endusers into the completed program. Involves early adopters or other partners. Design changes may occur as a result of this feedback.

• Beta testing. Development and test are basically finished. Finds final problems before the final release. Can be an open invitation to anyone who wants to download the software or try the service.

• Comparison testing. Comparing software features and stability to those of competitors.

• Accessibility testing. Checking if product or service is accessible to users.

• Server log testing/report testing. Examining the server logs after particular actions or at regular intervals to determine if there are problems or errors generated or if the server is entering a faulty state.

• Security testing. Testing the potential for accidental or malicious damage due to attacks, denials of service, open ports, and other issues.

• Memory leak testing. Testing the server components to see if memory is not properly referenced and released, which can lead to instability and the product's crashing.

• International sufficiency/localization/globalization. These are discussed in Chapter 7; however, each one is a distinct testing effort.

  • International sufficiency. This involves testing that the product can be localized into the target languages; languages that write from the right side of the page to the left side of the page place special requirements on the user interface as do double-byte languages such as Chinese and Japanese. Testing that the user interface can handle these is a separate task from actually translating the words.

  • Localization. This is testing that all the words that the user sees are translated into the specified language properly.

  • Globalization. This is testing that all the various characters and combinations from the various languages can be accepted by the system or are properly rejected and that no data conversions or corruptions occur.

• HTML validation testing. Specific to Web testing. This certifies that the HTML meets specifications and internal coding standards.

• SSL testing. Testing Web site/service over an SSL connection, if that's an option.

• Bandwidth testing. Testing a site with a variety of link speeds, both fast (internally connected LAN) and slow (externally, through a proxy or firewall, and over a modem); sometimes called slow link testing if the organization typically tests with a faster link internally (in that case, they are doing a specific pass for the slower line speed only).

Overall, you want to move away from brute force methods of testing. Sure you could find bugs by blindfolding yourself and randomly hitting keys, but it would take a very long time and be rather inefficient. You will include some amount of ad hoc testing in your test activities. Where brute force just bangs on the keys and the mouse, ad hoc testing lets loose your creativity to think more about certain areas and investigate them. This is best undertaken by a tester who knows the software and testing methodologies well enough to see the bug patterns and know where to poke to find more problems.