While on my reflective bender on my QA work over the year I decided to cover the actual processes we have in place at work. So, I wrote a blog post outlining the processes we have in place at Chirpify today, on the official Chirpify blog.
My last post was an overview, but this one will dive into some of the problems I encountered when I was first getting started as the de-facto quality stakeholder and dig into what REALLY mattered when it came to the actual process of QA. Fitting into the development cycle is critical.
There is no better way to learn the workflow than to follow a feature through the factory and out the door. Make it a priority to see a feature from design to deploy as soon as possible.
Every team has idiosyncrasies that make experience a better teacher than a ReadMe.
When I was hired on my job description clearly included committing actual code so I also had the advantage of being able to make several early commits and deploys that far and away gave me a better idea than just being told. Do this if you can.
Once you know the workflow, agile or not, you can get a better picture of where QA fits. Almost always at the end of a cycle, but often interspersed with development under certain conditions. If your team uses a kanban board, a flow chart, a spreadsheet, or project management software the next step is to carve out a QA section and OWN IT. This is your wheelhouse, and when a ticket or a story enters it it must bend to your will.
If having a QA engineer/Tester/Test Engineer wasn’t part of the teams workflow, or if testing was less of a process that was owned and more of a vague responsibility placed on each developer… then the workflow will need to change. You’ll be the catalyst here.
In order for your work to be effective you’ll need to start asking for things to happen upstream, long before they land in your lap. One of the best ways is to get your hands into the ticket/story system and outline steps that need to happen as that ticket is passed along to a developer. If your lucky like me, buy in from your manager here will be easy and they’ll be eager to help make that happen.
One of the simplest process wins early on was to simply request that every dev write a few short summary of how the feature should work, how it shouldn’t work, and finally how they had tested it.
Now you know how the “Happy Path” was tested (or if it was tested at all..) and you can immediately compare this summary with the feature spec in the story and make sure nothing was missed.
I was very skittish about walking into a new team, a new workflow, a new product, and a new codebase and then starting to make demands to make my life easier.
You need to suppress that doubting voice, ultimately you were hired to improve the product and build a process that makes more stability a foregone conclusion.
At a startup the only constant is change and you can rest easy knowing your changes will be the least of anyones concerns. As long as you explain the benefits of your decisions people are normally more than happy to hear the initiative being taken.
If you’re building a QA process for a startup then you are also the key stakeholder for Quality and by fiat you now have the opportunity to start instilling good habits. Don’t hesitate to advocate from a place of confidence if you know your changes will result in a higher quality end result.
When your team members start to reap the benefits of better quality any prior doubts will be washed away.
This year marked the first full year of QA at the startup I work at, working as the first QA hire on an existing engineering team. There were a lot of challenges, but I wanted to share some of my take aways and challenges that were overcome.
There was not a system in place for me to plug into when I arrived, testing was happening, deploys were happening, and code reviews were happening all somewhat organically and maybe haphazardly.
I had what amounted to a clean slate and worked to build up some systems from there.
My first step was to learn the product. The most important thing i’ve done since I started last year was to become a product expert. Knowing our product intimately continues to be one of the best values I bring to the table and allows me to be more targeted and succinct in testing.
As the product grew I also began to maintain documents outlining a lot of the more esoteric behavior, outside of repo ReadMes. This has saved my hair more than a few times.
My second step was to integrate myself into the Dev team workflow. Finding out where QA lives in the release lifecycle is important and defines a lot of the actual QA work that gets done. In our semi-agile team framework QA became the last step on the Kanban board. I like to think of that part of the board as ‘active development part II‘. In an ideal state i’m working hand in hand with the devs assigning and closing out bug tickets until we have a stable feature.
The third step was deciding on tools. We use Asana as our management software, ticketing system, and QA tracker. I’ve enjoyed using it as I’ve reinvented the QA ticket process several times because it affords a lot of flexibility in the organizational structure of your tasks (tickets).
I use Google Apps for spreadsheets, where I document feature behavior, or maintain checklists that are shared with third parties.
And I use CasperJS to automate a lot smoke testing that would otherwise eat a huge amount of my time.
I’m still searching for a good lightweight tool to organize functional test cases, an essential part of reducing the bus-factor of the QA team (1).
If I had to describe my year in one word it would be: Iterative
I haven’t built the best QA system, nor the best processes, but in the last year they’ve grown to better match the challenges we have everyday. The next year will be even (iteratively) better.
I’ve tried a lot of different thought organizing tools over the past year. in order to get a better grasp on my time, projects, and recreation i’ve bounced from different idea to idea, but the Bullet Journal is by far the most effective method i’ve tried so far.
What is Bullet Journalling?
Its a journal system with rules for organizing three things: Tasks, Events, and Notes over time.
I haven’t spent enough time to wax poetic about all the nuances that make it better than every alternative out there, but I can safely say that there is a sense of accountability that follows with carrying around your organization bible. Tasks are easy to reference and the at a glance summary of how I spent the previous month is incredibly satisfying.
As opposed to my google calendar, which is how i’ll need to allot my time based on my future obligations, these things aren’t necessarily more broadly important for me to remember, so referring back to it as a summary of how I spent my past month is relatively useless. This is curated, and easily so because that cruft never gets introduced into the Journal in the first place.
This has not, and obviously cannot replace things like calendar events for work related items, but for less strictly time sensitive items and for personal, events, notes and goals its just the right amount of scaffolding to support it.
I’ve really enjoyed it. Watch the video and if you decide to take the leap I recommend grabbing a grid ruled Moleskine notebook to get you up and running.
As shown by the frequency of updates to this blog my focus has been squarely elsewhere since the beginning of the year, but i’ve got a good excuse. I promise.
At the start of this year I began working as a QA Engineer at an exciting start up in Portland and i’ve barely had a chance to stop and catch my breath since. Rereading my last post I realize that I still have the same goals, but I need to be smarter about giving myself the room and prioritizing my time in order to be successful. I’d like to have a killer #DevYear, but i’d also like to crush it at work as a QA Engineer.
How do you set aside time to grow? It helps if you like what you do, and I do. But beyond that simply saying that you’ll apply yourself when free time presents itself isn’t enough.
My goals are heavily anchored around projects, realistic and attainable projects that achieve things I want for myself and require me to grow in areas I desperately want to. If I have a project as opposed to a learning goal I can schedule time and adhere to it much more strictly and quantifiably.
The culmination of that is in two large ongoing projects: An online magazine and a web application.
By focusing my work around these projects instead of a nebulous goal like “I’d like to become proficient at [insert skill here]” I have created deliverables for myself.
I plan to really grow my skills in the following areas by executing on these projects:
Just as i’m agile in the workplace I plan to be agile in my implementation of these personal projects. An MVP for the web app and Magazine to be debuted sooner than later. Watch this space.
Talk to you soon,
Johann
Building a better developer one Johann at a time.
I’ve procrastinated for some time now (admittedly its been a busy year, career wise) on a plan for my continued education, but I think things are finally taking shape and a plan is forming. In order to continue to grow from a Junior Developer into something more… I need a skeleton to put meat on and #DevYear will be my skeleton. Learning will be the meat on those bones.
What are my high level goals?
Become a better Rubyist
Become a better Javascript developer
Exhibit greater mastery over my developer tools
Learn enough UNIX to be dangerous
Build an ambitious Rails application that uses all of these skills
My toolbox so far:
Khan Academy (I need math learnin’ somethin fierce, y’all)
Reddit (I know, I know, but there’s real meat there for my spooky skeleton)
– /r/learnprogramming –/r/dailyprogrammer –/r/learnjavascript –/r/vim
Building a plan:
I’ll be posting soon about how i’ll regiment my time in the coming months to try to achieve these goals and will hopefully be able to analyze how helpful each step was in growing my understanding and skill set.
Picking up where the last post left off, our second month introduced the group project work. Rails and Ruby continued to be lectured on as well as general programming topics, but I think the important thing was that the students self organized into groups after choosing from project proposals and began to work on delivering them in a short time. This was exciting to me because delivering functioning code that someone else asked for was the name of the game and learning to work within a group is a key skill for a developer. You’ll rarely be a total “lone wolf” working as a professional on a dev team.
Gradual Release of Responsibility:
The idea of agile development came into play as self organized groups took focus away from a strict lesson plan and our first gradual release of responsibility took place. Coming into the program as a non-advanced student I think at this point I would have preferred more guidance, but others also seemed to thrive when allowed to go their own way with their use of their 9-5 office time. The key to staying focused was that a lot of the resources I was using already framed out a relatively straightforward learning plan that I could continue to execute, without them I think I might have flailed a lot more.
At a certain point however, what we wanted to focus on became more clear as what you tend to spend more time on you tend to get better at. Subconscious specialization if you will. The Development of Discuss-it was the breakthrough moment for me. Walking through the project from wire frames, mock-ups, and white-boarding to a feature complete app that is working and hosted. Built with a team and delivered on-time(ish). It also focused me on Rails and Ruby in a way that theoretical study couldn’t have. For a lot of the same benefits working through Hartl’s Rails Tutorial is fantastic and a great primer.
This is also where a lot of the value of the code school was for me: surrounding myself with enthusiastic people who I could collaborate with like this and who were at a similar skill level was absolutely crucial to building up my competency and giving me confidence and motivation to continue.
Company Tours:
The time continued to fly by and now we were starting to tour local development companies (and dev teams of non-development companies) through PCS. This was another great aspect of the code school that I think was key to job hunting success later on down the road. We toured a whole lot of very cool companies including: New Relic, Elemental Technologies, and Dark Horse Comics. We were able to ask a lot of questions about the practical day to day aspects of development work and about what me might need to do to better prepare ourselves for a position at one of these cool local companies and build up contacts for future networking. This part of the program was invaluable and led directly to my first official Developer job right after the program finished.
End Run:
In the last month we experienced another gradual release of responsibility that made essentially all of our class time our own apart from what we scheduled with our instructor, Chuck, ahead of time. This was both my most and least productive period of learning. I fell down several rabbit holes, set learning goals I didn’t accomplish, but also learned about tech I didn’t expect to (MongoDB, AngularJS). I also began work on a group project that did not manage to get off the ground. Components of it were sound and good work samples, but the project itself did not achieve its goals and that was on its own a very valuable lesson in project management.
The final release of responsibility was off course sending us off to apply to jobs, and our last week was almost exclusively focused on this. I was surprised to find that there were at least 100 tech companies in Portland that could be a good fit for a Jr. Developer, but there were in fact that many in a list the students worked to compile and with a healthy amount of caffeine I began to carpet bomb them with applications.
I started receiving responses immediately and I literally haven’t stopped receiving them since… more than three months later.
Was it worth it?
I have finished a contract with a company I had at the top of my list to work for when graduating from PCS and have signed on for a QA Engineering position to start at the beginning of the New Year at a start-up that i’m very excited about. You get back what you put in and I think I’ve gotten everything I wanted and most importantly built a model for my own personal learning plan for the future. And for that my tenure at PCS was worth what I spent, the time I put in, and the job that I quit to get here.
The program at Portland Code School has now changed, new instructors and staff, new hours and I cannot say whether it still affords the opportunity I got, but I can vouch for the program I attended.
A new posting in my portfolio: The Slashdot API officially spun out of Discuss-it now has its own page.
You can now query our slashdot API directly and grab the listings we scrape and format to populate the search results on Discussitapp.com.
Check it out:
Continued from Part I
The weekend bootcamp came and went pretty quickly. The basics of web development (AKA learning what happens when you click on a link in a browser besides “a page loads”) were covered, websites were launched and before you know it the weekend was over. It was enough.
After marinating on the thought for a little while I decided it was time. I loaded up the application page in my browser and… the application date had passed.
Damn.
On a whim I shot off an email checking to see if anyone had dropped out and if I still had a shot for the summer session. As luck would have it, fortune favors the mildly inquisitive. A few days later I had an interview and several days after that I had a curriculum: get comfortable with HTML and CSS because on day one you’ll be expected to work with it (the book we were assigned was by Jon Duckett and has the pleasure of being both informative and beautifully designed). So far so good, though, as it turns out once you apply for a 9-5 programming bootcamp you have to actually quit your job. In the interests of full disclosure I left a position in administrative assisting… somewhat non-ironically a field ripe for automation.
Two weeks went by quickly, but time slowed slightly for my non-deathbed conversion to OSX and then quickly sped up again.
Week One:
Day one is difficult to separate from all of week one without the aid of a spatula, but I vaguely remember introducing myself to a lot of unfamiliar faces who I count as friends today. The subject was Ruby, Git, and environment setup for anyone who hadn’t quite acclimated to their knew development home on the command line (hint: me!). The days were structured, lectures, assignments, readings and of course pairs for paired programming. I don’t recall the first few days being mind blowing, but they were demanding. A little later we found our Everest: Recursion. Most of us slammed our brains against the concept of implementing recursion and just before we grasped it we were moving on to the next thing.
I recall at the end of the week taking stock of myself. I was exhausted. 10 hour days and all of them spent learning something new. Everyday involved constructing context just to feel comfortable enough to crawl ahead another inch. I’d been out of practice educating myself for some time now. I wasn’t sure I could do it. Maybe I just wasn’t cut out for this. I could quit the following week and only lose the deposit… I could probably get my job back. I’d give it one more week.
Week Two:
More Ruby, the command line doesn’t feel alien, programs are starting to do what I want them to. I think i’ll stick it out. Finding out that I wasn’t the only one completely off balance was a great comfort and paired programming really helped drive home that I was among good people to learn with.
Week Three:
Javascript, the language of web ubiquity and semicolons, but mostly semicolons. We started by way of jQuery. The pace had been set by now to the point that no one seemed particularly phased by the complete shift in programming language. The ability to make things fly across the screen was a welcome change from ASCII graphics on the command line. A good week for small constructive victories.
Week Four:
You can test Javascript? Weird.
Read the rest:
Part III: Group Projects, Agile Development, and Employer tours.
Johann Hannesson 