Thursday, September 13, 2018

What's That Smell? Angie Jones Talks at #BAST (LiveBlog)

Tonight is proving to be an exciting evening for the Bay Area Software Testers Meetup.

Angie Jones has come out to talk to us about "Code Smells", where we have code that "works", but may have some unusual issues that don't necessarily jump out at us.

More than just talk about the issue, Angie is actually walking us through and showing a real project that has some definite issues. The first example she uses is classes that are too long, where there is a lot of stuff put into a single class and it doesn't have a specific purpose. Oftentimes classes grow over time because there's no other logical place to put something. Think of writing a test where you put a lot of browser interaction into a class so that it's readily available. One one hand, it makes sense, but on the other hand, if it is overloaded or the items added to a class can be grouped somewhere else, take the time to put it there.

Another common smell is "Duplicate Code", where if you have an issue where something is repeated in multiple places, you end up having to do what Angie calls "Shotgun Surgery" (I just love that term :) ). Anything being duplicated more than twice is probably a really good indication that a separate class with that information probably makes a lot of sense.

Next up is the 'Flaky Locator Strategy". Oh, do I know this one! Angie is exhorting, loudly, to not trust the Copy XPath option that comes with Dev Tools, and I wholeheartedly agree. This is also something I wrote about in my "Less Brittle Automation" posts, part one and part two. Happy to see that something I found frustrating is also something Angie pointed out :).

Angie calls out the "Indecent Exposure" smell. If you are showing too much of your data, you may allow for people to get to your data and information in ways you may not want to. This is fixed by narrowing the scope of your classes, making certain methods private when they should be and only keeping public methods that actually need to be public that distinction.

Something that I'm all too familiar with is the issue of explicit waits. Yes, I do this. No, I'm not proud of this. Yes, I can do better. Angie encourages us to Wait Intelligently, by either polling for an element or to make sure that the test doesn't move forward until there's a confirmation that an item is present.

Frameworks are supposed to drive the logic of the browser and to create a state condition. Frameworks don't actually test anything, so putting assertion codes into the framework is a problem. Instead, we want to create state conditions that e can evaluate elsewhere. Otherwise, we may find ourselves painted in a corner unintentionally.

This was a really great discussion, and it was made the more effective by seeing the actual code being modified. I'm super happy to have had Angie come out to speak with us at BAST tonight and she has an open invitation to come out and talk any time she wants to :). For everyone else, thanks for indulging me this evening as I got to geek out a bit. 'Til next time!

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 :) )