10 years of open source test case management
Todorov, Alexander
In the world of professional QA there are many proprietary test management tools but very few open source ones. This lightning talk will tell the audience why and how we resurrected Kiwi TCMS and what are we doing to make it the best open source test case management system! FOSDEM marks 10 years since the first version was released and our team will celebrate at the Open Source Test Management stand, Building K, Level 2, stand 10!
 Okay, hello, how are you? Good. My name is Alex and I have been coming to Foshtem for the past 10 years, every single year. And this is my first time doing a tightening talk. This is also my first time when I'm traveling together with a team so far I've been alone. And this is also the first time our team is having a project stand here at the conference and all of this is pretty cool. And I want to tell you the colorful history of Kiviti CMS and what we do, what we stand for. And I want to tell you that we are turning 10 years old this week. We are celebrating here at Foshtem so it's all good. So but first, what is test case management? When you do software testing, quality assurance, you need to keep a lot of information around. You need information about which version of your software was tested, on what kind of environment, which build, what kind of test cases were executed, which ones were not executed, what was the testing result. And at the end, all of this information goes down to should I ship this version to the customer or no. If you are a test manager, maybe a test lead, you will go to the system, take a look at the test results, figure out how happy you are with the current state of affairs in testing and make the decision, ship or don't ship. So in the commercial world, there are quite a few options for such systems. They are relatively popular. There are some that look very nice, others that look rather ugly. There are plugins for JIRA, there are standalone systems, desktop systems and web systems and so on. In the open source world, we don't have a lot of options. Initially, there was test link. It's very old projects. Many of you might have heard it. It is still a little bit active. They released about one version a year or something like that. Then after test link came to Stopia, another project from Mozilla, again open source, working in the same domain space. They lasted for a couple of years and it kind of disappears. Unfortunately, Mozilla doesn't use the Stopia anymore. They don't support it. Although there are some commits made to the repository. So not really active. And in 2009, I was working at Red Hat, starting my career as a software tester. And they decided, well, we don't like the current systems that are available in the open source world. So let's build another one. And this is how it was born. This is the first version that was released 10 years ago. And this is how our history starts. So this thing continues development for a while privately. And as we know, everything Red Hat touches becomes open source. So this is no exception. In late November 2014, the source code was pushed to GitHub. This is a nice thing by itself. Unfortunately, the way this was done was kind of indicating the direction where upstream was going. We have one single commit, no prior history, a bunch of files put together. We have no idea what they are, how they work. Turns out there is a lot of source code which was not used. There were a lot of functions which were not used. There were duplicate functions copied around different modules which were not in use. The test suite wasn't working. So all of that in the initial commit. So anyway, the GitHub history tells you that development continues for a while. From what I can tell mostly from people who are on the original theme of the upstream system. And then slowly in the next year, in 2015, kind of dies away. So at that time, I was consulting for a small startup company. And we wanted to use such systems. So the obvious choice is whatever is open source that is available on GitHub, let's take it, make a deployment internally, figure it out if it doesn't work. We'll fix it. So this is what we do. And we immediately start running into problems. So first upstream is using a very, very old version of Django that is full with security problems with bugs. We want to upgrade immediately. That's not possible because you cannot just jump from Django 1.6 to 2.0. So you have to go through every single minor version and fix a lot of stuff that is failing in between to actually be able to upgrade. Upstream is using MySQL. We are using Postgres. And you will say, well, it's an ORM-based system, but it's not. It's ORM-based and we had a lot of hard-coded SQL statements in the source code which work only on MySQL. They didn't work on Postgres. So we had to fix. Upstream was using vagrant for deployment. We were using Docker. So we had to build our own Docker images as well. So fix, fix, fix. And we started sending pull requests upstream. Some of them got merged, but most of them didn't. And the funny thing is my first ever pull request to the upstream repository was made almost three years ago and it is still open to this day. That is about changing the bug tracker system in this tooling. So upstream integrates, they have hard-coded bugzilla.redhead.com as the bug tracking system and you cannot use anything else. That's still open. So what we do, we do a lot of internal development. We do fixes. We start deploying internally. And we kind of start liking the system. And at the same time, I left the startup company and I decided I will continue to work on this alone because I like it. And I think it can be a nice project. It can be revived. So the obvious thing of choice to do when upstream is dead is to create a fork. And this is what I did. So I took the fork which we had internally in the startup company. It was in a private repository. So I took it externally to my personal GitHub account. Continue development. And during that time, I was able to fix the entire test suite, clean all the application warnings, remove tons of stuff that we don't need. We have removed, just for reference, about 20,000 lines of code. And the system continues to work pretty much with the same functionality in the same way that it used to do before. So you have a function that works with your data. And then you have another function that is called from the front end via Ajax. And it does the same thing. It just copies the code. It doesn't use the other function. And then you have the same action somewhere else in the system. It just copies the same thing over and over again. So we fix all of these things. We started building Docker images and started pushing them publicly for everybody on Docker Hub. And surprise, surprise, people actually started to download them and to use them. They started reporting bugs and started contributing and so on. And I was starting to realize that all of this to handle is too much for a single person. So I asked my friend Yanis from Mozilla. Yanis, tell me what should I do if I want this to continue? And he tells me, well, if you want this project to have any chance of surviving and becoming a little bit more popular, it needs to be independent from yourself. You have to create a separate GitHub organization. It needs to have a website so people can follow the progress if they're interested and so on and so forth. And most importantly, you need to have a team that will help you with all of these things. So I decided to follow the advice of my friend and started building the website and the option was build it myself or ask somebody else to do it for me. And I chose the second option. So I found three young developers and I told them, listen, I want this simple website to be built. I will tell you how to do it. I will teach you all the technical skills that you need to have. But you need to commit on GitHub. You need to help me. And if you like it, you can continue further to work on the project. And they built the website. They learned a lot of stuff. From the three of them, only one was left on the team. This is, you know, this guy here. He is very young. And the reason he's not here today is because he cannot travel abroad. He's too young. So after that, he decided to like stay around in the project, learn Python, learn Django, started fixing a lot of pilot errors. And until now, he's fixed more than 3,000 pilot errors that we had in the source code alone, which is quite impressive for somebody who didn't know anything less than one year ago. Then we had Anton who joined a little bit later and he's a little bit more experienced developer. But again, he learned Python, he learned Django, started working on the backend stuff with me. Now he's working on a lot of the frontend stuff, changing how all the pages look and feel in the system. We're migrating to another library for the user interface, which is like more modern, nicer to use. And this is mostly done by himself alone. So I just give some directions and I do the initial like proof of concept for some page and then leave everything to them to do. And during all of this time, I've been trying to make the project more popular. I've been trying to recruit other people to help us, be part of the core team. And we hit a snack with a lot of them. So we've got people who wanted to join the team and then didn't feel motivated enough to stay around and to contribute. We had people who didn't want to learn all the skills that they were missing, although we provide all the information for them. So we had to kick them out, unfortunately. And right around this time, I started to realize that it is too much for me to handle both the people side and the technical side. And that is why we have Renny, who is our team coach. And these two guys, they are over here. So applause for them. Thank you very much for helping me. So we've got a team and we need a community. And the way to build a community is to let it form itself. So we enable the community to form around the project. People ask for translations. We find a suitable translation system for them to document how to use this. They start contributing. And we've got French, Slovenian and German translations 100% contributed by the community. We don't speak these languages. Next we document how to set up your development environment, how to deploy the Docker images, how to configure the project. Because it's Django, it's straightforward, but it turns out a lot of people are not familiar with Django and it's hard for them. Once you document all of these steps and make it easy for them, they start contributing. And last but not least, you have to travel and you try to spread the word and tell people about your project. And we've done quite a lot of traveling last year, to be honest. Way too much traveling. The nice thing is we meet other people who work in the same domain space. So we are not alone. Two of these guys are Daniel from Germany and Dimitri from Belarus. And they both work on related open source projects. So they work on system test portal and report portal. And the three of us together today and tomorrow are hosting the open source test management stand here at FOSTEM. So come and say hi, learn something that maybe you don't know about testing, how it's done, how you can collect all the results in these various systems, what they can do, and so on. And last year has been very successful for us. We have, we started with pretty much zero external contributors and by the end of the year, we have had contributions from some relatively big companies and organizations, small contributions from big names. We have also had bigger contributions towards the end of the year from somewhere from Brazil. I don't really know where that is. Some states which I haven't heard before about a good contribution from a person. He didn't ask any questions, just send a pull request. It was perfect. We could merge it immediately. And we have decided, okay, the community starts to form around the project. So let's set up like a bigger goal for the project. We want to be the best in this field and we want to reorganize to change how testing is done in an organization. We have posted a lot of request for comments on GitHub, a lot of ideas, some screenshots. What can be done? What is possible technically? What is possible on the organization level? There are a lot of people who gave us feedback. If you do software testing, quality assurance, feel free to give us feedback to tell us that we are not doing something right or that we are idiots or maybe that you like it, hopefully. And the last thing is we celebrate 10 years. If you can figure out what this thing means, do the actions and come by the open source test management stand. We have a present for you. Thank you very much. I think we have only one minute for questions. Two minutes. Okay. Cool. Anybody? Question? Comment? Anyone can solve the puzzle? Oh, no, not allowed. Yeah, it's a puzzle, yeah. If you can solve it. Yeah, but if they tell everybody then. No. Doesn't matter. So any puzzle? No. Okay. No, you have to think about it. So thank you very much for listening to me. Thank you, Alex.
 Okay, hello, how are you? Good. My name is Alex and I have been coming to Foshtem for  the past 10 years, every single year. And this is my first time doing a tightening talk.  This is also my first time when I'm traveling together with a team so far I've been alone.  And this is also the first time our team is having a project stand here at the conference  and all of this is pretty cool. And I want to tell you the colorful history of Kiviti  CMS and what we do, what we stand for. And I want to tell you that we are turning 10  years old this week. We are celebrating here at Foshtem so it's all good. So but first,  what is test case management? When you do software testing, quality assurance, you need  to keep a lot of information around. You need information about which version of your software  was tested, on what kind of environment, which build, what kind of test cases were executed,  which ones were not executed, what was the testing result. And at the end, all of this  information goes down to should I ship this version to the customer or no. If you are  a test manager, maybe a test lead, you will go to the system, take a look at the test  results, figure out how happy you are with the current state of affairs in testing and  make the decision, ship or don't ship. So in the commercial world, there are quite a  few options for such systems. They are relatively popular. There are some that look very nice,  others that look rather ugly. There are plugins for JIRA, there are standalone systems, desktop  systems and web systems and so on. In the open source world, we don't have a lot of  options. Initially, there was test link. It's very old projects. Many of you might have  heard it. It is still a little bit active. They released about one version a year or  something like that. Then after test link came to Stopia, another project from Mozilla,  again open source, working in the same domain space. They lasted for a couple of years and  it kind of disappears. Unfortunately, Mozilla doesn't use the Stopia anymore. They don't  support it. Although there are some commits made to the repository. So not really active.  And in 2009, I was working at Red Hat, starting my career as a software tester. And they  decided, well, we don't like the current systems that are available in the open source world.  So let's build another one. And this is how it was born. This is the first version that  was released 10 years ago. And this is how our history starts. So this thing continues  development for a while privately. And as we know, everything Red Hat touches becomes  open source. So this is no exception. In late November 2014, the source code was pushed  to GitHub. This is a nice thing by itself. Unfortunately, the way this was done was kind  of indicating the direction where upstream was going. We have one single commit, no prior  history, a bunch of files put together. We have no idea what they are, how they work.  Turns out there is a lot of source code which was not used. There were a lot of functions  which were not used. There were duplicate functions copied around different modules which  were not in use. The test suite wasn't working. So all of that in the initial commit. So anyway,  the GitHub history tells you that development continues for a while. From what I can tell  mostly from people who are on the original theme of the upstream system. And then slowly  in the next year, in 2015, kind of dies away. So at that time, I was consulting for a small  startup company. And we wanted to use such systems. So the obvious choice is whatever  is open source that is available on GitHub, let's take it, make a deployment internally,  figure it out if it doesn't work. We'll fix it. So this is what we do. And we immediately  start running into problems. So first upstream is using a very, very old version of Django  that is full with security problems with bugs. We want to upgrade immediately. That's not  possible because you cannot just jump from Django 1.6 to 2.0. So you have to go through  every single minor version and fix a lot of stuff that is failing in between to actually  be able to upgrade. Upstream is using MySQL. We are using Postgres. And you will say, well,  it's an ORM-based system, but it's not. It's ORM-based and we had a lot of hard-coded SQL  statements in the source code which work only on MySQL. They didn't work on Postgres. So  we had to fix. Upstream was using vagrant for deployment. We were using Docker. So we  had to build our own Docker images as well. So fix, fix, fix. And we started sending pull  requests upstream. Some of them got merged, but most of them didn't. And the funny thing  is my first ever pull request to the upstream repository was made almost three years ago  and it is still open to this day. That is about changing the bug tracker system in this  tooling. So upstream integrates, they have hard-coded bugzilla.redhead.com as the bug  tracking system and you cannot use anything else. That's still open. So what we do, we  do a lot of internal development. We do fixes. We start deploying internally. And we kind  of start liking the system. And at the same time, I left the startup company and I decided  I will continue to work on this alone because I like it. And I think it can be a nice project.  It can be revived. So the obvious thing of choice to do when upstream is dead is to create  a fork. And this is what I did. So I took the fork which we had internally in the startup  company. It was in a private repository. So I took it externally to my personal GitHub  account. Continue development. And during that time, I was able to fix the entire test  suite, clean all the application warnings, remove tons of stuff that we don't need. We  have removed, just for reference, about 20,000 lines of code. And the system continues to  work pretty much with the same functionality in the same way that it used to do before.  So you have a function that works with your data. And then you have another function that  is called from the front end via Ajax. And it does the same thing. It just copies the  code. It doesn't use the other function. And then you have the same action somewhere else  in the system. It just copies the same thing over and over again. So we fix all of these  things. We started building Docker images and started pushing them publicly for everybody  on Docker Hub. And surprise, surprise, people actually started to download them and to use  them. They started reporting bugs and started contributing and so on. And I was starting  to realize that all of this to handle is too much for a single person. So I asked my friend  Yanis from Mozilla. Yanis, tell me what should I do if I want this to continue? And he tells  me, well, if you want this project to have any chance of surviving and becoming a little  bit more popular, it needs to be independent from yourself. You have to create a separate  GitHub organization. It needs to have a website so people can follow the progress if they're  interested and so on and so forth. And most importantly, you need to have a team that  will help you with all of these things. So I decided to follow the advice of my friend  and started building the website and the option was build it myself or ask somebody else to  do it for me. And I chose the second option. So I found three young developers and I told  them, listen, I want this simple website to be built. I will tell you how to do it. I  will teach you all the technical skills that you need to have. But you need to commit on  GitHub. You need to help me. And if you like it, you can continue further to work on the  project. And they built the website. They learned a lot of stuff. From the three of them,  only one was left on the team. This is, you know, this guy here. He is very young. And  the reason he's not here today is because he cannot travel abroad. He's too young. So  after that, he decided to like stay around in the project, learn Python, learn Django,  started fixing a lot of pilot errors. And until now, he's fixed more than 3,000 pilot  errors that we had in the source code alone, which is quite impressive for somebody who  didn't know anything less than one year ago. Then we had Anton who joined a little bit  later and he's a little bit more experienced developer. But again, he learned Python, he  learned Django, started working on the backend stuff with me. Now he's working on a lot of  the frontend stuff, changing how all the pages look and feel in the system. We're migrating  to another library for the user interface, which is like more modern, nicer to use. And  this is mostly done by himself alone. So I just give some directions and I do the initial  like proof of concept for some page and then leave everything to them to do. And during  all of this time, I've been trying to make the project more popular. I've been trying  to recruit other people to help us, be part of the core team. And we hit a snack with  a lot of them. So we've got people who wanted to join the team and then didn't feel motivated  enough to stay around and to contribute. We had people who didn't want to learn all the  skills that they were missing, although we provide all the information for them. So we  had to kick them out, unfortunately. And right around this time, I started to realize  that it is too much for me to handle both the people side and the technical side. And  that is why we have Renny, who is our team coach. And these two guys, they are over here.  So applause for them. Thank you very much for helping me. So we've got a team and we  need a community. And the way to build a community is to let it form itself. So we enable the  community to form around the project. People ask for translations. We find a suitable translation  system for them to document how to use this. They start contributing. And we've got French,  Slovenian and German translations 100% contributed by the community. We don't speak these languages.  Next we document how to set up your development environment, how to deploy the Docker images,  how to configure the project. Because it's Django, it's straightforward, but it turns  out a lot of people are not familiar with Django and it's hard for them. Once you document  all of these steps and make it easy for them, they start contributing. And last but not  least, you have to travel and you try to spread the word and tell people about your project.  And we've done quite a lot of traveling last year, to be honest. Way too much traveling.  The nice thing is we meet other people who work in the same domain space. So we are not  alone. Two of these guys are Daniel from Germany and Dimitri from Belarus. And they both work  on related open source projects. So they work on system test portal and report portal. And  the three of us together today and tomorrow are hosting the open source test management  stand here at FOSTEM. So come and say hi, learn something that maybe you don't know  about testing, how it's done, how you can collect all the results in these various systems,  what they can do, and so on. And last year has been very successful for us. We have,  we started with pretty much zero external contributors and by the end of the year, we  have had contributions from some relatively big companies and organizations, small contributions  from big names. We have also had bigger contributions towards the end of the year from somewhere  from Brazil. I don't really know where that is. Some states which I haven't heard before  about a good contribution from a person. He didn't ask any questions, just send a pull  request. It was perfect. We could merge it immediately. And we have decided, okay, the  community starts to form around the project. So let's set up like a bigger goal for the  project. We want to be the best in this field and we want to reorganize to change how testing  is done in an organization. We have posted a lot of request for comments on GitHub, a  lot of ideas, some screenshots. What can be done? What is possible technically? What is  possible on the organization level? There are a lot of people who gave us feedback. If  you do software testing, quality assurance, feel free to give us feedback to tell us that  we are not doing something right or that we are idiots or maybe that you like it, hopefully.  And the last thing is we celebrate 10 years. If you can figure out what this thing means,  do the actions and come by the open source test management stand. We have a present  for you. Thank you very much. I think we have only one minute for questions.  Two minutes. Okay. Cool.  Anybody? Question? Comment? Anyone can solve the puzzle? Oh, no, not allowed.  Yeah, it's a puzzle, yeah. If you can solve it. Yeah, but if they tell everybody then.  No. Doesn't matter. So any puzzle? No. Okay. No, you have to think about it. So thank you  very much for listening to me. Thank you, Alex.
10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_0_167.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_168_275.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_276_443.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_444_527.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_528_767.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_768_827.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_828_923.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_924_1667.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_1668_1775.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_1776_1871.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_1872_2075.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_2076_2171.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_2172_4103.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_4104_5615.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_5616_8627.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_8628_11399.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_11400_15275.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_15276_16775.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_16776_19631.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_19632_21215.png 10_years_of_open_source_test_case_management_with_Kiwi_TCMS_AD70w4F2NII_21216_21331.png
Okay, hello, how are you? Good. My name is Alex and I have been coming to Foshtem for the past 10 years, every single year. And this is my first time doing a tightening talk. This is also my first time when I'm traveling together with a team so far I've been alone. And this is also the first time our team is having a project stand here at the conference and all of this is pretty cool. And I want to tell you the colorful history of Kiviti CMS and what we do, what we stand for. And I want to tell you that we are turning 10 years old this week. We are celebrating here at Foshtem so it's all good. So but first, what is test case management? When you do software testing, quality assurance, you need to keep a lot of information around. You need information about which version of your software was tested, on what kind of environment, which build, what kind of test cases were executed, which ones were not executed, what was the testing result. And at the end, all of this information goes down to should I ship this version to the customer or no. If you are a test manager, maybe a test lead, you will go to the system, take a look at the test results, figure out how happy you are with the current state of affairs in testing and make the decision, ship or don't ship. So in the commercial world, there are quite a few options for such systems. They are relatively popular. There are some that look very nice, others that look rather ugly. There are plugins for JIRA, there are standalone systems, desktop systems and web systems and so on. In the open source world, we don't have a lot of options. Initially, there was test link. It's very old projects. Many of you might have heard it. It is still a little bit active. They released about one version a year or something like that. Then after test link came to Stopia, another project from Mozilla, again open source, working in the same domain space. They lasted for a couple of years and it kind of disappears. Unfortunately, Mozilla doesn't use the Stopia anymore. They don't support it. Although there are some commits made to the repository. So not really active. And in 2009, I was working at Red Hat, starting my career as a software tester. And they decided, well, we don't like the current systems that are available in the open source world. So let's build another one. And this is how it was born. This is the first version that was released 10 years ago. And this is how our history starts. So this thing continues development for a while privately. And as we know, everything Red Hat touches becomes open source. So this is no exception. In late November 2014, the source code was pushed to GitHub. This is a nice thing by itself. Unfortunately, the way this was done was kind of indicating the direction where upstream was going. We have one single commit, no prior history, a bunch of files put together. We have no idea what they are, how they work. Turns out there is a lot of source code which was not used. There were a lot of functions which were not used. There were duplicate functions copied around different modules which were not in use. The test suite wasn't working. So all of that in the initial commit. So anyway, the GitHub history tells you that development continues for a while. From what I can tell mostly from people who are on the original theme of the upstream system. And then slowly in the next year, in 2015, kind of dies away. So at that time, I was consulting for a small startup company. And we wanted to use such systems. So the obvious choice is whatever is open source that is available on GitHub, let's take it, make a deployment internally, figure it out if it doesn't work. We'll fix it. So this is what we do. And we immediately start running into problems. So first upstream is using a very, very old version of Django that is full with security problems with bugs. We want to upgrade immediately. That's not possible because you cannot just jump from Django 1.6 to 2.0. So you have to go through every single minor version and fix a lot of stuff that is failing in between to actually be able to upgrade. Upstream is using MySQL. We are using Postgres. And you will say, well, it's an ORM-based system, but it's not. It's ORM-based and we had a lot of hard-coded SQL statements in the source code which work only on MySQL. They didn't work on Postgres. So we had to fix. Upstream was using vagrant for deployment. We were using Docker. So we had to build our own Docker images as well. So fix, fix, fix. And we started sending pull requests upstream. Some of them got merged, but most of them didn't. And the funny thing is my first ever pull request to the upstream repository was made almost three years ago and it is still open to this day. That is about changing the bug tracker system in this tooling. So upstream integrates, they have hard-coded bugzilla.redhead.com as the bug tracking system and you cannot use anything else. That's still open. So what we do, we do a lot of internal development. We do fixes. We start deploying internally. And we kind of start liking the system. And at the same time, I left the startup company and I decided I will continue to work on this alone because I like it. And I think it can be a nice project. It can be revived. So the obvious thing of choice to do when upstream is dead is to create a fork. And this is what I did. So I took the fork which we had internally in the startup company. It was in a private repository. So I took it externally to my personal GitHub account. Continue development. And during that time, I was able to fix the entire test suite, clean all the application warnings, remove tons of stuff that we don't need. We have removed, just for reference, about 20,000 lines of code. And the system continues to work pretty much with the same functionality in the same way that it used to do before. So you have a function that works with your data. And then you have another function that is called from the front end via Ajax. And it does the same thing. It just copies the code. It doesn't use the other function. And then you have the same action somewhere else in the system. It just copies the same thing over and over again. So we fix all of these things. We started building Docker images and started pushing them publicly for everybody on Docker Hub. And surprise, surprise, people actually started to download them and to use them. They started reporting bugs and started contributing and so on. And I was starting to realize that all of this to handle is too much for a single person. So I asked my friend Yanis from Mozilla. Yanis, tell me what should I do if I want this to continue? And he tells me, well, if you want this project to have any chance of surviving and becoming a little bit more popular, it needs to be independent from yourself. You have to create a separate GitHub organization. It needs to have a website so people can follow the progress if they're interested and so on and so forth. And most importantly, you need to have a team that will help you with all of these things. So I decided to follow the advice of my friend and started building the website and the option was build it myself or ask somebody else to do it for me. And I chose the second option. So I found three young developers and I told them, listen, I want this simple website to be built. I will tell you how to do it. I will teach you all the technical skills that you need to have. But you need to commit on GitHub. You need to help me. And if you like it, you can continue further to work on the project. And they built the website. They learned a lot of stuff. From the three of them, only one was left on the team. This is, you know, this guy here. He is very young. And the reason he's not here today is because he cannot travel abroad. He's too young. So after that, he decided to like stay around in the project, learn Python, learn Django, started fixing a lot of pilot errors. And until now, he's fixed more than 3,000 pilot errors that we had in the source code alone, which is quite impressive for somebody who didn't know anything less than one year ago. Then we had Anton who joined a little bit later and he's a little bit more experienced developer. But again, he learned Python, he learned Django, started working on the backend stuff with me. Now he's working on a lot of the frontend stuff, changing how all the pages look and feel in the system. We're migrating to another library for the user interface, which is like more modern, nicer to use. And this is mostly done by himself alone. So I just give some directions and I do the initial like proof of concept for some page and then leave everything to them to do. And during all of this time, I've been trying to make the project more popular. I've been trying to recruit other people to help us, be part of the core team. And we hit a snack with a lot of them. So we've got people who wanted to join the team and then didn't feel motivated enough to stay around and to contribute. We had people who didn't want to learn all the skills that they were missing, although we provide all the information for them. So we had to kick them out, unfortunately. And right around this time, I started to realize that it is too much for me to handle both the people side and the technical side. And that is why we have Renny, who is our team coach. And these two guys, they are over here. So applause for them. Thank you very much for helping me. So we've got a team and we need a community. And the way to build a community is to let it form itself. So we enable the community to form around the project. People ask for translations. We find a suitable translation system for them to document how to use this. They start contributing. And we've got French, Slovenian and German translations 100% contributed by the community. We don't speak these languages. Next we document how to set up your development environment, how to deploy the Docker images, how to configure the project. Because it's Django, it's straightforward, but it turns out a lot of people are not familiar with Django and it's hard for them. Once you document all of these steps and make it easy for them, they start contributing. And last but not least, you have to travel and you try to spread the word and tell people about your project. And we've done quite a lot of traveling last year, to be honest. Way too much traveling. The nice thing is we meet other people who work in the same domain space. So we are not alone. Two of these guys are Daniel from Germany and Dimitri from Belarus. And they both work on related open source projects. So they work on system test portal and report portal. And the three of us together today and tomorrow are hosting the open source test management stand here at FOSTEM. So come and say hi, learn something that maybe you don't know about testing, how it's done, how you can collect all the results in these various systems, what they can do, and so on. And last year has been very successful for us. We have, we started with pretty much zero external contributors and by the end of the year, we have had contributions from some relatively big companies and organizations, small contributions from big names. We have also had bigger contributions towards the end of the year from somewhere from Brazil. I don't really know where that is. Some states which I haven't heard before about a good contribution from a person. He didn't ask any questions, just send a pull request. It was perfect. We could merge it immediately. And we have decided, okay, the community starts to form around the project. So let's set up like a bigger goal for the project. We want to be the best in this field and we want to reorganize to change how testing is done in an organization. We have posted a lot of request for comments on GitHub, a lot of ideas, some screenshots. What can be done? What is possible technically? What is possible on the organization level? There are a lot of people who gave us feedback. If you do software testing, quality assurance, feel free to give us feedback to tell us that we are not doing something right or that we are idiots or maybe that you like it, hopefully. And the last thing is we celebrate 10 years. If you can figure out what this thing means, do the actions and come by the open source test management stand. We have a present for you. Thank you very much. I think we have only one minute for questions. Two minutes. Okay. Cool. Anybody? Question? Comment? Anyone can solve the puzzle? Oh, no, not allowed. Yeah, it's a puzzle, yeah. If you can solve it. Yeah, but if they tell everybody then. No. Doesn't matter. So any puzzle? No. Okay. No, you have to think about it. So thank you very much for listening to me. Thank you, Alex.
time doing a tightening talk. This is also my first time our team is having a project stand of Kiviti CMS and what we do, what we stand for. test case management? When you do software commercial world, there are quite a few options web systems and so on. In the open source world, first version that was released 10 years ago. And the system. And at the same time, I left the simple website to be built. I will tell you how