Articles with tag community

Kiwi TCMS is donating € 10000 (ten thousand euro) to our community to enable more hands working together and give an opportunity for people to get exposed to open source contributions. You can read more about the rules of the program in Round 01!

Bounties announced in Round 02

Custom pylint plugins:

#736, #738, #1126, #1303, #1384

Automation tests:

#1596, #1597, #1598, #1599, #1600, #1601, #1602, #1603, #1604, #1605, #1606, #1607, #1608, #1609, #1610, #1611, #1612, #1613, #1614, #1615, #1616, #1617, #1618, #1619, #1620, #1621, #1622, #1623, #1624, #1625, #1626, #1627, #1628, #1629, #1630, #1631

Call for sponsors

We are also calling upon teams and organizations who use Kiwi TCMS in their testing workflows. Please consider making a one-time donation or becoming a regular sponsor via our Collective. You can contribute as low as € 1! The entire budget will be distributed to the community!

Vote for Kiwi TCMS

Our website has been nominated in the 2020 .eu Web Awards and we've promised to do everything in our power to greet future FOSDEM visitors with an open source billboard advertising at BRU airport. We need your help to do that!

Happy testing!

bounty program banner

Kiwi TCMS is donating € 10000 (ten thousand euro) to our community to enable more hands working together and give an opportunity for people to get exposed to open source contributions. You will help us complete pending tasks faster while learning something new and receive a bonus for your efforts! This blog post outlines the rules of our open source bounty program.

Who is eligible to participate

Everyone who meets the following criteria is eligible to participate:

  • Has an account on - needed to follow program updates and request payments
  • Has a bank account - needed for actual money transfer, more info below!

If you are beginner in Python, Django or some other technology that we use please consider available documentation, your local user group, developers forum and StackOverflow to get help. Do not turn GitHub issues into a "getting started in programming" discussion.

Engagement rules

FIFO order for code review

  • Contributions will be reviewed and merged in a rolling first-in-first-out order, that is we review 1 PR and while waiting for updates continue on the next in the queue
  • In case of collisions, multiple contributions that try to resolve the same problem, our team will review the first one, then the second one, etc. The pull request which is first to pass DoD and code review will be merged and the conflicting ones closed
  • Please comment on issues and work together with other community members to split the work and avoid collisions as much as possible

About issues

Our team will try to clearly describe each task and what constitutes a successfully completed task, e.g. definition of done (DoD). If this isn't the case please ask questions and seek clarification about such tasks.

  • Only Issues under the bounty-program milestone AND labelled with a specific monetary amount are eligible for payout!
  • Unlabelled issues need further refinement before they can be accepted for bounties!

Payout rules

Once DoD has been met and the contribution is merged you may claim the assigned bounty. You must perform the following steps:

  • Submit an expense to the Kiwi TCMS Collective
  • All expenses submitted to the Kiwi TCMS Collective must follow the invoicing rules of our Fiscal Host. Here is an invoice template (Google Doc) you can use. Fill-in the blue parts and leave the black parts
  • Invoice & expense description contains the number of issue(s) and PR(s) for which bounty is claimed

Identity cross validation:

Once an expense has been submitted add a comment with your GitHub/Crowdin username to it + open a new issue in GitHub /new discussion in Crowdin with link to the expense submission. This will help us cross-validate that we are talking to the same person between platforms.

Note on bank transfers

A message from our Fiscal Host:

We currently prefer to do payouts using bank transfers. We used to support PayPal but fees were way too high for the collectives.

About bank transfer, we do EU transfers as well as non EU (which takes more time obviously).

We noticed that several collectives are now using Revolut bank accounts which is the easiest and cheapest way (it’s free) to receive money anywhere in the world.

It looks like the fastest & cheapest way to get paid is via Revolut account if you have one, followed by standard bank transfer and PayPal account is last!

Bounties: translation related tasks

Bounties: test automation plugins

  • Django test runner reporting plugin - #693
  • py.test reporting plugin - #1511
  • JUnit plugin: annotation & improvement for test case mapping - #1512
  • TestNG plugin - #692

Bounties: assorted technical issues

Call for sponsors

We are also calling upon teams and organizations who use Kiwi TCMS in their testing workflows. Please consider making a one-time donation or becoming a regular sponsor via our Collective. You can contribute as low as € 1! The entire budget will be distributed to the community!

Vote for Kiwi TCMS

Our website has been nominated in the 2020 .eu Web Awards and we've promised to do everything in our power to greet future FOSDEM visitors with an open source billboard advertising at BRU airport. We need your help to do that!

Happy bounty hunting!

Click here to vote for Kiwi TCMS

Scenario: Display open source advertising in Brussels airport
    Given one of the prizes is a 2 month billboard advertising campaign
    And the awards ceremony is on Nov 18th 2020
    When Kiwi TCMS wins
    Then there is good chance this campaign coincides with FOSDEM

Out team promises to do everything in our power so that visitors to FOSDEM 2021 start feeling the community vibe directly at the airport!

Please vote and share.

Thank you!

Kiwi TCMS is the proud winner of a $10,000 award from Mozilla, Indeed, Open Collective, Ford Foundation & Simply Secure. Read below for the full story!

At the end of January Zahari alerted our team about the Open Source Speed Dating FOSDEM 2020 event and Alex was very swift in filing the application form. Just as we landed in Brussels, ready to host Testing and Automation devroom and the Open Source Test Management stand, we got the news - Kiwi TCMS has been selected as a participant.

What followed was a very hasty day of preparing a 5 min pitch and rehearsing it as much as possible so we can be ready to present our project. Alex prepared the pitch and made final review and polishing together with Anton. For the record everything was written down on paper, including important facts about the project and schedule - when and where is our slot, how is Alex going to get there, when does he need to leave to be on time, etc. We believe that preparation was key here and that's why our team always tries to be prepared when we participate at events! It was as good as it can get, no more changes!

On Feb 1st all hell broke loose - it was day #1 of FOSDEM, the Testing an Automation devroom was full with amazing speakers and packed with people, watch videos here, there was barely time to eat or drink water and at 5PM Alex had to rush across town to pitch Kiwi TCMS!

Then everything went like clockwork - weather was warm for the season, Alex decided to walk from ULB to La Tricoterie, both so he doesn't get stuck in traffic but also to regulate stress level and be clear minded for what comes next. He arrived just on time to meet with new folks and have a glass of wine before taking his turn with the judges.

Open Source Speed Dating is a format where projects pitch to a team of 3 judges who then follow up with various questions. Their goal is to assess how suitable your project is for the money they are giving away but also how would actually receiving an award help the project. You do get guidance how to prepare and what sort of information the judges are looking for. However you have no idea who the other participants are and who are you competing against! All you have is a 15 minutes slot where you have to give the best of you and hope it is enough.

Afterwards we reunited together, did even more walking, played the SPACESHIP at Let Me Out escape room and finished with a mandatory team dinner in the hearth of Brussels.

Following an internal selection process and due diligence we finally received the award. $10,000 for open source!

As a side note we also got to know who the other winners are, which can be seen from Open Source Speed Dating records: F-Droid, ossia, MNT Research GmbH and Kiwi TCMS!

We’re giving all of it to our community

All money from the Kiwi TCMS Collective will be going towards funding development tasks. Like Alex told the judges - this will help us enable more hands working on Kiwi TCMS and complete pending work faster. Stay tuned for our bounty program announcement!

Happy testing!

Hello testers, you can catch-up with your favorite open source test case management system during the month of March. Here's a list of events we are going to:

  • March 14 - QA: Challenge Accepted, Sofia where we will have an info booth. You will get a 15% community discount if you email and mention this blog post
  • March 19-21 - OpenTechSummit, Singapore - aka FOSS ASIA summit:
    • Kiwi TCMS exhibition booth - 3 days
    • How to write pylint plugins for fun & profit workshop on March 19th
    • Testing [for] security [in] open source presentation on March 21st

To claim a free Community Standard Ticket use code atodorov. First 5 tickets only! For a 25% discount use code fossasia-speaker. For a 25% discount use code exhibitor-friends - applies only to Community Standard Ticket.

  • March 27-28 - TestingStage, Kiev where Alex will present his Static analysis as a test tool session. You can also claim 15% ticket discount by using promo-code AlexanderTodorov
  • April 1-2 - TestCon Moscow where Alex will present the Static analysis as a test tool again

Original plan was to visit OpenTest Con, Beijing between March 30-31 which has now been cancelled! The new plan is to stay 2-3 more days in Kiev and join some meetups if available.

Feel free to ping us at @KiwiTCMS or look for the kiwi bird logo and come to say hi. Happy testing!

Project roadmap 2020

Hello testers, the Kiwi TCMS team sat down together last week and talked about what we feel is important for us during the upcoming year. This blog post outlines our roadmap for 2020!

roadmap image 2020

Project sustainability

The big goal towards which we are striving is to turn Kiwi TCMS into a sustainable open source project. For now this means several key areas:

1) Team
2) Technical
3) Community


Right now we have a core team with 6 newcomers on-boarding. Engineering performance is all over the place with some people contributing too much while others contributing too little. More importantly there is no consistent pace of contributions which makes planning timely completion of technical tasks impossible.

At the moment we do operate as a bunch of disconnected people who happen to talk to each other from time to time.

We are going to adjust our internal processes and how we on-board new members. In fact we did our first "scrum-like" meeting this week and agreed to change our existing practice and strive to become better as a team!

Goal: to have a cohesive team at the end of the year which operates with a predictable capacity.

Goal: 1 PR/week/person as broad measure of individual performance.


The areas shown on the picture above will receive more priority.

Goal: complete remaining Telemetry features.

Goal: complete bug-tracker integration milestone.

Goal: all pylint issues resolved.

Goal: migrate all remaining legacy templates to Patternfly UI. See patternfly-migration milestone.

Goal: where FE sends AJAX requests to BE views replace with JSON RPC API instead.

Extra: start tackling the JavaScript mess that we have. This depends and is related to Patternfly migration and overall refactoring.

Extra: make it easier for downstream installations to extend and override parts of Kiwi TCMS in order for users to adjust the system to their own needs. The system is pretty flexible as-is but there have been requests, both online and offline, to provide some extra features! We'll start looking into them, likely making partial progress in the next 12 months.


Last year Kiwi TCMS had massive success at every single conference that we've been to. Both project and team have been well received. While we are going to continue being part of various communities around the world we are trying to limit extensive travel and focus on functionality and partnerships which will increase Kiwi TCMS eco-system, make the project even more popular and drive further adoption!

Goal: extended GitHub integration via kiwitcms-github-app plugin.

Goal: release the following test automation framework plugins for Kiwi TCMS:

For more information see test-automation-plugins milestone.

Ongoing: work with our partners from the proprietary and open source worlds. This is hard to quantify and lots of it doesn't actually depend on the team. However we are continuing to talk to them regularly. Expect new feedback to become available under GitHub Issues.

Extra: see what we can do about testing productivity! This has always been part of our mission but we have not been able to produce anything worth sharing. We do have ideas in this space but we are generally looking for partnerships and collaborations. It is very likely that there will not be very much progress on this front because it is hard to define it properly :-(.


At the end of the day most of these goals compliment each other and help drive all of them to completion. Many of the still on-boarding people have expressed desire to improve their Python & Django skills. Working to resolve issues in the above specific areas will give them this opportunity! I expect they will show good progress on their respective tasks so we can write more about them on this blog.

Happy testing!

Roadmap status report for 2019

Hello everyone, in this article I will outline the progress that the Kiwi TCMS team has made towards achieving the goals on our 2019 roadmap. TL,DR: last year we've made lots of big and visible changes in Kiwi TCMS. This year less so. Progress has been slower than before and not so much visible. Community and team is growing. More contributors are welcome.

Complete the internal refactoring

Status: small progress, needs help

CodeClimate progress is:

  • -60 code smells
  • -55 duplications
  • -50 other issues
  • 4.4% technical debt improvement
  • -240 hrs remaining until issues are fixed

The trend is showing less issues remaining but it has been a slow progress. As we fix the easier items the remaining ones become harder to deal with.

We've done minor work related to fixing issues reported by pylint. Around 150 of them still remain!

We have not done any targeted work to resolve other issues reported by Scrutinizer, remove vendored-in JavaScript libraries, JavaScript refactoring or classification of issues in 3rd party dependencies.

Redesign the UI templates with the help of Patternfly

Status: 60% done, needs help

There are 22 HTML templates remaining to be redesigned (from 59). That's mostly due to internal cleanup and some refactoring! Test plan and Test run pages are the two major templates that still need to be redesigned with Patternfly.

Modernize reporting aka Telemetry

Status: 60% done, in progress, behind schedule

The specs for the new Telemetry system have been defined after taking into account feedback on GitHub issues. Anton Sankov is the leading developer for this feature. So far we have 4 telemetry reports merged: testing break-down, status matrix, execution trends and flaky tests.

There are lots of minor issues or missing functionality in these first iterations (compared to specification). Work continues on the other telemetry use-cases and related items.

Plugins for 3rd party test automation frameworks

Status: good, needs help

UPDATE: no change in last 6 months.

If you'd like to see plugins for more test automation frameworks and/or file formats please checkout the documentation for links and more info.

Redefine bug-tracker integration

Status: 66% complete, in progress, behind schedule

We've been making slow progress on this milestone lately. For more info see

GitHub flow integration

Status: done, awaiting deployment

Our team spent some time making Kiwi TCMS the first open source TCMS available on the GitHub Marketplace. At the end of this year we were able to create a small application that allows further integration and extending the testing workflow to the GitHub platform.

This is waiting on a few more clarifications from GitHub before we deploy but for now it can be considered as done. Future functionality will be tracked and developed directly at

Agile integration with Trello

Status: no progress, will drop

This will be dropped from roadmap for the next year until we can get more interest from the community.

Improve engineering productivity

Status: no progress

Looking for external help here. This will stay as a low priority item on our roadmap for 2020 until we can free more resources on the team.


Status: great, on track, needs work

This is our strongest area during this year. We have a strong presence in multiple communities, our event schedule is very busy and we are gaining more recognition every day! Core team hit several big bumps this year and is still recovering with a few more people onboarding.

Kiwi TCMS suffers from the problem that many of our users can't be contributors or simply don't want to!

In short: it is important for us to follow our mission and develop our core team so we can deliver on promises made in our roadmap! That requires a lot of time and effort which reduces short-term productivity.

Happy testing!

Kiwi TCMS is going to FOSDEM 2020

Stand at FOSDEM'19

Hello testers, Kiwi TCMS is going to FOSDEM 2020. This is where you can find us:

  • Fri Jan 31st: after 18:00 @ Delirium Café - we are taking part of the FOSDEM Beer Event where all participants are invited. Shout out with #KiwiTCMS on Twitter if you can't find us in the crowd
  • Sat Feb 1st: Testing and Automation devroom - we are proud to be co-hosting this devroom together with Linaro and SUSE. CfP is open until Dec 10th 2019. Apply here!
  • Sun Feb 2nd: Open Source Test Management stand - we will be together with our friends from SystemTestPortal and we are preparing some real black-box testing for you!

We would like to meet with all of you and talk about software testing, test management and test process organization. In case you are stuck for crazy ideas checkout our project mission for inspiration.

Picture: FOSDEM'19 with Kiwi TCMS, ReportPortal & SystemTestPortal

Happy testing!

Next month our team will be at PyCon Balkan, Oct 3-5 in Belgrade. Together with presentation and a workshop we are going to host open source sprints! These will be an informal gathering where participants will be able to learn more about how open source works and go through their first contributions. This is ideal for students and less experienced people but we welcome everyone. There will be tasks ranging from easy to very hard!

Who: 4 mentors from Kiwi TCMS and you!

What: full day of peer programming and contributing to Kiwi TCMS

Where: room will be announced on the days of the conference, follow @KiwiTCMS for more info

Why: up your tech skills, build your GitHub profile and have fun together

Translate Kiwi TCMS

Difficulty: easy

We have enabled Serbian language in our translation system. To get started checkout our translation contribution page. Once strings are translated kiwitcms-bot will automatically open a pull request with the new text.

Find unused CSS classes

Difficulty: easy

This should be relatively easy. For each class/selector defined in our CSS files search (grep) if any of the HTML templates use it. If it is not in use then remove it.

Find unused JavaScript code

Difficulty: easy

Similar to the above. We're not 100% certain but there could be legacy JavaScript functions which are no longer in use. Find them and remove them! At the very least you have confirmed that all functions are in use!

CodeClimate Minor severity issues

Difficulty: easy to moderate

Check-out the list of Minor severity issues. There are many of them:

  • CSS lint issues (we suggest you start with this one)
  • functions longer than 25 lines of code
  • functions with bigger cognitive and cyclomatic complexity
  • modules longer than 250 LOC

Try fixing a few to see how it goes and continue if you feel confident. Not everything may be an issue so if you have any questions ask someone from our team.

CodeClimate Major severity issues

Difficulty: moderate to hard

Check-out the list of Major severity issues. There are around 150 of them:

  • identical and similar code blocks
  • big modules
  • big functions

Most of these require some sort of refactoring, either splitting snippets of code into smaller pieces (functions or sub-modules) or using one function in several places instead of 2 very similar but different functions, etc. Ask our team members about which approach they prefer for fixing these issues to minimize the effort spent here.

CodeClimate Critical severity issues

Difficulty: hard

Check-out the list of Critical severity issues. All of these are functions with high cognitive complexity and the recommended way to deal with them is refactoring into class based views.

Improve pylint health

Difficulty: easy

Execute pylint against the latest sources and start fixing the issues. Looking at pylint logs the following items are relatively easy to work on:

  • Everything in module tcms.urls
  • Everything in module tcms.telemetry.api
  • Everything in module tcms.testruns.tests.test_views
  • Everything in module tcms.xmlrpc.forms
  • Everything in module tcms.testcases.tests.test_models
  • Everything in module tcms.core.forms.fields
  • Everything in module tcms.settings.common
  • Everything in module tcms.settings.test
  • All module-in-directory-without-init errors reported for module tcms.tests.__init__

Note: fixme, missing-permission-required and avoid-auto-field errors are usually harder to resolve and will require more work/refactoring. If you feel confident go ahead and fix them, if not skip to the next error message.

We also use a custom pylint checker which reports function based views. If you are looking for something harder to work on, then give it a try (see 3rd pylint line in Makefile) and refactor some of the existing view functions into class based views.

Fix 3rd party security issues discovered by Bandit

Difficulty: moderate to hard

Bandit is a static analysis tool similar to pylint. It focuses on discovering issues which may lead to security vulnerabilities. We have resolved all such issues in our own source code but we also execute Bandit against the entire Python dependency stack. There it finds thousands of issues, so much so that the reporter crashes.

In CI there are around 130 issues reported. The best course of action here is to execute Bandit locally against the offending library and then figure out what to do:

  • report an issue upstream
  • send a pull request upstream
  • if these are test files maybe exclude them from the package (e.g. don't ship them for production)

Note: inside Travis CI we have all runtime and testing dependencies which is more than what we have inside the official Docker image for Kiwi TCMS.

Work on reported issues

The following issues look suitable for a sprint and don't require lots of background knowledge. You can also find them using the PyConBalkan label on GitHub:

  • #212 - moderate - Convert jQ to $ - this is an easy search & rename but will require more extensive manual testing
  • #431 - moderate to hard - Remove JavaScript fireEvent() - 17 matches in static/js/. Must be replaced with direct function calls
  • #652 - easy - Removal of labels from form fields - all labels must be included in the HTML template and marked for translation
  • #681, #682 - moderate - Move API modules & their tests from xmlrpc/api/<app>.py to <app>/ These have good test coverage so you have to make sure you don't break anything
  • #971 - moderate - command for changing Site URL - will help with automatic provisioning, e.g. Ansible. For howto see Django docs
  • #1021 - moderate - Update TestCase page UI to allow adding TestPlans to cases - use TestPlan.add_case() API method and refresh the widget. See how Tags and Components cards work in the same page
  • #1070 - moderate - command for checking email settings - will help with troubleshooting misconfigured email. Must raise exceptions if something fails. For howto see Django docs
  • #733, #736, #738, #883, #1089 - hard to very hard - New checkers for pylint - Kiwi TCMS uses customized pylint checkers to discover various conditions. We need a few more of them and/or update of the existing ones

We hope to see you in Belgrade. Until then: Happy testing!

Your favorite open source test case management system is going on tour again. During the next several months we will be at:

Feel free to ping us at @KiwiTCMS or look for the kiwi bird logo and come to say hi. Happy testing!

Happy Monday, testers! In this series we are introducing the contributors behind Kiwi TCMS. This is our community and these are their stories.

Aneta Petkova - QA Chapter Lead at SumUp

Aneta is a software engineer navigating the complex field of QA since her first "grownup" job. She's been working in the area of test automation for web applications using different programming languages and tools. Her mission is to inspire people to think about quality from the very inception of ideas and to blur the line between developers and QA specialists.

What is your professional background

I have an engineering degree in computer science and I've spend the last 8 years in Quality Assurance. Java, TestNG and UI automation with Selenium WebDriver are my strongest technical skills but I use different programming languages and tools.

I believe languages and tools should only support an engineer and never define them.

Currently I am the QA Chapter Lead at SumUp, where I can work towards achieving my goals in an amazing team of people that do what they love.

When did you use open source for the first time

The first time I remember was in 2011, but I've probably used it before and just didn't pay attention. To me it seemed the same as proprietary, and I guess that means it was good.

Describe your contributions to the project

I created kiwitcms-junit-plugin. This is a native Java library which you can install via Maven Central. It will discover your automated test suite and publish test execution results in Kiwi TCMS. This plugin is very simple and requires only minimal configuration before it is ready to work. Check-out the example in TP-25!

editor comment: Aneta and Ivo (Kiwi TCMS) hosted the "Git crash course" workshop at HackConf 2018. Kiwi TCMS will be hosting 2 workshops this year so stay tuned!

Why did you decide to contribute to Kiwi TCMS

I had recently switched Java for Ruby and I was feeling nostalgic. Also, I had spent my entire career so far in QA and I wanted to slip on the developer shoes for at least a little bit.

Was there something which was hard for you during the contribution process

I'm used to working in a team and when I started working on this project I was the only active Java developer. Luckily for me, I live in the time of StackOverflow, so I managed to get most of my questions answered by strangers on the Internet.

I learned tons of stuff, but mostly I learned I can build software, not just test it!

Which is the best part of contributing to Kiwi TCMS

Doing something that has the potential to help others and that could be improved upon.

What is next for you in professional and open source plan

My current focus is moving slightly into DevOps direction and I am really overwhelmed by the amount of things to learn. I feel there is so much I want to experiment with. I am not really planning anything related to open source - it has never been a goal for me - but when I come across a project I feel strongly about, I'd probably be tempted to contribute.

Thank you, Aneta! Happy testing!

In this new series we are going to introduce the contributors behind Kiwi TCMS. This is our community and these are their stories.

Primož Klemen - QA tester, full time dad, Manchester United F.C. supporter

Primož is an early adopter and our Slovenian translator. He's been actively engaging in GitHub issues, posted pull requests for improving documentation and follows us on StackOverflow as well.

What is your professional background

I've started working in IT as tech support for the 2nd largest Slovenian ISP at the time. Then I've been at leading software provider for fintech in the Balkans region in the same role and gradually transitioned into QA role. Currently, I'm working as a QA tester for Better (by Marand) and ensure, with help of my colleagues of course, proper quality of administration application for health care sector.

When did you use open source for the first time

If I recall correctly that would be some 14 years ago when I ditched dreaded Internet Explorer in favor of Mozilla Firefox browser. The whole Internet got better in a matter of seconds.

What are your contributions to Kiwi TCMS

I mainly contribute via translating the application into my native language, Slovenian. Currently there are 7 languages available for Kiwi TCMS so you are more than welcome to join and add another one. Translating via Crowdin is very simple and requires no additional technical skills. I've also dabbled into project documentation and proposed a few updates to it. I'm also the culprit for some 32 issues and counting, the majority of them being proposals for future application enhancements and few UX/UI bugs (déformation professionnelle :-)).

Why did you decide to contribute to Kiwi TCMS

The guys and gals from the Kiwi TCMS team provided us with an application which solved our pain about building, maintaining and running manual regression tests.

They did all of that for free in their spare time! So I've decided to give something back to the whole community. This was indeed my first contribution to the open source world but not the last. Since then I've also contributed to other projects which I use on a regular basis.

In hindsight, Kiwi TCMS converted me from an open source user to open source contributor!

Was there something which was hard for you during the contribution process

Contributing to the project, as a non-developer, is very easy and intuitive by either opening issues on GitHub or translating via Crowdin or even committing updated documentation to git repository through GitHub Desktop client. All of the aforementioned was new to me and I've learned in depth how to use these tools. I've also had the pleasure to familiarize myself with project documentation - Sphinx and reStructuredText are my two new best friends.

Which is the best part of contributing to Kiwi TCMS

Being able to actively improve an application that we use on a daily basis in our development process. Getting to know more people from all around the globe and see their insights about software quality assurance thus learning something new every day.

What is next for you in professional and open source plan

Professionally I'm 100% committed to Better (by Marand) and helping us achieve the best standard of quality for health care applications which also incorporates using the knowledge gathered by following and/or contributing to open source. I'm going to continue contributing to Kiwi TCMS and Captura and if time allows maybe involve myself with some other interesting projects.

Thank you, Primož! Happy testing!

Hello everyone, in this article I will outline the progress that the Kiwi TCMS team has made towards achieving the goals on our 2019 mission and roadmap. TL,DR: Kiwi TCMS has made progress since January, it's been tough and may not have been very visible. I feel like we've been behind schedule till now! The greatest positive thing has been community and team development!

Complete the internal refactoring

Status: minimal progress, needs help

CodeClimate progress is:

  • -30 code smells
  • -40 duplications
  • -30 other issues
  • 4% technical debt improvement
  • -200 hrs remaining until issues are fixed

This is mostly the result of code reviews and minor fixes, not targeted work.

We have not done any targeted work to resolve other issues reported by Scrutinizer, Pylint, remove vendored-in JavaScript libraries, JavaScript refactoring or classification of issues in 3rd party dependencies.

There are new people onboarding in the team right now and our plan is for them to start grinding at these issues very soon!

Redesign the UI templates with the help of Patternfly

Status: 50% done, needs help

There are 27 HTML templates remaining to be redesigned (from 59). That's mostly due to internal cleanup than targeted refactoring. More work on this item will probably follow towards the end of the year after we get more priority items out of the way and get more of the new team members rolling!

Modernize reporting aka Telemetry

Status: in progress, a bit behind schedule

The specs for the new Telemetry system have been defined after taking into account feedback on GitHub issues. Anton Sankov is the leading developer for this feature. So far we have 2 telemetry reports merged: testing break-down and status matrix. The next one will be execution trends.

There are lots of minor issues or missing functionality in these first iterations (compared to specification). Our plan is to have the major use-cases satisfied first and then work to refine all of the existing telemetry pages.

Plugins for 3rd party test automation frameworks

Status: good, needs help

Until now we have released TAP, junit.xml and native JUnit 5 plugins. There's also a PHPUnit plugin which is more or less complete but unreleased yet. Both JUnit 5 and PHPUnit plugins are developed by external contributors!

We often get asked for plugins for languages and frameworks we don't use or don't even know! Given that our expertise is mostly in Python we will gladly accept your pull requests if you decide to maintain or contribute to one of the plugins. This will also help us get insight into what automation frameworks people are using and how exactly you structure a test automation workflow around Kiwi TCMS.

Checkout the documentation for links and more info.

Redefine bug-tracker integration

Status: no progress

Last week, right after OpenExpo, we did a check-up session and this was one of the areas identified with zero amount of progress. I have a strong preference to work on this feature myself but have not been able to due to various other items that need my attention.

The short version is that I'd prefer to remove all issue tracker specific code and allow the tester to add arbitrary URLs to link to existing bugs. How to do integration (even as simple as publishing a comment in the bug tracker) over a generic interface still eludes me. In the next few weeks I will kick-off this topic with a separate blog post/issue for everyone to comment on.

GitHub flow integration

Status: no progress

Our team spent some time making Kiwi TCMS the first open source TCMS available on the GitHub Marketplace. We will continue this integration effort and flow integration will emerge from that. There's also many things that need to be done to satisfy GitHub's .

Agile integration with Trello

Status: no progress

Improve engineering productivity

Status: no progress

Our mission is to transform testing in your organization by providing the tools for that via Kiwi TCMS. It is astonishing that so far nobody has provided any kind of feedback in Issue #703 wrt improving productivity in their teams!

We have some ideas which have been blocked by lack of resources on the team and refactoring tasks. Because we've adopted this as our mission this is an important item for us and we'll continue working on it as resources allow. Progress is to be expected towards the end of the year.


Status: great, on track, needs work

This is our strongest area during the year so far. We have a strong presence in several communities, our event schedule is busy enough and we are gaining more recognition every day!

  • Hosted project stand at 3/5 conferences with 2 more on-track
  • Won the OpenAward for Best Tech Community
  • Hosted several presentations and workshops with few more on track
  • Found new talent to join the core team: 2 just ready to start contributing, 5 more in training
  • 1 more senior engineer as a mentor. We also have a few independent wanna-be contributors and will be hosting qualification interviews for marketing assistant very soon
  • There are contributions and pull requests coming from users of Kiwi TCMS as well. We'd like to see more of course.
  • There are a couple of open source projects and companies using Kiwi TCMS who are friendly towards the project. We are working with them to get a public endorsement on the website and engage in more technical work together. Of course everyone has limited resources and is very busy :-(
  • Sponsors on OpenCollect are just a few but we didn't have any previously so this is a good sign.

This is the moment to mention that not all is honey and roses in open source land. Kiwi TCMS suffers from the problem that many of our users can't be contributors or simply don't want to!

Manual testers can't program. This is a fact and a good sized chunk of our user base actually performs manual testing. Those that can write automation and probably code decently well may not be familiar with Python and Django. At least in Bulgaria these two aren't very popular, definitely not among testers. That is to say this part of the user-base simply doesn't have the necessary skills to contribute and the majority of what we need is code contribution!

Another (fairly big IMO) group of users are coming from proprietary companies who view open source and Kiwi TCMS as a zero cost option. Something that they take free of charge and use it without ever contributing back. They don't understand nor really care about the open source culture.

To make things worse we receive requests every single day via our private email addresses or questions via IM despite our website clearly stating community engagement rules. On a few occasions we have received very rude comments of the sort "our company demands you fix this", "is this going to be ready this year" (context implying entitlement), etc. To make things more ridiculous we've even received support requests (via contact form) from companies and start-up who get their return address wrong so we can't get in touch directly!

In short: don't demand anything from us unless you are ready to pay for it, work for it yourself or propose a mutually beneficial scenario. We do try to keep the community happy but more importantly follow our mission and develop our core team!

Happy testing!

Image of the award

Kiwi TCMS is the winner at OpenAwards'19 category Best Tech Community! Big thanks to the jury, our contributors and core-team and the larger open source and quality assurance communities who voted for us and supported the project during all of those years.

This award is the best present we could get to mark the 10th anniversary of the project. More news of how we are progressing with current roadmap will follow soon in a separate blog post.

Thank you & happy testing!

Vote for Kiwi TCMS at OpenAwards 2019

Thanks to you, our community supporters, Anton Sankov and Alex Todorov took the lead at OpenExpo 2019 CfP votes. We need your help one more time. Our team has submitted participation in 'Best Tech Community' and 'Best Success Story' categories.

Unfortunately our submission into 'Best Success Story' has been pulled down! We used that category to share the story from a dead open source project into a thriving open source community with lots of users and contributors and to highlight some of our milestones. Here's the short version:

  • lots of technical updates and refactoring, latest everything, modern UI
  • the only open source test case management system on GitHub Marketplace
  • nearly 60000 downloads on Docker Hub
  • growing and active core team
  • active OSS contributors

Please help us gain more recognition:

Thanks you & happy testing!

On Tuesday I hosted my pylint workshop during the regular Django Bulgaria meetup. This edition was the first which was practice based.

Attendance numbers were low but participation was very good. We managed to create 4 new checkers for Kiwi TCMS:

Many thanks to all contributors. These new checkers have discovered quite a few new issues with Kiwi TCMS so this is an area which our team is going to improve.

Those who missed the workshop will be able to catch up one of the next editions:

  • 26-29 August, GUADEC, Thessaloniki - TBC (presentation)
  • end of September, Python meetup, Zagreb - TBA
  • 03-05 October, PyCon Balkan, Belgrade - TBC
  • 11-13 October, HackConf, Sofia
  • 15-17 October, TestCon Europe, Vilnius - TBC (backup presentation)
  • 23-25 October, Testwarez, Ossa, Poland - TBC (presentation)
  • 14-15 November, Software Engineering Conference Russia, Saint-Petersburg - TBC
  • 20-22 November, ConTEST, New York - TBC (workshop and/or presentation)

Happy testing!

Vote for Kiwi TCMS at OpenExpo

We are happy to announce that Anton Sankov and Alex Todorov are currently taking the lead at OpenExpo Europe's CfP votes!

Going to OpenExpo will be huge boost for Kiwi TCMS so please help us make this happen! Voting is open until March 17th 2019! You can cast your vote via Facebook login but remember to confirm your email address!

Thank you & happy testing!

Want to hack open source ?

Have you ever wanted to be part of an open source team? Have you ever wanted to contribute back the open source community ? Have you ever wanted to see your code used by thousands of people ?

If yes now you have the opportunity! Read on to learn how you can help Kiwi TCMS and how our team can help you.

Inexperienced Python developer(s)

It is fine not to have any experience at all! You will compensate with commitment and hard work. Initially you are going to work on refactoring, cleaning up pylint errors, removing duplicate code and other issues reported by CodeClimate.

By doing this you will have the opportunity to learn git, Python, Django, some CSS, JavaScript and Patternfly HTML of course. We are going to provide you with all the learning materials plus help and guidance from existing team members.

Everyone on the team has gone though the same training procedure and grueling tasks and so will you! Once you can demonstrate progress and learn the ropes you will continue working on more complicated tasks.

Experienced Python developer(s)

So you have some experience already, you've probably contributed code before and are now looking for more green stripes on your GitHub profile. We've got you covered!

There are many areas to choose from: issue tracker integration, GitHub integration, GitLab integration, external API library, Kiwi TCMS plugins written in Python and customized pylint linters! This is going to be where you get your hands dirty and show your strengths. Our team is here to help if necessary but we expect you to show progress by yourself.

A challenge for you will be to review pull requests from other contributors and be patient with less experienced contributors and team members. This is an excellent opportunity to work on your people skills as well.

Experienced non-Python developer(s) (with Java)

Kiwi TCMS is primarily looking for Java developers who will own our test automation plugins. Currently we have a plugin for JUnit 5 and TestNG is in planning. Maybe there will be a plugin for Jenkins as well. You are going to own these components and work solely on them. Unless you decide to learn Python and Django that would be a very easy job!

.NET, PHP, Ruby, JavaScript ? We don't have a lot of code written in these languages but you can help change this. The main thing we'd like you to know (or become familiar with) are the internals of popular test automation frameworks for these languages and how to create plugins for them.

QA engineer with Python

You are going to test a lot! You are going to write test automation a lot! Ideally you already have a medium level of experience in the software testing field and want to improve your coding skills and/or get more experience into a different application domain. We also have Linux and Docker in the mix, just for fun!

Your responsibility will be to design test scenarios for various features (new or existing), write test automation scripts and help improve overall test coverage and quality of Kiwi TCMS. You will also check-in on non-Python developers and help them with test design when necessary.

There are other things that can be tested as well, for example Kiwi TCMS performance and scalability. Here you will have to get down to the nitty-gritty stuff and do some profiling to pin-point where the root cause of the problem is.

Security freak

We've got Coverity scan and Snyk automatically inspecting our code base. We do have some other tools as well and we know they can never be enough.

You will be responsible for triaging the numerous issues being reported by these tools and help us decide if they are a real threat or a false positive. For example Coverity reports hundreds of issues mostly coming from our Python and Node.js dependency stack. We haven't had the time to classify them and work with upstream communities to fix them thus the majority of your contributions will be outside of the Kiwi TCMS code base.

Graphics designer

Your main job is going to be creating beautiful images for our website, blog posts and promotional material. All the images we use are licensed under Creative Commons which we then modify with the specific Kiwi TCMS look and feel. This is not going to change, your work will remain under a permissive license!

Marketing specialist

You will be directly responsible for driving more traffic to our website, interpreting Google Analytics metrics and coming up with creative ideas how to boost Kiwi TCMS popularity. This means, but not limited to blog posts, collaborations with other projects and/or bloggers, professional magazines, etc. You will also be in charge of events and conferences that we go to! Whenever possible you will be coming with us as well!

A challenge for you will be to learn some technical jargon and learn more about the software testing profession and software testers in general!

What's in it for you ?

You will sharpen your skills! You will use Kiwi TCMS as a platform to improve your career. You will experience the gratification of our community of users.

This blog is the medium where you can share tips and tricks and technical articles about interesting features in Kiwi TCMS. If you'd rather have your personal blog working on Kiwi TCMS will give you lots of topics to write about.

We go to conferences and meetups too. If public speaking is your thing you will have plenty of topics to talk about. We can also help you deliver your first presentation! Everyone on the team has done it!

Our existing team will help you learn and we will help you grow. Our personal time is the most expensive item we can offer to you! In return we expect you to fulfill your commitments and when you promise something will be done you will make sure it is done!

How to apply ?

You can figure this out yourself.

Happy testing!

In release notes for v6.5 we announced several plugins which will fetch test names and execution results from your automated test suite.

Plugins can be controlled via environment variables which will affect how test results are recorded in the Kiwi TCMS database! This blog post is an introduction how that works and what you can do with it! For this purpose I will be using the plugin-demo repository, which simulates real development work.

Full documentation and list of available plugins is available in chapter Automation Frameworks Plugins!

Always create new TestRun by default

The default behavior is always to create a new TestRun if controlling variables are not overridden! Product name, version and build will receive default values if tests are running in Travis CI or Jenkins. For example Travis Build #2 for commit d455fb4 creates TR-12 and TP-10!


Next we convert the README file from Markdown to reStructuredText which triggers Travis Build #3 for commit 418b80b. This build again creates a new TestRun and new TestPlan for it. Respectively TR-14 and TP-12!


Important: we can see that version is different which will affect how artifacts are organized in Kiwi TCMS, possibly affect how you will report status to stakeholders!

Override ENV variables for more control

Let's say the QA team has decided that all test results must be reported under the same TestPlan. This means version must be the same between various builds in Travis CI! To control this we export TCMS_PRODUCT_VERSION=master in CI before executing the TAP plugin! Checkout the commit on GitHub to see how it is done!

This triggers Travis Build #4 for commit e484e59. Because this is the first time where Version == master the plugin creates TP-14 and reports the results under TR-16.


Right after that I realized we can make this configuration a bit more generic because our team is planning to support multiple versions of the product and development will be done in separate branches! Travis Build #5 for commit f1f2878 still ends up with Version == master because we are still working on the master branch! That is to say, the product is in active mode of development.

Results are reported in TR-18 which is again part of TP-14.


Travis Build #6 for commit df6153b adds the new functionality README badges and reports test results in TR-20 which is again part of TP-14.

More ENV overrides

While giving status reports back to stakeholders and developers the information that we have in the TestRun is Build number! This follows the numbering scheme in Travis CI (or Jenkins job number) and isn't very useful.

Let's define TCMS_BUILD to be the first 7 characters of the commit hash! When QA tells devel that something isn't working and redirects them to the TestRun they can immediately use the Build information and git checkout the offending variant of the product for investigation.

This results in Travis Build #7 for commit bf75d0a, TR-22, TP-14.


Report results in pre-existing TestRun

There are many reasons you may want to do this:

  • include both manual and automation tests for the same build;
  • mix results from multiple test suites for the same build, e.g. unit, functional, performance
  • mix results from multiple but similar platforms in the same build, e.g. cross-platform application for iOS and Android

To do so I've created TR-24 beforehand and configured TCMS_RUN_ID=24 in my CI environment. TR-24 also contains TC-57: Verify we can report results from several plugins into the same TR. this was created and added via the web interface.

Note: mixing additional test cases can be done either before or after automation results are reported with the plugin!

Important: when reporting results to an existing TestRun Kiwi TCMS plugins don't care in which TestPlan this TR is! In theory it is possible to report the results for Product=kiwitcms/plugin-demo into any TP/TR pair! However we don't want to do this crazy thing and instead I've created TR-24 inside the already existing TP-14!

Note: because I don't know what is the git commit beforehand I've configured TR-24 with Build=unspecified. If I wanted I could update this with the correct value once I know the commit hash for the related changes I am testing.

Important: the plugin-demo repository uses both kiwitcms-tap-plugin and kiwitcms-junit.xml-plugin at the same time! They differ in the way test names are compiled! Both are reported in TR-24. See TC-57 text for information how to distinguish between the two.

See Travis Build #8 for commit 85ad939, TR-24, TP-14.


Also check-out comments in TR executions to see when and who had executed the test case.

So far there have been some tests which were failing (although Travis reports PASS) so I decided to fix them. Travis Build #9 for commit a25b384 is still configured with TCMS_RUN_ID=24. This means results will be reported in TR-24, effectively overwriting previous results.

Check-out Change Log under each individual execution and you will see several time stamps when status was updated! In other words, as long as TCMS_RUN_ID is pointing to an existing TestRun this TR will keep the results of the last test suite execution!

Continue development, restore ENV configuration

Travis Build #10 for commit c4f1ae5 removes TCMS_RUN_ID! Results are reported in TR-25, TP-14.


Branch out for an LTS version

Our team has decided to make the first LTS release of the product. We branch out into lts-v0 branch in git and cut the first NVR. This results in Travis Build #11 for commit 9f1ef71 TR-27, TP-16.


Because this is the first time we are running tests for this product version we end up with the newly created TP-16!

Note: see how version was populated with the correct value for the git branch! This is because my CI config uses TCMS_PRODUCT_VERSION=$TRAVIS_BRANCH and no further changes were required! I made this change back in Travis Build #5 anticipating what will come in the future!

The product is now live and customers have reported critical bugs for it: URLs for the badges in README are wrong! I fix those and add more tests of course, see: Travis Build #12 for commit 2d72754, TR-29 for TP-16.


TR-29 contains the new TC-58!

cherry-pick between branches

In the lts-v0 branch customers have identified a serious issue. It doesn't exist on master but the test is still valid so I cherry-pick it! In git you can backport or forwardport very easily. Regardless of the direction Kiwi TCMS plugins will record the test results for you.

See Travis Build #13 for commit 31ae5b3, TR-31 for TP-14.

We can see that TC-58, which was originally implemented on the lts-v0 branch is now present!


This is a very basic example of how you can organize collection and reporting for your automation test suite results with Kiwi TCMS. The links here only refer to artifacts created by kiwitcms-tap-plugin while in the DB we keep others as well.

There are feature requests for more ENV variables which will allow you to control TestPlan creation and child/parent relationship between test plans. See and vote with a :+1: reaction to help us plan for these features.

Kiwi TCMS automation framework plugins are nothing more than result parsers which talk back to a database. It is up to you to decide how to organize the collection of test results and how to report on them later, when the need arises.

Future installments in this post series will take a look at workflows with feature branches and pull requests and discuss possible organization scenarios. You are welcome to share your ideas in the comments below.

Happy testing!

Kiwi TCMS is going to FOSDEM 2019

Hello testers, Kiwi TCMS is going to FOSDEM this year. This is where you can find us:

Kiwi TCMS sticker

We would like to meet with all of you and talk about test management and test process organization. In case you are stuck for crazy ideas checkout our project mission for inspiration.

Be part of the community

We are turning 10 years old and we have presents for you! You will have to perform a small challenge and you can get your hands(errr, feet) on a pair of these:

Kiwi TCMS socks

Here's what else you can do to help us:

Happy testing!

Newer Posts

Page 2 / 3

Older Posts