Deep work as a tester

I have been reading this great book: http://www.goodreads.com/book/show/25744928-deep-work that has gotten me to ask some hard questions about my work, life style, career and its progression.

Cal Newport’s central premise is that being able to work with focus for stretches of time is valuable, rare, meaningful attribute and strangely *more* productive, you can get more valuable work done in less amount of time.

This post is about my day to day work and which of them can be considered deep vs shallow.

What is shallow work? By the end of the book he gave this rubric to determine what is shallow work.

How many months does it take a no-experience but smart out of college graduate work to do that specific task

Here is a snapshot of how most of my time is spent in the last month from rescuetime from my work computer.

Below is the breakdown on how I rank each of these activities and trying to identify my shallow/deep work.

At the outset, we can determine all(95%) the time spent in communication and scheduling is shallow. Yes its very important to communicate, to help others and let others know what you are doing but saying what you are doing is less challenging than doing the thing itself. A smart college student who deeply knows what I am doing and interpersonal dynamics, can learn this in one month. There goes my 50% budget for shallow work.

Jira/Confluence: is either for updating bug status or getting information about a story or sprint. So two months.

Bug reporting: I spend 80% of my time in Jira with reporting bugs. Though many folks don’t know how to write proper bug reports, if you are following a template and are motivated enough, its not very hard thing to do unless you are using appropriate tools and giving the almost exact information needed for fixing the bug or a workaround. So for writing a decent bug report three months but for writing a bug report that is effective and likely points to the root cause is a complex task. A technical, experienced tester that knows about the nooks and cracks of the software can do that, so I give this 18 months.

Mindmeister: I use this primarily for test planning. Test planning though seemingly a simple task needs to understand the functional, non-functional, business requirements and then come up with concrete steps for testing those. It has to account for variations and other scenarios. One can get help from using a template or examples but it has to be evolved according to a projects context and the team, so 24 months.

iterm2: Even though I feel special spending time at the terminal, there is not really that fancy I do there. Its a few commands that are customized for a given project. Its an acquired skill but for a CS graduate this is an easy skill to acquire so 2 months and to get to CS graduate level of shell expertise 12 months. So total of 14 months.

Jenkins: We use jenkins for creating build automation, running tests, deploying to app stores etc. It needs skills in shell, cron job, Jenkinsfile, docker, programming experience and a lot of patience. I’d give 24 months, 10 more than shell skills. Its the backbone for all the CI/CD efforts.

Charles: Charles is a network proxy similar to fiddler which leads me to find a surprising number of bugs, root causes and provide proof for a bug. It needs understanding of HTTP protocol and for advance usage needs to know how to manipulate it. Configuring it for mobile phones is hard and error prone but once learned this is not that something that is hard to replicate. So I give it 18 months adding to the baseline of 12 months for a CS 300 level graduate.

Android Studio: This is the crux of my job, Software Development Engineer in Test. Creating Android espresso I create the framework, helpers, configs and the test automation that helps us automate a large part of regression testing. This is mix of programming, test automation and Android all specialized skills in themselves. Each of them take an additional 6 months on the base 12 months of a CS 300 level, so it can add up to 30 months to up to 48 months depending on the complexity.

Webstorm: I use webstorm to create and maintain a MOCK server that simulates an actual API. This is a specialized test tools that was developed to aid test automation. Needs a knowledge of HTTP, node, js, programming, domain knowledge. At least as complicated as the espresso framework above, so 30 months.

There we go, my deep-work skill set is test automation activities, CI/CD and test planning/strategizing. I will try to document how that goes along.