Not so long ago, there was a common misconception that testers were individuals whose main goal was to make developers’ job miserable. It was also believed that they are the main reason why the final product is always delayed. Fortunately, with the increased awareness of project participants at every stage of its development, this myth is slowly fading away. These days, “disliking” testers is, shall we say, rather archaic.
This increase of awareness and change of the IT environment mentality is the reason why performing professional, accurate tests has become a standard practice. In fact, testers have become an integral part of development teams. It is to ensure that our product is always of the highest quality and, of course, reliable – we want reliability to be the main feature that our company is associated with. That special ingredient that attracts customers and convince them to stay with us.
This trend is also popular with research and development teams. As a rule, these teams require high creativity and readiness to use new tools, languages or technologies. In this article we will try to explain the role of testers in the SDNbox project and what challenges they face in their daily work.
What does a tester do?
The information available on the Internet throws some light on who software testers are and what they actually do.
A software tester is a person responsible for verifying the correct operation of a software or system. Their duties also include functionality testing. A tester’s work mainly consists of detecting errors and bugs and informing developers responsible for the given product or its parts about their presence. Their works helps to improve the quality of the software or allows for creation of a new one.
This description creates an image of a tester as a person responsible for reducing the number of defects in the tested software to a minimum. The defects may include:
- non-compliance of the implementation with the provided product documentation,
- undesirable software behaviour resulting from the execution of actions that were not foreseen by the developer,
- incorrect (from the end user’s point of view) behaviour of the software.
Although the above-mentioned duties are a large part of a tester’s job, they are not the only responsibilities they have in a team. In other words, their work is not limited to the constant pursuit of defects. They are also performing other important tasks, such as taking care of test documentation, creating reports based on carried out tests, presentation of developed products, or even suggesting changes based on experience. To make the tester’s work more effective – depending on the project – they can use the assets resulting from good design methodologies.
Agile project, agile tester
The SDNbox project involves several development teams, working together based on Scrum, a methodology that is quite popular today. This enigmatic buzzword means that the team has the right skills (such as developer, architect, tester, or scrum master competencies) to deliver the product or part of it within a specific timeframe, the so-called “sprint”. However, this does not mean that the team member is only performing the tasks of their role. There are situations when testers who do well with their tasks are given simpler programming tasks as part of their development. And the other way round, sometimes developers take their time to perform tests.
Proper cooperation within the team, as well as mutual transfer of knowledge and development of skills, broadening of competencies – these factors allow for maintaining continuity of the team’s work – even when there are some unforeseen absences or even extended holidays.
I know what I’m doing, or where to start with testing?
Before test planning, it is essential to have a proper understanding of the deployed functionality. At first, the number of interdependencies between individual components and the secrets of their operation may seem incomprehensible to the production team. This is where systems analysts get involved.
Analysts create use cases based on previously prepared user stories. These in turn form the basis for the correct definition of test cases. In order to get a better idea of the context of the deployed functionality, HLD (High Level Design) diagrams, developed by architects, are used.
Based on the collected knowledge, testers have a basis to start the process of developing and implementing test cases. During the case design process, the tester focuses not only on covering the scope presented in the use cases, but they also ensure testing of the most extreme situations and all other possible behaviours, which – according to their knowledge – could cause a system malfunction.
Working in accordance with Scrum methodology, the test cases are created in parallel with the software, not after its completion. This approach significantly speeds up the development process. It allows to find potential defects even during test design, as requirements may not match the presented case.
Continuous development, or from manual to automatic tests
The next step after defining the test cases is to implement them properly. This in turn is closely related to the level of advancement of the project. As you know – the more you get into it, the more complicated it becomes. While for the first tests it was enough to send a simple HTTP request to REST and read the response code, as the project develops it becomes necessary to test functionalities implemented on lower levels of the OSI model (also called the reference model).
Tools such as SCAPs proved to be helpful in test performance. However, the ability to manually build, send, or receive an Ethernet frame did not allow to simulate the proper operation of the tested mechanisms in the target network. Here the communication between individual frames takes place within a fraction of a second. Regardless of the amount of manual effort, we will never be able to replicate such a situation by sending subsequent frames manually.
It became necessary to automate the entire process. Our company based its first attempt to do so on the Robot framework. Clear and intuitive graphical interface allowed for quick familiarisation with the tool, but after a short time problems emerged with a not quite correct operation of libraries responsible for communication function in the second layer.
However, due to subsequent battles with not quite correctly implemented libraries in the Robot, our team decided to abandon this solution. Instead, we focused on writing tests in Python using the Pytest framework. This solution allowed the development team to play a much bigger role both in reviewing the new test code and in creation of the tests. As a result, it is safe to say that supporting the team during the seemingly arduous process of getting into Python testing has improved collaboration. It was also extremely helpful, and paid off for everyone.
Research and development
Writing tests in an SDNbox project involves careful selection of tools and technologies that will be able to simulate the desired action. The process of selecting a specific tool involves the necessity of verifying its capabilities – both in terms of the adopted premises and compliance with the applicable standards. Due to the innovative nature of the project, we often had a hard time finding a ready-made tool that would meet our expectations.
So, where did we start? The process of selecting such a tool begins with an initial recognition of its capabilities. It is followed by a simple task that confirms its usefulness (the so-called PoC – proof of concept). Depending on the results of the PoC, the solution may be accepted and implemented in the project or rejected. In such a case the process starts all over again. It often happens that the tool meets our requirements only partially. This necessitates additional implementation to meet all design needs.
Tester development in the SDNbox project
Working on an R&D project does not allow for stagnation. The increasing level of technical advancement of the project requires testers to undergo continuous development which is necessary to properly understand the issues of the implemented solution. Without it, it will not be possible to prepare tests that are able to check this solution.
Continuous development does not only refer to the specialisation in the field the tester is currently “dealing with”. Experienced specialists dealing with testing or programming have the possibility to extend their competencies with knowledge within the scope of specialisation of other departments. How? By taking part in chapters and guilds, which according to Spotify’s model nomenclature means meetings that bring together all people involved in software testing within a project or the whole company. This, of course, is beneficial both to them and to the project as a whole. There is therefore nothing to stop the tester from acquiring knowledge needed to effectively carry out the tasks of the DevOps department, or to delve into the secrets of the work of a Scrum Master.
