listeningTo: South Park, Season 1 Episode 4

inRealLife: It’s been a rough patch here, luckily I’m pretty easy to amuse and putting on my “When it rains, it Poes” shirt, featuring a very sad Edgar Allen Poe under an umbrella was enough to put a smile on my face this morning. If there’s one thing to know about me it’s that I love a good pun.

whatIReadThisWeek: We’ve had a difficult release cycle. I feel like I’m saying that a lot here, it’s not the norm, just the recent norm, if that makes sense. My time is pretty preoccupied and my TBR list is growing. I use the OneTab Chrome extension to keep track of articles that show up in my Inbox that I want to read and not lose. I also use Feedly to manage a lot of RSS feeds I’m subscribed to. Despite the busy-ness, I’m still trying to go through headlines and save some for later.

I did get a few reads in this week, which I’ll be talking about in this post. All three are about test automation: What’s Next in Test Automation and 5 Barriers to Automated Testing and How to Overcome Them both by SauceLabs, and 10 Best Practices in Test Automation #3: Build Maintainable Tests by Ranorex.

whatILearnedThisWeek: I built our automation project by myself from scratch earlier this year using a “codeless” solution called Sahi Pro – in fact it’s one of the main reasons I got this promotion and we hired a new assistant. I don’t have the time I want to focus on it, though, so although it is effective and running, I also have a list like 20+ items long of things I want to do.

This past release cycle, I ran through 37 scripts. I have a few more written, but I added them at the very last minute and they ended up not working as I hoped during the full test run, so I removed them at the last second and tested those steps manually. This last minute work is explicitly listed as one of the 5 barriers to automated testing in SauceLab’s article, and I’m happy to see I’m not alone here. The recommendation in the article is to “make ‘has automated testing’ a part of the acceptance criteria” when writing case requirements. This is something I’m going to experiment with this sprint. I will occasionally add a note to QA Plans to write technical documentation on the feature or add a manual test plan for regression testing, but I have not yet tried to work in writing automated scripts for each new feature (where applicable) and I think this is a great idea.

Another issue in the 5 barriers to automated testing article is “data dependency problems” and I feel that at a molecular level. We don’t have updated test data. The CTO will refresh the staging databases occasionally, though there is no set schedule and it usually only happens when I cry loud enough that my tests are virtually ineffective since we don’t have production-like data anymore. There is a long outstanding case in the backlog to automate the data refresh, or update some of the process so its a less onerous task or at least one that someone other than the extremely busy CTO can do. I push it up every now and then only to have it de-prioritized. “We’ve lived with it this long, what’s a few more months?” they say over, and over, and over. I have to choose my battles.

whatIAmThinkingAbout: Reading through the 3rd installment in Ranorex’s 10 Best Practices in Test Automation series sparked a lot of ideas and I highly recommend this article in particular as well as the first two. One of their tips is to “use a modular structure”. Um, yeah, that is ridiculous simple and something I am not doing at all in my current scripts. This sprint, I’m committed to spending more time refactoring my scripts, and the first step in that process was to audit what I currently have and identify what I can call out as a reusable function and what set up / clean up tasks are necessary for each chunk, rather than one bit set up in the beginning and one big (and partially manual) clean up at the end.

So far, I settled on a Google Sheet that lists all my scripts, by name, in the first column, and a few columns to check off if the script already includes set up, clean up, or if I can identify a part or parts of the script to pull out into a reusable function (log in, impersonate a member, etc). Once this list is complete, I will work on writing the actual functions, which will be a whole process of its own since we all know that I am not a coder, and what would take an actual developer 5 minutes to write will probably take me the better part of 5 hours.

Another tip that hits close to home but is yet unrealistic in my current set up is to “create automated tests that are resistant to UI changes”. This tip, too, seems so obvious, yet, with the software I am using it is unrealistic right now. Sahi Pro is a record and play kind of application, though, of course like all “codeless” options, there is a lot of custom JavaScript/CSS/xPath that has to go into each script. I’ve written the code where absolutely necessary, but for the most part, I am relying on the recording for the scripts. Because of how the recording is capturing the steps, there is a lot relying on the UI “to the left of this” “the first h1 under this element,” etc. The grand plan, as a part of the refactoring project,

recommendationsAndTakeAways: There is never a good, calm time to refactor. Refactoring projects are unwieldy, you start with a plan and get quickly sidetracked, thinking, “well, since I’m already working on this, let me just fix this this and this”. I’m going to attempt to put a cap on the refactoring and focus on the set up, clean up, and reusable functions, and not the 20 other things on my “I want to do this” list. One of the suggestions in the SauceLabs article to work automated testing into the normal sprint/AGILE process is very tempting. I’ll be experimenting with not only adding “write automated test” in some test plans for new features, but, I’m thinking of also writing my own cases to put an actual estimate and time aside on working with this code. All other code gets tracked through Jira, why shouldn’t mine?


listeningTo: some NFL show my husband is intently watching that I don’t care about…

inRealLife: I’ve been playing Destiny 2 on Xbox for a few months now, I’m not super good at it, but it is reeeeally fun. It’s also really stressful. Anyway, I need a break, so let’s talk about some personas, hm?

whatIReadThisWeek: I finished Dark Age! And it was fantastic. I powered through the entire final part last night and couldn’t stop. I’m undecided on what comes next, though I have been carrying around a (sort of) self-help how-to-be-more-productive book with me to the beach all summer and have yet to crack the spine, so, it may be time. (I can see it now: “how to be more productive? actually open this book…”)

Though I did not read it this week – at this point it’s been a few weeks back, actually – I do want to explore more about personas, which spun from a MoT Power Hour with Cassandra Leung.

whatILearnedThisWeek: I had a lot of takeaways from the Power Hour. I’ve wanted to delve into personas for a long time now, but I never had the time to devote to it or the support of the rest of the team to find that time. I think my site lends itself very naturally to identifying personas – we have different member types relating to the profession of the member, we have different levels of service relating to the size (and value) of the publishing house. At a minimum, I want to be identifying trends and shared behavior and start to define these better as a way to better understand how they may use the site, how they may break it, and how to prevent that from happening.

The first thing I learned was, really, what a persona is. My small understanding going into the Power Hour was exactly as I wrote above – different kinds of member types. It’s so much more, though, and much more important than gleaning behavior based on how a user identifies themselves. I never was sure how a persona even comes to be, but one of the responses indicated that the role usually falls on the UX designer. To a point, I do think UX is designing with many different “kinds” of users in mind, but, nothing is formal, UX, like me, is a team of one, and I’m sure all the personas, in any varying degree, just live inside his head and come out from time to time when he’s stuck on a design.

The other interesting points made are about diversity, brevity, and edge cases.

There were a few comments and questions about how diverse personas should be. We have a lot of data on our users, but not much insight into how diverse they are. One poster wondered about simply leaving gender, race, and age out of personas all together, as a way to not apply any biases. Leung, though, recommended against this. In her opinion, there will always be an implicit bias and we, as humans, will always fill in those gaps even if they’re not there. It’s better to define the things that make each persona diverse and be aware of where the gaps or assumptions are.

One of the most intriguing points was the questions about how detailed personas should be. I did not get to post a question before the Power Hour began, but one thing in the back of my mind that led me to reading the thread was exactly that – what do these personas even look like? How detailed should they be? Should they be vague to encompass more users? Should they be very detailed and pointed to hit at our exact user? As I said, I wasn’t alone, and there were a few questions that were similar. In one response, Leung suggests:

I find it much more helpful to get straight to the point of why a piece of information might be useful.

I love this advice – not only for persona writing, of which I still have no experience doing – but also just for testing in general. (Hell, just for life in general, right?) I reflected a lot on this when musing about proposing a persona-writing project, but also this week, as I’ve been writing and rewriting and rewriting test steps – is this useful, or is it fluff? (Hey, another topic to write about in the future, I’ve read a loooooot about “to automate or not to automate”).

More concrete advice, however, did come later. Leung recommends starting off small when writing a persona. Pretend you’re writing the user’s Twitter bio or dating profile, not autobiography. As the persona grows and can benefit from more information and detail, add it, but it is not necessary to start. I love this advice as well. It makes starting a persona project like this from scratch much less daunting.

And, finally, edge cases. We have a lot of these. In fact, I have never heard the phrase “edge case” until I started working here, and now I use it probably three times a day. If they’re all edge cases, are any of them? (Deep)…

Personas are there to remind us of our users, and if we are reminded that we are excluding some people, then we should be reminded. 

Sure, we’re being more detailed by including all our edge casers, but, they can be brief! Let’s just acknowledge they exist, give them a cute Twitter bio, and rest easy knowing we didn’t leave anyone out in the cold.

whatIAmThinkingAbout: My wheels have been turning ever since reading this thread originally. I want to do this project, I want to find the time to persona-fy my users and I want to discover how they break the site.

I think my first attempt will be just that – to try and identify the bad eggs. We have so much data, we even have reports that are updated daily with a list of our “unusual” users (they’re bad, let’s be real) so support can monitor their behavior. Maybe they just don’t know how to use the site. I know how to use the site – I know how to use the site in a creepy kind of way (seriously, if you need to know anything at all about how even the most obscure feature works, I’m your girl). What don’t I know? How to break the site! Getting into the minds of these users, taking the time to think about and write their personas, will allow me to see things through their eyes and can only benefit my testing strategy.

We started planning a new feature a few years ago – I think just over dinner at a Hack-a-Thon – about tiering our members. The idea was our best members would be rewarded for being the best (get access to new books sooner, get a badge, etc), our average users would continue to grind along as they always do, maybe see some incentive to strive for to become a top tier member, and our poor users would be punished (that’s harsh, I don’t think that’s the word we used) and maybe have access to less titles, or have a cap on how many titles they can try to get access to from the publishers. Anyway, that project was abandoned for many reasons, but not after hours of brainstorming about what the criteria for each tier would be. Now, I’m not the most organized person, sure, but I’m one hell of a note-taker and I know I have those tiers defined somewhere. What better place to start identifying different personas than from work that someone else already did?! (Sure, not helpful to my fellow DIY testers, but, as I said, I’m here to learn from and I’m happy to share the work that someone else did to you, too)…

recommendationsAndTakeAways: I’m gunna do it! I’ll report back. I need to find a block of time that I can devote to some heavy thinking and planning, which is few and far between, but maybe this how-to-be-productive book will give me some good guidelines on how to get shit done. I’m ready.

As for recommendations, well, apart from reading the Power Hour thread, I suggest pausing and thinking about how to break your site. Could you do it? Can you get in the heads of those bad users? If you can, I’m jealous. If not, have fun trying to break it!


listeningTo: Seduction by Eminem

inRealLife: I spent the last week in Florida visiting my grandma down there. It was HOT, and spending that much time with family is always tense and thoroughly exhausting. I did have a really fun day in Universal wandering around Diagon Alley and basically living 10-year-old Amanda’s dream (yes, I bought an overpriced wand to interact with things around the park with all the 6 year olds). Also we took her to a drag show and I’m pretty sure she had way more fun than she ever had in her life. (Looking at you, Ru!) I’m glad to be back, but, also, have a lot of stuff to catch up on. So it goes.

whatIReadThisWeek: I’m been studying the very exciting technical documentation on Bootstrap 4. I also read through Cassandra Leung‘s MoT Power Hour on the MoT Club – she was answering questions about using personas for testing. I plan on writing more about this in my next post because I found a lot of her responses to be very interesting and thought provoking. The link to the thread is here, but I think you need to be a member of The Club to see.

I also reread The Picture of Dorian Gray by Oscar Wilde on the beach this week, and am about 70% into Dark Age by Pierce Brown. Neither books are very light fun beach reading, then again, neither is technical documentation so, it is what it is.

whatILearnedThisWeek: We are working on a very long and slow project of migrating our entire site from Bootstrap 3 to 4. The short explanation is – we use Bootstrap for lots of our components and styles as well as easily making our site responsive on all devices. We don’t have a designated mobile app, so, this is how we make everyone happy who wants to use our site on their phones.

I’m pretty okay with CSS. I’m self taught (surprising, I know), and from what I understood previously of Bootstrap it’s basically componentized CSS. The developers did the initial work of setting up the application to listen to Bootstrap 4, and then the ongoing part of the project is to migrate each and every page to the updated version. This requires touching every single template and adjusting variable and class names to make sure the pages render the same way in BS4 as they did in BS3. It seems confusing. I wanted to learn more.

I was assigned a case to migrate a static text page (the Privacy Policy) page. It seemed simple enough – update the extends template to the BS4 version, update the class names to BS4 names, rinse and repeat. I noticed though that the style for bullet points that was already defined had an override to not change the color of links. Which is weird. Our entire site uses a specific color for all links. Also, wouldn’t an override be just that and not defined explicitly in the class? I had questions.

And I asked them! Half the developers told me I was nuts, the other half just ignored me, and I was thinking maybe I was overthinking it. (I tend to overthink). After a lot of back and forth via comments right in the Jira case, the CTO finally caught wind and chimed in. Hey, I was right! It was a great feeling. I carried on as I planned and even fixed the incorrect code from the original developer. Look at me! What should have been a very simple case ended up being much more but I was able to catch an error in the very early stages of a lengthy project that would otherwise cause serious issues down the road.

Testing for this migration has been equally difficult, though. I don’t test my own work, but I have tested the other migration pages. Things that are updated for BS4 are having unforeseen consequences on BS3 components, which is confusing and even the developers who did the initial work are scratching their head trying to figure out what went wrong. So, each round of regression testing since the first implementation of BS4 is requiring very thorough visual testing to make sure the BS3 pages remain unscathed. I never really thought an automated UI test tool was something that I would need to do my job but I’m feeling more and more like I may work on finding a reasonable solution because I’m getting pretty burned out and we are only in the very beginning 15% of the project.

whatIAmThinkingAbout: I realized as I was reading the section above back to myself that I keep saying things like “the developers do this” as if I’m not a part of their group. My position is really weird, I basically made it up, and it straddles both the development and product management teams. I’m pretty sure I still report to my product manager, but when the President sent around an updated org chart this week I was listed under the CTO’s line instead. Maybe we’re just disorganized, or maybe things changed and I didn’t hear about it?

I don’t see myself as a developer, however, I am frequently writing code for the application, and solely manage all automated testing code. Is it because it’s not in my official job title? Why would that even matter? What makes someone a developer? Committing code seems like a good first step. Hey guys, I’m a developer!

recommendationsAndTakeAways: Takeaways: trust yourself. It’s so cheesy, I know. I have the tendency to second guess myself. I’m new to web development, I’m the only woman on the dev team, I’m one of the youngest in the company. I have historically let more experienced people tell me that I’m off track and have listened to what they told me to do and did it like a good code monkey. But this proved that I do know what I’m talking about, I can push back, and I probably know more than I give myself credit for.