Testing Type Have you ever thought why do you need to categorize software testing into different types? What is the benefits of dividing software testing in different types? One of the main purpose of software testing is to identify defects in the software. Defects in software testing can be defined as variance from requirement or user expectation. Based on this simple definition, it is very easy to categorize defects. For example:

 If system is not functioning properly, its a functional defect. If system is not performing well, its a performance defect. If system is not usable, its a usability defect If system is not secure, its a security defect and so on..

Identify these different defects require different skill set, different techniques and different type of test cases. Testing is divided into different types to reflect, what kind of defects can be uncovered by those activities. This division also helps management in managing these activities effectively. Also, it is very rare to have someone with skills in all the types of testing and this division helps in getting proper resources for team.

Hope you understand importance of this categorization and also how important it is to have understanding of different types. This understanding will enable you to spot more defects which in turn will improve quality and make you more effective software tester.

There are many ways in which software testing can be categorized. Some of them are described as follows: 

Categorization of testing based on the knowledge of system

Black Box Testing White Box Testing Gray Box Testing

Categorization of testing based on the time it is executed in the Software Development Life Cycle

Unit Testing Integration Testing System Testing User Acceptance Testing

Different types of testing can be categorized based on the purpose of testing. This can be classified further into Functional Testing and Non Functional Testing. 

Functional Testing

In functional testing, the focus of testing activities is on functional aspects of the system. In functional testing, test cases are written to check the expected output. Functional testing is normally performed in all the test phases from unit to system testing.

The following types of test activities are normally performed under Functional Testing

o Installation Testing o Regression Testing o Upgrade and backward compatibility testing o Accessibility testing o Internationalization and localization testing o API Testing

Non-Functional Testing

In non-functional testing, the focus of the testing activities is on non functional aspects of the system. Non functional testing is normally carried out during the System Testing phase only. The focus of non functional testing is on the behavior and user experience of the system.

o Performance, Load and Stress Testing o Usability Testing o Security testing o more to come..

Testing can also be categorized based on how it is executed. Execution  could be in the form of verification or static analysis or it could be validation or dynamic analysis. Verification and validation can be categorized further according to how it is done.

Verification

In very simple terms, verification is the human examination or review of the work product. There are many forms of verification which ranges from informal verification to formal verification. Verification can be used for various phases in SDLC and can be in the form of formal inspection, walkthrough or buddy-checking.

Validation

Validation or dynamic analysis is the most frequent activity that as a tester you perform. Whether you are doing black box testing, non functional testing or any type of testing, chances are that you are performing validation or dynamic

analyses. Validation or dynamic analyses is associated with the execution, and could be related to the execution of test cases or testing in general. There are many ways in which testing can be executed, for example

o Manual Scripted Testing o Exploratory Testing o Automated Testing o Model Based Testing

o many more..

 

Black Box Testing

Probably this is what most of us practice and is used most widely. This is also type of testing which is very close to customer experience. In this type of testing system is treated as close system and test engineer do not assume any thing about how system was created. As a test engineer if you are performing black box test cases, one thing that you need to make sure is that you do not make any assumptions about the system based on your knowledge. Assumption created in our mind because of the system knowledge could harm testing effort and increase the chances of missing critical test cases. 

Only input for test engineer in this type of testing is requirement document and functionality of system which you get by working with the system. Purpose of black box testing is to 

Make sure that system is working in accordance with the system requirement. Make sure that system is meeting user expectation.

In order to make sure that purpose of black box testing is met, various techniques can be used for data selection like 

Boundary value analyses Equivalence partitioning

Activities within every testing types can be divided into verification and validation. Within black box testing following activities will need verification techniques 

Review of requirement and functional specification.

Review of Test plan and test cases. Review of test data

And test case execution will fall under validation space.

White Box Testing White box testing is very different in nature from black box testing. In black box testing, focus of all the activities is only on the functionality of system and not on what is happening inside the system.

Purpose of white box testing is to make sure that Functionality is proper

Information on the code coverage

White box is primarily development teams job, but now test engineers have also started helping development team in this effort by contributing in writing unit test cases, generating data for unit test cases etc.

White box testing can be performed at various level starting from unit to system testing. Only distinction between black box and white box is the system knowledge, in white box testing you execute or select your test cases based on the code/architectural knowledge of system under test.

Even if you are executing integration or system test, but using data in such a way that one particular code path is exercised, it should fall under white box testing. 

There are different type of coverage that can be targeted in white box testing

Statement coverage Function coverage Decision coverage Decision and Statement coverage

Conditional Testing

The first improvement to white box techniques is to ensure that the Boolean controlling expressions are adequately tested, a process known as condition testing.

The process of condition testing ensures that a controlling expression has been adequately exercised whilst the software is under test by constructing a constraint set for every expression and then ensuring that every member on the constraint set is included in the values which are presented to the expression. This may require additional test runs to be included in the test plan.

To introduce the concept of constraint sets the simplest possible Boolean condition, a single Boolean variable or a negated Boolean variable, will be considered. These conditions may take forms such as:

if DateValid then while not DateValid then

The constraint set for both of these expressions is {t ,f } which indicates that to adequately test these expressions they should be tested twice with DateValid having the values True and False.

Perhaps the next simplest Boolean condition consists of a simple relational expression of the form value operator value, where the operator can be one of: is equal to ( = ), is not equal to ( /= ), is greater than ( > ), is less than ( <), is greater than or equal to ( >= ) and is less than or equal to ( <= ). It can be noted that the negation of the simple Boolean variable above had no effect upon the constraint set and that the six relational operators can be divided into three pairs of operators and their negations. Is equal to is a negation of is not equal to, is greater than is a negation of is less than or equal to and is less than is a negation of is greater than or equal to. Thus the condition set for a relational expression can be expressed as {=, >, <}, which indicates that to adequately test a relational expression it must be tested three times with values which ensure that the two values are equal, that the first value is less than the second value and that the first value is greater than the second value.

More complex control expressions involve the use of the Boolean operators, and, or and xor, which combine the values of two Boolean values. To construct a constraint set for a simple Boolean expression of the form BooleanValue operator BooleanValue all possible combinations of True and False have to be considered. This gives the constraint set for the expression as {{t ,t } {t ,f } {f ,t } {f ,f }}. If both BooleanValues are simple or negated Boolean variables then no further development of this set is required. However if one or both of the BooleanValues are relational expressions then the constraint set for the relational expression will have to be combined with this constraint set. The combination takes the form of noting that the equality condition is equivalent to true and the both inequality conditions are equivalent to false. Thus every true condition in the condition set is replaced with ' = ' and every false replaced twice, once with ' > ' and once with ' < '.

Thus if only one the left hand BooleanValue is a relational expression the condition set

would be {{= ,t } {= ,f } {> ,t } {< ,t } {> ,f } {< ,f }}. And if both BooleanValues are relation expressions this would become {{= ,= } {= ,> } {= ,< } {> ,= } {< ,= } {> ,> } {> ,< } {< ,> } {< ,< }}.

An increase in the complexity of the Boolean expression by the addition of more operators will introduce implicit or explicit bracketing of the order of evaluation which will be reflected in the condition set and will increase the number of terms in the set. For example a Boolean expression of the following form:

BooleanValue1 operator1 BooleanValue2 operator3nbsp;BooleanValue3

Has the implicit bracketing:

(BooleanValue1 operator1 BooleanValue2) operato3 BooleanValue3

The constraint set for the complete expression would be {{e1,t}{e1,f}}, where e1 is the condition set of the bracketed sub-expression and when it is used to expand this constraint set gives {{t,t,t} {t,f,t} {f,t,t} {f,f,t} {t,t,f} {t,f,f} {f,t,f} {f,f,f}}. If any of the BooleanValues are themselves relational expressions this will increase the number of terms in the condition set. In this example the worst case would be if all three values were relational expressions and would produce a total of 27 terms in the condition set. This would imply that 27 tests are required to adequately test the expression. As the number of Boolean operators increases the number of terms in a condition set increases exponentially and comprehensive testing of the expression becomes more complicated and less likely. It is this consideration which led to the advice, initially given in Section 1, to keep Boolean control expressions as simple as possible, and one way to do this is to use Boolean variables rather than expressions within such control conditions.

Data Life Cycle Testing

Keeping control expressions simple can be argued to simply distribute the complexity from the control expressions into the other parts of the subprogram and an effective testing strategy should recognise this and account for it. One approach to this consideration is known as data lifecyle testing, and it is based upon the consideration that a variable is at some stage created, and subsequently may have its value changed or used in a controlling expression several times before being destroyed. If only locally declared Boolean variables used in control conditions are considered then an examination of the source code will indicate the place in the source code where the variable is created, places where it is given a value, where the value is used as part of a control expression and the place where it is destroyed.

This approach to testing requires all possible feasible lifecycles of the variable to be covered whilst the module is under test. In the case of a Boolean variable this should include the possibility of a Boolean variable being given the values True and False at each place where it is given a value. A typical outline sketch of a possible lifecycle of a controlling Boolean variable within a subprogram might be as follows:

~~~ SomeSubProgram( ~~~ ) is 

ControlVar : BOOLEAN := FALSE;

begin -- SomeSubProgram

~~~

while not ControlVar loop

~~~

ControlVar := SomeExpression;

end loop;

~~~

end SomeSubProg;

In this sketch ~~~ indicates the parts of the subprogram which are not relevant to the lifecycle. In this example there are two places where the variable ControlVar is given a value, the location where it is created and the assignment within the loop. Additionally there is one place where it is used as a control expression. There are two possible lifecycles to consider, one which can be characterised as { f t } indicating that the variable is created with the value False and given the value True upon the first iteration of the loop. The other lifecycle can be characterised as { f, f, ... t }, which differs from the first by indicating that the variable is given the value False on the first iteration, following which there is the possibility of more iterations where it is also given the value False, being given the value True on the last iteration.

Other possible lifecycles such as { f } or { f t f .. t } can be shown from a consideration of the source code not to be possible. The first is not possible as the default value will ensure that the loop iterates causing the variable to experience at least two values during its lifecycle. The second is not possible as soon as the variable is given the value True within the loop, the loop and subsequently the subprogram will terminate, causing the variable to be destroyed.

This quick look at the variable lifecycle approach only indicates the basis of this approach to white box testing. It should also indicate that this is one of the most laborious and thus expensive and difficult techniques to apply. As it is expensive and does not add a great deal to the testing considerations which have already been discussed, it is not widely used.

 Loop Testing

The final white box consideration which will be introduced is the testing of loops, which have been shown to be the most common cause of faults in subprograms. If a loop, definite or indefinite, is intended to iterate n times then the test plan should include the following seven considerations and possible faults.

That the loop might iterate zero times. That the loop might iterate once That the loop might iterate twice That the loop might iterate several times That the loop might iterate n - 1 times That the loop might iterate n times That the loop might iterate n + 1 times That the loop might iterate infinite times

All feasible possibilities should be exercised whilst the software is under test. The last possibility, an infinite loop, is a very noticeable, and common fault. All loops should be constructed in such a way that it is guaranteed that they will at some stage come to an end. However this does not necessarily guarantee that they come to an end after the correct number of iterations, a loop which iterates one time too many or one time too few is probably the most common loop fault. Of these possibilities an additional iteration may hopefully cause a CONSTRAINT_ERROR exception to be raised announcing its presence. Otherwise the n - 1 and n + 1 loop faults can be very difficult to detect and correct.

A loop executing zero times may be part of the design, in which case it should be explicitly tested that it does so when required and does not do so when it is not required. Otherwise, if the loop should never execute zero times, and it does, this can also be a very subtle fault to locate. The additional considerations, once, twice and many are included to increase confidence that the loop is operating correctly.

The next consideration is the testing of nested loops. One approach to this is to combine the test considerations of the innermost loop with those of the outermost loop. As there are 7 considerations for a simple loop, this will give 49 considerations for two levels of nesting and 343 considerations for a triple nested loop, this is clearly not a feasible proposition.

What is possible is to start by testing the innermost loop, with all other loops set to iterate the minimum number of times. Once the innermost loop has been tested it should be configured so that it will iterate the minimum number of times and the next outermost loop tested. Testing of nested loops can continue in this manner, effectively testing each nested loop in sequence rather than in combination, which will result in the number of required tests increasing arithmetically ( 7, 14, 21 ..) rather than geometrically ( 7, 49, 343 .. ).

User Acceptance Testing Acceptance Testing is the formal testing conducted to determine whether a software system satisfies its acceptance criteria and to enable buyer to determine whether to accept the system or not.

Acceptance testing is designed to determine whether software is fit for use or not. Apart from functionality of application, other factors related to business environment also plays an important role.

User acceptance testing is different from System Testing. System testing is invariably performed by the development team which includes developer and tester. User acceptance testing on the other hand should be carried out by the end user. This could be in the form of

Alpha Testing - Where test are conducted at the development site by the end users. Environment can be controlled a little bit in this case.

Beta Testing - Where test are conducted at customer site and development team do not have any control on the test environment.

In both the cases, these testing might be assisted by software testers.

It is very important to define acceptance criteria with the buyer during the various phases of SDLC. A well defined acceptance plan will help development/QE teams by identifying user's need during software development. Acceptance Test plan must be created or reviewed by customer. Development team and customer should work together and make sure that they have

Identify interim and final products for acceptance, acceptance criteria and schedule.

Plan how and by whom each acceptance activities will be performed. Schedule adequate time for buyer's staff to examine and review the product Prepare the acceptance plan. Perform formal acceptance testing at delivery Make a decision based on the results of acceptance testing.

Entry Criteria System Testing is completed and defects identified are either fixed or

documented. Acceptance plan is prepared and resources have been identified. Test environment for the acceptance testing is available

Exit Criteria Acceptance decision is made for the software In case of any caveats, development team is notified

Gray Box Testing Grey box testing is the combination of black box and white box testing. Intention of this testing is to find out defects related to bad design or bad implementation of the system.

In gray box testing, test engineer is equipped with the knowledge of system and designs test cases or test data based on system knowledge. 

For example, consider a hypothetical case wherein you have to test a web application. Functionality of this web application is very simple, you just need to enter your personal details like email and field of interest on the web form and submit this form. Server will get this details, and based on the field of interest pick some articles and mail it to the given email. Email validation is happening at the client side using Java Scripts.

In this case, in the absence of implementation detail, you might test web form with valid/invalid mail IDs and different field of interests to make sure that functionality is intact.

But, if you know the implementation detail, you know that system is making following assumptions

Server will never get invalid mail ID Server will never send mail to invalid ID Server will never receive failure notification for this mail.

So as part of gray box testing, in the above example you will have a test case on clients where Java Scripts are disabled. It could happen due to any reason and if it happens, validation can not happen at the client site. In this case, assumptions made by the system are violated and 

Server will get invalid mail ID

Server will send mail to invalid mail ID Server will receive failure notification

Hope you understood the concept of gray box testing and how it can be used to create different test cases or data points based on the implementation details of the system.

Do you have a better example? Share with us.

Unit Testing I have heard some people saying that Unit testing is done primarily by the developers and test engineers need not know about Unit testing. But this is not the case, Unit testing is as important for test engineers as it is for developers.

Probably developers will write the unit test cases but your understanding of the framework and unit testing can certainly help him/her in designing the flow for unit test cases, generating test data and making good reports. All these activities will ultimately help you in the long run as product quality will increase significantly because of the efforts you put in on the unit testing.

So if you think as a test engineer, you should also learn/know about unit testing read on.

Unit testing is the method of making sure that smallest unit of your software is working properly in isolation. You can define this smallest unit in your own term, it could be a java class or library. A more formal definition and one of the earliest paper on Unit Testing by Kent Beck can be found here.

Kent Beck wrote JUnit framework along with Erich Gamma and it became extremely useful for the Java community. JUnit made it very easy for the developers to write, organize and execute unit test cases for there java code. Success of JUnit was enough to inspire people working on other languages to come up with unit testing framework for the language of their choice. Now we probably have more than 25 Unit testing frameworks based on the XUnit architecture covering all the major languages. Information on unit test frameworks available are present here.

Information about JUnit and Jtescase is also present here, because these are the most widely used unit testing frameworks. If you want me to add more information about any particular unit testing framework, contact us.

Regression Testing As some one has said, changes are the only thing constant in this world. It holds true for software also, existing software are either being changed or removed from the shelves. These changes could be due to any reason. There could be some critical defects which needs to be fixed, there could be some enhancements which has to happen in order to remain in the competition. 

Regression testing is done to ensure that enhancement, defect fixes or any other changes made to the software has not broken any existing functionality.

Regression testing is very important, because in most places these days iterative development is used. In iterative development, shorter cycle is used with some functionality added in every cycle. In this scenario, it make sense to have regression testing for every cycle to make sure that new features are not breaking any existing functionality.

Whenever there are any changes in the system, regression testing is performed. Regression testing can be performed for the complete product or it can be selective. Normally, full regression cycle is executed during the end of testing cycle and partial regression cycle is executed between the test cycles. During the regression cycle it becomes very important to select the proper test cases to get the maximum benefits. Test cases for regression testing should be selected based on the knowledge of 

What defect fixes, enhancement or changes have gone into the system? What is the impact of these changes on the other aspect of system?

Focus of the regression testing is always on the impact of the changes in the system. In most of the organizations, priority of the regression defect is always very high. It is normally included in the exit criteria of the product that it should have zero regression defects. 

Regression testing should always happen after the sanity or smoke testing. Sanity/Smoke can be defined as the type of testing which make sure that software is in testable state. Normally, sanity test suite will contain very basic and core test cases. These test cases decides the quality of the build and any failure in the sanity test suite should result in the rejection of build by the test team.

Regression testing is a continuous process and and it happens after every release. Test cases are added to the regression suite after every release and repetitively executed for

every release. 

Because test cases of regression suite are executed for every release, they are perfect candidate for the automation. Test automation is discussed separately in the Test Automation section of this website.

ntegration Testing Objective of Integration testing is to make sure that the interaction of two or more components produces results that satisfy functional requirement. In integration testing, test cases are developed with the express purpose of exercising the interface between the components.

Integration testing can also be treated as testing assumption of fellow programmer. During the coding phase, lots of assumptions are made. Assumptions can be made for how you will receive data from different components and how you have to pass data to different components. During Unit Testing, these assumptions are not tested. Purpose of unit testing is also to make sure that these assumptions are valid. There could be many reasons for integration to go wrong, it could be because

Interface Misuse - A calling component calls another component and makes an error in its use of interface, probably by calling/passing parameters in the wrong sequence.

Interface Misunderstanding - A calling component makes some assumption about the other components behavior which are incorrect. 

Integration Testing can be performed in three different ways based on the from where you start testing and in which direction you are progressing.

Big Bang Integration Testing Top Down Integration Testing Bottom Up Integration Testing Hybrid Integration testing

Top down testing can proceed in a depth-first or a breadth-first manner. For depth-first integration each module is tested in increasing detail, replacing more and more levels of detail with actual code rather than stubs. Alternatively breadth-first would proceed by

refining all the modules at the same level of control throughout the application. In practice a combination of the two techniques would be used. 

Entry Criteria

Main entry criteria for Integration testing is the completion of Unit Testing. If individual units are not tested properly for their functionality, then Integration testing should not be started.

Exit Criteria

Integration testing is complete when you make sure that all the interfaces where components interact with each other are covered. It is important to cover negative cases as well because components might make assumption with respect to the data.

System Testing System testing is probably the most important phase of complete testing cycle. This phase is started after the completion of other phases like Unit, Component and Integration testing. During the System Testing phase, non functional testing also comes in to picture and performance, load, stress, scalability all these types of testing are performed in this phase.

By Definition, System Testing is conducted on the complete integrated system and on a replicated production environment. System Testing also evaluates that system compliance with specific functional and non functional requirements both. 

It is very important to understand that not many test cases are written for the system testing. Test cases for the system testing are derived from the architecture/design of the system, from input of the end user and by user stories. It does not make sense to exercise extensive testing in the System Testing phase, as most of the functional defects should have been caught and corrected during earlier testing phase.

Utmost care is exercised for the defects uncovered during System Testing phase and proper impact analysis should be done before fixing the defect. Some times, if business permits defects are just documented and mentioned as the known limitation instead of fixing it.

Progress of the System Testing also instills and build confidence in the product teams as this is the first phase in which product is tested with production environment.

System Testing phase also prepares team for more user centric testing i.e User Acceptance Testing.

Entry Criteria Unit, component and Integration test are complete Defects identified during these test phases are resolved and closed by QE team Teams have sufficient tools and resources to mimic the production environment Teams have sufficient tools and resources to mimic the production environment

Exit Criteria Test cases execution reports shows that functional and non functional

requirements are met.

Defects found during the System Testing are either fixed after doing thorough impact analysis or are documented as known limitations.

User Acceptance Testing Acceptance Testing is the formal testing conducted to determine whether a software system satisfies its acceptance criteria and to enable buyer to determine whether to accept the system or not.

Acceptance testing is designed to determine whether software is fit for use or not. Apart from functionality of application, other factors related to business environment also plays an important role.

User acceptance testing is different from System Testing. System testing is invariably performed by the development team which includes developer and tester. User acceptance testing on the other hand should be carried out by the end user. This could be in the form of

Alpha Testing - Where test are conducted at the development site by the end users. Environment can be controlled a little bit in this case.

Beta Testing - Where test are conducted at customer site and development team do not have any control on the test environment.

In both the cases, these testing might be assisted by software testers.

It is very important to define acceptance criteria with the buyer during the various phases of SDLC. A well defined acceptance plan will help development/QE teams by identifying user's need during software development. Acceptance Test plan must be created or reviewed by customer. Development team and customer should work together and make sure that they have

Identify interim and final products for acceptance, acceptance criteria and schedule.

Plan how and by whom each acceptance activities will be performed. Schedule adequate time for buyer's staff to examine and review the product Prepare the acceptance plan. Perform formal acceptance testing at delivery Make a decision based on the results of acceptance testing.

Entry Criteria System Testing is completed and defects identified are either fixed or

documented. Acceptance plan is prepared and resources have been identified. Test environment for the acceptance testing is available

Exit Criteria Acceptance decision is made for the software In case of any caveats, development team is notified

Regression Testing As some one has said, changes are the only thing constant in this world. It holds true for software also, existing software are either being changed or removed from the shelves. These changes could be due to any reason. There could be some critical defects which needs to be fixed, there could be some enhancements which has to happen in order to remain in the competition. 

Regression testing is done to ensure that enhancement, defect fixes or any other changes made to the software has not broken any existing functionality.

Regression testing is very important, because in most places these days iterative development is used. In iterative development, shorter cycle is used with some functionality added in every cycle. In this scenario, it make sense to have regression testing for every cycle to make sure that new features are not breaking any existing functionality.

Whenever there are any changes in the system, regression testing is performed. Regression testing can be performed for the complete product or it can be selective. Normally, full regression cycle is executed during the end of testing cycle and partial regression cycle is executed between the test cycles. During the regression cycle it becomes very important to select the proper test cases to get the maximum benefits. Test cases for regression testing should be selected based on the knowledge of 

What defect fixes, enhancement or changes have gone into the system? What is the impact of these changes on the other aspect of system?

Focus of the regression testing is always on the impact of the changes in the system. In most of the organizations, priority of the regression defect is always very high. It is normally included in the exit criteria of the product that it should have zero regression defects. 

Regression testing should always happen after the sanity or smoke testing. Sanity/Smoke can be defined as the type of testing which make sure that software is in testable state. Normally, sanity test suite will contain very basic and core test cases. These test cases decides the quality of the build and any failure in the sanity test suite should result in the rejection of build by the test team.

Regression testing is a continuous process and and it happens after every release. Test cases are added to the regression suite after every release and repetitively executed for every release. 

Because test cases of regression suite are executed for every release, they are perfect candidate for the automation. Test automation is discussed separately in the Test Automation section of this website.

Security Testing

Security Testing is very important in today's world, because of the way computer and internet has affected the individual and organization. Today, it is very difficult to imagine world without Internet and latest communication system. All these communication systems increases efficiency of individual and organization by multifold.

Since every one from individual to organization, uses Internet or communication system to pass information, to do business, to transfer money it becomes very critical for the service provider to make sure that information and network are secured from the intruders.

Primary purpose of security testing is to identify the vulnerabilities and subsequently repairing them. Typically, security testing is conducted after the system has been developed, installed and is operational. Unlike other types of testing, network security testing is performed on the system on the periodic basis to make sure that all the vulnerabilities of the system are identified.

Network security testing can be further classified into following types Network Scanning Vulnerability Scanning Password Cracking Log Review File Integrity Checkers Virus Detection War Dialing Penetration Testing

None of these tests provide a complete picture of network security. You will need to perform a combination of these techniques to ascertain status of your Network Testing Activities.

Apart from Network Security Testing, you should also take care of Application security testing. Intruders can target specific applications for unauthorized access or for any malicious reason. It becomes even critical for the web applications, because of the visibility and access of the application through Internet. Web application Security Testing is covered in a different section. 

Recent Updates

Guerrilla Testing Tips One CPU better than two TG Tips For Automation?Is It Really Done? Exploratory Testing Automated Testing Model Based Testing Live News