Compatibility Testing - Definition, Types, Tools Used

What is Compatibility Testing

• Compatibility testing is to check whether your software is capable of running on different hardware, operating systems, applications , network environments or mobile devices.
• Compatibility Testing is a type of the Non-functional testing
• Initial phase of compatibility testing is to define the set of environments or platforms the application is expected to work on.
• Tester should have enough knowledge on the platforms / software / hardware to understand the expected application behavior under different configurations.
• Environment needs to be set-up for testing with different platforms, devices, networks to check whether your application runs well under different configurations.
• Report the bugs .Fix the defects. Re-test to confirm defect fixing.

Types of Compatibility testing :

• Hardware
• Operating Systems
• Software
• Network
• Browser
• Devices
• Mobile
• Versions of the software

Let’s look into compatibility testing types briefly.

Hardware : It checks software to be compatible with different hardware configurations .

Operating Systems: It checks your software to be compatible with different Operating Systems like Windows , Unix , Mac OS etc.

Software: It checks your developed software to be compatible with other software’s.For example: MS Word application should be compatible with other softwares like MS Outlook,MS Excel , VBA etc.

Network: Evaluation of performance of system In network with varying parameters such as Bandwidth, Operating speed, Capacity. It also checks application in different networks with all parameters mentioned earlier.

Browser: It checks compatibility of your website with different browsers like Firefox , Google Chrome , Internet Explorer etc.

Devices : It checks compatibility of your software with different devices like USB port Devices, Printers and Scanners, Other media devices and Blue tooth.

Mobile: Checking you software is compatible with mobile platforms like Android , iOS etc.

Versions of the software: It is verifying you software application to be compatible with different versions of software.For instance checking your Microsoft Word to be compatible with Windows 7, Windows 7 SP1 , Windows 7 SP 2 , Windows 7 SP 3.

There are two types of version checking.

• Types of Version Checking

• Backward compatibility Testing
• Forward compatibility Testing

Backward compatibility Testing : is to verify the behavior of the developed hardware/software with the older versions of the hardware/software.

Forward compatibility Testing : is to verify the behavior of the developed hardware/software with the newer versions of the hardware/software.

Tools for compatibility testing

• Adobe Browser Lab – Browser Compatibility Testing - This tool helps check your application in different browsers.
• Secure Platform – Hardware Compatibility tool - This tools includes necessary drivers for a specific hardware platform and it provides information on tool to check for CD burning process with CD burning tools.
• Virtual Desktops - Operating System Compatibility - This is used to run the applications in multiple operating systems as virtual machines. N Number of systems can be connected and compare the results.

Adhoc Testing - Definition, Types, Advantages, Disadvantages

Adhoc Testing

Definition :

• Adhoc testing is an informal testing type with an aim to break the system.
• This testing is usually an unplanned activity.
• It does not follow any test design techniques to create test cases. In fact is does not create test cases altogether!
• It is primarily performed if the knowledge of testers in the system under test is very high.
• Testers randomly test the application without any test cases or any business requirement document.
• Adhoc testing can be achieved with the testing technique called Error Guessing.
• Error guessing can be done by the people having enough experience on the system to “geuss” the most likely source of errors.

---

Types of adhoc testing

1. Buddy Testing
2. Pair testing
3. Monkey Testing

Buddy Testing

Two buddies mutually work on identifying defects in the same module. Mostly one buddy will be from development team and another person will be from testing team. Buddy testing helps the testers develop better test cases and development team can also make design changes early. This testing usually happens after unit testing completion.

Pair testing

Two testers are assigned modules, share ideas and work on the same machines to find defects. One person can execute the tests and another person can take notes on the findings. Roles of the persons can be a tester and scriber during testing.

Buddy testing is combination of unit and system testing together with developers and testers but Pair testing is done only with the testers with different knowledge levels.(Experienced and non-experienced to share their ideas and views)

Monkey Testing

Randomly test the product or application without test cases with a goal to break the system

---

Advantages of Adhoc Testing :

• Adhoc Testing saves lot of time as it doesn’t require elaborate test planning , documentation and test case design.
• It checks for the completeness of testing and find more defects then  planned testing.

Disadvantages of Adhoc Testing : 

• This testing requires no documentation/ planning /process to be followed. Since this testing aims at finding defects through random approach, without any documentation, defects will not be mapped to test cases. Hence, sometimes, it is very difficult to reproduce the defects as there are no test-steps or requirements mapped to it.

Define Equivalence Partitioning with Examples

Define Equivalence Partitioning with Examples

What is Equivalence Partitioning ?

The technique is to divide (i.e. to partition) a set of test conditions into groups or sets that can be considered the same (i.e. the system should handle them equivalently), hence ‘equivalence partitioning’. Equivalence partitions are also known as equivalence classes – the two terms mean exactly the same thing.

Example 1 for Equivalence partitioning :

Test cases for input box accepting numbers between 1 and 1000 using Equivalence Partitioning:

1) One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a valid test case. If you select other values between 1 and 1000 then result is going to be same. So one test case for valid input data should be sufficient.

2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid input data test case.

3) Input data with any value greater than 1000 to represent third invalid input class.

---

Example 2 for Equivalence partitioning :

For example in a savings Bank account,

3% rate of interest is given if the balance in the account is in the range of $0 to $100,

5% rate of interest is given if the balance in the account is in the range of $100 to $1000,

And 7% rate of interest is given if the balance in the account is $1000 and above.

We would initially identify three valid equivalence partitions and one invalid partition as shown below. [Click on the image for Zoom view]

---

Example 3 for Equivalence partitioning :

A store in city offers different discounts depending on the purchases made by the individual. In order to test the software that calculates the discounts, we can identify the ranges of purchase values that earn the different discounts. For example, if a purchase is in the range of $1 up to $50 has no discounts, a purchase over $50 and up to $200 has a 5% discount, and purchases of $201 and up to $500 have a 10% discounts, and purchases of $501 and above have a 15% discounts.

Now we can identify 4 valid equivalence partitions and 1 invalid partition as shown below:

Invalid Partition	Valid Partition(No Discounts)	Valid Partition(5%)	Valid Partition(10%)	Valid Partition(15%)
$0.01	$1-$50	$51-$200	$201-$500	$501-Above

Happy Sharing! :)

Define Boundary Value Analysis with Examples

Define Boundary Value Analysis with Examples :

What is Boundary Value Analysis ?

A test data selection technique in which values are chosen to lie along data extremes. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values. The hope is that, if a systems works correctly for these special values then it will work correctly for all values in between.

Example 1 for Boundary Value Analysis : 

Password field accepts minimum 6 characters and maximum 12 characters. [Range is 6-12]

Write Test Cases considering values from  Valid region and each Invalid Region and Values which define exact boundary.

We need to execute 5 Test Cases for our Example 1.

1. Consider password length less than 6

2. Consider password of length exactly 6

3. Consider password of length between 7 and 11

4. Consider password of length exactly 12

5. Consider password of length more than 12 

Note : 1st and 5th Test Cases are considered for Negative Testing

---

Example 2 for Boundary Value Analysis :

Test cases for input box accepting numbers between 1 and 1000 using Boundary value analysis:

1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 1000 in our case.

2) Test data with values just below the extreme edges of input domains i.e. values 0 and 999.

3) Test data with values just above the extreme edges of input domain i.e. values 2 and 1001.

---

Example 3 for Boundary Value Analysis :

Name text box which allows 1-30 characters. So in this case writing test cases by entering each character once will be very difficult so then will choose boundary value analysis.

So in this case at max 5 test cases will come:

Test case1: minimum -1 character: Validating not entering anything in text box

Test case2: minimum +1 character: Validating with only one char

Test case3: maximum -1 character: Validating with 29 chars

Test case4: minimum +1 character: Validating with 31 characters

Test case1: any one middle number: validating with 15 chars

Happy Sharing!

What Is System Testing

What Is System Testing

Testing the behavior of the whole software/system as defined in software requirements specification (SRS) is known as system testing, its main focus is to verify that the customer requirements are fulfilled.

System testing is done after integration testing is complete. 

In system testing, there are two type of testing

1. Functionality testing

2.Non-functionality testing

Click on the image for zoom view

Functionality testing is to test whether application functioning as per requirement or not.

Non-functionality testing are several types :

• Load,
• Stress,
• Performance,
• Reliability,
• Security,
• Usability
• Configuration,
• Compatibility (forward & Backward),
• Scalability, Etc...

Click on the links to read more about Functionality testing and Non-functionality testing

Bug Life Cycle Or Defect Life Cycle In Software Testing

Bug Life Cycle Or Defect Life Cycle In Software Testing

Defect life cycle is a cycle which a defect goes through during its lifetime. It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced. Defect life cycle is related to the bug found during testing.

Click on the image for zoom view

Integration Testing And Types Of Integration Testing

Define Integration Testing And Types Of Integration Testing

Integration Testing:

Combining the modules and testing the flow of data between them. Integration Testing is divided into 2 types.

• Incremental Integration Testing:

Adding the modules incrementally and checking the data flow between them. Modules are added in a sequential fashion.

This can be done in two ways 

• Top-Down Approach
• Bottom-Up approach.

Software Test Documents - Test Plan, Test Scenario, Test Case, Traceability Matrix

Explain about Software Test Documents (artifacts)

Testing documentation involves the documentation of artifacts which should be developed before or during the testing of Software.

Documentation for Software testing helps in estimating the testing effort required, test coverage, requirement tracking/tracing etc. This section includes the description of some commonly used documented artifacts related to Software testing such as:

• Test Plan

• Test Scenario

• Test Case

• Traceability Matrix

What is Acceptance Testing ?

What is Acceptance Testing :

This is arguably the most importance type of testing as it is conducted by the Quality Assurance Team who will gauge whether the application meets the intended specifications and satisfies the client.s requirements. The QA team will have a set of pre written scenarios and Test Cases that will be used to test the application.

More ideas will be shared about the application and more tests can be performed on it to gauge its accuracy and the reasons why the project was initiated. Acceptance tests are not only intended to point out simple spelling mistakes, cosmetic errors or Interface gaps, but also to point out any bugs in the application that will result in system crashers or major errors in the application.

By performing acceptance tests on an application the testing team will deduce how the application will perform in production. There are also legal and contractual requirements for acceptance of the system.

What is Automation testing and List of Automation Testing Tools

What is Automation testing ?

Automation testing which is also known as Test Automation, is when the tester writes scripts and uses another software to test the software. This process involves automation of a manual process. Automation Testing is used to re-run the test scenarios that were performed manually, quickly and repeatedly.

Apart from regression testing, Automation testing is also used to test the application from load, performance and stress point of view. It increases the test coverage; improve accuracy, saves time and money in comparison to manual testing.

What to automate ?

It is not possible to automate everything in the Software; however the areas at which user can make transactions such as login form or registration forms etc, any area where large amount of users. can access the Software simultaneously should be automated.

Furthermore all GUI items, connections with databases, field validations etc can be efficiently tested by automating the manual process.

When to automate ?

• Test Automation should be uses by considering the following for the Software:
• Large and critical projects.
• Projects that require testing the same areas frequently.
• Requirements not changing frequently.
• Accessing the application for load and performance with many virtual users.
• Stable Software with respect to manual testing.
• Availability of time.

How to automate ?

Automation is done by using a supportive computer language like vb scripting and an automated software application. There are a lot of tools available which can be use to write automation scripts. Before mentioning the tools lets identify the process which can be used to automate the testing:

• Identifying areas within a software for automation.
• Selection of appropriate tool for Test automation.
• Writing Test scripts.
• Development of Test suits.
• Execution of scripts.
• Create result reports.
• Identify any potential bug or performance issue.
• Software testing tools

List of Automation Testing Tools :

• HP Quick Test Professional
• Selenium
• IBM Rational Functional Tester
• Silk Test
• Test Complete
• Testing Anywhere
• Win Runner - Click to see WinRunner Automation Testing Interview Questions
• Load Runner
• Visual Studio Test Professional
• WATIR

Benefits of Automated Testing

• Reliable: Tests perform precisely the same operations each time they are run, thereby eliminating human errors.
• Repeatable: You can test how the software reacts under repeated execution of the same operations.
• Programmable: You can program sophisticated tests that bring out hidden information from the application.
• Comprehensive: You can build a suite of tests that covers every feature in your application.
• Reusable: You can reuse tests on different versions of an application, even if the users interface changes.
• Better Quality Software: You can run more tests in less time with fewer resources.
• Fast: Automated tools run tests significantly faster than human users.
• Cost Reduction: The cost is reduced as the number of resources for regression test is reduced.
• Choosing the right tools for the job and targeting the right areas of the organization to deploy them can only realize these benefits. The right areas where the automation fit must be chosen.

Disadvantages of Automation Testing

Though the automation testing has many advantages, it has its own disadvantages too. Some of the disadvantages are:

• Proficiency is required to write the automation test scripts.
• Debugging the test script is major issue. If any error is present in the test script, sometimes it may lead to deadly consequences.
• Test maintenance is costly in case of playback methods. Even though a minor change occurs in the GUI, the test script has to be re-recorded or replaced by a new test script.
• Maintenance of test data files is difficult, if the test script tests more screens.

Some of the above disadvantages often cause damage to the benefit gained from the automated scripts. Though the automation testing has pros and corns, it is adapted widely all over the world.

Read more about Manual Testing and Manual Testing vs Automated testing

Define Verification and Validation in Software Testing

Various Definitions for Verification and Validation :

• Validation checks that the product design satisfies or fits the intended use (high-level checking), i.e., the software meets the user requirements. This is done through dynamic testing and other forms of review.

Verification and validation are not the same thing, although they are often confused. Boehm succinctly expressed the difference between them:

• Validation: Are we building the right product?
• Verification: Are we building the product right?

According to the Capability Maturity Model (CMMI-SW v1.1),

• Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610].

• Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610]

In other words,

• Validation ensures that the product actually meets the user's needs, and that the specifications were correct in the first place, while verification is ensuring that the product has been built according to the requirements and design specifications.
• Validation ensures that "you built the right thing". Verification ensures that "you built it right".
• Validation confirms that the product, as provided, will fulfill its intended use.

From testing perspective:

• Fault – wrong or missing function in the code.
• Failure – the manifestation of a fault during execution.
• Malfunction – according to its specification the system does not meet its specified functionality.

Within the modeling and simulation community, the definitions of validation, verification and accreditation are similar:

• Validation is the process of determining the degree to which a model, simulation, or federation of models and simulations, and their associated data are accurate representations of the real world from the perspective of the intended use(s). Accreditation is the formal certification that a model or simulation is acceptable to be used for a specific purpose.

• Verification is the process of determining that a computer model, simulation, or federation of models and simulations implementations and their associated data accurately represents the developer's conceptual description and specifications.

Black box testing and White box testing

What is black box testing and white box testing :

Black Box Testing :

Black-box testing is a method of software testing that examines the functionality of an application (e.g. what the software does) without peering into its internal structures or workings.

Definition by ISTQB

• Black box testing: Testing, either anatomic or non-functional, after advertence to the Centralized anatomy of the basic or system.

---

White Box Testing :

White box testing is aswell accepted as Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing!

Definition by ISTQB

• White-box testing: Testing based on an assay of the centralized anatomy of the basic or system

Read more about Manual Testing , Automation Testing and Manual Testing vs Automated testing

What is Waterfall model and list its advantages, disadvantages

What is Waterfall model

List its advantages and disadvantages

What is Waterfall Model ?

The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.

Traceability matrix in Software Testing with example template

What is Traceability Matrix :

A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many-to-many relationship to determine the completeness of the relationship. It is often used with high-level requirements (these often consist of marketing requirements) and detailed requirements of the product to the matching parts of high-level design, detailed design, test plan, and test cases.

A requirements traceability matrix may be used to check to see if the current project requirements are being met, and to help in the creation of a request for proposal, software requirements specification, various deliverable documents, and project plan tasks.

What is the need for Requirements Traceability Matrix in Software Testing?

Automation requirement in an organization initiates it to go for a custom built Software. The client who had ordered for the product specifies his requirements to the development Team and the process of Software Development gets started. 

In addition to the requirements specified by the client, the development team may also propose various value added suggestions that could be added on to the software. But maintaining a track of all the requirements specified in the requirement document and checking whether all the requirements have been met by the end product is a cumbersome and a laborious process.

The remedy for this problem is the Requirements Traceability Matrix.

What is Traceability Matrix from Software Testing perspective?

• A requirements traceability matrix is a document that traces and maps user requirements [requirement Ids from requirement specification document] with the test case ids. Purpose is to make sure that all the requirements are covered in test cases so that while testing no functionality can be missed.

• This document is prepared to make the clients satisfy that the coverage done is complete as end to end, this document consists of Requirement/Base line doc Ref No., Test case/Condition, and Defects/Bug id. Using this document the person can track the Requirement based on the Defect id

Types of Traceability Matrix:

• Forward Traceability – Mapping of Requirements to Test cases

• Backward Traceability – Mapping of Test Cases to Requirements

• Bi-Directional Traceability - A Good Traceability matrix is the References from test cases to basis documentation and vice versa.

Why Bi-Directional Traceability is required?

• Bi-Directional Traceability contains both Forward & Backward Traceability. Through Backward Traceability Matrix, we can see that test cases are mapped with which requirements.
• This will help us in identifying if there are test cases that do not trace to any coverage item— in which case the test case is not required and should be removed (or maybe a specification like a requirement or two should be added!). This “backward” Traceability is also very helpful if you want to identify that a particular test case is covering how many requirements?
• Through Forward Traceability – we can check that requirements are covered in which test cases? Whether is the requirements are coved in the test cases or not?
• Forward Traceability Matrix ensures – We are building the Right Product. and Backward Traceability Matrix ensures – We the Building the Product Right.

Disadvantages of not using Traceability Matrix [some possible (seen) impact] :

No traceability or Incomplete Traceability Results into:

• Poor or unknown test coverage, more defects found in production 
• It will lead to miss some bugs in earlier test cycles which may arise in later test cycles. Then a lot of discussions arguments with other teams and managers before release.
• Difficult project planning and tracking, misunderstandings between different teams over project dependencies, delays, etc

Benefits of using Traceability Matrix :

• Make obvious to the client that the software is being developed as per the requirements.
• To make sure that all requirements included in the test cases
• To make sure that developers are not creating features that no one has requested
• Easy to identify the missing functionalities.
• If there is a change request for a requirement, then we can easily find out which test cases need to update.
• The completed system may have “Extra” functionality that may have not been specified in the design specification, resulting in wastage of manpower, time and effort.

Steps to create Traceability Martix:

• Make use of excel to create Traceability Matrix:
• Define following columns:
• Base Specification/Requirement ID (If any)
• Requirement ID
• Requirement description
• TC 001
• TC 002
• TC 003.. So on.
• Identify all the testable requirements in granular level from requirement document. Typical requirements you need to capture are as follows: 
• Used cases (all the flows are captured) 
• Error Messages 
• Business rules 
• Functional rules
• SRS 
• FRS  and So on…
• Identity all the test scenarios and test flows.
• Map Requirement IDs to the test cases. Assume (as per below table), Test case “TC 001” is your one flow/scenario. Now in this scenario, Requirements SR-1.1 and SR-1.2 are covered. So mark “x” for these requirements.
• Now from below table you can conclude –
• Requirement SR-1.1 is covered in TC 001
• Requirement SR-1.2 is covered in TC 001
• Requirement SR-1.5 is covered in TC 001, TC 003 [Now it is easy to identify, which test cases need to be updated if there is any change request].
• TC 001 Covers SR-1.1, SR, 1.2 [we can easily identify that test cases covers which requirements].
• TC 002 covers SR-1.3.. So on..

Requirement ID	Requirement description	TC 001	TC 002	TC 003
SR-1.1	User should be able to do this	x
SR-1.2	User should be able to do that	x
SR-1.3	On clicking this, following message should appear		x
SR-1.4			x
SR-1.5		x		x
SR-1.6				x
SR-1.7			x

This is a very basic traceability matrix format. You can add more following columns and make it more effective:
ID, Assoc ID, Technical Assumption(s) and/or Customer Need(s), Functional Requirement, Status, Architectural/Design Document, Technical Specification, System Component(s), Software Module(s), Test Case Number, Tested In, Implemented In, Verification, Additional Comments.

The RTM Template shows the Mapping between the actual Requirement and User Requirement/System Requirement. 

Any changes that happens after the system has been built we can trace the impact of the change on the Application through RTM Matrix. This is also the mapping between actual Requirement and Design Specification. This helps us in tracing the changes that may happen with respect to the Design Document during the Development process of the application. Here we will give specific Document unique ID, which is associated with that particular requirement to easily trace that particular document. 

In any case, if you want to change the Requirement in future then you can use the RTM to make the respective changes and you can easily judge how many associated test scripts will be changing.

Click to read about other Test Documents

Black box testing and its advantages and disadvantages

What is black box testing ?

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.

Definition by ISTQB :
Black box testing: Testing, either functional or non-functional, without reference to the internal structure of the component or system. Black box test design technique: Procedure to derive and/or select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure.

 

This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see.

This method of attempts to find errors in the following categories:

• Incorrect or missing functions
• Interface errors
• Errors in data structures or external database access
• Behavior or performance errors
• Initialization and termination errors

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.

Black Box Testing Techniques :

Following are some techniques that can be used for designing black box tests.

• Equivalence partitioning
• Boundary Value Analysis
• Cause Effect Graphing

Equivalence partitioning

Equivalence Partitioning is a software test design technique that involves dividing input values into valid and invalid partitions and selecting representative values from each partition as test data.

Boundary Value Analysis

Boundary Value Analysis is a software test design technique that involves determination of boundaries for input values and selecting values that are at the boundaries and just inside/outside of the boundaries as test data.

Cause Effect Graphing

Cause Effect Graphing is a software test design technique that involves identifying the cases (input conditions) and effects (output conditions), producing a Cause-Effect Graph, and generating test cases accordingly.

Advantages of Black Box Testing :

Tests are done from a user’s 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 :

Only a small number of possible inputs can be tested and many program paths will be left untested
Without clear specifications, which is 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.

Click to know about White box testing and Gray box testing and Differences between Black Box and White Box Testing and Compare Quality-Assurance, Quality-Control, Testing

Manual Testing and its Advantages, Disadvantages

What is Manual Testing ?

• Manual testing is the oldest and most rigorous type of software testing. Manual testing requires a tester to perform manual test operations on the test software without the help of Test automation. 

• Manual testing is a laborious activity that requires the tester to possess a certain set of qualities;
• To be patient,
• Observant,
• Speculative,
• Creative,
• Innovative,
• Open-minded,
• Resourceful,
• Un-opinionated,
• Skillful.

What is Acceptance Testing - Alpha, Beta Testing

What is Acceptance Testing :

This is arguably the most importance type of testing as it is conducted by the Quality Assurance Team who will gauge whether the application meets the intended specifications and satisfies the client.s requirements. The QA team will have a set of pre written scenarios and Test Cases that will be used to test the application.

More ideas will be shared about the application and more tests can be performed on it to gauge its accuracy and the reasons why the project was initiated. Acceptance tests are not only intended to point out simple spelling mistakes, cosmetic errors or Interface gaps, but also to point out any bugs in the application that will result in system crashers or major errors in the application.

By performing acceptance tests on an application the testing team will deduce how the application will perform in production. There are also legal and contractual requirements for acceptance of the system.

When is it performed?

Acceptance Testing is performed after System Testing and before making the system available for actual use.

Who performs it?

• Internal Acceptance Testing (Also known as Alpha Testing) is performed by members of the organization that developed the software but who are not directly involved in the project (Development or Testing). Usually, it is the members of Product Management, Sales and/or Customer Support.
• External Acceptance Testing is performed by people who are not employees of the organization that developed the software.
• Customer Acceptance Testing is performed by the customers of the organization that developed the software. They are the ones who asked the organization to develop the software for them. [This is in the case of the software not being owned by the organization that developed it.]
• User Acceptance Testing (Also known as Beta Testing) is performed by the end users of the software. They can be the customers themselves or the customers’ customers.

Definition by ISTQB for Acceptance Testing

Formal testing with respect to user needs, requirements, and business processes conducted to determine  whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.

Define Alpha-Beta Testing :

Alpha Testing

This test is the first stage of testing and will be performed amongst the teams (developer and QA teams). Unit testing, integration testing and system testing when combined are known as alpha testing. During this phase, the following will be tested in the application:

• Spelling Mistakes
• Broken Links
• Cloudy Directions

The Application will be tested on machines with the lowest specification to test loading times and any latency problems.

Beta Testing

This test is performed after Alpha testing has been successfully performed. In beta testing a sample of the intended audience tests the application. Beta testing is also known as pre-release testing. Beta test versions of software are ideally distributed to a wide audience on the Web, partly to give the program a "real-world" test and partly to provide a preview of the next release. In this phase the audience will be testing the following:

• Users will install, run the application and send their feedback to the project team.
• Typographical errors, confusing application flow, and even crashes.
• Getting the feedback, the project team can fix the problems before releasing the software to the actual users.
• The more issues you fix that solve real user problems, the higher the quality of your application will be.
• Having a higher-quality application when you release to the general public will increase customer satisfaction.

Gray-Box Testing Definition, Example

What is Grey / Gray box testing ?

Definition :

Gray Box Testing is a software testing method which is a combination of Black Box Testing method and White Box Testing method. In Black Box Testing, the internal structure of the item being tested is unknown to the tester and in White Box Testing the internal structure in known. In Gray Box Testing, the internal structure is partially known. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level.

Gray Box Testing is named so because the software program, in the eyes of the tester is like a gray/semi-transparent box; inside which one can partially see.

White-Box Testing Definition, Example, Application, Advantages, Disadvantages

What is White box Testing ?

Definition :

White Box Testing (also known as Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is a software testing method in which the internal structure/design/implementation of the item being tested is known to the tester.

The tester chooses inputs to exercise paths through the code and determines the appropriate outputs. Programming know-how and the implementation knowledge is essential. White box testing is testing beyond the user interface and into the nitty-gritty of a system.

Unit Testing - Definition, Execution, Disadvantages

Unit Testing:

Click on the image for zoom view

A unit is smallest testable piece of software :

• Can be compiled, linked, loaded
• E.g functions/procedures, classes, interfaces
• Normally done by programmer
• Test cases written after coding