Software testing is the act of testing… software… yeah it’s pretty obvious but the topic still has its trick. The goal of software testing is to provide enough information about what is being tested in order to meet certain requirements.
These requirements commonly being, but not limited to:
- Meeting the requirements that guided its design and development
- Responding correctly to all kinds of inputs
- Performing its functions within an acceptable time
- Being sufficiently usable
- Able to be installed and run in its intended environments
Similarly to other topics in this blog, this topic has a process to follow, and this one has a number of steps that can be seen below.
Test Plan: We have seen this before in verification and validation, a test plan can be a document detailing what needs to be tested, how it will be tested, the objective of the test and what to do if the test fails.
Test Design: This will be defined in the test plan; the test design dictates the nature of the test. Will it be a manual test? Will it be automatic? How does it work?
Test execution: In the execution the test will be executed, important things to consider in this point are how much time you have for it and how much time does it take to complete.
Exit criteria: unexpected problems are common in tests; this is why they are here for. So you define what completes the test or completely halts it.
Test reporting: This step will take place once the test has been completed, how well did it go? Was the result satisfactory?
Manual vs automated tests
Manual tests and automated tests each have their disadvantages and advantages, and with a complex code or system the line that separates these 2 types of tests is more evident.
Manual testing is done by a human, giving inputs and receiving what the software returns. This has the advantage that a person is interacting directly with the product which will yield results that can be very specific right of the bat and it is a way of flexibility in the tests.
Automated testing in the other hand is a more robust and straightforward type of test. These are performed by the machine which was preloaded with the necessary instructions. They might not be as flexible and perhaps not be as visual as a manual test, but it is quicker to execute (since you only have to write it one time in order to test 1000 times), it is 100% safe from human errors and can provide quality results, depending on how well it was written.
With this in mind we can now see the various types of tests there are and how they are ordered:
Levels of testing
Unit Testing
During this first round of testing, the program is submitted to assessments that focus on specific functions, individual programs or components of the software to determine whether each one is fully functional. One of the biggest benefits of this testing phase is that it can be run every time a piece of code is changed, allowing issues to be resolved as quickly as possible. It is common for software developers to perform unit tests before delivering software to testers for formal testing.
Integration Testing
Integration testing combines all of the units within a program (most likely previously tested in unit testing) and test them as a group. This testing level is designed to find interface and comunication defects between the modules/functions. This is particularly beneficial because it determines how efficiently the units are running together.
System Testing
System testing is the first level in which the complete application is tested as a whole. The goal at this level is to evaluate whether the system has accomplished all of the requirements and to see that it meets the quality standards of the project.
System testing is done by testers who did not play a role in developing the program. This testing is performed in an environment that closely resembles production.
Acceptance Testing
The final level, Acceptance testing (or User Acceptance Testing), is conducted to determine whether the system is ready for release. During the Software development life cycle, requirements changes can sometimes be misinterpreted in a fashion that does not meet the intended needs of the users. During this final phase, the user will test the system to find out whether the application meets their business’ needs.
For more types of testing visit here: https://www.softwaretestinghelp.com/types-of-software-testing/
Activities and roles in testing:
We’ve seen till now that testing is quite the important task in order to maintain quality in the software, but another important aspect is the people in charge of the tests. There are quite some roles involved in the process of testing, each functioning differently from one another to cover the most aspects possible of the product.
The types of roles involved in testing are shown below:
QA Leader: The face and manager of the testing team; this position presents the connection between the team and whoever wants to contact it
- Acts as a point of contact for inside and outside interactions, meaning it represents the entire team when dealing with customer relationships
- Decides about test budget and test schedule, also manages resources and plans the testing process
- Delegates the testing activities to the team
- Makes status reports of the testing activities
Test Lead: Highly intelligent and wise, this position will provide great understanding of technical skills such as data management, test design and test development
- Has technical expertise regarding test programs and how to approach them
- Provides support for customer interface and will deliver progress status reports.
- Validates the quality of testing requirements. (Testability, test design etc.)
- Implements the test process
- Ensures documentation is complete
Test engineer: This position’s job is to determine the best way to create a process to test a product in the most complete manner possible. There are different roles a test engineer can have, and its area of expertise will depend in which role it takes.
- Usability Test engineer: Best suited for designing usability testing scenarios and has great understanding of usability issues.
- Manual Test engineer: Great understanding of the GUI design and its standards. It is best suited for manually testing and attending test procedure walkthroughs.
- Automated Test engineer: Great understanding of software testing and GUI design. It is best suited for working with test tools in order to build and execute automated tests.
Network Test engineer: Great understanding of databases, operating systems, programming languages and networking. They are best suited for integration testing since they know a little about everything.
Test library and Configuration Specialist: This position will be in charge of managing changes and version control.
- Manages changes to the test-script
- Maintains test-script version control
- Creates test builds whenever required
Tester: This position has to be able to interact efficiently with the testing team, it will design scenarios that would require testing and will execute the tests as defined in the standards and procedures.
- Designs the testing scenarios for usability testing
- Analyzes test results and submits reports to the development team
- Conducts testing as marked in the standards and procedures
Testing environments
We already know about the process of testing and the roles to be taken to accomplish the task, but we still need to know some stuff that will help testing greatly. This is testing environments.
A test environment is a combination of hardware, software, data and configurations which are required in order to test different test cases. These environments are commonly found in the shape of servers and virtual set ups which can be replicated. A testing environment is a very important tool to have at disposition if you want to have confidence in the test results and jump from saying “Well it works just fine in MY computer” to saying “It works on all operating systems with these minimum specifications”.
There are types of testing environments which focus on changing and configuring different aspects of the software:
Integration testing environment
In this environment different software modules are integrated to form a system, and then the test will proceed to verify its behavior.
Environment setup depends on the type of product that wants to be tested. It usually consists on ensuring availability of the right hardware, the right software version and the right configuration. The trick on this environment is that it should mimic production scenarios as closely as possible. This includes servers, databases or any other service required to be involved. This environment is focused in testing communication and functionality between all the components, which is why every other aspect of the environment is set to work in optimal conditions.
Performance testing environment
In this environment the system’s performance will be tested. This means that performance goals like concurrency, throughput, response time and stability will be put to test. A good performance testing environment place a crucial role in defining the bottlenecks in the system tested. What component is slowing down things or what thing breaks if too much stress is bestowed to it are questions this test environment will focus on answering.
The test will vary in the specifications of the hardware, amount of concurrency in the system and the volume of data managed.
This type of test is time consuming and expensive compared to other tests, which is why it is recommended to run this tests only in required occasions, for example every major change in the system or once a month.
Security testing environment
This type of testing environment focuses on finding security flaws and vulnerabilities. To create this environment organizations usually contract internal or external security experts that will try to identify any vulnerability in the software.
A good security testing environment will try to be isolated from external sources and try to use mock data that is not in production.
Chaos testing environment
The chaos environment focuses in trying to make the product fail in any point of the execution and make that failure cascade into making the whole system fail. This is done by understanding the dependencies within the project. These environments are set just the same as a production environment and trying to combust the server into a state of error recovery phase, It is kind of when schools make a fire drill to see the reaction of the students and their exit time. Because of the nature of chaos testing environment, it is executed as rarely as the performance testing environment. Very often they are tested alongside each other.
Test case design techniques
There are different types of techniques that are used to test the software’s functionality. These techniques can be categorized into 3 types
Specification based technique
Also known as Black-Box technique, this type of technique consists of testing based on defined specifications and test cases, this will provide the tests of this nature with a very wide coverage in test cases. One thing to note is that this technique does not use any information regarding the internal structure of the component or system to be tested.
Structured based technique
Also known as the white box technique, the structured based technique takes in consideration the internal structure of the tested components and it is used to derive test cases deemed necessary.
Experience based techniques
This technique will depend on the experience of the team using it. The knowledge and experience of people are used to derive test cases and it is more useful in identifying special tests not easily captured by formal techniques.
For more information you can visit this link
Process for control and management of defects in artifacts
The only thing left to see about software testing is how we can manage the defects we find with the previous knowledge. This is as simple as following some steps in order to classify the defect and resolving it.
Discovery
In the discovery phase, the project team tries to discover as many defects as possible before anyone else can discover them. A defect is said to be discovered and change to status accepted when it is acknowledged and accepted by the developers.
Categorization
Defect categorization helps the software developers to prioritize their tasks. There are types of categories as seen below and developers will categorize defects based on the effects they have on the product.
Resolution
Resolution will stand for the process of fixing the defects. Defect resolution process starts with assigning discovered defects to developers, then defects are fixed and developers send a report of resolution to the test manager.
Verification
After the development team fixed and reported the defect, the testing team verifies that the defects are actually resolved.
Closure
Once a defect has been resolved and verified, the defect is changed status as closed. If the defect has not been resolved the defect has to be checked again in the resolution step with the new observations.
Reporting
Test managers prepare and send the defect report to the management team for feedback on defect management process and defects’ status.
To victory!!! 