About Quality Engineering

For the most part of my professional life I worked as an IT Specialist in Brazil. An IT specialist is a professional that designs, develops, employs or maintains information technology systems. It is a pretty broad term that may encompass several different different job roles (from database administrators to software engineers to production support analysts). In my case, I was engaged with 2 primary activities: software development and application architecture.

All of that changed 3 months when I left my IT Specialist job in Brazil and moved to Czech Republic to work as a Software Quality Engineer (aka Quality Engineer) for Middleware Messaging products. Since then, a few friends had come to me to ask: a) what I am doing, b) what exactly a Quality Engineer does and c) do you write code. With that said, I think I have answered question ‘a’. Since question ‘a’ is already answered,  let me explain what is a Software Quality Engineer (SQE) and it does.

A SQE is a specialized type of engineer that works on all phases of development to design, develop and execute tools, process and strategies to ensure that software products meet or exceed desired levels of quality (with quality being defined as the degree of excellence of an item or product).

A SQE usually:

  • Design, develop and maintain tools to perform automated testing
  • Develop and maintain automated test cases
  • Elaborate and implement Continuous Integration (CI) and Continuous Delivery (CD) strategies including its infrastructure and support tools
  • Help to investigate and verify security issues
  • Elaborate and execute test plans
  • Define and implement software quality metrics and design, develop and maintain tools to collect them
  • Review product documentation

Whether an SQE writes code depends on what type of products it works with. For example, in my case I work with tools for messaging and enterprise application integration, therefore I tend to write code quite frequently, as most of these products are used by software developers, IT specialists and IT architects to integrate disparate systems.





Recommended reading

Quick post to share some interesting material I came across the Web:






Axis webservices with Maven overlays

I should have published this months ago, so I hope I am not missing any details … This short post shows how to build an Axis-based webservice, using Maven overlays.

The first step is to add the required Axis dependencies:



Then you can configure the war plugin so that the important part of Axis is exploded and included in the deliverable and the non-important parts are excluded:

And that should do the trick.

Simplifying JMS testing with embeddable brokers

Ever hoped for an easy way to run embed brokers and simulate a full cycle JMS messaging cycle? Well, this pet project of mine may be useful for you (or, at least, give you an idea for an implementation). It works on top of JUnit, by providing a JUnit test runner, a JMS provider, a set of JMS-related annotations that will inject object instances and additional utility classes to simplify dealing with JMS. At the moment it works only with ActiveMQ, but adding additional providers should be fairly easy.

Here’s example of the a test class that sends and receives data through an embeddable ActiveMQ broker:

It’s pretty simple as of now, but I can see some interesting uses for running certain types of tests.

You can find the project page here.

JSON manipulation: reference material

While working on ways to export my backlog in Trello, which I wrote about in this post, I came across the following articles that I think might be useful for those manipulating JSON data:

The titles are speak for themselves. Have fun.

Using jq to convert a backlog hosted in Trello

Disclaimer #1: Trello is awesome and it can export its data to CSV if you sign-up for one of the business plans. Because I was using it as an alternative solution for a couple of weeks, I did not feel the need to subscribe the service. If you have a large backlog, that’s the way to go.

Disclaimer #2: I understand each team may use a different board/checklist format for their history, therefore please interpret this article as generic instructions about how to export the data.

Pre-steps: In order to perform these steps, you will need to export Trello data to CSV. You can follow these steps to export the data.

Consider, for the purpose of this post, that your product and sprint backlog look like this (click for a larger version):

Sample Trello board
Sample Trello board

The colors (labels) represent either the effort, in points, for each history or whether it is in progress or delivery.

Each use case is composed of a checklist that represents the user histories. Pretty much like this:

Sample Trello Backlog
Sample Trello Backlog

To export the product backlog as well as the sprint backlog, you can use:

The backlog.tmp should look like this:

To export the labels, which contains the effort (points) for the use cases, you can run:

The backlog-points.tmp should look like this:

Finally, you can export the progress of the project with the following command line:

Although readable, the exported files contain data that may not yet adequate to import into LibreOffice (or any other CSV-capable reader). It is recommend to filter the files of invalid characters. In this example, both “[” and “]” should be filtered. Here’s a sample command line that can do the trick:

Just remember to replace file.tmp with one of the files generated in the steps above.

Processes, automation and discipline

Regardless the introduction of tools such as Puppet, Vagrant, Apache Maven, Jenkins and many others tools that automate the job away, a lot of software development teams still rely on outdated processes and manual labor to perform the bulk of delivery.

Unsurprisingly, the excuses for relying on outdated development practices haven’t changed either:

  • We don’t have resources.
  • We don’t have time.
  • It does not create value.
  • It does not fit our development process.
  • We just do simple stuff, or a variation, we just write small stuff.
  • We don’t have the skills to do it.

There is a vast amount of literature rebutting these misguided – and often short-sited – opinions, therefore it’s not my intention to rebut them.

What I want to point out is that more than just laying out algorithms in a text file, delivering great products involve processes, automation and discipline (see observation below). Just like a pit stop in a Formula 1 race:

(An outdated, manual and loosely disciplined approach versus a modern, automated and highly disciplined approach).

Obs.: discipline as in a systematic, ordered approach to development, and not to be confused with blindly following the rules or an unquestioning behavior.

Running Apache Camel within an Application Server

This week I needed to show a colleague how to use Apache Camel, Apache CXF and Spring to create a web-based integration application. To do so, I created a Camel-based implementation of the Simple Apache CXF examples I wrote in 2012. Although this topic is covered more than once on Camel documentation, some details are either missing, which can make it tricky to run this setup this the first time, or are specific to a the application server where the code will run.

Therefore, I created this example (which you can find in this repository in my GitHub account) to complement the official documentation with additional details. I used the open source GlassFish application server to run the code.

Continue reading Running Apache Camel within an Application Server