Today there are many Automation tools that companies are working with. It’s evident that not every process around baking quality into mobile apps is perceived the same. In my 10 years working for enterprise and startups there always seems to be one thing that teams tend to overlook. It’s rather simple, but as engineers we sometimes make our lives harder than it has to be. This is especially true when we are faced with a business process related to do items.

If you’re working in a large organization you might know what I am talking about. It’s what you get asked for at the end of every sprint and before being ready to release to production. The “thing” I am referring to is a Report. 

A REPORT! I believe that most of the companies and teams understand the importance of a comprehensive report or dashboard for tracking and measuring, especially when trying to implant the mindset of mobile DevOps. How can something so simple actually make engineers lives better but also painful as well? Stories in the development world are a great piece of literature. They contain instructions as well as dates of when something happened and when it should end. Now you might be thinking, isn’t he talking about like User stories or Epics? Yes, in a way this refers to User stories or Epics. But this is not a lecture about either, we’re talking about reports!

For companies adopting the agile process in mobile dev & test, each sprint should be trackable and measurable to see the improvements. From my experience, however, many development teams tend to overlook the activities that are done at the end of a sprint, or there’s no data to backup the retrospectives to correct and make changes for the next sprint. We are always asking ourselves “What really went wrong, if when we know that if we really talked about it, we would be afraid of what people would say.” Depending on what industry your team is working in, there’re many checks and processes that other teams outside of your core team need a status on. Depending on the asks, this can be a cumbersome process. I dreaded the time when I would have to compile reports for security audits. I had to produce documents on what was tested, the result, what version it was done for, and the check-in’s that occurred. If mobile DevOps processes are already implemented in your organization, this might all sound simple. But still, not everyone has the luxury of paying for tools to do the job for them. Trying to get buy in for a tool can be very difficult depending on how much change is being introduced.

But what if you could get buy in from your core team and not have to worry about compiling those reports for other teams and management to see? I think for most people this would be a game changer! When we talk about the benefits of DevOps, it’s really the practice of making everything automated and shipping hard and fast. What no one talks about is when everything is automated how do you know it’s all working? What, from an automation standpoint, do you know what’s there? I hear people talk often about how “Code is your documentation”, well that’s cool but I have to take issue with this. Code is only as good as the engineer or developer that created it and how many people it makes sense to. Therefore, it’s possible if you have crappy code you have crappy documentation… I think developers are trusted too much these days and nothing is holding them accountable for the work they are doing. Don’t even get me started on peer-reviews… When it comes to testing, I’ve seen developers check-in unit tests that pass no matter what the condition! We can call it whatever you want or have excuses for it.

Now how do reports come into this? Reports and metrics provide information that tells a story of what is going on. It’s a great mechanism for everyone to see what is going on with a build or software. It holds individuals/teams accountable for what they are working on. If XYZ build passed unit tests but functional automation is failing right away, why did the build pass unit tests? Whose check-in broke that code? Reports can show trends that would not be visible to people right away. Reports should be made in such a way that it is clear to the business and engineers what is going on. If I want to know the health of a build that shows both efforts of automation and manual testing, it can be hard to produce this as it requires manual efforts most of the time. I think this topic isn’t talked about often due to everyone’s needs that are different from company to company and team to team. I think there are some similarities that could be consolidated and be shared for everyone to benefit from.

So what reports, dashboards, and metrics do your teams use? Post your comments below!