Software Engineering

Why automated E2E testing is essential for a valid agile process

Automated End to end testing (E2E) is something that you as a software developer should at least have heart multiple times about. This topic is always something that has haters and supporters but it is an important one anyway. Most of the people I know are not a big fan of E2E testing because of all the effort it occurs together with the dependencies you need to consider. In this blog post I will discuss why the effort is worth it and why agile development principles need E2E testing to work in a propriate way.

Let’s start with a very provocative sentence: Without E2E testing you cannot have reliable and a working continues deployment. Continues deployment describes the process of trying to deploy new releases in a continues way, so you will not have the big bang one time but you are going to deliver software every time a feature is ready for testing. Something that is essential if you are living agile development correctly as customer integration is a core part of that way of software development. But what does that mean? After every sprint, so every 1-3 weeks you need to deliver working software to the customer. Nothing worse if you are a one man development team which delivery is just a zip with one web app folder. But this is alone a pretty big deal if you have many development teams working on a microservice architecture. In such a scenario you need some kind of automation when something is ready for deployment as well as some kind of automation in terms of how the software gets ready for the customer. And in automation you always need some kind of validation, a way to have that kind of automation is E2E testing.

First of all what does E2E testing mean? E2E testing is the process of testing the whole application. So in contrast to unit testing where you just check if a granular part of the application works in E2E testing you check if the whole application works with the interactions the user might do. In a typical web application which has a registration form that would cover an automatic interaction with the GUI which the user fills out to register as well as the storing of the user and the email confirmation process. So to cover that scenario you need the whole application being set up.

What are the parts you need to consider when you decide to doing E2E testing? First of all the whole application needs to be setup in way that E2E testing is possible. If you have a web app ids on the HTML elements are very important as it is extremely difficult to address a specific element if you don’t have that. If there are no ids you would need to formulate a xpath query which is sometimes not only difficult but also might result in multiple results. Also such queries need to be adopted when something changes in the web app.

Next it is important that you need to specify when your app should be tested automatically. That is a topic for the build pipeline which needs an extra step for E2E testing which covers the setup, the execution and the clean up of the tests. Such a build step should not be a part of the actual application build process as it needs some time and a goal for efficient automatic build pipelines is that developers get feedback quick. So a typical way is that first the application gets build and pushed to a global repository (for instance Nexus) and then the E2E testing process starts.

Also you need to specify when E2E testing is necessary. As E2E testing is an effort it is typically a specify user story task. And also not always it makes sense. The discussion whether or not the user story needs E2E testing needs to take place in a meeting where the development team, testers and the PO sits together as it needs all the different opinions. A meeting which is ideal for that is a refinement. Typically you need to do E2E testing in case you have repetitive work like signing up for an application or creating some sort of general entities. More complex processes which need to be thought througth are done by manual testers. The aim of E2E testing is not to replace manual testing but to let them do the important work!

Next question might be who is responsible for creating those E2E tests as normally you need to create code for that. In my opinion creating E2E tests is a task for software developers but in a big company you might think of having employees with special know-how in E2E testing so that difficult tests can be created by them. But software developers should also create those tests so that everybody understand why something needs to be coded in a certain way (like having ids on HTML elements). Software developers are also responsible of making sure that new features do not destroy E2E tests. That in mind when estimating a new feature it is also important to think of which test might be affected.

But what has that to do with agile development? I agree that E2E testing should also be done in other software development processes. But especially for agile development principles it is important to have automated E2E tests. To understand that, you first need to think why E2E testing is done? To increase application quality, as everytime when you do tests. In agile development high quality software is important as too many bugs will result in problems when it gets to reaching sprint goals. And manual testers have lot of work to do, so they should not retest basic functionality all the time. If manual testers can focus on complex work they will find more relevant issues and this can only be done when you reduce other tasks they might need to do. Also you can make sure that the customer will not discover basic bugs when rolling out the new release as tests have checked that before.

So that is my opinion on E2E testing. It is a lot of effort but it is still worth it. What do you think about that topic?

Things to consider when choosing a new technology

Happy new year! Finally we are in 2021, the last year was definitely something very special. Hopefully everybody of you had fantastic holidays and now you get back to your job fresh-minded and motivated. And what better opportunity can we get than the beginning of new year to start with a new technology ? Wouldn’t it be great to eliminate the problems of the old framework or wouldn’t it be fantastic to use all the advantages of a new programming language?

First of all, nowadays we face the fact that we get new languages, new frameworks, new technologies nearly every hour. You just need to compare how you implemented code in 2015 and how you do it today, actually two different things. If you look a little further back in time you will see that 20 years ago solutions needed to be reimplemented all the time. For instance, most softwares included some custom implementation of a datagrid with all of its functionality. Must have been hell, or? In contrast to that, most of the programming languages used today enable us to use third party libraries for free, so we don’t have to reimplement things again and again. Ironically we get to the problem now, that there are too many libaries out there, just check the number of Javascript libraries and you understand the problem.

So, in that big cluster of programming languages and frameworks, how can you choose the correct one for your problem? The first step for me is always to check if you really need a new framework or if you can use something that exists in the company. Of course, starting from zero is something great, you can choose whatever you want, but in reality you always start from somewhere. Maybe some modules exist already, maybe there are already implemented parts. It occurs too often that programmers are too enthusiastic about a new language, just check your own feelings when you see some new language that will make your life so much easier. Personally I think that today we need to stay up to date in terms of technology but there are too many people that are a bit, let’s say critical, when it comes to learning a new technology. And that is a key factor as you are not the only software engineer in your company, if you are the only one that is aware of a language your life will get very difficult when it is used in your company.

What you also need to consider is whether or not the new technology fits to existing software modules. Sometimes it is neccessary to reimplement a software from the bottom up. But when you do that, you not only have a lot of work to do that has no obvious advantage for users of the software, but also you are throwing away years of experience. I am not saying that you shouldn’t modernize applications, but often there is a step by step way so that you do not run into a big bang where you loose all the experience from past years. I did that mistake already when I used a technology which wasn’t able to communicate with some old services that were delivering data via CORBA (yes, that thing still exists…). So I needed to reimplement the whole service, a bit more research on the project requirements would have lead to solutions that provide a interface for CORBA.

Next it is important to check if the technology is being updated regularly. Nothing is worse than implementing something in a way that will not be able to maintained because of some old technology. By doing so you would run into the same problem as I explained already, at a point you need to throw away everything and this point will come earlier than you might expect. Maybe you ask yourself now where you can check if something is maintained. Often that is specified on the website of the creators of a technology. When using a Javascript framework it is always a good idea to check the number of weekly downloads together with when the last version was deployed to npm. Also you can check Github for the last commits if there are some. For me a good number of releases is at least one every half year and if I check github and see that the last commit was 2 weeks ago everything is fine. If you see that the last commit was 5 months ago it is likely that the framework is no more supported. To make sure that this is the case also check the weekly downloads because maybe the framework is just so stable so that no checkins are needed.

Another important question is the existing know how in your company and also how likely it is that the new technology will get used without problems. Sometimes it is necessary to switch the used programming language but if nobody is able to write code with it it will not help you a lot. For instance, in a company full of C++ programmers you will not be able to choose Java as the one and only programming language, senior software developers will argue with you about the speed of the language, about how bad Java is and so on. In such a situation it would be better to question why you would use Java. Maybe it is because of the fact that it is easier to find new employees or because you are able to use some framework. To improve the acceptance it is one idea to make workshops, trainings or coding sessions with that you are able to prove that some language is better for the company. Another possability would be to choose a technology that is easier to be learned from software developers with their existing skills (in my example C# for example).

Ok, now we have chosen something that fits the requirements and is able to be used by others too. Unfortunally every creator promises everything from some framework or some language. That means that you need to make a prototype to check if the technology is really the correct solution for the problem you have. Prototyping doesn’t mean to include all the details, it means to provide some proof of concept. How long can prototype building take? Good question, the answer is actually “it depends”. But I would say, for a medium-sized problem (for instance a new module for displaying something with 3D-grafics) I would take a day to create a proof of concept. This prototype always includes an interface to one existing module to proof that it is possible to connect it to the existing software. Also I normally go throught the code with some of my colleagues just to check if everything is understandable. What you also can do is to start with a version of the framework or technology that is older and then try to update the proof of concept. By doing so you can check if the framework is able to be updateable.

Sometimes you need to cover very specifc requirements or you need to cover requirements that you are not able to cover with the proof of concept. One example would be a performance requirement in production that you will not be able to cover at the early stage as you have not the data available. In such example it is recomendable to check the internet for reports or blog posts like mine when I explained why I prefer using Angular (https://www.styriandev.at/styriandevblog/index.php/2020/02/23/some-reasons-why-i-think-you-should-consider-using-angular-for-your-next-project/). By doing so you are also checking the size of the community, a bigger community means that you can find help faster.

Also include a check if you are still able to test the software with this technology. Not only I mean that you are able to click throught it but also check if automatic unit tests or E2E tests are still possible.

One point that programmers might forget is the compatibility of the technology with the companies strategy. For instance, you will not be very successful when you try to make the company use Firebase (Backend as a Service solution by Google) when the company states in the strategy to not move towards the cloud. To not loose credability during the presentation of a technology in front of the management you should check that point.

Before we get to the end I would also like to state something that seems clear to me but might be unclear to some of you. Every decision process must be documented. It is not important which decision you make, but it is for sure that this decision will be questioned by somebody all the time. And if you have nothing that explains why you decided that something should be used by the company you can’t do this explanation. So make sure to document the advantages of the new technology, document how you plan to use it and which problems are not covered by that technology. Also communicate that documentation, at least somebody will read it and may give you useful input that you can include.

I would like to end this post by addressing you to try something out. There are fantastic new technologies enable us to do things you couldn’t have imagined some years ago. Take your pick, you will find something that will generate a perfect solution! If you try you do more than most of the others.

Get it done – How to organize yourself during stressful times

Finally back, I am sorry that I wasn’t able to write something during the last months but the reason is that the last months were full of work for me. As we are getting to christmas finally everything gets a bit more silent and relaxing (especially in that year) so there is finally more time to work on this blog which is a work I like a lot. And what better topic I could write about than how to organize yourself in stressful times as I experienced one in the last months.

In one of my first blog posts I was writing about things that you can do during a lockdown situation as we have that again right now (https://www.styriandev.at/styriandevblog/index.php/2020/03/18/how-to-make-the-best-out-of-the-corona-crisis/). Maybe you found some new activities to do and you would like to keep working on them, so it seems that you need some extra time during your daily routine. The same situation occurs when you get new tasks in your job, maybe you worked well and you proved yourself as ready for the next stage within the company. You might be ready for being team lead or just having more responsability in the company. That means that you need to organize yourself because it will be more work to do in the same time. Not only that, often you also need to educate yourself to meet the requirements of your new role. Such a situation occured to me as I got more responsability in the company I work now.

First things first, it is important to know that you cannot do everything at once. Therefore, one of the most important things is to say “No” to things that you cannot work on. I know, this seems obvious, but haven’t you been in a situation where your boss came to you and needed something you were more or less forced to say yes even thought you knew that finishing that task needed extra time in the evening? I was in such a situation too often as saying “No” seemed to be difficult to me. For me the reason for that was that often I didn’t know why I can say no because I didn’t know what was left to do – so not being organized that well. Often I was working on something that I didn’t know exactly how long that task would take and for getting a clue on how much time I need to finish I always thought in the best case szenario which especially in software engineering is a thing that never gets achieved, is it? So what I started doing was to write down the tasks that I want to finish during the day, and the thing here is to really write it down. You could of do that on paper, I am preferring it in the digital way to have it everywhere. With that list it is easy to decide whether or not a task can be completed and also this list can help to argue why it is possible to say no.

To-do lists can be very easy but of course they can also be very complex. For me the best way is a very easy list. I am using the most easy tool to work on them, which is for me a single Notepad++ document which I am using to write down tasks and when I am finishing them I am deleting the lines. I am using the simple technique as a more complex creation of tasks for me often leads to actually not doing it because administrative work is nothing that we like to do.

For more complex works like my bachelor’s thesis which I could finish during the summer I prefer using some kind of Kanban board. For me the most important part is having a tool which is pretty flexible in the stages that it has as every work has different stages. This is important because whatever task you are working on that can be pretty different, some examples are the following: For software developement you would have something like “NEW”, “Technical Specification/Analysis”, “Development”, “Testing”, “Finished” for academic papers I was having “Not Done”, “Finding literature”, “Literature summarizing”, “Writing”, “Re-read”, “Finish”. Some tools that I like to use for Kanban boards are Trello (https://trello.com/de) or the Planner app in Teams.

Another important thing in getting something done is having an idea when it is done. This simple line is summarizing one topic that many people forget having which is specifying goals. I prefer having short time and long time goals. It is important to have some strategy and vision, something like “In 5 years I would like to have my Master’s degree or something like “Next year my thesis should be completed”. But this long time goals will not help you a lot. Our brain’s are programmed in a way that they can work on things that seem to be achievable soon or seem to be very tangible. For instance if I specify that I would like to finish my thesis within a year it is difficult to motivate myself as I do not know how the hell I should finish all of that work. It is easier for me to motivate myself if I work on something like finishing a concrete topic. This is also the reason why so many people are having good intentions for the new year but never achieve them.
As you might already saw from my examples the timespan of such goals can be very different. To know if you are specifying short time goals or long time goals it is often enought to think if you would work on that immediatly. If yes that is normally a short time goal. So my suggestion is creating long term goals but also creating some short-time goals that you can achieve. This suggestion is not only for tasks but also for your life in general, with goals you know what you are working on and what you want to do with your life. By doing so you are going to be more motivated and more organized as well.

Another point that will help you which is also needing some kind of goals is having a plan for the next day/week/month. It helped me a lot when I started creating weekly plans. Those plans are not including a detailed plan for every hour of every day but they are including a general goal on what I want to achieve on the different days of the week. Formulating such goals will need some ideas on what you need to do at the specific days and therefore you will have an idea on what this week will bring to you. I prefer doing that type of task at Sunday evening when I have some minutes and I note those goals down on a paper which I stick onto a wall where I can see it. I also use that technique to note down things that I do for myself during the week, when I would like to work out or when I will meet my girlfriend. Having things that you look forward to is important to stay motivated.

My last suggestion is including how you organize your day. Especially now, when we are doing home office, you need to keep track on which activities you do in which order. The point I am trying to make is that if you are doing things you are pleased to do before you are doing things you do not like it is very likeable that you will not finish the second one as you might not be able to motivate yourself to do it. This is some error that I used to make a lot when I was spending time on YouTube before doing the actual work. The reason for that is your brain which gets a reward for wathing YouTube but not for a task that it needs to do. Therefore it is better to first work on the things you need to do and then reward yourself at the end of the day.

I hope I was able to give you some ideas how you can achieve what you want to achieve. Having goals, daily plans or just To-Do lists are some examples which will help you getting your things done.

Do you also experience a stressful time during this special year? What are you doing to get things done?

Why test driven development sucks but why you still should do it

Hey, you still reading after seeing test driven development in the title, well done. Let’s face it, testing is nothing that a software developer enjoys to do. It is lot of work, you need to think of many different cases and as your application is deployed the first test that the customer does is something you never thought about. We all know that feeling.

Especially when software is increasing it gets more complicated to test. What is the best aproach then? Of course, one option would getting a tester for your team. But what happens then? Omg, 10000 bug tickets, great, isn’t it? So today I would like to talk about some better ways of testing software and how you can integrate such processes in your existing development process.

Maybe lets start with some basics. There are different testing techniques. The application may be tested manual by someone clicking through all processes. This approach is the one that is used at first most of the time first because obviously it is the easiest thing that also the user does. Some of you may also now frameworks that do that part of testing automatically for you. As explained, this testing technique can be done without many knownledge of this topic. But what you need to keep in mind that when an application gets bigger there are many preparations need to be done to just test some piece of logic you just implemented. That is why there is another testing technique called unit testing. Unit testing is a technique to test the most granular piece of logic you have – in programming terms that means that you test methods. Unit testing is done via writing code logic that tests your code that you wrote. With unit testing you will only test one unit of the logic, meaning that you should not use other units of the application for that. This is because you focus on testing only the logic. Because you may need to test also the behaviour your class has in the context of a bigger part of the application there is also something between the described techniques, this one is called integration testing.

So, next, what is test driven development. It is a way of creating software by thinking first about tests your new logic requires. Literature mostly describes that technique in terms of unit testing meaning that you first create or unit tests and then writing the logic. But in my mind this can also be done at a much higher level. You can also do “test driven development” by formulate tests while creating a new requirement. As a product manager/owner/requirements engineer this is something you do while thinking about requirements anyway. Something like “ok, when I click there I would like this to happen”. By using testing cases while formulating new requirements software engineers will understand the requirements better too. And it could also lead to other test cases by the software engineers or even better ways of doing the same. In a scrum way of creating software I would suggest to add a section in the user story that is covering all the test cases. And that test cases will be used to show how everything should work. This section must be of course flexible because there may be cases where software engineers think of new test cases needed during development.

Alright, now let’s move on to code testing. I think that creating unit tests for your code is essential especially when you are working on a project with different software engineers. That is because such unit tests can be seen as an approve that the whole logic works. Think about new features you develop and during development you may adopt some pieces of code in backend. Wouldn’t it be great to have something that makes you sure that all the other pieces will still work? Unit tests make that happen if they are included in the build. And here comes the most important thing, NEVER, and I really mean NEVER create a production build with some “build-skip-tests” flag. Once done everybody will do that and therefore nobody will care about tests. And when you finally think, ok, maybe let’s fix the test you will end up getting very frustrated because lot of work will be needed to be done.

The amount of time you need to write unit tests isn’t low, that is true. But if you think of the amount of time you would need to retest everything in a complex product just to see if your piece of code didn’t broke any functionality the effort of writing tests is totally worth it. It is much faster to develop pieces of logic incrementally and test the code by the created unit tests. Also, if you write unit tests before writing the class you gonna see that you will think more about the structure and the requirements that this piece of logic should cover. And programming by trying out things is, as we all know, normally not the best way of doing things.

Writing unit tests will also lead to a kind of documentation for the code. Just think of when you last got into a project with thousand different classes covering lot of logic. You normally need lot of time to understand where you should put some code. If the project is well tested and for all logic pieces a test exist you will notice that engineers will first check out the tests and with those tests they can understand the logic. Of course, you can achieve the same by comments in the code, but what project does not include deprecated comments? Deprecated test cases are not possible, because if they cover some old logic they will fail. That is why developers will adopt tests when adding new logic. And that leads to some kind of documentation for the code.

Tests can also be used for new employees to get into the companies way of coding. Together with an experienced developer the new employee could start with creating a unit test for some logic that the senior is then implementing. After some rounds the setup can also be changed that the new employee is writing the actual piece of logic. By doing that the senior could explain frameworks/base methods and so on and the new employee is able to find out how everything works.

Test coverage is a measurement to identify how many lines of your whole application are covered with tests. When companies try to add unit tests they often include a “100% or at least 90% code coverage” strategy. 100% of code coverage would mean that all lines of your whole application are tested, also those boring getter and setter methods. And I have a problem with such strategies. It is simply not possible to cover all code pieces. In my mind all important parts that contains logic must be tested. By that I mean business logic classes, complex calculations and so on. Some code of a framework, like a spring repository in java, is nothing that will not work. Therefore I don’t think you need to test these.

E2E testing is a technique that is used for testing the whole application by something that really clicks through a deployed app. So instead of manually testing everything an automated part will do that. This kind of testing is used to test parts of the application that are not very complex to test but testing these all the time would cost lot of time. By creating E2E tests you will increase the quality of your application since it is testing the whole thing over and over again. But those kind of tests need an application setup that not everybody has. For web applications for instance without ids on all the dom elements it is very complicated to address different pieces of the application. Also such tests are very complex and timeconsuming to create. It is neccessary to create a presetup of the test, than all the tests are executed and then all the things need to be deleted again to not create negative side effects. Also running those tests need many time since they really simulate a user doing things in the application. Therefore such tests should not be included in every build but they should be executed at least once a day. I think E2E tests make sence for application parts that are very boring and repeatable to test like some sign up process. Including such kind of tests needs some preparation and also must be calculated in terms of the time effort that they need.

Alright, those are my thoughts of testing software. What is your experience and which testing technique is your favourite?