Testing in Software Engineering
What is it and why do we do it?
As in any different product delivering business, testing in software engineering is an essential step to make sure our product is on track along the way of developing it.
Although one could think that testing the final product should be enough, testing software is more similar to testing cars. when your final product consists of many different elements and components working together as one body, testing can be prioritized by stage of development:
1. Making sure every element works fine on its own which means testing the outcome of every element on its own.
2. Putting the different elements together and making sure they function the way they are intended to.
3. Assembling the whole product and making sure the whole thing delivers to its promises.
Unit testing
Even with the different development patterns, unit testing remains the responsibility of the developer.
In the next steps, I will highlight the different actors who can perform every specific type of testing.
Unit testing is one of the most common tests in software development, engineers write their tests before writing any code.
Then writing their code, software engineers make sure it passes the tests they have in place. as its name indicate unit test targets units (functions) and in a well designed software those have single responsibility with well defined inputs and outputs.
Because unit testing is very low-level, it is dependant on the programming language used. below are examples of languages and their corresponding unit test frameworks and tools.
In addition to the need of knowing the development language, a unit tester or the developer needs to know the requirements and the code.
Integration testing
One level up from unit testing, a build or component test is to make sure that those singular units work well together and don’t conflict.
Both developers or testers can write/run those tests.
Integration testing can be done following two methods:
- Bottom-up integration: testing begins from small to big, from unit tests, followed by higher level and bigger modules combining many units.
- Top-down integration: starts with testing builds/modules and follows with unit testing.
Ususally integration testing is done bottom-up first followed by top-down integration tests.
System testing
After testing all our components/builds, we have those working together now, we have a system running.
Testing the system is an important step to make sure the business requirements are implemented and that the application is behaving by the business rules.
System testing is the first time the application is tested as a full solution and it is usually tested in environment that is so close to the production environment.
A specialized testing team performs this type of testing, and makes sure the application meets quality standards.
Regression testing is specific to when changes and bug fixes are introduced to the application, and its main intent is to make sure no other features or business rules has been affected.
Acceptance testing
After all the previous tests, that were happening along the way of the product development lifecycle, the product in question is almost ready.
Specialized Quality Assurance teams put it to the test now to make sure it meets the intended specifications and client’s requirements.
Armed with use-case scenarios and test cases, QA teams will thoroughly test for any bugs in the application that will result in system crashes or major errors in the application in addition to pointing to spelling mistakes, cosmetic errors and Interface gaps.
Alpha and Beta are well known phases of acceptance testing.
Conclusion
So as a software engineer you are only responsible of the first levels of testing, even though testing engineers can also use development and coding skills.
A lot of testing is being automated using languages like Python.
Pipelines are being engineered and built to keep the process of development, and testing pretty automated and seamless which you might have encountered before as CI/CD continuous integration and continuous deployment. Those pipelines are ruled by test script results.
In later articles, I would love to go deeper into unit testing, would choose a language and build some unit tests, and I will explain more about automation in tests.
