”Life as…” is a blog series where we dive into professionals’ everyday work life and get to learn more about their chosen profession.
In this part of ”Life as...” we meet Viktor Nilsson who works as a test developer at Infotiv.Viktor have studied System, Control & Mechatronics at Chalmers University of Technology. The education program is a combination of electricity, mechanics, electronics, and programming. During a summer break, Viktor started working at Infotiv. It was also at this time he encountered testing. At Infotiv he realized there was a whole industry involving test development. Since 2014, Viktor works as a consultant at Infotiv. Viktor has also taken the role as competence leader where he is responsible for competence development investments. In addition to this, Viktor has previously been responsible for educations at IT-högskolan where he was a teacher in software testing. At Infotiv, his work title is Inhouse test developer, which means being a project manager for project towards clients and within the company.
In this blog post, Viktor will describe software testing, its different steps, manual test vs automated tests and what the future holds for the test development industry.
Software testing, roughly, include two general questions:
The first questions include what we had planned to build and develop from the beginning. The second question means that it is possible to build something that works exactly like we expected it to, there are no errors for example. But if nobody wants the product, it doesn’t serve any function or purpose and does not add any value, then it is likely that we don’t move forward with the product.
The two questions are different from each other, but both are equally relevant. It goes both ways; it’s possible to build something that tries to add value but does not work properly. It’s not a complete product. These are questions that software testers try to answer. Then, of course, there are details, and we can dig deep into these questions. But it is always on the basis of these questions that the software test starts from.
When performing a test of a product, there are multiple steps to go through. The picture above shows a simplified and general picture of that process. Traditionally, this have been a process that stretch over a long period of time. You plan six months or a year ahead and then you go through each step in the process. However, this is something that has changed in recent years. A modern software development team might go through this process once a day or once a month. This is because the faster you have developed a software, the shorter you want to make the process. For the modern team, the timespan is shortened but there are still various parts that you try to make into smaller and smaller steps.
Planning is the starting point of the process. Questions to answer is:
This part of the process is something that happens simultaneously, particularly if you work with automatization. A test could be done multiple times a day or at least every night. We need to understand what we have tested and if we have covered everything in the tests. If the team are in the beginning of the development phase, then the answer probably will be no, and we have to perform more tests. The team then need to start designing. It’s about looking at the test results and ask if everything worked as we expected it to. We also consider if there are anything else that needs to be tested.
In this step we go into detail of what we are building. It can be new features that we plan to add to the product that is being developed. We might want our product to manage a new type of payment solution through our web shop or we might want to make a car autonomous. This will result in different requirements for our testing. In this step we take what we are developing into consideration and as a test developer you think of how do we test in the best possible way.
This part is also about collaboration. If the team works in a modern organization, the employees often work tightly together. The test developers, programmers and the person keeping track of the client’s demand are three common members of the team. It’s important that all three are involved to be able to understand what we plan to build, what’s new and which parts that won’t change. It’s important that the functions that already exists in the product will continue to work regardless if a new function is added or not. Not many customers would accept a new functionality at the cost of an old one that stops working. The larger and more complex a product gets, the more code and more functionalities we have that we need to make sure still works.
You need to know where something might go wrong and where in the product or service the biggest risk of errors are. This will control how we design and plan our testing. If we know from previous experience that payment solutions are difficult to deal with, then we also know we will need to put a lot of effort into having a functioning invoice solution. We might also need to put a lot of time on manual testing to really understand how everything works. Here the experts at writing code can come in and point to the things that might cause trouble for the team. Then, we can use that in the test design to be able to test as efficiently as possible. As with any development, there will be limited time and resources. Therefore, it is important to make considerations: “Where should we put the effort to be able to get out as much as possible?”. It’s important to think outside the normal use of a product. There will be customers who does things completely different than what we have thought. There might be scenarios that may not be very common, especially during the development phase. If you distribute your product to 100 000 users and there is a low frequency of odd behavior, then this behavior still will occur a lot of times.
In this step we create a plan for our manual tests, or we implement automated tests when possible and suitable.
If manual tests are part of the process, it is in this step they will be executed. If it’s about automated tests, you press start and wait for the results.
This step is about making conclusions from the process. The team will compile the results to be able to evaluate the product. We ask ourselves if the product is ready or not. And then, the process starts all over again.
Often, there is nothing that will be finished, instead it’s about developing a new feature for example. You might also need to do another round of the process if we feel that the product didn’t live up to the expectations. Then we look at the possibilities for improvements or we test it again. Traditionally, testing have been something to be done at the end and have been seen as something that we just need to check off in our list. This has often meant, if something else in the process takes longer time than expected, the testing will be squeezed in at the end. Today, in modern companies it’s common to involve testing as early as possible in the process. For example, with each feature that is being developed this will happen simultaneously.
The different steps in the process are something that test developers go through multiple times, especially if the work is done in fast, short loops and the goal is to release finished products continuously.
When I wrote my Research Paper at Volvo Trucks, one question often came up: “How fast does our automated test need to give a result back?”. The aim was 250 milliseconds. This was an acceptable time frame to be able to give a first response. We quickly realized that it would be impossible to cover everything in 250 milliseconds. But a first response should arrive during this time frame, from the code being written, and then communicated that it is ready for testing and then for it to give feedback. The reason it being 250 milliseconds is because if it is more than that, then we lose focus and other things like coffee breaks becomes more interesting instead. We want to give fast feedback to the people writing the code to be able to let them know if the code was good enough or if it didn’t work as we planned. If you would be given your test results one month later, then you might experience difficulties when trying to remember how we thought at that time. For this process to go as fast as possible, we need automatization. We won’t be able to automate everything, however, automatization is a key part when giving a first response.
Now I will discuss how we at Infotiv work with testing. This approach is not something we came up with ourselves, it’s something the whole industry is working towards. The three cornerstones that we base our testing on is: methodology, infrastructure, and test systems. Let’s start with methodology.
The methodology part includes which test strategies we need that is part of the long-term plan. “How do we build a product that can be tested?”. We need a plan to be able to know how to assemble the product for it to be a finished product.
Way of working is about working in an agile way. This means working in small teams and for the team to focus on a part of the product instead of seeing coding and testing as two separate activities for example. It’s also about how we communicate our results and how we collaborate.
Living documentation is about the importance of documenting our work. This is important since we might need to go back and look into what we did three months ago for example. It also involves the question regarding what demands we set for our product earlier and how it would work.
This cornerstone also involves ISTQB- certification which is a certification with different levels within software testing, from basic level to more advanced. At Infotiv we educate and certificate on the basic level. We think it’s important to create a basic understanding among our consultants regarding software development.
This part becomes more and more important if you work with automatization, since there are several systems that software testers encounter. It’s everything from framework for test automatization to continuous integration. Continuous integration means that the team use small code changes that happens continuously to build a product. It also means to have the product tested to be able to make sure the product is working the way it should. The infrastructure part is also about analyzes and measurements of the ongoing testing. It can be about monitoring and to be able to give a test result in a transparent way that we can base our decisions on. The last part, server architecture, is tightly connected to IT. Since automated testing is a complex process, we need support and the competencies from IT.
Test systems is connected to what is located close to the product. How we integrate with a product, for example. An example connected to this is if we have a computer in a car. The computer is used to communicating with 100 different computers. But we only want to test one computer and we want to make this in an isolated way. Then, we need a system that allow us to fool the software to believe it’s located in an actual car, even though it is not. This is about how we interact with what’s being tested in the most effective way possible. This is a crucial part within automatization.
Automated tests and manual tests have different application areas. Automated tests can be useful with tests that will be done multiple times. Additionally, it’s useful when we need to confirm that we will cover a behavior that won’t disappear. If we test a web shop for example, the customer can log in and look at their orders etc. Therefore, it is important to make sure all the current functionalities still work when we introduce a new feature. This is something that can make the value for the customer to disappear.
The manual testing is useful for finding errors in the more complex situations. The manual testing should be used shortly after the code have been written. This is because we want to be able to find complex cases that might take several steps into the product. In these cases, manual testing is a better choice. To find new errors is an area where manual testing is useful and to make sure we don’t destroy something previously developed then automatization is more useful. We need to take this into consideration, since automatization can bring a lot of insights if you are in the development phase. In this phase we want feedback on what we are developing to know how to move forward. It’s important to be aware of the limitation with automated tests and what we need to test manually.
https://digital.ai/periodic-table-of-devops-tools
In the image above, you see an overview of the most popular tools within automated testing. The different colors indicate different categories. A challenge that we often encounter is to pick the best combination of tools in order to create a complete tool chain. Along the way, you might have to switch some parts out during the process if you find better tools or new tools that replace old ones. This is an important challenge to consider within the architecture part of the tools.
It’s very uncommon that a person knows all the tools an employer asks for. If a person has worked a lot within a certain category, most likely there are some similarities between the programs. There will always be a certain overlap, if I know the tool Maven then I will recognize a lot of things in Gradle for example. I will need to learn new things but the concept and purpose with the tool goes along with it. Therefore, it’s more important to understand a chain and its components rather than knowing a specific tool.
To learn new tools is a reality for consultants. When you arrive at a new job and there is a high probability that there will be tools that you don’t know. This is the case with programming and programming languages as well. If you know some sort of programming, there will be a lot of things in common and things that you can use from previous experiences.
To work in teams is a development that have taken major steps. Traditionally, there have been a department that codes and one department that tests. It’s becoming more and more common to combine the two and be consultants with a different depth than before. An area where testing is an ongoing development is to combine the three specialist competencies: person responsible for the code, person responsible for the test and the person to keep the clients demands in mind. When working in teams we need to answer the following questions:
The person responsible for the code needs to be a competent programmer that can solve the customers problems with good code. The person being responsible for the testing needs to have knowledge in automated tests and manual testing. The team have to build something that they actually can sell. Therefore, we need a person that both understands the customers’ needs and at the same time understands interaction design, meaning that the product is looking appealing and is easy to use for example. I think this is one thing that is easy to miss if you come from a test- and programmer background, where you just focus on the code.
A role that hasn’t been mentioned before is a person that know IT and the infrastructure, meaning how we get the tools to work and how to make sure the servers keep going etc. From my perspective, I can see teams struggling that want to increase their pace, but they don’t have the support or competence from IT, and therefore it can be difficult for them to move on.
We have to combine these specialist competences, and make sure that all parts are included. We might have written a lot of code, but we don’t know if the product works. We can have written a lot of test cases, but we don’t have a product living up to the expectations. Or we have both the code and test, but we don’t really know if we have built the right product because we haven’t had any communication with the person that knows what the product should be able to do. To synchronize this and to take small steps instead, is a part where I see a lot of challenges in the future and where there are a lot of potential for development.
I think the work with fast feedback loops will become even more important in the future. Today, companies aim to get their products out to the market as fast as possible. A car shouldn’t take five years to develop, instead this time frame should be shortened, and a functioning software should be released to the market in a faster pace. There will therefore be a high demand for technical knowledge to be able to make this work. But there will also be a need of a tighter collaboration between the test developers and the experts who write the code. I think it will be important to be able to work even closer in a team, and to take advantage of the whole tool chain for example. We usually talk about that we need to have our knowledge in a t-shaped form. This means that we need a broad foundation to stand on but at the same time we need our specialization. It’s important that you share you foundation among your co-workers. As a test developer you need to understand how the product is built to be able to test it quickly and efficiently. As a test developer, I need to communicate with my colleagues and learn from the people being good at programming to be able to understand the whole process. I believe this is an important part. The faster a product can be released, the quicker we get paid which of course is a huge driving force.
During my career I have encountered two different ways of becoming a test developer. I have studied five years at Chalmers University of Technology, and I feel I have a good foundation to stand on. I would have been able to manage software development, even though I only use a little bit of what I learned during the programming courses. But I have spent five years during my education solving difficult problems which is something I can bring along with me. Several of my colleagues that I have worked with have went to more specialized educations towards software testing such as vocational educations. They gain more specific tool knowledge. They also have the fundamental understanding of what test is and what it could add to the software development process. I think it is possible to pursue a career with both educations, it’s more about continuous self-development. If you have a university degree, then you will need to get to know specific tools compared to if you come from a more specialized vocational education then you might need to practice more problem solving. This, of course, depends on which direction you want to go for. If you want to become a good test developer within automatization for example, then I would say the people going to a more specialized vocational education have the upper hand. This is because they have both programming and the specific tools for test automatization.
If the interest is towards test strategies instead and “the big architecture”, a longer technical education resulting in a university degree, might be a good choice since it probably will provide a greater understanding for complex systems for example.
I think there could be aspects of testing where the testing could be useful. A fundamental testing activity and quality assurance method that both test developers and programmers use is a type of review that we call friend check. You ask a colleague if they can double check to make sure everything is looking like it should. After working as a test developer and working with code review, I can’t send an Excel-document without a colleague have taken a look on it. It’s very easy to make mistakes when writing code and even easier to do a mistake in an Excel-form. If I were to guess, I believe there are companies where it can have a huge impact if one zero extra is added to an Excel-sheet.
This is an area I see potential in, to collaborate and work in teams where you review each other’s work. Within programming there is a concept called couples programming, where you sit together with someone else to make sure there are no mistakes.
A Society is the consulting company of tomorrow and can help consultants find assignments at companies who are looking for specialists within IT and test development. Register an account on our website and you will get a contact person from A Society who will reach out to you and hear what type of assignments you are looking for. You will also get access to all assignments that are advertised in our network. Joining our network is completely free!
Read more articles from specialists in our network such as Johan Sjögren who works as a Machine Learning Consultant or Paulina Raymond, a UX-designer.