Friday, August 17, 2018

The Testing Show - Conferences and Conferring with Anna Royzman, Claire Moss and Mike Lyles

I have been terrible with my shameless self-promotion as of late, but I think it's time I switch that up a bit. Remember my comment about that "grind" earlier in the week? Here's the end result and yes, I always feel better about it after it's all said and done because I enjoy seeing the end product and most importantly sharing it with everyone out there.



I have a little favor to ask as well if you are so inclined. Do you enjoy listening to The Testing Show? If you do, could I ask you to go to Apple Podcasts and write us a review? Reviews help people find the podcast and make it more likely to appear in the feed listings. Seriously, we all would really appreciate it. We work hard to bring these out and I'd love nothing better than to have more people be able to find it.



In any event, we hope you enjoy this month's episode. To set things up, here's the lead in for the show:

August is a busy time of year for software testing conferences (not to mention conferences in other industries). This month, we decided that, with everyone heading off to conferences hither and yon that we would dedicate a show to the topic, and we have done exactly that. Anna Royzman (Test Masters Academy), Claire Moss (DevOpsDays) and Mike Lyles (Software Test Professionals) join us as guests in their capacity as conference organizers, speakers and attendees (not necessarily in that order) to riff on Conferences and Conferring with Matthew Heusser, Michael Larsen, and Perez Ababa. Want to know where to go, what format to take part in or if you want to try your hand at speaking/presenting? We’ve got something for all those bases!

The Testing Show - Conferences and Conferring with Anna Royzman, Claire Moss and Mike Lyles: The Testing Show team discusses the QA conference season with Anna Royzman, Claire Moss and Mike Lyles. Tune in to learn more!


Sunday, August 12, 2018

When There's Nothing But The Grind

First off, I want to make sure that this doesn't come off sounding wrong. The title is accurate, but perhaps not for the reason folks might suspect.

As the Producer and Editor of The Testing Show, the heavy lifting of getting a show finished and up on Apple Podcasts is done by me. Yes, when we schedule the recording the panel and guests are all in on it together. When I deliver it to QualiTest, they take care of posting it so it's available. At times I am able to outsource the transcription process, but not always. This episode, it's all in my wheelhouse due to vacation an unavailability of my regular transcriptionist (who does a fantastic job, I might add and worth the price to have them do it).

There's no easy way to say it; to produce the show to the level I want to have it, with as clean audio as possible, grammatical edits and a full transcription so those who are hearing impaired can follow along, there are no time-saving shortcuts. Every second of the audio needs to be examined, edits made, transitions cleaned up, and waveforms spliced so that there is a minimum of intrusion. If I've done a good enough job, the end listener should just think it's a seamless conversation. For anyone who has actually done editing for podcast dialog, you know what I mean when I say, as soon as you've done these kinds of edits, you forever hear them in other podcasts, too. Perhaps I'm a little too aggressive in this process but since I do it this way, it takes quite a while to edit each show. The tricky part is (since I'm dealing with edited audio and transcribing edited audio), this is the literal definition of an extended monotask. When I write code, test, or write these blog entries, I can have other things going on in the background, take little detours, let my mind idle for a bit and then pick up again. When I'm editing the podcast, I don't get that break. I have to be focused and nothing else can be vying for my attention while I do it. For veteran podcasters, this probably comes as no surprise, but I can (and frequently do) spend about six hours per episode from completion of recording until handoff for posting. It can really chew you up some days but there is no exhilaration quite like when it's all finished and the email goes out saying "It's all ready to post, have at it!"

To relay this to testing and the oft-heard fact that monotasking is the best way to accomplish a goal, I both agree and disagree. Having to switch contexts from one project to another frequently does make for inefficient work and I have plenty of experience with that in my everyday testing life. However, too much focus on one thing, even if I am "in the flow", will physically chew me up and fatigue me fast. Still, there's no way around it. The show needs to be edited, it needs my undivided attention and that undivided attention can easily spread to six hours per show. What to do?

This is where I have to exercise supreme diligence if I don't want to drive myself crazy. Was I a smart individual, I would block out the track immediately, determine where I could perform rough cuts, do them within the first hour, and then approach a fine tuning on subsequent days, spending no more than an hour at a time on any given day. Of course, that doesn't often happen. What typically happens is I find myself coming up on a deadline and then the sense of "compression" takes over. With that sense of compression the "procrastination adrenaline" kicks in. From there, I move Heaven and Earth to get it all done in one Herculean shot and, once I do, I feel both joyous that I have finished it and absolutely mentally drained at the sheer volume of the process. This, of course, lingers in my memory, but for some strange reason, it doesn't make me any more likely to be more diligent the next time. So many times, it really does come down to "Dude, this is the last day before the deadline, now you have to do "The Grind" all in one day!" For a long time I thought I was just insane, but as I've talked to many creative types in various capacities, this approach is way more common than I thought. In a way, the combination of "time compression" and "procrastination adrenaline" all come flooding in at once, and that sense of terror is both motivating and, again, exhilarating. It's terrible on the nervous system, though. The hangover that comes after completion is rough and I literally feel like I need days to recover. Yet time after time I find myself doing it again. It's as though there is a form of "project amnesia" that creeps in. Either that or my amygdala just craves that terror state and tricks me into doing it again and again.

Question for those out there reading this... how do you deal with a project that demands sincere monotasking? Are you measured and deliberate? Are you a procrastination adrenaline junkie? Somewhere in between? How do you deal with it? What are your approaches to making it more manageable? Don't get me wrong, I love producing the show and will continue to do so. I'm just looking for better ways of keeping what little of my overall sanity I have intact ;).

Friday, August 10, 2018

Coming off a Long Break

Hello, everybody!

With the exception of yesterday's post to Jerry Weinberg, this blog has been quiet for a few months. That was partly by design, but it stretched way longer than I intended it to. There was a specific issue I was trying to deal with (elbow procedure that required me spending less time on the keyboard) but in reality, for a time, I felt like I had come to an end of what I wanted to say. After eight years and more than a thousand posts, I started to feel like I was going through the motions, repeating myself, or just posting content to promote other content I was producing elsewhere.

I intended to take a break for a few weeks but that break stretched into almost four months. In that time, my work life changed considerably. My company was acquired for the second time. Socialtext is still a part of PeopleFluent and PeopleFluent is now a part of LTG based in London, UK. Dealing with the changes from that took a lot of getting used to. In those changes is the fact that much of our old approach to work and doing things went out the window. I've had to adapt to new roles, new needs, and a new overall view as to what we should be doing. As part of that change, I've been asked to:

- Be the Scrum Master for our Engineering team (those who say "wait, isn't Socialtext a Lean/Kanban shop?", the answer is "we were, but now we are aligning with Scrum principles so as to be in line with other teams").

- Investigate a new approach to automation (we will be embarking on using Cucumber with the two lower layers in a yet to be determined configuration but it will be totally different than what we have used up to now).

- Upgrade and update our overall infrastructure for how we build and deliver our software (mostly dealing with a Jenkins modernization and moving to pipelining but also looking at our container strategy and what we could do differently or better).

- Somehow still find time to test software in an environment where we are now adjusting to two-week sprints.

While "life has been happening while I have been making other plans" I came to the realization I actually have been unlearning and relearning a bunch of new stuff. Why haven't I been talking about it here?

- Partly out of fear.
- Partly out of feeling inadequate.
- Partly out of not really understanding what I'm doing.
- Partly out of feeling like I'm making this all up as I go along.

I then realized,  "Wait! That's the whole point of this blog." Had I waited until I was an expert on anything, zero posts would have been written and this blog would not exist.

I was asked a couple of days ago on Twitter about what to do when someone wants to start blogging but doesn't know what to talk about or feels they don't really have any worthwhile experience to share. I said to "just start" and "while you may not be an expert in X, you are an expert in your own experience with X. Start there." That may have been helpful to them, but I realized that it was most helpful to me. It reminded me that there's a lot I'm learning and relearning and that process is rarely pretty, often incoherent and usually frustrating. That never stopped me before. Why am I letting it stop me now?

If you're still with me, thank you for indulging my "navel-gazing" for today. I have a lot of stuff I'm working on, and things I've wanted to talk about but not felt it would be worth saying. That attitude is over. It's time I started talking about my own worldview on "fill in the blank" again. Looking forward to re-engaging. I hope you will be, too :).



Thursday, August 9, 2018

Farewell, My Dumbledore



On August 7, 2018, the Cosmos reclaimed one of the greatest and most benevolent minds I’ve ever had the pleasure to work with. Granted, the man in question was someone I never met in person but through his books, blog posts and our occasional correspondence over the past eight years, that didn’t matter. I considered him a legitimate friend, mentor and, yes, a wise old wizard who helped me see things differently.

Jerry Weinberg will be remembered for many things. His absolutely prolific writing career. His career as a computer scientist is legendary. He almost single-handedly created the software testing profession (that’s a bit hazier, of course, but it’s hard to argue with how profoundly his effect on the craft and profession of software testing has been). “Perfect Software and Other Illusions About Testing" is my most gifted book to others on the subject. I've read it multiple times and will be rereading it again, along with several other works of his I've had the pleasure to own and read.

My Interactions with Jerry have been varied but I appreciated the fact that, were I ever to write a book review, no matter how old the book, he would always write back with a note of appreciation. If I had a question in the review, he would patiently explain it and help me see the intended meaning or bigger picture.

His “Fieldstone” method towards writing was the single biggest revelation for me and how I could organize ideas and thoughts when it came to writing. Too often I would start something and I’d either consider it not worth continuing or I’d question my direction. He taught me that was fine and perfectly normal. Just like a stonemason doesn’t use every rock they pick up immediately to create a wall, they often store those rocks in a spot so that, when the time comes to use that stone, they can shape it with minimal effort and put it in its proper place. An idea was not necessarily good or bad (well, some were just plain bad) but many ideas just weren’t ready to be put into the wall of my work just yet. Worry not, the time to use it will come.

What I will always remember about Jerry was his immense kindness, to just about everyone. I’ve thus far never met anyone that actually interacted with Jerry and had a negative thing to say about him. His various workshops over the years have been attended by several of my peers and to a person, every one of them said that Jerry took the time to understand them, learn their issues and frustrations, and somehow work beyond them. A phrase of his that I love is “whatever the problem is, we will deal with it.” I’ve taken that phrase and, in my own black humor have repurposed it as “we will jump off that bridge when we get to it” but the sentiment is really the same. Jerry always inspired me to try to solve problems, no matter how difficult.

We have lost a loving wizard, a true Albus Dumbledore in the flesh. That phrase was first mentioned by my friend and colleague Martin Hynie and I realized at that moment that that really was who Jerry was to me. Jerry was my Dumbledore. Always approachable, at times intimidating at a distance but never up close. He always endeavored to make you feel like you could overcome anything and that ignorance was a definitely curable condition. He has left us with a body of work that is frightening in its quantity but as has proven to me time and time again, reading it is so very worth it.

Farewell, my dear wizard. Thank you for making me just a little bit better as a tester, a technologist, an inquirer, a writer, and hopefully as a human being.

Thursday, April 12, 2018

Docker and the Path to a Better Staging Environment - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

Wow, time flies. I'm in the last session of the conference, and while I've had to split my time and focus on work stuff today, I've still been able to participate more than I thought I would. I have a couple of additional entries I'll make later (so they don't really count as "Live Blogs" but I still want to get them down).

My current work environment uses Docker extensively for a number of things. Perhaps most specifically we use Docker for massive parallelization of our automated tests and for our CI?CD system. Docker has been around since 2013 and it was at that time that we implemented our parallelization strategy. A fair amount of Docker was still experimental at that time, so we implemented some creative methods to get Docker top do what we wanted it to. We accomplished our goal, but Docker has matured a lot in five years. THus I wanted to get a better feel for the present state of Docker. Gil Tayar is providing that opportunity :).

To be frank, there is no way I am going to be able to do justice to what Gil is covering here as he is typing fast and furious. I am, however, getting a better appreciation for how Docker actually does what it does. I have wondered what the port mapping actually did and why it was so important. Seeing it live is pretty cool. It's transactionally very fast.

Little things I am learning that are quick hits:

- Kubernetes is a large scale docker coverage tool. It means "captain of the ship" in Greek.
- #K8s is short for kubernetes. Now I finally understand what that means :).
- There's a lot of stuff we can do with Docker that my current implementation is not doing. I need to do some digging in the dirt for this.

And with that, I'm going to say "adieu" to old friends, new friends, and to those who I haven't met yet... there's still time :). Please say "hello" before you leave. Just look for the guy with the elbow and wrist brace. I'm pretty sure I'm the only STP-CON attendee that has that distinction :).

Talking About Talking - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

Any time I attend a conference, I tend to go with 70% new content and about 30% familiar speakers. Over time, I've found it harder to look for new people because many of the people I get to know get asked to repeat present at conferences. With that out of the way, I consider Damian Synadinos a friend, but I picked his discussion for a specific reason. While I think he is intending for this to be about public speaking, I'm looking to see how I can leverage public speaking focus on my own active company interactions.

Why do I speak at conferences, at meetups, or at events? There are a variety of reasons but if I have to be 100% honest, there are two reasons. The first is wholly professional. I want to develop credibility. I want to show that I walk the talk as well as that I know at least an aspect of something. The second is personal and depending on how well you know me, this is either a revelation or so obvious it's ridiculous. I'm an ex-"RockStar". I used to spend a lot of time entertaining people as a singer and I loved doing it. I get a similar rush from public speaking, especially when people say they actually enjoy what I'm talking about and how I deliver the messages I prepare.

Part of talking in public is the fact that you are putting your ideas out there for others to consider. That can be scary. We own our ideas and our insecurities. as long as we keep them to ourselves, we can't be ridiculed for them. In short, people can't laugh at us for the things we don't put out there. Personally, I think this is a false premise. I have had people laugh at what I presented, but not because what I was saying was foolish or made me look dumb. Instead, it was because what I was talking about was in and of itself funny (actually, more absurd) but people laughed because they could relate. To date, I have not been laughed at. Laughed with, lots of times. If you are afraid people will laugh *at you*, let me reassure you, it's hugely unlikely that will happen.

The biggest reason why I encourage getting out there and speaking is that our ideas deserve to be challenged and we should want to challenge our ideas. Also, we may never aspire to get on a stage and speak, but all of us participate in meetings or presentations at work, in some form or another. By getting out there and speaking, we can improve our ability to function in these meetings. 

Something else to consider for a reason to give a talk or speak in public is what I call the "ignorance cure" for a topic. It's wise to talk about stuff we know about, but once a year or so, I will deliberately pick something I don't know much about or that I could definitely know more about. When I do this, I try to pick a timeline that gives me several months so that I can learn about it in a deeper way. People's mileage may vary with this, but I see a definite benefit from doing this.

Not every talk idea is going to be amazing. Not every talk idea is going to be some revolutionary idea. Truth be told, I'm lousy at revolutionary things. I'm highly unlikely to be creating the next big anything. However, I am really good at being a second banana to take an idea someone else has and running with it. Don't be afraid that something you want to talk about isn't new. We aren't born with ideas, and most of the time, we stand on the shoulders of giants.

My recommendation to anyone who has any interest in public speaking, no matter how small, is to borrow from Morrisey... "Sing Your Life". Talk about your experiences, as they will always be true and real. You may not be an expert on a topic, but you are absolutely an expert on *your experiences* with that topic. Also, if anyone wants to get up and talk, let me know. I'd be happy to help :).

Release is a Risky Business - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

Good morning. Let me get this out of the way now. I'm going to be splitting my mental energy between attending STP-CON and the fact that a new candidate release dropped last night and I need to see how close to shippable this one will be. Splitting my brain is an everyday occurrence, but that may mean I might miss a session or two, but I'm not missing this first one ;).

Simon Stewart is probably well known by those who read my blog regularly. Web Driver guy and a bunch more.  We're talking about the changes and the way that "release" has morphed into faster releases, along with a greater push to automation. Some stuff that fell by the wayside in that change is honestly a lot of stuff that I don't miss. There's a lot of busywork that I am glad has been taken over by a CI/CD pipeline.

Outside of software testing, my professional life has become very closely knit into release. Jenkins is my baby. It's an adopted child, maybe a foster child, but it's still my baby. As such, I tend to spend a lot of time fretting over my "problem child", but when it works it is quite nice. Remind me when I am over the PTSD of the past month just how sideways CI/CD can go, but needless to say, when a tester takes over release management, they go from almost invisible to ever present.

Release is risky, I can appreciate that greatly, especially when we get closer to a proper release. Though I work in an environment where by necessity we release roughly quarterly, in our development and staging environment, we aim to be much "Agiler" and closer to an actual continuous environment (And yes, I checked "Agiler" is a real word ;) ).

Simon points out, and quite rightly, that release is really less about quality and more about risk mitigation. For that matter, testing is less about quality than it is risk mitigation. For that matter, staging environments do not really give you any level of security. Simon makes the point that staging environments are a convenient fiction but they are a fiction. My experiences confirm this. About the only thing a staging environment tells you is if your feature changes play well with others. Beyond that, most staging environments bear little to no resemblance to a proper production environment. If you think Simon is encouraging releasing and testing in production, you would be correct. Before you have your heart attack, it's not the idea of a massive release and a big push of a lot of stuff into production and all bets are off. If you are going to be doing frequent releases and testing in production, you have to think small, get super granular and minimize the odds of a push being catastrophic. Observability and monitoring help make that possible.

There's a lot that can go wrong with a release and there's a lot that can go right with it, too. By accepting the risk and doing all you can to mitigate those risks, you can make it a little less scary.


Wednesday, April 11, 2018

The Use and Abuse of Selenium - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

I realized that the last time I heard Simon speak was at Seleimum conf in San Francisco in 2011. I've followed him on Twitter since then, so I feel I'm pretty well versed with what he's been up to, but the title intrigued me so much, I knew I had to be here.

Selenium has come a long way since I first set my hands on it back in 2007.  During that time, I've become somewhat familiar with a few implementations and bringing it up in a variety of envirnments. I've reviewed several books on the tools and I've often wondered why I do what I do and if what I do with it makes any sense whatsoever.

Simon is explaining how a lot of environments are set up:

test <-> selenium server <-> grid <-> driver executable <-> browser 

The model itself is reasonable but scaling it can be fraught with disappointment. More times than not, though, how we do it is often the reason it's fraught with disappointment.  A few interesting tangents spawned here, but basically, I heard "Zalenium is a neat fork that works well with Docker" and I now know what I will be researching tonight after the Expo Reception when I get back to my evening accommodations.

Don't put your entire testing strategy in Selenium! Hmmm... I don't think we're quite that guilty, but I'll dare say we are close. Test the happy path. Test your application's actual implementation of its core workflows.

Avoid "Nero" testing: what's Nero testing? It's running EVERYTHING, ALL THE TIME. ALL THE TESTS ON ALL THE BROWSERS IN ALL THE CONFIGURATIONS! Simon says "stop it!" Yeah, I had to say that. Sorry, not sorry ;).,

Beware of grotty data setup: First of all, I haven't heard that word since George Harrison in "A Hard Day's Night" so I love this comment already, but basically it comes down to being verbose about your variables, having data that is relevant to your test, and keeping things generally clean. Need an admin user? Great, put it in your data store. DO NOT automate the UI to create an Admin user!

Part of me is laughing because it's funny but part of me is laughing because I recognize so many things Simon is talking about and how easy it is to fall into these traps. I'm a little ashamed, to be honest, but I'm also comforted in realizing I'm not alone ;).

Modern Testing Teams and Strategies - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

One of the fun part of being a "recidivist conferencist" is that we get to develop friendships and familiarity with speakers we get to see over several years. Mark Tomlinson and I share a ridiculous amount of history both in the testing world and personal endeavors, ao I always enjoy seeing what he is up to and what he will talk about at any given event. This go-around, it's "Testing Teams and Strategies" so here we go...

Does it seem common that the people who decide what you do and how you do it have NO IDEA what it is you actively do? I'm fortunate that that is not so much the issue today but I have definitely lived that reality in the past. It's annoying, to be sure, but often it comes down to the fact that we allow ourselves to be pigeonholed. The rate of change is insane and too often we think that we are being thrown into the deep end without a say if what happens to us. If we don't take some initiative, that will continue to happen to us.

I've had the opportunity over the past (almost) three decades to work in small teams, big teams, distributed teams, solo, and freelance. Still, in most of my experiences, I've been in what I call part of "the other" organization. That's because I've worked almost exclusively as a tester in those three decades (my combined time as a cable monkey, administrator and support engineer equals up to less than four total years and even in those capacities I did a lot of testing). Point being, I've spent more time as part of another organization that has been siloed. It's a relatively new development that I'm working on a team that's both small enough and focused enough where I'm actually embedded in the development team now. As a point of comparison, my entire development team is seven people; three programmers, three testers, and one manager. Really, that's our entire engineering team. That means that there is too much work and not enough people for anyone to be siloed. We all have to work together and in reality, we do. My role as a Tester has dramatically modified and the things I do that fall outside of the traditional testing role is growing every day.

if I had to put a name on our type of team, I'd probably have to describe us as a blended group of "Ronin", meaning we are a relatively fluid lot with a host of experiences and we are ultimately "masterless". If something needs a champion, it's not uncommon for any of us to just step up and do what's needed. The funny part is Mark just put up the "non-team testing team" and basically just defined what I just wrote. Ha!!!

OK, so teams can be fluid, that's cool.  So how do we execute? Meaning, what is the strategy? To be clear, a strategy means we deliver a long-term return on investment, align resources to deliver,  arrange type and timing of tactics and make sure that we can be consistent with our efforts. Ultimately, we need a clear objective as well as a strategy to accomplish the objective. Sounds simple but actually being concrete with objectives and developing a clear method of accomplishing them is often anything but. In my opinion, to be able to execute to a strategy, we have to know what we can accomplish and what we need to improve on or develop a skill for. Therefore a skills analysis is critical as a first step. From there, we need to see how those skills come into play with our everyday activities and apply them to make sure that we can execute our strategy with what we have and develop what we need to so that we can execute in the future.


(still editing, refresh to see the latest :) )

More than That - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

I had to step out and take a meeting so I missed probably half of Damian Synadinos' talk. Therefore, if this feels incomplete and rambling, well, that's because it literally is ;).

I am intimately familiar with being asked "what I do" as well as "who I am". The fact is, I am a lot of people. No, I don't mean in a schizophrenic sense (though that's debatable at times). I mean it in the Walt Whitman sense:

"Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes."

The point is that we are never just one thing. All of our quirks, imperfections, and contradictions come from our many experiences, histories and active pursuits.

Depending on who you talk to about me, you might get a wildly interesting view of exactly who I am. It might get really interesting depending on what period of my life you ask about, but if I had to guess, these identities might show up:

actor
bass player
bodybuilder
boy scout leader
carpenter
cosplayer
dancer
drummer
father
fish geek
gardener
guitar player
husband
mandolinist
mormon
obsessive music fan
otaku
photographer
pirate
podcast producer
poet
programmer
prose writer
singer
snowboarder
tester
video gamer
yogi

If I had to choose a specific attribute, I'm going to lay claim to "eclectic".

Each of these has informed my life in a variety of ways, and each of them has given me skills, interests and a number of very interesting people to do this variety of things with. In many ways, it's the people that I interacted with that informed how long or how little time any of these endeavors/attributes have been a part of my life, but all of them are and all of them have provided me skills to do the things I do.

Also, if any of the items on that list have you wondering what they are or how I'm either actively involved in or why I chose to mention them, please be my guest :).

Performance Test Analysis & Reporting - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

One of the factors of performance testing that I find challenging is going through and actually making sense of the performance issues that we face. It's one thing to run the tests. It's another to get the results and aggregate them. It's still another to coherently discuss what we are actually looking at and how they are relevant.

Mais Tawfik Ashkar makes the case that Performance Analysis is successful when people actually:

  • read the results
  • understand the findings
  • can be engaged and most important 
  • understand the context in which these results are important


Also, what can we do with this information? What's next?

Things we need to consider when we are testing and reporting, to be more effective would be:

What is the objective? Why does this performance test matter?
What determines our Pass/Fail criteria? Are we clear on what it is?
Who is on the team I'm interacting with? Developers? BA? Management? All of the Above?
What level of reporting is needed? Does the reporting need to be different for a different audience (generic answer: yes ;) )

What happens if we don't consider these? Any or all of the following:


  • Reports being disregarded/mistrusted
  • Misrepresentation of findings
  • Wrong assumptions
  • Confusion/Frustration of Stakeholders
  • Raising more questions than providing answers

Mais starts with an Analysis Methodology.  Are my metrics meaningful? Tests pass or fail. Great. Why? Is the application functioning properly when under load/stress? How do I determine what "properly" actually means? What are the agreements we have with our customers? What are their expectations? Do we actually understand them, or do we just think we do?

By providing answers to each of these questions, we can ensure that our focus is in the right place and that we are able to confirm the "red flags" that we are seeing actually are red flags in the appropriate context.


Tester or Data Scientist - a 1 1/2 armed #LiveBlog from #STPCON

Smita Mishra is covering the topic of  "Tester and Data Scientist". Software Testing and Data Science actually have a fair amount of overlap. Yes, there is a level of testing in big data but that's not the same thing.

A data scientist, at the simplest level, is someone who looks through and tries to interpret information gathered to help someone make decisions.

Website data can tell us what features people engage with, what articles they enjoy reading and by extension, might help us make decisions as to what to do next based on that information.

An example can be seen on Amazon. About 40% of purchases are made based on user recommendations. the Data Scientist would be involved with helping determine that statistic as well as its validity.

Taking into consideration the broad array of places that data comes from is important. Large parallel systems, databases of databases, distributed cloud system implementations, aggregation tools, all of these will help us collect the data. The next step, of course, is to try to get this information into a format to be analyzed and for us (as Data Scientist wannabes) to synthesize that data into a narrative that is meaningful. I find the latter to be the much more interesting area and for me, that's the area that I'm most interested in learning more about. Of course, there needs to be a way to gather information and pull it down in a reliable and repeatable manner. The tools and the tech are a good way to get to the "what" of data aggregation. Interacting with the "why" is the more interesting (to me) but more nebulous aspect.

So what do I need to know to be a Data Scientist?

  • Scientific Method is super helpful.
  • Math. Definitely, know Math.
  • Python and R both have large libraries specific to data science.
  • A real understanding of statistics.
  • Machine Learning and the techniques used in the process. Get ready for some Buzzword Bingo. Understanding the broad areas is most important to get started.

Recommended site: Information is Beautiful

The key takeaway is that, if you are a tester, you already have many of the core skills to be a Data Scientist. Stay Curious :).

Shifting to Quality Engineering - STP-CON 1 1/2 Handed #LiveBlog

Melissa Tondi is leading off with a keynote discussion about Quality Engineering (QE) and what it specifically means. QE is a mindset and an attitude.

These components help to make this shift:

- explicit and implicit info gathering
- tools and tech to craft a solution
- executing to the solution

Some interesting things to consider:

Ever individual owns the quality of the work they produce. They do NOT own the quality of the overall project. In short, we can only guarantee quality in the areas that we have direct control over.

Some changes are already happening, and there's a definite debate as to their validity:

- testing is not dead, but it is certainly changing.
- automation will not replace all testing, but it is a huge plus for the mind-numbingly repetitive tasks.
- AI and Machine learning will make testing irrelevant (I'm not holding my breath on this one at all ;) ).

Some of the shifts that I have seen in the testing world are moving from an ad-hoc approach to an ISO 9000 specific standardization. Good or bad, that was a change I lived through and I found some of it useful and a lot of it needless overhead. Later, I worked in much smaller teams where such an approach was complete overkill. Needless to say, I adapted to what those organizations needed. Technologies that were part of my everyday test environments (virtual machines, scripting languages, etc.) morphed into actual production environments. Agile became a mantra and something everyone said they advocated and championed, but actual implementation was wildly different in each company.

The point is that every year has given me something new to look at and consider. Every year some different approach has taken precedence and grabbed people's attention. I have been an enabler of good things and some dumb things as well. The key is that we can make the choice as to what we put forward and what we want to contribute to the process.

Some areas that we can make improvements and helping to make a QE shift are:

- showing our value
- putting ourselves into the circle of influence
- leveraging technologies and taking advantage of them
- locating inefficiencies and figuring out how to reduce them
- owning our own quality and letting other people own theirs
- stay curious, look for the implicit information and help make it more explicit.

Another good point Melissa makes and that I agree with is that this shift is more than just changing our work environment, but the broader community that we are part of. while it may not be practical for everyone to be a speaker or content creator, everyone can help change and build the narrative at a broader level. Engage with your broader testing community whatever and wherever it may be.

STP-CON: A One-and-a-Half Handed #LiveBlog

Hello everyone! Greetings from Newport Beach, CA.

This session of the Testhead Live Blog will be a little different this year for a couple of reasons. The fundamental difference is that I am down the significant use of one arm. I had elbow surgery a couple of weeks ago (lateral epicondylitis for those who like specifics). It involved using ultrasound to pulverize a bone spur, perforate a tendon in my elbow so it looks like a slice of Havarti cheese and an insertion of blood serum from my other arm to give the tendon the optimal chance of healing. The net result is that I have a lovely wrist brace and elbow cuff that limits motion and makes typing with my left hand... less than optimal.

My loss is your (potential) gain. It means my trademark verbosity (I am a wordy fellow,. let's face it ;) ) will have to be diminished a bit. It also means I get to use some Accessibility features that I test for and advocate using. Some of these posts will be verbally generated, which should be... interesting.

I'd like to take the chance to first off say thank you to the attendees of my workshop yesterday. I taught a session on "Designing and Testing Inclusively" and it gave me a chance to expand on material and approaches that I usually get less than an hour to talk about or demonstrate. It also gave me an opportunity to explain why I chose the tools that I did, what the tradeoffs are for using them and an unexpected but nice detour. Towards the end of the session, we had a philosophical discussion about advocating for what can at times be conflicting suggestions. When does our advocacy for one goal mean that we are making someone else's experience diminish? Can we go too far? Additionally, how can we help people to care a little more about this?

Today is the first full day of the conference, and I will probably have to take a little more time to compose my thought than normal, so the rapid-fire multi-post process I'm known for may not happen this go around. Still, I'll do my best, so stay tuned :). 

Monday, March 5, 2018

Taking an AXe To It: Starting Accessibility Tooling (#CNC2018 #BLOGMORE)

I am rather far behind with my commitment to the #BlogMore challenge in the #CNC2018 campaign. Part of that is, of course, “life is what happens when you are busy making other plans” but more specifically I came to a conclusion that my original outlines were way too ambitious.

My topics as outlined were more suited for chapters for a possible book rather than single blog posts. Thus, I have decided to take something from each of the outlines and get very specific. Rather than do a vague post about Accessibility and Inclusive Design, I will focus on a specific tool that will allow me to address coding and design more directly.

There are numerous tools available that will allow programmers and testers to evaluate websites and applications for Accessibility and Inclusive Design. This post will be about just one of them. aXe is a tool developed by deque. It is open-source, free and runs inside of the browser along with a variety of Developer Tools. Currently, two versions are available (for Chrome and Firefox).

Adding an aXe to Your Arsenal


Installation is straightforward. Start by navigating to the download page for the extension (here’s the flow for Firefox):

1. Click on the Add to Firefox button.



2. Give aXe permission to be added as an extension.


3. After installation completes, this confirmation screen will appear.


4. Depending on how many add-ons you have, you will see something similar to the following on your Firefox browser toolbar.




5. Click on the aXe icon to get a help message. aXe is part of Developer Tools and appears within that context.


My preferred way to open Developer tools is to just click anywhere in the browser main window, right click, and then select “Inspect Element”.


If your installation went correctly, you should see the following. Click on the aXe navigation bar header to see the screen below. If you see this, you are good to go.



Press the “Analyze” button on your chosen web page. I might as well pick on myself. Let’s have a look at http://mkltesthead.com/.



See that output at the bottom? That’s an indication that I have some stuff to deal with.

I hear you saying, “well, OK, that’s… interesting… what exactly am I looking at here?”


A First Pass at your aXe Analysis
aXe gives the user a condensed listing of issues found. Let’s take a look at the listing in more detail:



The top section displays the number of Accessibility violations (in this case, 95 of them). The listing below the violations count is an area that says “Needs review”. These are potential violations, but they may not be. Let’s take a look at one of them:




We can see the issue. The validator cannot actually determine if the color contrast of the title is compliant. The reason is that there is an image beneath it, and that image has varying shades, where in some areas there is definitely a bold contrast, but in a few areas, the “whites of the Tachikoma’s eyes” are right next to the text. Below the issue description is the actual code that is being evaluated.

In this case, I have two choices. I can either tell the system that this is not an issue and move on, or I can consider how to match both the letter and spirit of the issue and fix it. Options are I could remove the image, or I could darken the image significantly so that all areas are in sharp contrast.

Additionally, I can do some sleuthing through the tool by clicking on the “Learn more” link next to the description. I can also click the “Inspector” link and see the element in context with the surrounding code for the page:



Clicking on “Highlight” will focus on the element in question but leave us with the review screen:



Having given the code a once-over, I can now (if I choose) make a decision for a course of action. In this case, I am going to make the executive decision to leave the image as it is and say that it is “not an issue” because, for 97% of the text, there is ample contrast.

By selecting “This is not an issue” and clicking the “Save” button, I update the aXe database and move on to the next issue that needs review.


If you followed along, that should give you some feel for how you can quickly use aXe to validate a number of Accessibility issues on your chosen page. There's plenty more where that came from, to say the least, and I will be getting into more details in future posts, both with aXe and a few other favorite Accessibility tools.

Monday, February 5, 2018

The Code Newbie Challenge for 2018 #CNC2018: BLOG MORE: Mission Two: Blog Outlines and Schedules



Week three and mission two are completed. My thanks to Christian Haas for feedback and some additional commentary in this post :).


This week's homework for Blog More is to complete an outline for each of the three blog post ideas.


Homework:
1. Post your favorite outline below.
2. Find someone’s posted outline in the group and give them some feedback. What stands out to you? What points were most interesting? What did you want to learn more about? Be kind but specific in your feedback.

Mission 2:  Outlines and Schedules

My Top Three

1. Writing Code around Accessibility and Inclusive Design
  • Intro: a quick explanation as to what Accessibility and Inclusive Design are.
  • Sample Code that is not accessible and why (web example)
  • Using Inclusive Design Patterns to help set the stage
  • Changes to code that will make it more accessible
  • Methods to check and validate such things
  • Sample Code that now IS accessible and why (web example)


My initial thoughts: 
I’m realizing this is a topic I could write examples for every week for a year and probably still have plenty to write about. I will probably have to tailor this down to an introductory article first and then go into specifics about individual inclusive design patterns, etc.

Christian's comments:
I'm curious about this topic as a whole. For me, your first entry could be about setting the stage, with one or two examples showcasing how far the topic could reach. I myself am more interested from a theoretical point of view. It would affect my daily work only if there were info/references to "closed" systems; I'm not working on web UI, but for a dedicated, trained, target audience using Java UI.

My follow-on thoughts based on feedback:
This is an interesting angle and one I hadn't considered. How do we make applications accessible in a more specific programmatic focus? By Java UI I am assuming these are applications that have a command line style interface or otherwise interactions at the Operating System level and not online or via the web. To be honest, I haven't given a lot of thought to how this would work for a command line application, but it's an interesting thought experiment. When I'm writing a script or some interactive piece of code, how Accessible or Inclusive am I making those interactions? Definitely worth considering.

2. Skeleton Keys: a resource for TDD/BDD in the shell and other programming languages
  • What is skeleton-keys?
  • Why would anyone need it?
  • TDD/BDD in the shell? Really?
  • Unit Testing Tools in three languages (bash, ruby, and python)
  • Starting small: structure, tests, and output
  • Compare and Contrast the three languages and approaches

My initial thoughts:
Why did I pick three languages? OY!!! Oh yeah, so I could actually make some comparisons. I think these might end up being rather long (like book chapter long), but on the plus side, once I get this started, I will probably have plenty to write about for a very long time.

Christina's comments:
Bash: yes - Ruby/Python: is there a particular reason to have both? I don't have experience in either language and see (from the outside) they are somewhat similar in terms of capabilities. Mainly procedural with object-oriented additions; weak type system, and interpreted. For a broader coverage, it should have a variation in perhaps at least two of these points. (e.g., using C, C++, Java, C#, Go, or ...). Since you already identify that this can be done in various languages (taking time and effort to write this), I suggest that, if you want three initial examples, they should be quite distinct from each other. Or reduce to two. (Or give particular reason why Ruby & Python)

My follow-on thoughts:
This is a very good point. I picked Ruby and Python mostly because they are languages I'd been either working with or had some recent exposure to and wanted to set up as a way to focus on some starting poitns for those languages. Having said that, they are two languages that fill a similar niche. They're not the exact same, but Christian makes a good point that they are similar enough that they may not prove to be all that interesting a comparison. Perhaps using a language such as Java or C++ would make more sense, though I haven't used either in a meaningful way in a long time. Still, for this purpose, it may make for a more interesting comparison, so worth re-examining.


3. Creating a framework from the ground up (Jenkins, Docker, Protractor, Angular, Jasmine)
  • You Keep using that ‘Framework’ word. I don’t think it means what you think it means.
  • Jigging your Jig-Saw Pieces (short intro/tutorial on all five pieces, including installation)
  • Setting up a basic application to test
  • Puting the onion back together
  • writing the Angular App
  • testing with Protractor/Jasmine
  • putting it into Docker
  • managing it with Jenkins
  • Lather, rinse, repeat


My initial thoughts: 
This would make for a great series with a minimum of five posts for each piece (plus the many that I haven’t even mentioned yet, such as plug-ins or add ons to make the job easier to manage).

Christian's comments:
With your first point about using "framework" wrong, I suspect this title is intentional. Still, is the overall goal to write a Javascript based template project?
If so, I'd be less interested as I don't work in JavaScript (That should not be a reason to change your goal, I understand that), though, if it were pitched as "how to create a template stack with Jenkins, Docker, ..." might be half interested as I'd consider an automation pipeline for different languages. Perhaps this could even be a two-parter: How to set up a build-pipeline with Jenkins & Docker and then specializing it for a JavaScript project, and then specializing it for a Java project for instance... (These are all just ideas, I believe your thoughts go already in that direction...)

My follow-on thoughts:
Yes, the use of the word "framework" in both the title and the shout-out to The Princess Bride reference is in part to say that the word framework gets thrown around a lot and maybe doesn't really mean what a lot of people think it means. My goal is to address the broad areas and try to see how to implement the pieces. Just setting up the scenario would be a series of posts (setting up Jenkins, working with git, creating docker containers, setting up a project, making tests for the project, running those tests, making sure they integrate with the CI pipeline, etc.). Perhaps skeleton-keys could be the project that allows me to put this all together and integrate into a series of posts.


One thing is certain, this challenge series is showing me that there are plenty of things to write about in these spaces and I will probably have ample to write about for a long time.

Monday, January 29, 2018

Code Newbie Challenge 2018: #CNC2018 #BlogMore: Mission One: Blog Ideas

The first official mission for the Code Newbie Challenge has completed. Here are my follow-up and thoughts about this week's assignment.

Mission 1:  Three Ideas

Goal
Develop and validate the three blog ideas for this challenge.

Homework 
Come up with 10 blog ideas, then narrow those down to 3.

This challenge had a lot of great supporting material to help people get into the mindset of what it would take to create a technical code blog post. 

Research: 
  • Search Twitter for hashtags related to areas of interest.
  • Search blogs that talk about areas of interest. Medium, Dev.to, FreeCodeCamp, Hackernoon, Codeburst, basecs, Mozilla Hacks, etc.
  • Look at Newsletters like JavaScript Weekly and RubyWeekly
  • Think about things I am actively working on and wish there were posts that answered my concerns.

Brainstorm:
Aim for ten ideas. Here's the list I came up with:
  1. Examining Accessibility and Inclusive Design (this is my personal touchstone topic, as if I really want to make a transition to writing code, I want to do it in a way that can help me advocate for Accessibility and Inclusive Design better) - Explainer for concepts, tutorial or project for specifics
  2. Walking through Developer Tools that emphasize Accessibility - Explainer
  3. Making a Skeleton Resource for Coding (my biggest problem is getting started, so my overall goal is to make something that will help me do that. I figured I could explain along the way as I make it). Project, possibly tutorial
  4. Writing shell scripts using TDD and BDD principles (using shunit2) - Tutorial, Project
  5. Quick Fixes for Big Headaches (the shell can be your friend) - Project
  6. Deploying your own little CI Pipeline (Deploying Jenkins on your local machine) - Tutorial, Project
  7. Containers for the curious (Deploying Docker on your local machine) - Tutorial, Project
  8. Blending Angular, Protractor and Jasmine into a testing framework - Tutorial, Explainer, Project
  9. Road Rash: Cautionary Coding tales while the wounds are still healing (I did something, I got stuck, it hurt but I figured a way out of it) - Explainer
  10. How Would You Automate This (an actual Series I’m Currently Working On) - Explainer

Narrow it down to 5:
Many of the ideas I came up with are not so many ones I would want to eliminate as they are either peripheral to or prerequisite of what I'd want to write about. By taking my original list and grouping them, I came up with the following more condensed list:

  1. Examining Accessibility and Inclusive Design, Walking through Developer Tools that emphasize Accessibility  - Explainer for concepts, tutorial or project for specifics
  2. Making a Skeleton Resource for Coding, Writing shell scripts using TDD and BDD principles, Example shell fixes to demonstrate the project - Project
  3. Deploying your own little CI Pipeline (Deploying Jenkins on your local machine), Containers for the curious (Deploying Docker on your local machine), Blending Angular, Protractor, and Jasmine into a testing framework - Tutorial, Explainer, Project
  4. Road Rash: Cautionary Coding tales while the wounds are still healing (I did something, I got stuck, it hurt but I figured a way out of it) - Explainer
  5. How Would You Automate This (an actual Series I’m Currently Working On) - Explainer
One of the reasons I ordered this list this way is that I couldn't figure out how to put Road Rash into another location other than as a sidebar, and it felt the weakest of my choices. How Would You Automate This I deliberately put at the bottom as I'm already writing the series. I want to emphasize posts and areas that I'm not already doing or that would actually be new territory for me.

Validate your ideas
I received some great feedback and interest from several people who reviewed my list and who expressed interest in seeing certain topics get covered. That had a lot to do with my grouping and decisions on which topics I would want to focus on.

Pick your top three

The top three and the working titles for each:
  1. Making Your Pages and Apps Accessible Using Inclusive Design Principles
  2. Skeleton Keys - A Project for Getting Started in bash, Python, and Ruby
  3. A Testing Framework From the Ground Up - Jenkins, Docker, Angular, Protractor, Jasmine

Turn In Your Homework 
 
Turned in to the CNC2018 Facebook group, but also this blog post :).
 
Bonus Reading 
 
Here are some additional blog posts to check out:

Saturday, January 27, 2018

Book Review: How To Become A Web Developer: The Career Changer’s Guide



One of the most difficult to pin down topics and titles of the last couple of decades is to define oneself as a web developer. What exactly does that mean, and what skills does one need to know to become one in this day and age?

Julie Torres, one half of the "Code Crush" podcast, has done what I feel is a good job distilling that into an 86 page book titled, specifically enough, How to Become a Web Developer: The Career Changer’s Guide.

Starting with the Prologue, Julie describes the specific circumstances that started her on this journey. With a softening job market during what we now refer to as “The Great Recession,” Julie describes how she moved from being a bank teller to become a junior developer. Her point in sharing this story is to make clear that you don’t need an advanced degree in computer science or have lots of history as a programmer to make the shift into doing web development. This book pledges to help you make that transition. Does Julie deliver on that promise?

Chapter Zero: Prepare for the Journey 

Julie sets out some basic markers to help you make the most of this journey including the idea of starting your job hunt while you start your web development journey. Counterintuitive, but makes good sense. Looking at what is out there, what is required and what skills are consistently being asked for is a great way to tailor your learning path. Utilizing Meetup groups and other resources will also help. Determine how to measure your progress, whether that be a way to check in with an online community or work with a specific mentor or group of people. In this day and age, showing goes a long way and having resources you can demonstrate to show your skill can be a big boost in this process. Code repositories and websites in the cloud to show your work can help tremendously. Don’t be concerned with whether or not you “measure up” to others out there. At the start, you won’t but your journey is yours and that’s what matters.

Chapter One: First, Choose Your Goal

Front End, Back End, Full Stack, Mobile, and a reference to QA by way of automation. This particular part touches me because I am primarily a tester in my work role, but many web development skills are still part of my daily repertoire. I’m glad Julie include testing on the list because many developers do actually make a decision to look at testing as a primary responsibility. The point is, deciding where you want to place your efforts will make a big difference in what you study and in what order. Likewise, there’s no rule that says you have to be permanently committed to any one goal, right?

Chapter Two: Choosing Your First Programming Language

Languages have a lot to do with the applications or environments you want to work on. Java is now a perennial favorite of many organizations because it is ubiquitous. Large corporations use it, Android devices use it, and there’s a large ecosystem for the language. It’s a wordy language, true, but the benefit is that there’s a lot of examples out there to look at and review. JavaScript is a language that has spawned numerous libraries and smaller ecosystems of their own. When you see people asking about Angular, Bootstrap, jQuery, React, etc, those are all specialized JavaScript frameworks. PHP is a great language specific for a large number of existing sites. Python and Ruby are also popular languages that also run in web stacks (Django and Rails, respectively). What you use will depend a lot on what you ultimately want to work on. If your dream job is making iPhone apps, you may want to take a look at Swift. The key is start with where you want to go and then pick what you will work with.

Chapter Three: Paths to Learning

You may be thinking “I don’t have a Computer Science degree” and that’s totally fine. Many of the best developers I’ve know have degrees in completely different disciplines. Whether you choose to go to college, do a coding Bootcamp or use an online resource like freeCodeCamp, the point is you have to put in the time, get frustrated a little and work through the issues you will undoubtedly face.


Chapter Four: What Skills Do You Need?

The foundational skills necessary are surprisingly small. Yes, it helps a lot if you can touch type and do so at a decent speed. Knowing how to use a computer or mobile device well is important especially if you can understand how to open, edit, move and manipulate files and directories. Understanding fundamental math skills and having a good understanding of the scientific method is also very helpful (not mentioned in the chapter and were I to suggest any additional basic skills to include I’d strongly suggest that one ;) ). From there, you will need to learn about how to use the command line of your chosen operating system(s), understanding the basics of HTML and CSS, using a version control system to chart your progress and, on occasion, back up and go to an earlier time to do something different, and understanding of how the Internet works (TCP/IP and HTTP, for example). From there, databases, return codes, error handling, and flow control of programs will come into play. Sounds scary? In truth, it’s fairly straightforward but the devil is in the details. Again, the key here is to understand what you want to do and then plot the course to get there. It will require a fair amount of knowledge buildup and experimentation, as well as false starts and frustrations. Julie goes into some detail in this chapter about the various frameworks available, sample programs and applications you can develop and ways to display them so that people can notice your progress.

Chapter Five: Things to Ignore (at Least For Now)

Depending on what it is you wish to work on, there may be many skills that will be important later on, but that you do not need to worry yourself with at the start or even in the first few years of your progress. You may never have to get familiar with topics like binary, specifics of computer hardware, or the underlying computer networking infrastructure and communicating with the lower layers. There is a list where there are things that will be helpful to understand later on and while I agree with much of the list, I have to take issue with testing being considered not so important. Personal opinion time, I wish more developers would put testing and a testing mindset at the forefront of their learning. It will help encourage more developers to see what they are developing, to begin their work with questions of quality and experimentation in mind and to ultimately help deliver a better product to their users.

Chapter Six: Learning Resources

This chapter includes a list of resources to help fill in key concepts and skills you may need. Many of them are completely free, while some have a small cost associated with them (small is relative, of course). Julie also includes a variety of blogs and websites that can also be helpful (I too am a fan of the Tuts sites and encourage people to check it out).

Chapter Seven: Staying On Track

The chapter starts out with this quote:

"Learning to code is more of a motivational challenge than a technical one." -- Quincy Larson, Founder of freeCodeCamp

On the whole, I agree with that. How we keep ourselves motivated is important, and finding our true motive is also critical. Do we want to make more money? A good place to start but may not sustain us in the long run. Chose methods that will help you stay committed to your goals, such as participating in meetups, hackathons, or other projects you can do with other people to get feedback and feel connected to what you are doing.

Chapter Eight: Career Goals

Just as important as what you want to do is where do you want to do it? Do you want to work for large companies or would you be interested in working for smaller organizations? Understanding the tradeoffs for each is important. Large companies can have great infrastructure but very defined ways of doing things. Smaller companies may be more chaotic and struggle with getting to profitability but the sky's the limit with where you can potentially get involved. You can also work with various employment agencies on a contract basis to rotate jobs and gain experience. Once you have a good enough foundation, you could perhaps hang up your own shingle, so to speak, and freelance. Don't be surprised if you find yourself doing a little of all of that, especially in the first few years.

Chapter Nine: The Job Hunt

Remember that advice in Chapter Zero? Here's where doing all of that this whole time should start helping. If you have been communicating with a variety of people along your journey, they may take an interest in what you have put together and speak with those in their organizations that have a hand in hiring. Resumes still matter at a lot of places, but they are taking a backseat to demonstrable ways that you can show your skills. In this day and age, tools like LinkedIn, GitHub, SlideShare, and a blogging platform can do a lot to boost your visibility as well as have lots of examples of demonstrable skills. Additionally, connect with people and communicate with them. The key here is to start this process well before you need to look for a job so that when you are ready, you have already identified people who you can communicate with. Another bonus is that, if you do this regularly, they will likewise know you are ready and can help you find your next gig.

Chapter Ten: Interviewing

Whether it be initial phone screens, in-person general interviews or technical interviews, you will be judged based on how you respond. Having a good handle on a variety of skills and being able to explain them will go a long way in helping you with these interviews. You may be given a coding challenge to complete, either on-premises or as a take-home assignment. Practice a few of these so that you can feel confident that you can do them if given the opportunity or request. This chapter has a lot of practical advice for specific technical interview questions as well as how to negotiate for salary.

Chapter Eleven: Building a Successful Career

Once you get that first job, realize that it's the bottom rung of a new ladder. There's still much to learn and many areas that you can get involved if you choose to. Pay attention to sticking points in the organization and see if you would like to tackle those challenges. See where the rest of the market is going and if you feel that you are ready to pivot if market forces change. Most importantly, never stop learning.


Along with all of these chapters, Julie shares many personal anecdotes of her own journey that has brought her to where she is today. These vignettes help the reader see what choices she made, both for good or ill, that have helped inform the rest of the text.

BOTTOM LINE:

For those who are looking for an in-depth guide to learning how to become a web developer, this book doesn't cover those except for skimming the resources needed to accomplish those goals. This is much more of a field guide to allow you to safely manage the trek and it is filled with a variety of markers that you may find interesting along your journey. As the title says, this is a Career Change guide, and those focusing on the "How To Become a Web Developer" are missing the key in the subtitle. This is a guide to navigating a career change. To that end, it meets its goal admirably.

Monday, January 22, 2018

The Code Newbie Challenge for 2018 #CNC2018: BLOG MORE: Introduction

Hello to new readers that are coming across this blog for the first time. To those who have read these pages for a while now, this should not surprise any of you at all ;).

I've decided to take on the Code Newbie Challenge for 2018. There are four "tracks" that you can choose. They are:

Start Coding
Code More
Blog More
Get a Job


I have chosen the "Blog More" challenge for a specific reason. Much of the time on this blog I have talked about testing and peripheral topics from a layman's point of view. I've strived to "speak dude" as often as possible, and to that end, I've kept coding specific stuff to a minimum. that sounds like a simple answer, doesn't it? Well, let's get real here. There's a darker secret. Part of the reason why I don't post code frequently is that I harbor a fear that people will look at my code and think it's simplistic, stupid or just plain lame. To tell the truth, that may happen. Maybe it won't. Regardless, I've always been a little leery of posting code samples beyond language tutorials because I've just been concerned about getting it picked apart.

That's the overwhelming reason why I chose this challenge. I can't get better if I don't actually put something out there, right? I can talk a mean game about what I know about things like automation and web development, but does it really matter if my actual code is lacking? More to the point, wouldn't it make a lot of sense to actually talk about code, show examples, explain it from my perspective and let people who do know about code comment on it?

Sure, it might bruise my fragile ego but isn't that the whole point? How do I expect to learn or actually demonstrate I know anything if I'm not willing to show what I actually know and take the chance that someone might be willing to tell me a better way to do it? On top of that, there may be lots of things I may be doing that are actually interesting and may be helpful to others. Finally, if I can explain what I'm doing in a blog post or several, I can explain it to anyone and draw on it when I write code in the future.

Let's get this party started. Each assignment as part of this challenge will be posted here. This is my own preamble to get the ball rolling. Look for the tags CNC2018 and CodeNewbieChallenge to see posts specifically targeted for this challenge.

Exercise Zero: The Pre Mission

Read 3 tech blog posts you wish you wrote. Jot down why you like them and what you'd change.

Find examples of good tech writing to see what you'd like to incorporate into your own posts, and what you might want to avoid. 

You'll refer back to these later in your challenge.

There are three styles that were described for this challenge. First is the "Tutorial", which actually walks through how to do something. Second is the "Explainer", which take a concept and breaks it down. Third is the "Project" which describes how to do something and gives actual examples that you can follow along and build yourself. The pre-challenge is to pick three examples, (one from each category) that I wish I had written, describe what I like about it, and what I would like to see to improve the piece.

Tutorial: "Protractor for Beginners, Part 1" by Hannah Pretswell

Why a tutorial on Protractor? Because it's what we are exploring as a replacement for our current automation framework. Nothing like a pressing business need to get your mind racing and your thoughts flowing. Hey, you know it will come in handy very soon, right? For starters, let me comment on something I really appreciate. Hannah said she struggled with getting the pieces to work together. Hearing that up front helps me in two ways. First, it lets me know that the tasks ahead may be challenging. Second, she also lets me know that she's done her best to document those frustrations and help let me know that I likely will succeed if I'm patient and follow her advice. Too often, I've gon through tutorials that expect a user to jump in and get moving with little concern over the sticking points. Gladly, that's not the case here.

Another positive is the fact that there are a fair number of repetitive steps. It's tempting to spell them all out, but by doing so, it makes updating a tutorial daunting and thus something the writer would likely not do. Instead, she points to a few additional tutorials already written that explain the process of setting up your environment and making sure everything is working correctly before getting started. Additionally, the resources listed point to the protractor GitHub page. This is a good practice because it lets the user get started with the most recent advice from the maintainer of the framework so that if the instructions change, the writer of the tutorial doesn't have to be the one to change the details on her site as well.

So, what would I have done differently? Truthfully, not much. I think it's a solid opener and it goes through the specifics as the first part of a tutorial should. I suppose I would have liked to have seen some example output of the code as displayed and some output of tests as well. For me, with a variety of tutorials, I think this is a good step so as to show what you could expect. I understand why many people don't in that OS changes and formatting details could put images like that out of date quickly, and it does add overhead to downloading what would in many cases be pictures to demonstrate the output. Still, on the whole, this is a really solid example.





Explainer: Test Driven Development in BASH by Torstein Krause Johansen

This is presented as a talk, but in many ways, that's a great way to explain a concept in a few words, with the impetus on the reader to go and learn more if they are so inclined. Specifically, I like the curt and focused content, the way the information is presented and the walkthrough of the ideas with examples. Each slide builds on the previous one and lets you see why the topic makes sense and the reasoning behind Torstein's approach. I was also excited to learn about shunit2 and I must say I'm more than a little curious at this point.

So what would I do differently? Again this is a set of slides from a talk, and at first glance, I'm guessing the HTML code was put there for a reason, but if the point was to demonstrate bash syntax and how it interacts with a testing framework, the HTML was distracting and made the underlying code hard to read. Again, I may be missing a key context here as to why that was presented that way (perhaps to prevent copying and pasting willy-nilly) but if that were the concern, I could see saving screenshots of the code itself and displaying pictures (great to prevent copy and paste but admittedly a nightmare to update and keep current).

Project: 10 Angular and TypeScript Projects to Take You From Zero to Hero by Dan Wahlin

This interested me seeing as I will be doing work with Protractor and Jasime as a testing framework for Angular apps. To that end, it helps to have something to look at, play with and practice on and these ten projects will allow me to do that. I like that the projects start simple and get progressively more difficult as they go. Each project is laid out with sample images of what you will build with links to each of the projects so that the project page is independent of each of the individual listed projects. The projects are lust listed with a title, a basic description, level of difficulty, a link to the files and some pictures of what the project will look like when completed.

On the whole, this is a nice layout and method. It leaves it up to the individual reader to decide where to expend their energy and each project simply links to the necessary packages to get them done. Were I to do it myself, I would probably split each project out to its own page and try to give some instructions about what to do with each. Having said that, the economy of having ten projects to choose from without a lot of navigation and page dancing is a good tradeoff.

There's the start. The assignments proper start on January 22, which is the same day this post goes live. Feel free to follow along and, as I tackle each assignment, your feedback and commentary is appreciated :).

Tuesday, January 9, 2018

It's That Time Again: The #StateofTesting Survey 2018

As in previous years, I have decided to take part in "The State of Testing" Survey and I encourage anyone else who is actively involved in testing endeavors to do the same. Note: I did not say "testers" need to take it, though that's likely who it's directed to. As I have become more involved in software delivery as a process, software testing is a key part of what I do, but it's not the only thing I do.


As I see it, software testing is transitioning. There will certainly be areas where dedicated testing as a role, a responsibility, and a job title will remain for quite some time to come. However, I also see that testing as a dedicated discipline in many organizations, if not disappearing, is definitely getting to be hazier. In previous decades, I might have been worried about that and truth be told, I was. Today, I take heart in the fact that there is much we all can do to be successful and do meaningful work. as I often remind myself, my mentor Ken Pier was fond of saying "there is always work moving from theory to practice".

The following I am borrowing directly from the Practitest QA Intelligence Blog, so I am presenting it in its entirety below (Thanks, Joel and Lalit :) ):

What is the State of Testing?

The State of Testing™ seeks to identify the existing characteristics, practices, and challenges facing the testing community in hopes to shed light and provoke a fruitful discussion towards improvement.
The final report is translated into several languages and shared globally, further expanding the reach and impact this report has on all of us in the QA world.
This is the 5th year that the QA Intelligence Blog is running this survey in collaboration with TeaTime with Testers, and with your help,  it can be bigger and more comprehensive than in previous years.
Each year the amount of participants has increased, and the final reports become even more valuable as a culminated reflection of testing trends, challenges, and characteristics.
So there you have it, another chance to take part in the State of Testing Survey is upon us. Are you interested in playing along? If so, click below and let's get to it :).

ANSWER SURVEY NOW