TYPES OF SOFTWARE TESTING
What are the different Types of Software Testing?
We, as testers are aware of the various types of Software Testing such as Functional Testing, Non-Functional Testing, Automation Testing, Agile Testing, and their sub-types etc.
Each of us would have come across several types of testing in our testing journey. We might have heard some and we might have worked on some, but not everyone has knowledge about all the testing types.
#1) Alpha Testing
It is the most common type of testing used in the Software industry. The objective of this testing is to identify all possible issues or defects before releasing it into the market or to the user.
#2) Acceptance Testing
An acceptance test is performed by the client and verifies whether the end to end the flow of the system is as per the business requirements or not and if it is as per the needs of the end user. Client accepts the software only when all the features and functionalities work as expected.
It is the last phase of the testing, after which the software goes into production. This is also called User Acceptance Testing (UAT).
#3) Ad-hoc Testing
The name itself suggests that this testing is performed on an ad-hoc basis i.e. with no reference to the test case and also without any plan or documentation in place for such type of testing. The objective of this testing is to find the defects and break the application by executing any flow of the application or any random functionality.
Ad-hoc testing is an informal way of finding defects and can be performed by anyone in the project. It is difficult to identify defects without a test case but sometimes it is possible that defects found during ad-hoc testing might not have been identified using existing test cases.
#4) Accessibility Testing
The aim of accessibility testing is to determine whether the software or application is accessible for disabled people or not. Here disability means deaf, color blind, mentally disabled, blind, old age and other disabled groups. Various checks are performed such as font size for visually disabled, color and contrast for color blindness etc.
#5) Beta Testing
Beta Testing is a formal type of software testing which is carried out by the customer. It is performed in the Real Environment before releasing the product to the market for the actual end users.
Beta testing is carried out to ensure that there are no major failures in the software or product and it satisfies the business requirements from an end-user perspective. Beta testing is successful when the customer accepts the software.
Usually, this testing is typically done by end-users or others. It is the final testing done before releasing an application for commercial purpose. Usually, the Beta version of the software or product released is limited to a certain number of users in a specific area.
So end user actually uses the software and shares the feedback to the company. Company then takes necessary action before releasing the software to the worldwide.
#6) Back-end Testing
Whenever an input or data is entered on front-end application, it stores in the database and the testing of such database is known as Database Testing or Backend testing. There are different databases like SQL Server, MySQL, and Oracle etc. Database testing involves testing of table structure, schema, stored procedure, data structure and so on.
#7) Browser Compatibility Testing
It is a subtype of Compatibility Testing (which is explained below) and is performed by the testing team.
Browser Compatibility Testing is performed for web applications and it ensures that the software can run with the combination of different browser and operating system. This type of testing also validates whether web application runs on all versions of all browsers or not.
#8) Backward Compatibility Testing
It is a type of testing which validates whether the newly developed software or updated software works well with older version of the environment or not.
Backward Compatibility Testing checks whether the new version of the software works properly with file format created by older version of the software; it also works well with data tables, data files, data structure created by older version of that software. If any of the software is updated then it should work well on top of the previous version of that software.
#9) Black Box Testing
Internal system design is not considered in this type of testing. Tests are based on the requirements and functionality.
Detailed information about the advantages, disadvantages, and types of Black box testing can be seen here.
#10) Boundary Value Testing
This type of testing checks the behavior of the application at the boundary level.
Boundary value Testing is performed for checking if defects exist at boundary values. Boundary value testing is used for testing a different range of numbers. There is an upper and lower boundary for each range and testing is performed on these boundary values.
Testing Tools
Every major software development framework or language has a set of tools that help you to test your code. With Ruby and Ruby on Rails, we most commonly use RSpec. RSpec is actually written in Ruby (Ruby testing Ruby!) and it lets you execute a broad and flexible script of tests to make sure your application is still working the way that it should. RSpec’s syntax even reads sort of like English, though it still takes some getting used to.
Test Coverage
Backing up to the highest level, how much testing do you need anyway?
We use the term Test Coverage to describe how much of the code is actually tested, but what does 100% “test coverage” really mean? Do you test every method? Every possible path the user could take through your application? Every possible way that any logical branch (e.g. an if statement) of your code can be run? You will always need to compromise between an acceptable level of coverage and the complexity (and time) costs of implementing a highly granular test suite.
Some ways of thinking about test coverage dive in deeper than you need to remember, but should give you a healthy respect for how much people have thought about testing over the years. Borrowing heavily from Wikipedia:
- Function Coverage — Has each function or subroutine been called?
- Statement Coverage — Has each statement been executed?
- Branch Coverage — Has each branch of each control structure been executed?
- Decision Coverage — Has every possible decision in the program been tested? Similar but not identical to branch coverage.
- Condition Coverage — Has every boolean sub-expression been both
trueandfalse? - State Coverage — Has each state in a finite-state machine been reached?
- Parameter Value Coverage — In a method taking parameters, have all the common values for those parameters been tried?
In a web environment, there are also a variety of simulation tests that can be run. You not only test the methods of your application on a specific level, but you can “fire hose test” the whole application by throwing thousands of requests at it per second and see what breaks first.
Testing Levels
There are also different levels of testing. Starting as specific as possible and getting more general, they are listed below:
- Unit Testing — Isolating a very specific unit of code by faking any inputs/outputs/methods inside it and testing its characteristics. Is the function working as expected?
- Integration Testing — Verifying the interfaces between units. This can occur on many levels, from small modules to high-level architectural components.
- System Testing — Verifying that the fully integrated system meets its requirements without corrupting its environment.
- Acceptance Testing — The system is delivered to the user (or Product Owner in Agile) for acceptance or rejection.
1. Basic functionality testing
Begin by making sure that every button on every screen works. You also need to ensure that you can enter simple text into each field without crashing the software. You don’t have to try out all the different combinations of clicks and characters, or edge conditions, because that’s what your testers do—and they’re really good at that. The goal here is this: don’t let other people touch your work if it’s going to crash as soon as they enter their own name into the username field. If the feature is designed to be accessed by way of an API, you need to run tests to make sure that the basic API functionality works before submitting it for more intensive testing. If your basic functionality testing detects something that doesn’t work, that’s fine. Just tell them that it doesn’t work, that you’re aware of it, and that they shouldn’t bother trying it. You can fix it later, just don’t leave any surprises in there.
2. Code review
Another pair of eyes looking at the source code can uncover a lot of problems. If your coding methodology requires peer review, perform this step before you hand the code over for testing. Remember to do your basic functionality testing before the code review, though.
3. Static code analysis
There are tools that can perform analysis on source code or bytecode without executing it. These static code analysis tools can look for many weaknesses in the source code, such as security vulnerabilities and potential concurrency issues. Use static code analysis tools to enforce coding standards, and configure those tools to run automatically as part of the build.
4. Unit testing
Developers will write unit tests to make sure that the unit (be it a method, class, or component) is working as expected and test across a range of valid and invalid inputs. In a continuous integration environment, unit tests should run every time you commit a change to the source code repository, and you should run them on your development machine as well. Some teams have coverage goals for their unit tests and will fail a build if the unit tests aren’t extensive enough.
Developers also work with mock objects and virtualized services to make sure their units can be tested independently. If your unit tests fail, fix them before letting someone else use your code. If for any reason you can’t fix them right now, let the other person know what has failed, so it won’t come as a surprise when they come across the problem.
5. Single-user performance testing
This is particularly true for back-end code. But developers should also be looking at single-user performance on the front end and making sure the software is responsive when only they are using the system. If it’s taking more than a few seconds to display a web page taken from a local or emulated (and therefore responsive) web server, find out what client-side code is slowing things down and fix it before you let someone else see it.