listeningTo: Gone Away Five Finger Death Punch

inRealLife: Real life is meshing pretty well with work life and applies to this post, yay! I have decided to officially start a #100DaysofCode challenge – for those who don’t know, you commit to practice learning to code for, you got it, 100 days in a row. There is probably science behind doing something for 100 days to make a habit, to learn, but I don’t know too much about that. What I do know is I have a personal (and professional) goal to work on a personal portfolio in the hopes of one day (soon?) taking on small freelance projects and get some extra money coming in doing something I am personally excited and interested about. I love projects!

whatIReadThisWeek: I haven’t read much this week. I am on day 11 of the challenge, mentioned above, and have been relying a lot on one Udemy course – Full Stack Web Developer Bootcamp 2019 – which covers HTML 5, CSS s, JavaScript, Bootstrap 4, PHP, and MySQL. I’m just at the HTML/CSS part, but I know JS, BS4, and PHP will also immensely help me at work so it’s a win-win.

I also listened to my pay-it-forwarder fellow tester, Hilary Weaver-Robb’s Ministry of Testing talk Digging In: Getting Familiar with the Code to be a Better Tester, which is now up on the MoT Dojo without needing a paid account! My computer crashed and died 1/2 way through the talk (hello blue screen of death) but I was able to finish it up by squinting at the screen on my phone and got the gist (and am happy to have the link to the recording because I’m sure things have been missed). My biggest takeaways from the talk was about using Static Analysis tools, which we have at work but I am too scared to touch, and how to use the Inspector toolbar in Chrome, specifically looking at the Network tab to see what kind of silent errors may be occurring. I’ve already put this into practice and found an error that’s probably been around forever!

whatILearnedThisWeek: I got through all of the HTML tutorials, which are really just a reminder, I feel very confident in HTML, and fairly confident in CSS, but am still working through all the videos to get the full picture. I’m a little disappointed in the tutorials, I feel like I’m relying a lot on outside information I have about the languages than is being covered in the videos, but, I’m hoping they are more detailed as we get into the more complicated languages.

The mid-point project is to replicate a personal portfolio website. The course just has you watch along as the instructor does it on her screen, but, I like to make things hard on myself, so I paused the videos at this point, looked at the source example provided by the course, and decided to build it up myself.

I immediately ran into a bunch of problems. This was my first iteration. I spent over an hour trying to center those social account icons and style them so they didn’t look like hyperlinks. I gave up, posted my obligatory #100DaysOfCode tweet, and called it a night. The next day, I really focused hard on this, watched the tutorial clip where the instructor showed how to do it, and, ah ha! I don’t have a screenshot exactly of that section, but in my code I was trying to style the social-icon class, which is in a div wrapped around all the icons, when I should have been adding the style to the social-icon a elements – just the links. Though some styles apply to the li, too. Once it clicked that different styles had to be defined for different elements, and it wasn’t as easy as just applying it to the parent div, I had:

.social-media li {
     list-style: none;
     display: inline-block;
     text-decoration: none;
     font-size: 2em;

.social-media a {
     color: black;
     height: 40px;
     width: 40px;
     text-align: center;
     padding: 8px;
     transition: all 0.2s ease-in;
.social-media a:hover {
     background: darkseagreen;
     font-weight: 900px; 
     color: white;

My next issue was trying to align my columns. In the middle of the portfolio, I wanted to list my positions in the left column, and explanatory text (just placeholder for now) in the right. Here was my first stab:

For the life of me I could NOT get that second column aligned with the first. I still have no idea where I went wrong. (You’ll see I also didn’t fix the social icons at this point, which was my second day and ~3rd hour working on this page). I quit, again, for the night, you will continue to be Future Amanda’s problem.

The next day, day 3 of this project, and day 10 of the challenge, I finally admitted I did not know everything, despite studying CSS on and off for a few years, so I proceeded with the tutorials and watched as the instructor was making her portfolio look like the example. At one point, she couldn’t remember the padding on something, and she checked the Chrome Dev Tools to find out. Another ah ha! I paused the video, went to the example they provided, and inspected the crap out of it. I was able to solve my alignment issue once and for all!

For starters, I created two new classes: col-narrow (for the left column) and col-wide (for the right). This could apply to both the bio section and work experience section, beautiful. Next was to apply a margin width to the whole container (or, both containers, since I want them to match). I forgot you can do this. I was struggling with padding and margins for each element and crying (almost for real) that they wouldn’t “just be right”. But, hey, now they were!

.content-wrap {
     display: block;
     width: 90%; 
     overflow: hidden;

.col-narrow {
     float: left;
     overflow: hidden;
     margin-top: 10px;
     margin-left: 50px;
     text-align: right;

.col-wide {
     float: right;
     text-align: justify;
     overflow: hidden;
     width: 70%;

Once I got past the container width, I was able to define sizes to both the left and right columns, and have them aligned and uniform, just the way I like it. I’m still not sure what overflow:hidden; or overflow:auto; actually mean, but as I was watching the instructor work through this section, she kept adding them, and once I did, too, everything popped into place. Perfect magic. (Except for the magic of teaching, because, as I said, there is less teaching and more “hey look what I can do, you probably can too”).

The other very useful definition I put in there was clear:both;. This refers to the floats – one column would continue to float to the left of the block (see content-wrap where I define the section as being a block*), float:right; makes sure that content floats to the right of the block, but to make sure they don’t overlap, which was happening A LOT to me, you have to make sure one or the other has clear:both;. Magic, come on.

I also got the social icon fix in at this point, since I was feeling big and bad and confident at this point. (Amazing what some confidence can do). And I added a little color. I’m not a colorful person… like at all… but I felt like since this is practicing design that maybe some color-work is a good idea. I also have a hover event on those social icons and they turn that same green, which is in the code snippet above.

So, here we are! I want to add a background to the My Work Experience section, as well as one more section below with contact information, and a footer. Follow along on Twitter if you want real-time project updates!

whatIAmThinkingAbout: I still see places where my code can be cleaner, but I feel like getting the gist of it, for the purposes of this project, is good enough. I’m really proud of what I accomplished in 3 days, and I am keeping a list of my questions that come up, and their resolution, so I can hopefully report back if I find anything noteworthy.

I’m not sure if there will be any reason to use PHP or MySQL on a personal portfolio page like this, but I will certainly be adding JavaScript elements when I start those tutorials. I’m excited to see how it works out, and excited to publish it eventually and use it to get some business in the future.

recommendationsAndTakeAways: Even though I don’t love the course I’m working through, I do think it’s important to stick with it. There are little gems in there that just make things click. People study this stuff for years, there are so many resources out there to help, it’s useful to remember that I don’t need to memorize everything, I just need to know enough to know what I need to look up – it’s been a good process so far and I’m looking forward to the end result.


listeningTo: The Trauma Model by King 810

inRealLife: My whole company is remote spread out all over the world, but we get together once a year in NYC for a two-day team meeting, and it’s this week! I’m excited to see everyone, but I’m more importantly excited for tomorrow night’s team excursion to see To Kill a Mockingbird on Broadway! (Ed Harris’s first day on the job!) TKAMB is my absolute favorite novel of all time for many reasons – one of my doggie’s name is Scout and I have a large-ish forearm tattoo inspired by a few of the classic book covers. I’ve been in a rut, and I think this will be the thing to pull me out.

whatIReadThisWeek: I’m still feeling less like myself, so no personal reading, which in itself is making me feel down, but, also, Maggie Stiefvater’s new book comes out tomorrow and I think that will excite me enough to get back on track.

While these articles aren’t super recent, I have had them saved for weeks in anticipation of this post and I did read most of them in the last week or so. If you’d like to read along:

whatILearnedThisWeek: In part 1 the other week I focused mostly on what the heck a mind map was, and this part will be more about what the heck exploratory testing is, and how the two can be used together. As a quick update on the last post: I have an official Mind Map skeleton!

Created using MindMeister

I’m really excited to continue the project. I decided to map the full application, first, but am still thinking it will be more useful to create a map on the feature-level where I can add way more details and not be so overwhelmed. This is really just the basics of the site and it’s already feeling like a lot to look at. I need to pretty it up!

Reading more about exploratory testing the last few weeks have also strengthened my hunch that the two processes can be used together in a really nice way. Questions posed by That’s the Buffet Table drove the point home for me that, yeah, this is something I should be doing regularly; “Are you really performing only the specified steps and checking the specified expected results or are you doing more?” Uh, always more, I get so distracted… “How do you tell people what you saw when you moved away from the script?” I don’t, I try to just remember to come back to it later, which often ends up not happening since by the time my hands are in the application and I’m working through my manual regression test plan, I’m already so stretched that there is usually not enough time to address non-release related things. “Are your cases/steps answering questions about risks?” No, I don’t think they are. I would say 99% of my test cases are searching for bugs, which are risky, sure, maybe I’m not understanding what is mean by “risks”, but, the way I’m thinking about it is not necessarily finding bugs, but finding what makes the application vulnerable, or what provides a stupid user experience which could risk the business. Is there a better term for this?

But, anyway, what is exploratory testing? I’ve mashed up my own definition based on the limited reading/watching:

Exploratory testing is poking around your application for a specified amount of time with no real purpose other than to see where you are taken and uncover any underlying bugs or weirdness not commonly caught with structured test plans to come up with documentation to share with your team of areas of risk, bugs to fix, processes to rethink.

I’ve seen a few sources discussing formal exploratory testing sessions where time is specified, charters are written, and plans are in place long before the session begins, and I’ve seen some more loosey-goosey “hey let’s click around and see what breaks”. I think I would prefer the later, since everything I do is generally loosey-goosey, but keeping in mind that I have this obsession with using my mind map to guide my exploratory testing sessions, I think having a formal session and guide will make the event more successful.

TestBuddy’s video proposes 5 steps to successful exploratory testing:

  1. Understand the product’s value.
  2. Come up with possible risks.
  3. Turn risks into questions.
  4. Run a test session to answer our questions.
  5. Share your findings.

Performing the actual test session isn’t until step 4, but I struggle to think of answers to steps 2 and 3 before exploratory testing. I think once I have more of an idea of where the risks lie, I can better form questions that I want answered in subsequent test sessions, but for the first one, I want to go in blind.

Undeveloped Bruce writes about how her team uses charters and a specific Six Thinking Hats method, which I’m very intrigued about, but, sadly, since it’s still just me here and though I feel like a different person depending on the day, I don’t think I can personify 6 different kinds of people in one session all by my lonesome. I’ll be interested in researching the method more if I ever get the luxury of working on my personas project…. but, anyway, there is a nice example of their testing charter in the article, though, that I am hoping to use as a guideline as to what I should be pre-planning before jumping in which includes things like “target or scope”, time, and who will be focused on what. If my first session alone goes well, I may try and recruit some other people on my team for a little experiment. I have to be careful, though, since we all have big grand plans for the site and I don’t want to be misleading about being able to “fix” any of the weird stuff we uncover in a timely manner – we still have a massively ambitious road map for the next 6 months that I’m not at all anxious about (I say through a forced smile and terrified eyes) (send help).

whatIAmThinkingAbout: If I make more targeted mind maps at the feature level as I keep musing about, I think I can make the two of these strategies really work well together. My immediate thoughts are about new feature planning, but when considering testing I think focusing on one large feature or a group of related features will be worth the time. We encourage members to leave reviews for books they get access to on the site, so a smart experiment could be working through the get-a-book-and-leave-feedback process, which is slightly more complex than it sounds, at least there are a ton of moving parts that can be explored…

I don’t always (ever?) have the luxury of working on big projects outside of my “normal” job responsibilities. There has been a recent conversation with my supervisor, though, that it’s probably time to start acting managerial (despite “manager” being in my title for 4 years) which will involve passing off some of my normal day-to-day stuff to the actual project manager. I’m hoping this frees me up to do things like make my mind map, schedule regular exploratory testing sessions, finally get to this personas project that has been haunting me for 2 years, and, like, actually be able to maintain my test scripts, not to mention some time for personal development.

With the fantastical free space coming up, I think a smart project to jump on first will be implementing exploratory testing sessions, even if it’s just an hour or so at the beginning of a release cycle or some time that makes sense. I struggle to determine what of my work I want to track in Jira like a real dev, or what work I just do quietly by myself and bring up out of the blue when it seems relevant and listen to everyone be like “wait what when did this happen?” I’m leaning towards scheduling a 1 pointer in Jira every now and then just to 1. honor my specified amount of time dedicated to this, 2. have a place to post my documentation, and 3. let anyone who cares know it’s going on and see if they want to join in for a session or 2.

recommendationsAndTakeAways: The biggest takeaway for me came from the exploratory testing Power Hour question about taking and sharing notes. Simon Tomes responded, “I enjoy using the PQIP approach: I document Problems, ask Questions, share Ideas and give Praise for stuff I discover that I think is cool.” I think this format of note taking is fantastic for any setting, but I can see it making exploratory testing sessions even more digestible for the rest of the team if I can present these four categories to them and ask for them to add their own thoughts.