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: