Hello testers, this blog post outlines Kiwi TCMS roadmap for 2021 and what we feel is important to us!

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 three key areas:

1) Team
2) Technical
3) Community & Adoption

Team

Right now we have a core team with 3 members, 3 more members on-boarding and 2 interns. In the past year we weren't successful into turning more people into core-team members. I have seen several problems and core-team will significantly reconsider how we approach & recruit people to join the team, how we on-board and help them so that they can become productive and fully fledged team members.

Long term focus is improving and strengthening core-team which also implies a level of responsibility and performance criteria which core-team members must meet.

Goal: 1 PR/week/person as broad measure of individual performance so that we can operate with a predictable capacity.

Goal: (re)structure internal team processes around candidates and newcomers! Note: These are not public at the moment.

Technical

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

Goal: complete remaining Telemetry features.

Goal: complete remaining refactoring with major focus in pylint issues, migration to Patternfly v4 and eslint issues.

Goal: improve SSL configuration with strong bias towards Let's Encrypt being configured by default.

Goal: provide support for web hooks so that Kiwi TCMS can be integrated more easily/flexibly with 3rd party systems. We're aiming for Kiwi TCMS to be able to POST webhooks to external URLs and inform them about events in the system.

Community & Adoption

Last year Kiwi TCMS had massive success despite not visiting many events. The open source community spirit is important to us both in terms of technical collaborations and in terms of features & exposure which drives further adoption of Kiwi TCMS downstream.

Goal: complete bug-tracker integration milestone.

Goal: extended GitHub integration via GitHub actions which will report results into our database. We do have other ideas as stretch goals.

Goal: similar to GitHub actions we're looking towards GitLab pipelines and similar integration with GitLab.

Goal: continue our collaboration with Major League Hacking Fellowship program.

Goal: apply for the Google Summer of Code program and work with students if selected.

If you like what we're doing and how Kiwi TCMS supports various communities please help us!

• Give ⭐ on GitHub;
• Nominate Kiwi TCMS as GitHub Stars;
• Donate via Open Collective as low as 1 EUR;
• Join our newsletter and follow all project news;
• Become a contributor and an awesome open source hacker;
• Become a customer and we'll share our profits with the community

Another year rolls out and despite all difficulties it is by far the strongest one for Kiwi TCMS!

Stats

• 2 physical events and a few virtual ones
• 12 releases
• 24 language translations
• 683 PRs, most of them closed & merged
• Reached Issue/PR number 2000
• Reached 5000 commits
• Reached 8000 registrations via https://public.tenant.kiwitcms.org
• Reached 270K downloads via Docker Hub

Status update

From the 2020 roadmap we've established 3 main areas to work on. Their completeness scores are:

1) Team - 30%
2) Technical - 70%
3) Community - 100%

Average score is 65% completion!

Team

Overall the team has stalled its growth and improvement. Contributors which started onboarding a year ago are still under-productive and do not meet our criteria to become core-team members. The average team productivity is far beyond the goal of 1PR/week/person. This is largely due to contributors not being active on their items, very long periods between pull requests and longer than average time for closing pull requests.

The only positive side in this area is that core-team has improved its internal processes, is meeting regularly, discusses issues with members when they arise and relatively quickly spots problems and acts on them.

Technical

The dominating effort this year was refactoring the remaining legacy UI and converting everything to PatternFly. The effect of this is reduced code complexity and improved CodeClimate score/technical debt, removed vendored-in JavaScript dependencies and lots of unused code in favor of using the existing API.

Additional work has been done on closing bugs, implementing some features, integration with new bug tracking systems and improvements around the telemetry feature.

However there is still a lot of work to be done until all telemetry pages are complete. There are also around 30 pylint issues remaining which require internal refactoring and more legacy code cleanup. It's getting there but it's also getting harder.

Community

This area turned out to be our strongest one this year. We started very strong at FOSDEM 2020 and collaborated with multiple communities on plugins, code & translation contributions, adoption of Kiwi TCMS and general partnerships around open source.

Kiwi TCMS got a substantial grant from the Mozilla foundation which helped bootstrap our open source bounty program and internship program.

In May we reached 100K downloads on Docker Hub then in October we've surpassed 200K. Next month we'll reach 300K!

Summary

2020 was definitely a year full with uncertainties and hardship. It was not what we were used to and there were many ideas and lead projects that looked very promising in the beginning of the year but didn't materialize for a multitude of reasons.

Overall Kiwi TCMS, its team and its community did very well and I am confident that next year we can achieve more together!

Happy Testing and Happy New Year!

If you like what we're doing and how Kiwi TCMS supports various communities please help us!

• Give ⭐ on GitHub;
• Nominate Kiwi TCMS as GitHub Stars;
• Donate via Open Collective as low as 1 EUR;
• Join our newsletter and follow all project news;
• Become a contributor and an awesome open source hacker;
• Become a customer and we'll share our profits with the community

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!

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

Team

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.

Technical

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.

Community

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:

• PHPUnit plugin
• py.test plugin
• TestNG plugin
• Jenkins plugin
• Robot framework plugin
• Django plugin

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 :-(.

Summary

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!

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 https://github.com/kiwitcms/Kiwi/milestone/1

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 https://github.com/kiwitcms/github-app/issues.

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.

Community

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!

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.

Community

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!

Hello testers, Kiwi TCMS has taken on a brave new mission! We would like to transform the testing process by making it more organized, transparent & accountable for everyone on your team. Our goal is to improve engineering productivity and participation in testing. The following blog post outlines how we would like to achieve this and what goals we put before ourselves for this year.

Complete the internal refactoring

Last year we took on the challenge to bring a legacy code base up to modern coding standard. We did not complete that effort but made very good progress along the way. This is not a small task and that's why our team will continue with it this year.

• CodeClimate: 0 issues, 0% technical debt, health score A
• Scrutinizer: only A and B type issues
• Pylint: 0 issues
• Remove vendored-in Handlebars, jQuery, jQuery-UI and TableDnD JavaScript libraries in favor of existing npm dependencies
• Front-end uses the existing JSON-RPC instead of backend views that are only used for AJAX requests. Tip: these are usually accessed via postToURL() and jQ.ajax() on the front-end
• Inspect and classify all 3rd party issues reported from Coverity and Bandit. Report and fix what we can, ignore the rest that do not affect Kiwi TCMS.

Redesign the UI templates with the help of Patternfly

There are 59 templates remaining to be converted to a modern look and feel. Along with them comes more refactoring and even redesign of the existing pages and the workflow around them. Together with refactoring this will make Kiwi TCMS easier to use and also to maintain.

Modernize reporting

We are planning to remove the existing reports feature because they are not well designed. We will re-implement existing functionality that our community finds useful, add new types of reports (incl. nicer graphics and UI) and make it possible for the reporting sub-system to be more easily extendable.

Phase out is planned to begin after 1st March 2019! Until then we are looking for your feedback. Please comment in Issue #657!

Plugins for 3rd party test automation frameworks

These will make it easier to collect results from automated test suites into Kiwi TCMS for later analysis. Instead of creating scripts that parse the results and talk to our API you will only have to install an additional package in your test environment and configure the test runner to use it! Automation test results will then appear inside Kiwi TCMS.

• JUnit 5 plugin - already in progress
• TestNG plugin - RFC
• Django plugin - RFC
• py.test plugin - RFC

If you would like to use such functionality leave your vote inside GitHub issues! In case you would like to write a test-runner plugin you can find the specification here.

Redefine bug-tracker integration

Question: Does Kiwi TCMS integrate with JIRA?

Answer: Well, it does. How exactly do you want to integrate?

... silence ...

The following dialog happens every time someone asks me about bug-tracker integration, especially with JIRA. The thing is integration is a specified set of behavior which may or may not be desired in a particular team. As of now Kiwi TCMS is able to open a URL to your bug-tracker with predefined field values, add comments to bug reports and report a simple summary of bugs inside a TestRun.

We recognize this may not be enough and together with the community we really need to define what bug tracker integration means! The broader domain of application lifecycle management tools (of which TCMS is a sub-set) have an integrated bug tracking system. We can add something like this and save you the trouble of using JIRA, however many teams have already invested in integrating their infrastructure or just like other tools. For example we love GitHub issues and our team regularly makes public reports about issues that we find internally!

• Goal: Redefine what bug-tracker integration means, vote in Issue #698
• Goal: Bug-tracker functionality inside Kiwi TCMS, similar to GitHub Issues. Vote in Issue #699
• Goal: Integration with Redmine (per current specification), vote in Issue #41
• Goal: fix existing bugs around bug-tracker integration (per current specification). Vote in Issue #97, Issue #117, Issue #289, Issue #290, Issue #320, Issue #479 and Issue #530

GitHub flow integration

Developers have their GitHub PR flow and if they have done the job of having unit tests then they will merge only when things are green! This leaves additional testing efforts kind of to the side and doesn't really help with transparency and visibility. I'm not going to mention having an automatically deployed staging environment for every change because very few teams actually have managed to do this effectively.

• Goal: Figure out how Kiwi TCMS can integrate with GitHub flow and bridge the gap. Please share and +1 your wildest ideas in Issue #700.
• Follow up: depending on the results in #700 we will follow with other goals and sub-tasks

Agile integration with Trello

Speaking of modern engineering flow is your team truly agile? When and how do you plan your testing activities ? Before the devel sprint or afterwards? How many testers take part in refining product backlog and working on user stories?

Similar to GitHub flow lots of teams and open source projects are using Trello to effectively organize their development process. Testing should not be left behind and Kiwi TCMS may be able to help.

• Goal: Figure out how Kiwi TCMS fits into the overall devel-test-planning process for agile teams and what we can do to make this easier for testers. Please share and +1 your wildest ideas in Issue #701
• Follow up: depending on the results in #701 we will follow with other goals and sub-tasks

Improve engineering productivity

What makes a test engineer productive when they need to assess product risk and new features, when mapping product requirements documents (PRD) to test plans and test cases, when collaborating on user stories and behavior specification ? What makes developers, product owners, designers and other professionals productive when it comes to dealing with testing ?

For example consider the following workflow:

• Company has idea for a new product
• In case this is a big product it may have its own mission, i.e. what kind of problem is it trying to solve and for which group of customers
• Product backlog is then created which outlines features that map to the product mission
• Then the team, together with test engineers perform example mapping and discuss and refine the initial feature requirements. User stories are created
• Behavior specification may also be created
• Test plans and test cases are the immediate product of BDD specs and desired user stories

Later we iterate through the sprints and for each sprint something like this happens:

• Desired product features are planned for development. They must be complete at least in terms of requirements, specs and tests
• Devel writes code, maybe some unit tests, testers can also write automated tests and/or manually verify the current state of the feature being developed
• Testing, including exploratory is performed before feature is merged
• Rinse and repeat

Devel is also part of testing, right? Product owners, UX and interaction designers as well. Producing quality software product is a team effort!

In every step of the way Kiwi TCMS can provide notification wizards, guidelines and/or documentation for best practices, facilitate tooling, e.g. to write user stories and assess them or map out an exploratory testing session, etc. The list of ideas is virtually endless. We can even go into deep learning, AI and blockchain but honestly who knows how to use them in testing ?

Our team is not quite sure how this goal will look like 3 months from now but we are certain that testing needs to happen first, last and all the time during the entire software development lifecycle. By providing the necessary functionality and tools in Kiwi TCMS we can boost engineering productivity and steer the testing process in your organization into a better, more productive direction which welcomes participation from all engineering groups.

Let's consider another point of view: testing is a creative activity which is benefited by putting your brain into a specific state of mind! For example Gherkin (the Given-When-Then language) has the benefit of forcing you to think about behavior and while doing so you are vocalizing the various roles in the system, what kind of actions are accepted and what sort of result is expected! Many times this will help you remember or discover missing scenarios, edge cases and raise even more questions!

Crazy ideas, brain dumps and +1 as always are welcome in Issue #703.

Community

Coding alone is not fun! Here's what you can do to help us:

• Become a stargazer by clicking the Star button on our GitHub repository
• Follow @KiwiTCMS on Twitter
• Subscribe to our newsletter - we are GDPR compliant and we don't spam, we promise!
• Vote with a +1 reaction on GitHub issues (top-right corner)
• Send us testimonials and feedback about using Kiwi TCMS. We will be happy to publish them on our website
• Send us a pull request on GitHub
• Become a sponsor!

We are also looking to expand our core team and the list of occasional contributors. The following are mostly organizational goals:

• Goal: participate in 5 conferences with a project stand
• Goal: define how we find, recruit and onboard new team members. The foundation is already set in TP-3
• Goal: clearly mark GitHub issues which are suitable for external contributors which don’t want to spend lots of time learning how Kiwi TCMS works under the hood. We're going to tag all such issues with the label

Development policy

Our team will be working on areas related to the goals above. A +1 reaction on GitHub issues will help us prioritize what we work on!

Bug fixes and other issues will be occasionally slipped into the stream and pull requests from non-team contributors will be reviewed and merged in a timely fashion.

There is at least 1 full day of work that goes behind the scenes when a new version is officially released: compile changelog, build images and upload them, create blog post and newsletter announcement, share on social media, etc. We also deploy on our own Kiwi TCMS instance as a stop-gap measure before making everything public!

New PyPI tarballs and Docker images will be released every few weeks as we see fit, this has been our standard process. We try to align releases with Django's release schedule and try to cut a new version when there are known security vulnerabilities fixed. However we can't guarantee this will always be the case!

If you are in a hurry and need something quickly the best option is to send a pull request, build your own Docker image from source and maybe consider sponsoring us via Open Collective!

Happy testing!

Hello everyone, in this article I will outline the progress that the Kiwi TCMS team has made towards achieving the goals in our 2018 roadmap (mid-year update here). TLDR; goals are completed at 62%. Refactoring legacy code is showing good results, less so on the front-end side and there are items still in progress!

Make code easier to maintain

Status: good progress

Initially CodeClimate reported a "D" rating with 600+ code smells and 600+ duplications and a 1 year estimation to resolve these. We're now down to "C" rating with 171 smells and 203 duplications.

The level of technical debt has dropped from 32.5% down to 17.7% and we have removed around 14000 lines of Python code and 8000 lines of JavaScript code without losing significant functionality.

Checkout the stats for more info!

Use pylint and pylint-django

Status: almost finished

Both pylint and pylint-django have been integrated into our CI workflow. There are even some custom built plugins that we use. The number of issues reported is down to 100 from 4000+ initially. These are predominantly fixme comments which are also in parts of the code that are scheduled for removal and refactoring.

Render HTML, return JSON

Status: moderate progress

Several views were modified to return pure JSON but we've not done any targeted work to resolve this issue. A number of other views have been removed in favor of using the existing JSON-RPC layer.

This is an internal refactoring effort which isn't very visible from the outside. This is also one of the factors contributing to the high number of removed source code.

Submit forms, post JSON, GET clean URLs

Status: no progress

Not much has been done in this area except the occasional refactoring to JSON-RPC.

API layer

Status: complete

Documentation

Status: moderate progress, dropped

All RPC methods have been documented! The rest of the internals will be documented as we go along.

No vendored JavaScript libraries

Status: good progress

We still carry around jQuery, jQuery-UI and Handlebars.js. They will be removed once the pages using them are converted to use the Patternfly widgets library.

Less HTML templates with better organization

Status: moderate progress

There are still over 50 HTML templates in tcms/templates/ that need to be refactored into Patternfly. We've been working on them one at a time and will focus more on this effort in the next couple of months.

Modern interface with Patternfly

Status: moderate progress

Some of the pages have been converted to use Patternfly. The most important pages that still have a different look and feel are TestPlan view, TestCase view and TestRun view. These are also the hardest to convert because they have lots of tabs/components which pull information from various places. Our goal is to create reusable widgets for the various components (e.g. a list of TestCases) and then include these components into several different templates to minimize code duplication.

JavaScript updates and front-end testing

Status: moderate progress

A number of JavaScript functions have been refactored and removed during the past few releases but there are still thousands of lines of code left to deal with. This effort is mostly happening in parallel with the Patternfly redesign. We still don't have anything to test front-end JavaScript functionality!

Community efforts

Status: good progress

We are seeing a steady stream of new users registered on https://public.tenant.kiwitcms.org and there are several active contributors on GitHub. Most of our translators are very active and keep their respective languages fresh and up to date!

Kiwi TCMS was represented at OSCAL Tirana, DjangoCon Heidelberg, PyCon Prague, HackConf Sofia, PiterPy St. Petersburg and OpenFest Sofia. We've also been approved for a project stand at FOSDEM 2019 so watch this blog for more news.

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 roadmap.

Make code easier to maintain

Status: moderate progress

Initially CodeClimate reported a "D" rating with a 1 year estimated effort. Now it is still on "D" rating with a 7 months estimated effort to bring the project back in shape. Code smells have dropped from 600+ to 418, duplications have been reduced from 600+ to 359! At the same time technical debt ratio has been decreased from 32,5% to 21,6% and little over 10000 lines of code have been removed from the source code. Checkout the stats for more info!

Use pylint and pylint-django

Status: good progress

Both pylint and pylint-django have been integrated into our CI workflow. There are even a few custom built plugins that we use. The number of issues reported is down to around 900 from 4000+ initially. The cleanup has been lead by Anton Sankov with help from Ivaylo Ivanov and myself.

Render HTML, return JSON

Status: no progress

Several views were probably modified to return pure JSON in the meantime but we've not done any targeted work to resolve this issue.

Submit forms, post JSON, GET clean URLs

Status: no progress

Same as above, not much has been done in this area.

API layer

Status: complete

After Kiwi TCMS v4.0 the server side API has been reorganized and updated to follow the model/method names used internally.

After the recent version 5.0 the client side API library has been stripped to its most basic form so that you can work directly with the responses from the server.

There is no more duplication and ambiguity in names because there isn't a lot of code left!

Documentation

Status: moderate progress, dropped

All RPC methods have been documented! The rest of the internals will be documented as we go along.

No vendored JavaScript libraries

Status: moderate progress

Several JavaScript libraries have been removed but we still carry around jQuery and Handlebars.js. No work has been done to convert Kiwi TCMS to use the jQuery version provided with Django.

Less HTML templates with better organization

Status: minimal progress

There are still over 100 HTML templates in Kiwi TCMS. Some of the HTML templates have been merged together, some email templates have been refactored and marked as translatable but the majority of them have not been updated for a long time.

Modern interface with Patternfly

Status: no progress

JavaScript updates and front-end testing

Status: small progress

A number of JavaScript functions have been refactored and removed during the past few releases but there are still thousands of lines of code left to deal with.

Community efforts

Status: moderate progress

We are seeing a steady stream of new users registered on https://public.tenant.kiwitcms.org and there are several active contributors (issues, translations).

Kiwi TCMS was represented at OSCAL Tirana, DjangoCon Heidelberg and PyCon Prague! We're planning to attend HackConf and OpenFest in Sofia by the end of the year.

Happy testing!

Hello everyone. As you know Kiwi TCMS has been around for a while and it has gone through some big changes in the last year! It started as an abandoned Django 1.6 project with broken test suite and is now currently running on the latest Django 2.0.1 with Python 3.5! It is clearly a legacy code base!

We, the Kiwi TCMS team, have learned a lot more about the project and this blog post describes our roadmap for 2018 in terms of technical work and community engagement. The general technical direction is cleaner/simpler code, improved UI/UX and more tests!

Make code easier to maintain

The current code is a bunch of very large modules and functions and classes bundled together. It is also old and sometimes looks like spaghetti code. CodeClimate gives us a "D" rating for maintainability with a 1 year estimated effort to fix that. There are 600+ code smells and 600+ duplications detected by CodeClimate. Our goal is to get this number down to zero!

Use pylint and pylint-django

pylint is the standard static analyzer for Python and currently it reports over 4000 errors and warnings when executed against Kiwi TCMS. This is a huge number and it needs to become zero! We've also identified interesting patterns that will make it into pylint and pylint-django plugins!

Render HTML, return JSON

The current state of affairs is a mix and match of everything. There are views that render HTML, others which return pure JSON, other which return HTML encoded as JSON string and probably everything in between. Views that render pages need to do just that and views that are used with AJAX calls from the UI need to return pure JSON! A lot of these are hiding in plain sight and will come to light when we start overhauling the user interface.

Submit forms, post JSON, GET clean URLs

There are lots of forms in Kiwi TCMS. Sometimes they are submitted by the user and other times they are serialized and POSTed by some JavaScript code. This isn't very easy to understand plus this entire home-grown utility code doesn't bring anything useful to the project. All of these need to be identified and cleaned up. JavaScript code needs to send or consume JSON, nothing else!

There are also lots of places where Kiwi issues GET requests with a number of query parameters. Our goal is to minimize these and where possible have the parameters as part of the Django urls scheme, not as query strings.

API layer

The current API module is a bit disorganized. API namespaces don't match the names of the underlying DB models and the API client classes don't match any of the other two! The way we pass parameters and what these parameters are named should match between the client, the RPC method and the underlying model!

In earlier releases we've removed duplicate or similar RPC methods and we think there are more of these that need our love.

Documentation

We've started producing documentation from doc-strings and most of the RPC methods have such. However it is unformatted and barely readable, sometimes even inaccurate. Previous releases made progress on this but there's a lot more to cover.

All RPC methods should be documented first and then the rest of Kiwi's internals to make development easier!

No vendored JavaScript libraries

There are 11 vendored-in JavaScript files that we carry around in Kiwi TCMS. Most notable are jQuery plus a few addons and Handlebars.js. To the extent possible our goal is to use jQuery provided by Django or installed via NPM dependencies!

Less HTML templates with better organization

There are over 100 HTML templates in Kiwi TCMS. There are also email and even JavaScript templates. For example there are get_cases.html and get_review_cases.html which are essentially the same. This is kind of also true for templates used in new and edit views! Such templates should be unified!

Those JavaScript templates need to be totally gone!

All templates are stuffed together in a single directory and their names are not very predictable. They need to be split per application and follow some kind of naming convention.

Modern interface with Patternfly

The UI already uses the Patternfly library for some of its widgets. Most notably the main navigation header. Our goal is for the entire UI to be ported to Patternfly by updating widgets HTML and CSS where needed. This will also help clean things up a lot. At the same time we'll be rethinking how information is organized on screen and how the person interacts with it! Usability suggestions are very welcome!

This move will also help us get rid of the Handlebars dependency which is now used for pop-up dialogs.

JavaScript updates and front-end testing

There's lots of JavaScript code on the front-end and honestly we don't quite know what it does or how it is organized. There are also no tests on the front-end whatsoever!

It is our goal for this to change with the intention to not overdo the JavaScript part and keep things very minimal. At the moment we're thinking about vanilla jQuery that will act as a proxy between the browser and the back-end!

Community efforts

A year ago hardly anybody knew what Kiwi TCMS was, the project didn't even have this name, there was 1 active contributor and hardly any users! Now the community has started to slowly revitalize, we're seeing some contributions from our junior team members (more on this in another blog post) and also seeing folks installing and using Kiwi TCMS and reporting interesting bugs and feature requests around it!

For the upcoming year our goal is to seek active engagement with other open source projects that could make use of Kiwi TCMS and work with them. Kudos to openSUSE for being the first to propose such integration! We're also planning couple of appearances at a few conferences but there's nothing confirmed yet.

Every other contribution in terms of bug reports, new users and feature requests is of course welcome but we're very conscious of the fact that there's tons of work to be done and the team is still very small!

Team wise we'd like to get the existing team members up to speed and tackle the above tasks with priority. This will also help us introduce bug fixes and new features more quickly!

Happy testing!