Fall 2018: Blackberry Coop Report
January 10th, 2019.
Table of Contents
List of Illustrations
Introduction
Welcome to my BlackBerry Coop review. Through this page, you'll learn about my first University coop experience, including my thoughts, goals and a bit of background on both my position and what the company was about.About BlackBerry
BlackBerry Limited, previously known as Research In Motion, is a Canadian tech company that focuses on secure enterprise software and the Internet of things.[1] Founded in 1984 by Mike Lazaridis and Douglas Fregin, BlackBerry has become a multinational corporation best known for their BlackBerry devices and cybersecurity.[2]Job Description
The role of a test automation developer is to design and write programs that run autonomous test scripts on new or existing software. It is a key part of the software development cycle, and generally stands between the building of the software and depoloyment.[3]
Cosgrove, Cameron (2016-01-13). "DevOps builds software better, cheaper and faster". DigitalCTO.
Test Automation Developer in the Mobility Solutions Team at BlackBerry
As a Test Automation Student on the Mobility Solutions team, my primary role was to provide test suite results as soon as possible after a new productivity app build. The sooner we all got the tests done, the sooner we could debug or release a new build. Releases were usually done once or twice a week across two different app versions, where one would be hotfixing and the other would be development. Beyond test execution, my role involved building the test suite infrastructure, and working with developers to fix any problems that were being had.Testing Experience
Test automation is a highly rewarding, albiet frustrating experience. It's very difficult to get the job right, and requires a lot of knowledge in a lot of different areas of computer science.
On the Mobility Solutions team at BlackBerry, test suites were done programmatically and ran autonomously, but it was important to quickly respond to any failures. A product failure requires the immediate creation of a Jira task, and a sync up with the component's developers for additional testing. Test failures, where the test crashed or reported inaccurate results, have a slightly lesser priority, where the root cause would need to be identified before a Jira task is created and triaged, where it is then fixed by someone on the team.
However, maintenance and expanding the test infrastructure was an equally large role. While you might not always be the one fixing the broken test cases you report, it's important to know how it's done so you can create more insightful Jira tasks for others to follow. Additionally, the creation (or cleanup and optimization) of new suites helps provide new coverage and confidence in builds being prepared for a release; in some cases, new coverage makes a really big difference when showing results previously not had.
Skills on the Job
Most of the development on the job was done in Android Studio, but that's not necessarily where all the skills came from. All the hard skills had been taught in school, such as Java, git and basic linux, but beyond the actual development, many additional testing and project management skills were required. Jira and Gerrit were the two dominate tools for product management, where Jira logged tasks and issues for the team to handle and Gerrit provided a clean interfact to peer review code. These, along with Jenkins, a tool for running automated tests, where easily learned on the job and there was always help available from within the team. So as long as you follow along both in school and at work, there's no surprises there!Main Project - Application Profiling Automation
One day, I was assigned to help him collect some data regarding launch and load times within some of the apps. Most of the data was collected by clicking a few buttons on an app, then reading the log lines and calculating various things.It was a bit odd of a task, and I found it rather mundane and repetitive. I was more than happy to do it, but it just didn't feel like I was being efficient with my time - and half an hour later, I was still not even halfway through. So I stopped, and I thought how I could make this better.
The first thing I did was write a very hacky, command-line script that would parse out the logfile and make it so I could just copy the raw data into a file to manipulate. After doing that for a few more minutes, I opened up Android Studio and wrote a second very hacky Espresso test, which I had learned from copy-and-pasting code off other files. Combined, the Espresso test would click the buttons on the app, and my command-line script would parse the output to a file. I sat back for a moment and watched it do my work for me, and continued with some other developments while it worked away.
During a meeting the next day, my manager asked about the data and if I got around to collecting it. Alongside the data that I presented, I explained that it was a tedious and potentially inaccurate task due to human error, and that I had written a script to do it for me. While I didn't think much of it, both my manager and one of the more senior technical leads were quite surprised by my initiative and seemed very content about the work I had done, even after I had explained many of the scripts limitations and drawbacks.
My manager suggested he was interested in continuing the development of the little project, and we agreed it would be best if both myself and Yehia, another coop from the team, recreated the script as a proper test suite together - and so we did.
Over the course of the next month and a half, Yehia and I worked many long days on producing a robust and flawless suite that would be adaptable to many different apps and would be compatible with any supported versions. We additionally removed the need for any overhead, by having the suite kick off another program that would fetch the log data, parse it and report it in real-time as the tests ran. By the end, we had a fully autonomous Application Profiling test suite with full documentation, such that anyone on any device could just kick it off and harvest results - many of which included load time for certain screens, data loader measurements, and app start times under hot and cold start conditions.
Overall, the final result was a huge success, with many people requesting additional features and functionality too. All the while, both Yehia and I continued to provide test results for new builds, never missing a release. The project is now a large component of the test automation team, and will have its features expanded by the next coop in 2019.
Goals
Learn new skill sets
Challenging yourself on a technical front was always a goal I had looking forwards to coop in general. I had heard that test automation development was a very Jack of all Trades position, so I was excited to learn about all the tools they used - with the personal goal of knowing how I could set up a testing infrastructure from scratch, on my own. Needless to say, I learned a lot. In my spare time I do a lot of development work, but I never really understood what was going on behind the scenes. How does the buildbot know how to run my program?, or What is this "test coverage" sheet they keep talking about? where always questions I kind of knew the answer to... but not really. Yet that wass only the surface; because after working this role at BlackBerry, not only did I acheive my goal, but I also learned so many more things relating to test automation as well. In order of what I find most significant to least,- Android Espresso
- Ui Automator
- Jenkins
- Gradle tasks
- Gerrit code reviews
Performance
When I first heard that BlackBerry had accepted me as a coop, I endured a giant rush of joy and relief. I was excited to go to Waterloo where many of my friends lived, excited to see the BlackBerry headquarters, and I was excited to think what my daily life routine might be. But then I had a thought - I realized it was one thing to get in and be accepted, but it was another to prove my worth.I set out with a very straightforward goal, of do well, impress my managers, and uphold the reputation of Guelph. I had a lot of fears, worries and doubts, but I knew that I could do it if I just worked hard and continued to push myself. So long as I wasn't bored and was doing my best, it seemed like a plan that wouldn't fail. But how would I measure it? How would I know if I performed well? It seemed a bit difficult, so I broke it into two ways.
The first was to see how frequently I would receive good feedback on my work. For me it was a very passive way to determine how I was keeping up, and whether I was meeting or exceeding my manager's expectations. I often asked for feedback and made sure to genuinely adjust to it, and as the term went on I continued to improve on my performance and do a better job.
The second, and the bigger measurement I strived for - was "Will my manager ask me to come back?". In my mind, if a coop does a good enough job to be welcomed back to the position, they must have had a strong performance. To achieve this, I continuously pushed myself and found more work. If my tasks for the sprint were complete, and all my tests were run, the last thing I would do is sit back and relax. I would seek out extra work from my manager, or if he was busy, I would find work on my own, whether it was improving something that I used regularly or even updating documentation on the wiki. Through this method I inadvertently started what would become my main project, and through this extra initiative I had earned what I had strived for; a personal invitation from my manager to come back next year.
Identify my weaknesses
I've always been a strong programmer, and that was never really my worry. I used to think my weakness was quickly learning the ropes of a large project, but looking back that isn't so much a weakness as something every programmer has to deal with throughout their career. The best way to really determine if I had a weakness would be to have an identifiable problem I can look at, and see what I can do to make it better.And my manager, Patrick Lam, helped me do just that.
I never had an issue with my performance or the quality of my deliverables - but for some reason, my performance would slow down when I worked with a team. For the first month and entering the second, I blamed it on a lot of things. "Ohh, these meetings are so useless.. I could have coded it by now" or "Oh come on, I can do his part better than he can" were some of the excuses I always told myself. But the truth was, it was me. I simply didn't want to hear what other people had to say because I wasn't willing to accept I could be wrong.
I personally feel like it wasn't a conclusion that I was willing to accept, because in hindsight it seems to obvious. One individual in particular who really helped me see that way was a full-time employee, Chris, who worked on the development of productivity apps. We were talking about interviews, and he mentioned that he doesn't care if the candidate knows anything coming in, or if they can write fancy algorithms on a whiteboard - only if they're willing to accept other people and adopt to their different points of views. I jokingly replied that I would fail his interview, to which he replied "at least you realize that"... Which left me quite shocked in the moment, because it was entirely true.
After some back and forth with my manager and some other coops who knew how I worked quite well, one of the things I began to heavily focus on was my teamwork and communication skills. I remember thinking it seemed silly at first, but it just seemed to make the days so much easier and the work so much less stressful - and over time, as reflected in my one-on-one meetings with my manager, I began to improve. Moving forward, and after my exit interview with my manager, I now realize that communication and teamwork are not just checkboxes that I have to check off; but they're actually things you have to work on as hard as anything else to do. They are key elements of a working environment that I know I need to improve, and so I now know they will be my future my goals of things I would like to do.
Recommendations
I found that I had a significant number of meetings - many of which I didn't need to be a part of, or of the 1-hour meeting only five minutes would be distantly relevant to anything I was doing. Between the test automation meetings and the CCNT test automation meetings, only one of the two were really necessary. For the greater team meeting, in which everyone under Jeremy's organization gives an update for what they've been doing that week, I feel like it could be better done in a mattermost channel instead. Overall, the time spent in meetings adds up substantially, and even when working through them it feels greatly unnecessary at times.I also feel like the onboarding experience was a bit too much to absorb; while in hindsight it seems like a very fufilling way to bring the new hires to the team, it only seems that way since I now understand everything that was going on back then. At the time, I found it to be too much abstract information that wasn't sticking no matter how hard I tried to apply it. Each technical lead gave too little depth on too many subjects to follow along, and while it was far from a waste of time, it could have been better with some hands-on activities in the mix at a slightly slower pace, and with a bit less coverage.
Conclusions
The experience I had as a test automation development student at BlackBerry was fast paced, and at times very rewarding. It allowed me to learn tons of new testing and Android development tools, while ensuring I was never giving a task I couldn't complete. One of my favorite parts about the experience was just the time allocated to do my own thing, from trying new outreach on projects to working on something wildly different every month. My goals and expectations were met and my performance exceeded, and a bit takeaway is I now know where I can focus for improvement in my future positions.Acknowledgements
I'd like to thank Patrick Lam for being honest with me about my mistakes, rather than attempting to avoid conflict. It allowed me to work on issues where I was struggling as quickly as possible, as well as maintain performance that was up to and beyond standards. I would also like to thank Yehia Habib, another coop on the test automation team for keeping me motivated and on track for projects that went into overtime and late into the night. It was certainly a experience, and would have been much more difficult without their help.References
"BlackBerry says pivot to security is beginning to right the ship". CyberScoop. 2016-11-11. Retrieved 2019-01-02
"RIM co-CEOs resign, hand to job to insider". National Post". 2012-01-23. Retrieved 2018-12-30
"Test automation developer: job description". Targetjobs. 2017-04-23. Retrieved 2019-01-01