Blog

buildingAPortfolioWebsite.part1htmlcss

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;
     clear:both;
     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.

exploringMindMaps.part2

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.

exploringMindMaps.part1

listeningTo: The Addams Family

inRealLife: It’s fall! And I’ve officially been pumpkin picking twice already, planning to carve today. I love spooky season.

We had a MASSIVE platform release last week which called for lots of overtime hours. It was a few months in the making, definitely nail-biting near the end, but at the end of the day, we are up and running on the recent version of Symfony in addition to many other important tech upgrades. While it wasn’t the most flashy release we’ve done, it was definitely one of the more vital in combating the never-ending list of technical debt we have built up, which is a great feeling.

And, to follow up, somewhat, on the last post’s topic – career stuff – I recently found out that, after more-or-less asking for some more responsibility, I’ve been named tech-lead on a large WordPress migration project we have going on for one of our WordPress sites, but, also, all the other sites (a total of 3)! It’s been a hard time for me, personally, and I’ve been feeling pretty defeated, but the opportunity came up, and I decided to practice what I recently preached and went for it. I am SO excited to tackle this thing and prove to myself I can do this, and more.

whatIReadThisWeek: I’m in a reading rut, which is unlike me as I usually get through at least a book a week. I’m sure I’l get back into it.

Tech-wise, I have been reading a lot about exploratory testing ideas and mind maps. When I first started considering my next blog topic, I thought the two would go hand-in-hand. I still think this, but I decided to focus solely on mind maps today. There is so much cool info and ideas floating around my head I think they deserve their own posts. If you’d like to read along:

whatILearnedThisWeek: I have definitely heard of mind maps before, even saw the phrase tossed around in various testing-related research I’ve done, but I never really knew why people used them, or how they corresponded with testing practices. They look nice and organized, at least as organized as a scattered bunch of words can be. The resources I read this week have helped shape a pretty good definition of what a mind map is actually intended to be and gave me lots of inspiration to create my own.

I was under the impression a mind map was something you wrote down during brainstorming (mind > brain, you know?); however, I found mind maps to be much more orderly and thought out than typical brainstorming notes. To start, I was really looking for a definition of what a mind map was. The examples I found all looked differently and had different levels of detail, but some of the qualities all mind maps shared were a very focused, organized, attractive organization of whatever topic the map was being used for. Elizabeth Zagroba explains mind maps as “smaller, prettier, more focused” than a stack of text-heavy documentation; SoftwareTestingHelp.com defined them as “a graphical representation of ideas and concepts”; and Dragos Campean simply explained they are “a diagram used to visually organize information”. None of these definitions are terribly scary or overwhelming, so why was I assuming this was some high-level, complex project likely out of my scope?

Now that I wrapped my head around what these things are, I was interested on seeing all the examples of how software testers use these products to help facilitate their tests or their jobs in general. Zagroba succinctly says a mind map just provides an overview of the whole product. Okay, this makes sense to me – my application isn’t extraordinary big, but we have a lot of moving parts. On the product management side – which we all know I’m still somehow involved with and we’re not at all bitter about it – we often create visual flow charts for explaining how complex features work or explain how our APIs talk back and forth to other APIs. Mind maps, then, can just be a really big flow chart for the whole product. Cool.

I had a vision – I was staring at a huge mind map that for some reason I printed out and tacked up to the wall of my home office despite not even having a printer let alone one large enough to print a, literally, wall-sized map. I could see each teeny tiny section of my site represented. And I could see, in my mind, tiny automated changes occurring in the branches when thinking about introducing a change to a specific feature. “Oh, you want to add another required field to the member registration form? Look at the “member profile” branch rebuilding a la Game of Thrones intro style. I’ll need to make sure positive and negative form testing occurs here, and here, and here” and I traced that branch from the member registration branch out. The implications were terrifying and I had immediate anxiety about all the times I thought I remembered to test everything when introducing a tiny change and maybe (probably) I hadn’t. When the hallucinations and anxiety passed, I whole-heartedly decided a mind map was in my future.

It might be fun – at least that’s what SoftwareTestingHelp.com would like me to think. It “increases creativity” which is an alluring thought. I consider testing in general a very creative process, despite it being fairly technical and sciency. My test plans are boring, though, and my documentation probably has never been read by anyone but me (and my boss, as I’ve learned). As I was having the thought, I read Zagroba’s point that a mind map can “help you share information with your team”. Of course! No one will ever read my test or feature documentation, but I know our flow charts go over very well with the non-technical team, and it is definitely worth a shot.

whatIAmThinkingAbout: Back to hallucinatory-Amanda for a second – imagining my mind map encompassing the entire wall of my office – I start to wonder how big they end up, or, more interestingly, how small they can be to still be beneficial. What if I didn’t map my entire project, but instead just map at the feature level? I think it would be less useful when trying to determine everything a code change could effect, but I think it could very extremely helpful when writing test cases and QA plans at the individual feature or even case level. Similarly, since I have to wear my tester and project manger hat at all times – could the mind map be created at the feature planning level, and then updated and reused when it’s time to test the thing? I have big plans, I’m excited to try generating some of these things.

recommendationsAndTakeAways: I wrote a few months ago about really wanting to dive into a persona-writing project, and, of course, have not found the time yet. I’m thinking of marrying the two ideas and coming up with a mind map for a few specific personas. I’m not sure how this will work, and I’m thinking maybe it will be better to not try and get too fancy my first time out, but, why not?

I don’t have any recommendations since I really only just understood what these things were the last few weeks. Once I put it into practice, which I’d like to work on this week, I’ll hopefully have some more recs.

Part 2 of this post will focus more on exploratory testing – a concept I have heard MUCH about and have, embarrassingly, never actually participated in. Does that make me less of a tester? Probably. Does it sound just as fun as making a mind map? It does! Will I make my life even more complicated and try and marry a mind map based on personas from an exploratory testing session love-triangle style? Yeah, most likely.

formingYourCareerInTesting

listeningTo: The Simpsons Season 2 Episode 5

inRealLife: I’ve been intending to write for weeks, I really have. Things have been serious health wise, busy work wise, there’s no real good excuse. I just checked though, thinking “I bet I haven’t blogged in over a month” but AH HA! as long as I post this today as I’m writing it, I will just miss my month-a-versary by a day, so, small victories are still victories.

whatIReadThisWeek: I finished Recursion by Blake Crouch. I’m going to write a better review for my company’s consumer-facing blog later this week, but, the short version is: please read this book.

Otherwise, as the post’s title may lead you to believe, I have read a few articles on careers in testing. This is a topic I’ve been drawn to lately. Possibly because of the aforementioned “busy work wise” (to put it mildly) statement, possibly because I’m about to be 30 (alright in like 8 months) and I still don’t know if this is what I want to be when I grow up, or, possibly, because there happen to have been a bunch of good content popping up in my feeds on the topic in the last not-quite-a-month since I’ve written. If you’d like to read along, here are the links:

whatILearnedThisWeek: Not to go too far back into my career history (you can get that on the usually-ignored About page), but, I, like most testers I’ve heard from, simply “fell into testing”. I applied for a QA Analyst/Assistant Product Management position on a whim, primarily because it was a work from home job because and I, as a 25 year old with 1/2 a masters degree, had just been asked to clean out my boss’s file cabinet which I decided was an outrage (okay I’m still bitter about it 4 years later)… Somehow I managed to twist whatever minimal job experience I had into skills my company was looking for in an entry-level tester, and, that was that. My career path so far has been QA Analyst/Assistant Product Manager > Project Manager > QA Manager.

My titles have never really meant that much to me. When someone asks me what my title is it is usually always followed up with a blank drooly stare and an immediate follow up “so, like, what do you do?”

“I test things”

“Oh, okay.”

(If you ask one of my friends, I am a book editor, somehow, another one thinks I’m a journalist and if you ask my mother what I do, she’ll tell you “Oh well, she gets free ebooks, really, like any ebook you could ever want to read”. My grandpa just thinks I’m unemployed since I “sit at home all day” and my dad is convinced my work-at-home company is a scam “I have health insurance and a 401K” “I don’t know, Amanda, I just don’t trust it”).

I’m a woman, and as a woman I’m as interested enough in the equal pay, equal opportunity buzz as the next chick, but probably not as much as I should be. In the publishing industry, which I work in, it’s really very common to be surrounded by female co-workers, female bosses, female mentors, and we all want to lift each other up. It’s really a beautiful thing. I know other industries are absolutely not the same.

What I found interesting about the CNET article is that there is not a big shortage of women in tech, we’re here, we’re not going anywhere, but we’re in places you wouldn’t expect: non tech-companies. When I first started working in the tech field rather than the editorial field, I was like “duh, so many industries need testers, developers, ‘computer people’ – not just Google (the dream, Amanda, you’ll get there)”.

A refreshing stat from the article, in 2019, of the companies included in the study, almost 30% of entry-level tech jobs were held by women, and there is a higher rate of female promotions this year, too. Though, also, there is a higher rate of women leaving their companies. This makes me hopeful that not only are more companies hiring young women, but we are making career moves into, hopefully, bigger and better positions, more frequently.

As I soon realized from reading the articles this week, I’m not alone in the weirdness around tester job titles. Do they really even mean anything? My takeaway from Del Dewar’s Testbash talk, is, nope. In his talk – which I highly recommend for just normal life advice not even related to “stepping back” in your career or like testing at all – he explains how he went from a Test Manager title to a Test Analyst title, and a recruiter accused him of moving backward in his career, even though he did not feel that way. It’s a natural assumption that moving away from being a “Manager” is a step back, but, is it?

As explained and as I’ve noticed, every company has their own role titles, and, like Melissa Eaden’s article briefly mentions, a lot of us make up our own titles and career paths. I know I certainly did. QA Manager means… nothing? I mean I assume it would seem like I manage the QA team, but, you know, the QA team is… me. But I not only manage the test process, I write all the automated scripts, write the manual test cases, write the QA plans for every Jira case, consult with the other devs on testing approaches, and let’s not even get into the I’m-still-a-project-manager-but-no-ones-talking-about-it part of my days. How do you summarize that in a single job title? A lot of titles were thrown around when I got this promotion last year “QA Engineer” “Test Lead” and really just “Developer”. I think it was easier to just replace “Project Manager” with “QA Manager” in my email signature so we settled on that (not really, my boss just picked since I couldn’t make up my mind). Back to the point, though, as Dewar muses at the end of his talk when considering a career as a consultant,

Don’t let the role define you. You define the role.

So, what does a “typical” career path even look like? The examples from Eaden’s article are: Tester > Management, Tester > Business Analyst, or Tester > Development. Where that leaves me as a tester-project manager-developer, I’m not too sure, but it’s nice to see I’m heading in the right direction, or at least know what to realistically expect if I continue in this career.

whatIAmThinkingAbout: One more point Eaden’s article makes is that most testers will naturally navigate towards a role as Automation Tester, and while that’s great and necessary for many test teams, it is not usually a real role at many companies. It’s suggested, instead, to use automation testing skills as a stepping stone to a role as a developer or test lead. I know for me, my experience learning to code specifically for my automated test suites is making me fall more in love with software development, and making me more inclined to take on more development-related projects. I can see myself drifting off into the development side of things, eventually.

I’m still learning to code way too slow, or at least slower than I’d like to be, even considering I generally pick things up pretty quick. There isn’t enough time in the day to dedicate to learning a new skill that technically isn’t directly related to my current job, though I would like it to be. I’m always considering a coding bootcamp or other kind of paid, formal program, but then they are usually a ton of money and many require too many hours a week and, though I’m sure they are very beneficial and worth the time and money, it’s not a commitment I can make now.

Mostly I’m just thinking a lot about where I hope my career leads me, and what I think I’ll be doing in 5 years, 10 years, and more, but none of that anxiety makes for exciting blogging. Despite the anxiety that is with me, always, (love you), I do feel better digging into these articles – I feel good about the future for women in tech, and I feel good about not really understanding the tester role hierarchy and where I stand in it.

recommendationsAndTakeAways: I don’t think it’s ever a bad thing to pause and think about where you are in your career and where you want to be. I’m going to be thinking even harder this week and coming up with a list of short-term and long-term career related goals and see where that takes me.

learningJavaScriptClasses

listeningTo: Arrested Development, Season 1, Episode 2 (for the 1569th time)

inRealLife: Halloween decorations are officially up and creepy! I was a few days late this year, I usually aim for September 1st. I’m in my happy place.

whatIReadThisWeek: So much! As the title of this post will tell you, I have been focused primarily on upping my JavaScript skills. And by upping, I mean getting some, there were no prior skills. A year (or more, probably) ago I started working through tutorials from The Odin Project, which is a free and open source project for anyone hoping to learn some cool tech skills from the ground up.

But, it’s me, so I go off on my own tangents trying to cram as much info into my skull as possible, and I retain like, I don’t know, 37% of it? One the many things I love about The Odin Project is all the external, vetted links they have to other awesome online resources. Codecademy is a given, I’ve worked through countless of their tutorials even before starting with Odin, and got sucked into the Intro to JavaScript course – 72% complete!

In non-work-related reads, I finished reading Baby Teeth by Zoje Stage and Ruthless Gods by Emily A. Duncan (pre-pub ARC). Baby Teeth did not live up to the hype, but Ruthless Gods was everything I was hoping it would be for the sequel to Wicked Saints.

whatILearnedThisWeek: I had previously learned all the basics to JavaScript in a cram-session meant to help me make sense of some custom automated testing scripts I had to write (despite, again, my “codeless” automated testing solution), so the tutorials I worked through this week were more “advanced” topics this time (fancy me, I know).

Topics included: Iterators – like how to use the forEach() function, Objects – which are still an enigma but I think in theory I understand what’s what, Methods and Nested Objects – methods are just functions but they’re sometimes referred to as methods… which was the main takeaway there (don’t quote me on that), Getters, Setters, and “this” – sure, you can use the code you wrote in this file, but make sure we know you mean “this” this file, and Classes – which roll all the aforementioned topics into one fun code block. There was also an exercise on Browser Compatibility and Transpilation (a fun word that means translating code from one programming language to another) that went over my head, and Node.js Modules that’s, also, up over my head. I think at that point I was too tired and I may have to re-read those exercises before they make sense in my head.

Let’s talk about classes! They’re used to really quickly produce similar objects, basically like an object template. Please don’t ask me to explain what an object is. It’s just a block of code that gives different parameters to a variable (right?). Let’s see a really simple example based on the one from Codecademy:

class Dog {
     constructor(name) {
          this._name=name;
     }
     get name() {
          return this._name;
     }
};

const pitbull= new Dog('Scout'); //This is a new instance of Dog
const rattie = new Dog('Sasha'); //This is another new instance of Dog

pitbull.name(); //returns: Scout
rattie.name(); //returns: Sasha 

Classes require a constructor() function which is the common thread between the class and it’s duplicates. In this example, name has to be passed into the new instance of the class, and that is the only required information needed to duplicate the class.

The line just under the constructor function defines what that function is doing. It is taking the name and saying – “okay, wherever you see name in this code, we mean the name passed into the constructor, and that is Scout or Sasha in Amanda’s example”. (Classes are very eloquent, sorry).

AND then, once your new class instance is created (via that const statement), you can call on it to run any method (function) on that new class (const). So, the very last line in the code example above, we can ask our code to politely return the name of pitbull, our new Dog class instance. When that code executes, it will return the name associated with the pitbull class, or, Scout, (the goodest girl).

There’s more! The whole point of classes are that they are reusable. I have two dogs and two cats, so the parent class should be Pets, which I can create Dog and Cat children of (aww). So, using the same simplistic example, let’s say:

 class Pets {
     constructor(name, type) {
          this._name=name;
          this._type=type;
     }
     get name() {
          return this._name;
     }
      get type() {
          return this.type;
     } 
}; 

This is my parent class, Pets! Notice the constructor() now requires two parameters: name and type. To create a Pets child, we have to make sure we extend Pets so all of Pets‘ properties are copied to the children. To create the Cat child class:

 class Cat extends Pet {
      constructor(name, type) {
          super(name, type);
     }
};  

const fireBreather = new Cat('Dracarys', 'Cat'); //This is one instance of the Cat child class of Pet

const cook = new Cat('Heisenberg', 'Cat'); //This is a different instance of the Cat child class of Pet

fireBreather.name(); // - MISSANDEI 😦 - (sorry). This returns: Dracarys
cook.name(); // - SAY MY NAME - (sorry!!). This returns: Heisenberg  

We have to use the extends keyword to make the connection, but after that, you can use any of Pets properties (in this example, name) in Cat. The first line of the constructor() should always be the super() function, which passes the child parameters back to the parent class, so the child can use the parent’s methods and properties. In my example, when we pass 'Dracarys' and 'Cat' to the child class Cat, the constructor() also makes sure 'Dracarys' and 'Cat' are passed to Pets.

However, when you extend a class, you don’t need to use all the inherited properties, and you can create properties on the child class that aren’t used in the parent. In my example, I changed the type to be hard coded to ‘Cat‘. If I were to extend Pets in a new child class named Dog, I could hard code the type in Dog to be ‘Dog‘.

Obviously this is an overly simple example and possibly more confusing than necessary, but, classes are cool, and complicated, but in a cool way.

whatIAmThinkingAbout: Uhh, classes? How can I make use of this in my own code? I recently endeavored in a long and arduous (okay it was like 4 days) project of refactoring my automated scripts. I have functions now, guys! I’ve come a long way. Maybe the next worthwhile project will be to take another close look at my code and see if those functions make even MORE sense as methods to plug into some sick classes.

recommendationsAndTakeAways: JavaScript is pretty easy to wrap your head around and is a pretty approachable language as the first I’m really trying to learn the “right” way (looking at you manual HTML edits on my angsty 8th grade Xanga page).

I recommend the Codecademy tutorials as a really organized laid out hands-on practice when learning a new language. What I do not recommend is their community forums. If you’re stuck, it’s a nice way to skim through and justify that other people are also stuck and you’re not just dumb. But, if you’re posting and looking for an answer, try researching more elsewhere. There is quick explanatory text before each exercise, so, if you’re like me, and need to read up on something more than just a few sentences before truly committing it to memory, I CANNOT recommend The Odin Project in conjunction with Codecademy enough.

refactoringAutomatedScripts

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?

personas

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!