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.
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:
Disclaimer #1: Trello is awesome and it can export its data to CSV if you sign-up for one of the businessplans. 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):
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:
To export the product backlog as well as the sprint backlog, you can use:
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:
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 vastamount 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.