Tag Archives: Software Quality

May 07

Formal Code Review with Upsource

Posted on by

Upsource LogoIn the embedded world there is a never ending story to reach the highest quality of code possible. Once you bake a chip with a certain ROM, it’s usually  pretty expensive to fix bugs and a nightmare to upgrade devices in the field. Because of this, the quality delivered ‘for production’ should be thoroughly checked, formally reviewed and signed off as OK before sending it out to the manufacturer.

In previous posts I’ve talked about Software Requirement Traceability which already gives you a better idea on the overall state of your software through linking testcases with certain requirements. But we can go one step further!

People who have worked with Git might know Gerrit as some kind of gatekeeper that will force people to sign off bits of code, commits, before allowing it to be merged into the main repository. Due to various reasons I could not use Gerrit at the company I’m currently doing a project with and had to look elsewhere. Thanks to a friend of mine who is working at ZeroTurnaround I bumped into Upsource (from the guys over at Jetbrains and famous for their IntelliJ IDE). Upsource presents itself as a Polyglot Code Reviewing tool, which isn’t a lie!

I’m not going to bore people with details but rather give an overview on how I’ve implemented it and convinced people to actively use it.

First off, Upsource is a post-commit review framework. Unlike Gerrit, changes will have been merged into your favorite SCM. With this you really have to follow-up on what commits are done. Luckily you can set up Upsource to have triggers so it automatically creates reviews for commits done on, for example, a certain module of your software.

Secondly, these reviews can be auto-assigned to people based on some limited options (Upsource 3.5 should have more capability here, this is scheduled for September 2016 the last time I checked). What I added to my Upsource install is assigning people to a review based on one or more tags in the commit message. For example a message that looks like this: “Refactor sign-in function [DKE]” would have Upsource automatically assign it to me thanks to the [DKE] tag. With this, the committer can immediatelly notify people he would them to have a look (or sanity check) at whatever was in that commit.

Thanks to Upsource and the reviewing, we’ve already ended up with cleaner code, nobody wants to be “that guy” if you know somebody will have a (quick) look at your code. We used to shout feedback about commits back and forth and informally tell the original author to update this and that. Nothing of the converation got captured for future reference. Now we have the entire review history in Upsource and can get back to it in an instant to see why a certain decision to change some code was made. As an added bonus, people on the team might also become more familiar with parts of the code they are not an owner of maintainer of.

Lastly, Upsource provides some neat analytics on how much of your commits have been reviewed by one or more people. This could then also be used to show the management that the quality of the software is continuously being reassessed by the team and no compromises are being made.

I’d like to close with the fact that Upsource neatly integrates with GitHub, YouTrack and JIRA. The setup time took me less than an hour and in less than a day I got most of the system up and running. If your code quality could use a boost, give it a try, you’ll like it!

May 09

Test Management using TestLink – Pt I

Posted on by

I’ve been using TestLink for a while now and would like to share some of the knowledge I’ve gained during this period. In this tutorial series I’ll tackle the whole process from start to finish to set up a system that uses TestLink for Requirements and Test Project/Plan/Case management along with Test Plan execution using Jenkins.

Topics we’re going to handle include

  • Setting up TestLink
  • Creating content in TestLink (Projects, Plans, Requirements, Test Cases, …)
  • Issue Tracker integration
  • Pulling your Test Plan into Jenkins for test executions
  • Pushing the results back to TestLink

What I’ll be using in this tutorial is

If you do not have access to a webhost that has MySQL (or MSSQL) and an up to date version of PHP you’ll also want to install a webserver on your own PC (or your Jenkins machine) for experimenting purposes. In case you are not familiar with setting up a webserver or database I’d recommend you get

It doesn’t really matter what version of the software mentioned you get. Jenkins seems to release update very frequently while TestLink gets about a new release per quarter. Things might be slightly different in newer versions but it shouldn’t be a problem to follow the tutorial.

Let’s get started installing TestLink! Surf to the location of your TestLink instance, if you’re doing this on your own computer it’s probably something along the lines of http://localhost/testlink1_9_13/, you’ll be greeted by this page

TestLink Install

If you’re doing a fresh install just hit the “New Installation” link and agree to the license agreement. The following page checks if your setup meets the requirements. If you’re running this on your own computer you might need to resolve write access issues before being able to continue.

TL Install requirment check

Next we need to configure the database access. Select which DBMS you want to use (I’ll be using MySQL in this tutorial). Enter a user with enough “admin” rights and fill in a username and password which TestLink will use to access the database (this is NOT your login info for TestLink itself. Default credentials are admin/admin). Let’s continue!

Install report

In the case that TestLink could not write your config file, you’ll have to manually create the file and paste the given contents into it. Now everything is set up, browse to the root TestLink URL and you’ll be presented with a login screen.

Note that you can do a whole lot of configuration in TestLink but it’s not accessible in the GUI. You need to open up config.inc.php in a text editor and manually change the values there. I suggest you scroll through it and have a look what you can do. To be safe, make a backup of the file before you start editting it.

Some default behaviour I liked changing included the following

  • Change the path of the upload directory and log files
 $g_repositoryPath = '/var/testlink/upload_area/'; /* unix example */
 $tlCfg->log_path = '/var/testlink/logs/'; /* unix example */
  • Do not hide the available actions on pages by changing the value to inline
 $tlCfg->gui->op_area_display->test_spec_container = 'none'; // ''
 $tlCfg->gui->op_area_display->test_case = 'none'; // 'inline'
 $tlCfg->gui->op_area_display->req_spec_container = 'none'; // 'inline'
 $tlCfg->gui->op_area_display->req = 'none'; // 'inline'

There are many, many more things that are possibly a good idea to change depending on your needs, just keep in mind that all of these settings are in this file for future reference.

Congratulations! You’ve just installed and configured TestLink. When you log in you’ll be asked to create a Test Project before you can continue. I’ll be talking about this and more in the next tutorial.