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.


listeningTo: cranking air conditioners and hot pacing doggies

inRealLife: My phone decided it only wants to hold calls for 6-12 minutes, which was not very conducive for my very long sprint demo, estimation, and planning calls today. We use Zoom, cool, so I can just use Internet Audio. Oh, but then the internet went down for like 3 hours. Today is a hard day for my technologies.

whatIReadThisWeek: I read a lot of books. I would say it’s because of the industry I work in, the nature of my website, but, no, I’ve always been a bookworm. I finished Ill Will by Dan Chaon which was a really fast but intense crazy read, and started Dark Age by Pierce Brown this morning – I can’t stop talking about this series (Red Rising) and so I felt obligated to share here because I’m so freaking excited for this one.

But, okay, in tech news – a lot of this week has so far still been pre-occupied by broken release issues, more on that later, but I did read through a bunch of headlines and saved some articles for further reading if I ever have that luxury again. Topics include: deciding when automated testing isn’t the best solution, automating visual testing (I’m excited for this!), and a few articles about Google Tag Manager because in addition to QA Manager I am also the lead on many of my old Project Manager-responsibility projects and Google Tag Manager is that pest I cannot exterminate. “Find gaps and fill them,” everyone I spoke to about job hunting instilled in me. This is a gap that should have been left unfilled. I’m sure I’ll dedicate a post shortly as I embark on a big refactoring project.

whatILearnedThisWeek: “Amanda, do not certify a release if you cannot predict what will happen on production. Be persistent. Be annoying. Do.Not.Release.” That’s less learning as much as it is a warning for future Amanda. As you can see in my previous post, I had a lot of questions and hesitation around releasing our current build since it was so unpredictable how it would react out in the wild. I knew to be worried, and I tried to bring up my concerns on our stand up calls, but, no one else was as worried and I let it go. Don’t let it go, guys. If you have reason to think something may not work, make sure you prove yourself wrong before certifying the release. Or else.

Well, not really or else. But it would have saved a bunch of my colleagues and I a bunch of overtime and headache this past week. We had a lot of issues with testing the current release, and once it was released in the wild it BLEW.THE.HELL.UP. I griped about the lack of tools I have to use to predict similar situations from happening once we hit production, but at the end of the day, I found no good solution and was convinced the “let’s just see how it goes” method would work. It didn’t. We ended up having to roll back the release, which is the first time we have ever had to do that in the history of the company. Not cute.

In non-disastrous news, though, I did learn how to very basically migrate a Bootstrap 3 page to Bootstrap 4. My next post will be more about this for anyone who wants to hear more about how that goes. We have an on-going project to migrate each and every page to Bootstrap 4 now that 3 is no longer being supported, and I am trying to learn it from the ground up by hands-on touching each file and making those changes. I’m starting with really simple, static, text pages for now, but as I get more comfortable (what I really mean is once I build the trust of my team) I hope to tackle more complex pages.

whatIAmThinkingAbout: What would I have done? It was like knowing you were about to see a car crash a millisecond before the cars collide. I know on a personal level I need to work on being more assertive, finding my voice, and demanding authority where authority is due.

Professionally, though, I need to find a tool or a process for testing in production type environments. I KNOW most people have great solutions for this, maybe I just need to survey what is out there and plead my case. This last release fiasco may be the ammo I need to drive my point home.

recommendationsAndTakeAways: I’m sure it’s been covered. What’s done is done. After too many retrospective calls it was determined that no one was at fault, which I agree with. It’s hard to not blame the tester, and in the past when things go wrong it is usually the jerk-reaction to blame the tester, but it was acknowledged across the team that whatever went wrong – which to date is still unknown – is not happening on staging and could not have been caught by devs or testers in a non-production environment. Takeaways? Finding a production-like environment is more critical than ever.


listeningTo: Lucifer, Season 1 Episode 9

inRealLife: After dinner, my husband and I went out to the car, just in the driveway, to clean it out after our long weekend trip this past weekend (okay, we’re super lazy, I’m aware it is Thursday…). I let Scout out with us, my little baby 65lb pit bull, forgetting how batshit crazy she gets about the car. Open door > Scout inside > Scout won’t leave. She’s not too big we can’t pick her up, but she is too cute to not give in, so, in we go, and drive our little baby around the block. I felt both so pathetic and so motherly at the same time.

whatIReadThisWeek: This has been a week from hell (what a cliche, I’m watching Lucifer in case you missed it, I’m allowed). It took me until 5:15 this evening as I was waiting for a round of automated tests to run (they failed) to even remember ‘oh yeah, I told myself to keep up on industry news at least once a day.’ What I won’t admit is it took me until 5:15 pm on Thursday for the first time I remembered and attempted to read something educational or semi-related to work. This section will typically be way more useful than my ramblings right now.

whatILearnedThisWeek: I am not as good at time management as I previously convinced myself (and my supervisor) that I am. But, for real, I did learn how to create a symlink between two code repositories, and by learn, I mean I Slacked my developer so many questions he just called me walked me through it from start to end until I was pretty sure I could do it again. Yes, I wasted his time, but not as much as I will when I get my hands on that feature and send back all my changes…

whatIAmThinkingAbout: I know there are a bunch of ways to create test data that matches production data – it all seems very fantastic and useful and just a teeny bit complicated. However, I don’t have that luxury at work. Whatever grand plans I have require me working it out on my own with little to no support, and I don’t know where to start with this one; it is something I think about often, though… The underlying issue this week is how can I read my application’s mind and ensure nothing will explode when the release is pushed to production? Well, I can’t; I try, but, can’t.

Regression testing just started – well, should have just started – for a platform release scheduled for next Wednesday. Included in this release are a ton of query refactoring that – in an ideal world – will increase performance on our largest of pages AND it will do so in an unobtrusive way. It will be magic (I’m assuming)… I won’t mention how the work is taking longer than promised and I won’t complain about how that is effecting my test schedule. I will mention, though, that the QA Plan I received is “make sure nothing blows up” and this feels much easier said than done.

So when I get the build, where do I start? Our site is segmented into three natural sections: members, clients, and admin. First thing first – predict the “big” pages that could benefit from streamlined queries and list them per section. Alright, I can probably figure that out. But, oh yeah, I can see his code. I know SQL, at least enough to read complex queries. So, I can look through his code, see how the queries changed, and hope for the best. Right?

This all feels like a ton of guesswork. I’m okay with guesswork, a lot of software testing is guesswork, right? And even if I make a definitive list of every single route that was probably touched by the refactoring, how do I even know if the performance is better? Performance is always great on staging! At any given time there can be a maximum of 10 of us on at a time, if there is performance issues then, please pray for us if that code ever makes it into the wild.

recommendationsAndTakeAways: I have no good answers. I asked the developer for ideas, asked the CTO for ideas – the best they can come up with “just hit every page and watch the profiler for long load times or lots of queries.” Okay, I say, what constitutes too many queries? “It depends on the page, just, like, a lot.” Aye aye.

The plan, for now, is to do as they suggest. Well, not every page, it would take me 6 years. I have a list with my best educated guesses, I have a vague idea of how to use the symfony profiler, and I have recruited two of my product managers to lend a hand – or, eye? Hopefully I can report back that everything was a great success. Hopefully I can find a good solution for mimicking production like traffic and this will never ever be a problem again. I’ll be sure to report back!


This first post probably won’t be very exciting to anyone but me, but I have a special thank you to give out.

THANK YOU to Hilary at g33klady for paying it forward and gifting me with a year pro subscription to the Ministry of Testing. She is a wonderfully giving person and I will forever be grateful for her generosity and willingness to help newbie testers get on our feet! While I’m not able to financially pay it forward yet – though I do hope  to follow in her footsteps soon enough – I did want to create this site and remain committed to keeping it updated as a way to pay whatever knowledge I gather from this experience forward to all my other diy testers. 

Next, I’d like to create a list of links I’ve found useful. This will likely eventually break out into its own page, but for starters, let’s see: