Agile QA using GitHub + ZenHub
New tools are not always the best solution to support new processes. Find how we structure the Quality Assurance process in PDVend without increasing the scope of tools used by the team in a 24-week timebox to ensure a process that delivers agile and quality solutions.
How everything start
I joined PDVend in May 2017, as a trainee, to work with Quality Assurance of PDVend’s android application (in August 2017 I was hired as Software Quality Analyst =D). On my first day, I left with the impression that the process of inserting collaborators into PDVend was extremely efficient.
They explained to me the whole history of the company, the role of each employee, the organization of the office and other matters, during all morning and in a very simple way. It was the first time when my questions were answered before I even did them.
The next day’s task was the configuration of the development environment. One of the android team developers instructed me and, to my surprise, the morning’s mission was executed successfully and without the intrinsic “suffering” to that moment I experienced in other organizations.
This contributed to my expectations for the mission of the third day going up a lot. Set to enterprise, environment set up, all ready to start the QA work of the app, said no one ever. I explain: there wasn’t yet a well-defined workflow for development/QA in the android team.
Despite the initial strangeness that this caused me, it was an opportunity to contribute to establishing a workflow for the team, rather than having to adapt to a previously defined one. The conviction that it was an opportunity is allied to one of the things I was told on the first day: don’t be afraid to ask, say, suggest, criticize, we are totally open to it!
I can say that I have never had this freedom in other organizations and this always left me extremely unsatisfied because I’m very critical, curious and thirsting for changes in favor of improvements.
Beginning of the process: choosing a tool
Speaking of changes, it was time to establish a workflow that didn’t bring a lot of process to the android team, but that was effective, making development and QA work extremely organically.
Initially we thought of using some specific test tools like Mantis and TestLink, but it would bring an unwanted process and conceptual charge to the team, which could result in non-adherence to the new process. It was necessary a simple process, that suited the agile methodology and that it was not onerous, mainly for the developers.
Following this line of reasoning, we chose, instead of adapting to a new tool, only to take advantage of some features of a tool that devs were already accustomed to: GitHub! Taking advantage of the issues feature to register the features, improvements and/or bugs of the android app found in the QA of the app.
Tool adaptation
The team adapted very well to the use of the issues, however, we still had some difficulties to visualize the progress of the work of the team through GitHub. Although there were pipelines from GitHub, the team could not have a clear view of what issues were still to be developed, which ones were being developed, and especially which were finalized and could go to the QA phase. In order to have this visualization it was necessary to individually monitor in each issue which pipeline was assigned to it.
Trying to solve this problem, we have chosen to use ZenHub, a plugin for Google Chrome and Mozilla Firefox browsers that adds robust management tools directly into the GitHub interface, making project collaborations faster, more visual and more organized.
One of ZenHub’s features is a customizable kanban-style board. The issues are organized on this board in pipelines and moved between them according to the progress of the team’s work. We customized the board with the pipelines: New Issues, All, Doing, Code Review, Ready to QA, QA and Closed.
For example, when an issue has to be developed within the sprint, it will be moved to the Todo pipeline. When one of the developers starts doing it, it should move the issue to Doing. When finished, the issue is moved to Code Review. Finished Code-Review, issue goes to the Ready to QA pipeline. When the QA of this issue is being made, it is moved to QA. If there are corrections to be made, the issue returns to the Todo pipeline and the cycle restarts. If the issue is approved by QA it can be closed and will automatically go to Closed.
Using more GitHub features
In addition to the pipeline, issues created can be classified according to their type by labels. These are the labels created for the android team:
To better organize the sprints of the android team, we started to associate issues with milestones. Each milestone created corresponds to a team sprint. The milestones can have an expiration date and allow the monitoring of the work progress through a percentage of completion of issues associated with a particular milestone.
The ZenHub board can be viewed using filters by labels or milestones, for example. You can also filter by issues assigned to employees. In the android team the developers organize themselves and designate in which issues they will work during the sprint.
Conclusion
Using only the GitHub tool and the ZenHub plugin, the android team started to have a simple, easy-to-use development/QA process using tools that were already part of the development team’s daily.
But, be surprised, not all our problems have been solved (lol). In the next article I’ll talk about how we structure our organization of branches and environments and which of our problems we can solve with that.
