Monday, June 27, 2016

Spelunking Dark Patterns

"It's a Trap!" - General Akbar

It's happened to many of us. We've downloaded an app, started playing with it on our phones or desktops and then suddenly, what looks like a simple click sends you down the road into an application wormhole you can't get out of until you complete whatever dastardly functionality you became stuck in. Or exit the program all together.

Dark patterns, as defined by, are "a user interface that has been carefully crafted to trick users into doing things".

Emma Keaveny gave a talk at 2016 European Testing Conference. She spoke about her personal experience with dark patterns and why they were the focus of her talk.

"I was in a Weekend Testing Sunday session when I got duped by LinkedIn and its Friend Spam Dark Pattern. [I] was testing the mobile version, and chose to test the contacts, as I was going through the contacts screens you are shown who isn't connected in your email and phone contacts, a small, helpless send all button was at the bottom of the page, so I pressed that for the emails, notifications were sent, I was OK with this, with the mobile contacts I thought a warning would come up when I pressed the button, like a "Hold on you are going to spend money spamming!", but nope, they went through, there was also no real way to tell that you had sent all these contacts, the screen would go blank and you moved on to the next page, however if you went back to the same page all the contacts would appear again, so you could re-spam them as much as you want on your own cost! I was told by Neil Studd (the host) that this was a dark pattern, a friend spam pattern, and that's where I went exploring the term," said Keaveny.

Keaveny is not alone in her experience with mobile apps and the very deceptive ways they get information from your phone or charge your mobile account. In fact, many things have dark patterns and the easiest to miss are the ones that set defaults.

Defaults Can Lead to Dark Places

The use of defaulting options is a very prevalent design pattern and can quickly lead to dark patterns. The dark pattern comes in when the user is unable to easily identify whether the default is the preference they would prefer to have. This type of  dark pattern is called a "Trick Question"(1).

In the research paper "Decision-Making Approaches and the Propensity to Default: Evidence and Implications," where participants in an retirement plan were surveyed, the percentage of participants that choose the default option who would have preferred to have chosen another plan doubled compared to actively chosen plans. There was also a strong correlation with procrastination and the default option.(5)

Often the business, whether it's intended to help or harm the user, is mostly responsible for driving these patterns due to metrics which drive up membership, views, or even profit (2).  A majority of dark patterns take advantage of users who would have an implicit trust because of the brand they are dealing with or have choice fatigue and go with a default setting, sometimes not understanding what they are agreeing to. Most people are guilty of not reading a EULA or a user agreement document, and clicking the "Agree" button, simply because these have become standard items and mostly filled with legal speak and jargon which the average user becomes very bored with reading, so they skip to the end and press the button.(3)

{Writer's note: From personal experiences I don't stop to read EULAs and I know how much I could be giving away in them. The only EULA I recently read is one that I had to verify was updated for our software release.}

 Based on the 2016 Design In Tech report, "78 percent of design, engineering and product leaders say that at their company, the stakeholder that drives ultimate product decisions is Product. In 2nd place was Engineering at 16 percent."(4) It also notes that ethical design decisions are a topic of concern trying to harness behavior and motivation for good rather than just for profit.(4)

This battle of good verses evil plays out when some design decisions are made. The graphic is from an article comparing the various benefits verses evil-doing that can happen when defaults are implemented. (6)

Light Vs Dark

From "Dark Patterns: Deception vs. Honesty in UI Design" by Harry Brignull(also the originator or

Caveat emptor (Let the Buyer Beware)

General experience and various tales of woe with lessons like "buyer beware" and "you pay for what you get", along with "a sucker is born every minute," should give one caution to any transaction they seek to make. Often, this isn't the case.

There is a current trend in stock management where robo-advisers are buying or selling stock based on market trends and user requests. There are some disturbing possibilities as this trend grows more popular with how the algorithms are buying and selling stocks.(7) Could dark patterns be playing a part in this as well? It's possible. It's even more worrying because it's a less visible process, and because you are dictating an action and that action requires choices that are now out of your control and in the hands of an algorithm that could have been biased in the company's favor.

With the popular trend of moving to subscription based models for nearly everything these days, billing and hidden costs are becoming the norm for users. The pain of paying up is only off-set by how much the user gets out of the service. The "shut-up-and-take-my-money" principle, lets services get away with some pretty devious things, like setting up accounts to automatically renew, or adding a service charge to handle payments or deliveries. Or just adding a fee because they can. The more popular a service, the more likely people will put up with fees and charges.

The use of dark patterns have ethical implications, whether for good or evil, whether on purpose or accidental, only the consumers can decide, with their voices and their money, what patterns are acceptable.

Accidental  Darkness

While speaking with Keaveny over Skype about her experience, a small revelation happened. It was possible her dark pattern, which certainly qualifies as a dark pattern, might have been also a localization problem. When you have a company that creates a feature to get more people to sign up for their service, using contacts and texting those contacts, if they are based in the US, this is a relatively a non-issue and generally doesn't cost most users. People in Europe on the other hand, could have contacts from multiple countries and texting those contacts could cost quite a lot compared to texting in the US. Knowing your audience and understanding the impact to that audience could avoid many issues that could evolve into a dark pattern, or even worse, a dark pattern with other impacts to service and usability. I would imagine that LinkedIn didn't set out to cause distrust by using a dark pattern. They were likely thinking of a quick way to help users gain more contacts on the platform. Unfortunately, not thinking about global implications could possibly have cost LinkedIn some mobile application users, but only they would know that.

A Working Example

Once you know what dark patterns are, they are easy to spot in everyday life. Here are a few tips to spot dark patterns in your own testing environment.

1) Defaults are probably the number one offender when it comes to dark patterns being utilized behind them. If you have a story with a default setting, gather information about what current uses are around that setting and why it's needed and what the drive for it is. Is it metrics? Is there a better way to get those numbers rather than using a dark pattern? Start the conversation with your team and find out if it's a good default or a bad one. Especially look at any checkboxes or radio buttons around Email settings, preferences, security settings, and even account settings. These are usually where defaults become dark patterns.

From a tech article on the web.

2) Ads are probably the second most used dark pattern. When ads are a large part of the revenue of free software, it's extremely hard to get management and product to not stick them in every nook and cranny they can find. Try to find some compromises for users if you can.

3) Read your EULAs! Important things could be hidden in the EULA. It's a pain, but it could save a lot more pain later, depending on how those EULAs were written. And sometimes you even find neat easter eggs in them.

A EULA from a game on the Steam network.

4) Read over the examples at! It has a pretty good list of patterns that are out there on the web, and even examples of offenders of those patterns. It's not just the little companies either. There are some big names out there.

5. (pg 39,41)

Sunday, June 26, 2016

Mentoring Women in Tech

Mentoring Mission - Women Who Code

Mentoring Women into STEM

This weekend was full of meetups and happenings. First, I worked on my course. I've made it to my first project, which is a tribute page. It's just HTML5 and CSS at the moment, but it's been a challenge even if it's mostly because of list orders and various formatting issues. I like it. It keeps me thinking about what I'm doing. It keeps me working with code and trying new things, even if it's copying from someone else and then modifying it to fit my own needs. 

The second thing that happened was another awesome meetup for Women Who Code. Holly Gibson is a co-founder of the local Austin chapter and they have 1800 members with 15 different meetups happening every month. It's a huge group that is doing awesome things for women in the Tech industry. Today was a meet-and-greet with the founders of MentorTex. ( 

Alan Chapa and Dave Jobe are passionate about working with women to develop mentorships for leadership skills and paths into the tech industry. They are currently on the hunt for a Female Senior Architect to build out their 1.0 vision of the platform they are hoping will bring women together to elevate them in an industry where female leadership is very much lacking. 

I don't think the platform will be exclusively for women. However, Dave gave a very passionate plea to get women involved in his fledgling startup. He's committed to achieving a staff ratio of 75 percent women. I was impressed with that alone. It's a huge commitment. I have no doubt he will achieve it. 

This initiative needs your help! If you are in Austin, or you know someone in Austin that could or would be a mentor, especially women, contact them via their website, or contact me. They are looking for clients, especially women in the Austin area, that are interested in STEM. While software development is a fairly easy focus, STEM includes other areas as well, so if you have a background in any field under the STEM umbrella, get in touch with Dave and Alan. If you think your company would be interested in being a sponsor and/or interested in working with this initiative, definitely get in touch with these gentlemen. 

In the last few months, mentors have been a huge influence for me. I have done things for my career that I never thought I had enough experience or knowledge to do. My mentors are currently all women who have successful careers and definitely understand the challenges I've been working through in my own career. There is a huge difference in my confidence and attitude because of my mentors. This is why I think this program is very important, especially for younger women, minority women, and women that are changing careers. Mentorships can be the difference between having a career and having a meaningful career. 

If you have a local Women Who Code group, join. Regardless of whether you code or not. As long as you are interested in code and want to learn, get involved. They have access to scholarships and the members range from beginners to senior developers. For me, it's been one of the most welcoming groups I have had the pleasure to be involved with. 

If you are local to Austin, check out MentorTex. Give the web address to women you know. And feel free to contact me for more information. Some of you that know me, know I have...opinions. And Dave was more than happy to get me involved in helping with this imitative. I feel strong enough about the importance of STEM and mentorships that I am going to try very hard to help him. If you are interested in working with Dave and Alan on the website, please contact them. Volunteer and part-time positions are available. Preference will be given to women for many of these roles.

If you are a woman reading this blog, and you don't have a mentor, or would like one, contact me. I'll see what I can do to point you in a direction. Like someone did for me. 

At this time I would like to thank my mentors: Marii Thompson, Lisa Crispin, Abby Bangser, Maaret  Pyhäjärvi, and Holly Gibson. Without these wonderful women, I don't think I would be where I am today.

Monday, June 20, 2016

Mel's Take-Aways: TestTalks Episode 100: Gerald Weinberg

"Adapt to what is rather than what it should be."

 - Gerald Weinberg

I listen to Test Talks by Joe Colantonio when I have some free time and need some inspiration. I think Joe has a great interview style that is easy to follow and conversational. These podcasts are not fluff pieces though. If you find yourself taking notes and stopping to re-listen to a segment, I wouldn't be surprised. I end up doing that just about every time.

The 100th episode isn't the most recent one, but it's where I left off from the last time I stopped by the page to give a podcast a listen. There were so many take-aways from Joe's conversation with Gerald that I felt I needed to write a blog post, and create a new section in my blog for just that.

Take-Away #1:
Stop looking for secrets to testing or developing or really anything. Get rid of things that are wasting time. Learn to love things you find boring about your job, find a way to love the boring things, then find an excuse to do it. 

This was the first 10 minutes of the podcast and this hit home for me in the most striking of ways. I find writing code, boring. There, I've said it, it's been my dirty secret for like, ever. However, fixing code, reading code, testing the guts of code or how the services that use code interact, that's the best mind candy I have ever had. I love testing. I love problem-solving. I am not exactly the most thrilled when I have to write code. (Admittedly, I don't do it that often.) It's a different kind of problem solving/making that I've sorta distanced myself from. And, that has created a weakness I'm working to address, not only because my ever-changing profession is pushing in that direction, but I am pushing myself as well, to adapt and move out of comfort zones and learn.

Take-Away #2:
Who's risks are you concerned about? Which risks take priority over others?

When you look at testing from this perspective, you can make a mind-map of risks (generic or otherwise) and really get to the point of these questions. You can not test everything. It's an impossible thing to do. But if you do your best, and your best includes a priority of risks for what you are testing then you can mitigate risk. If you are not testing with prioritized risks, you are not really testing.

Take-Away #3: 
"Name Magic." Calling it a leg, doesn't make it a leg.

Weinberg then goes on to mention that you can automate tests, but it doesn't automate testing. Colantonio then mentions a phrase from Richard Bradshaw to Weinberg which is: "Automation IN testing" (I capped and underlined the word on purpose for emphasis.) We should all be wary of buzz words and magic phrases that seem to promise more than they offer. Weinberg's reaction to Bradshaw's phrase is neat. Part of his response was: "A tiny change can make an enormous difference." 

Making a difference.
Colantonio asks about the "One piece of advice to improve their testing efforts" and I think Weinberg responded with the best response I've ever heard to that question. "The one thing you need to do to become a better tester is to discover the one thing they need to do to become a better tester." He tells a story about a body builder and then gives an examples in testing. Basically Wienberg points to finding and working on the weak points in your testing skills. "If you find yourself saying you don't need that skill, that's probably the one you need to work on."

The podcast was full of great things to think about and I only mentioned three that stuck out as things I've valued, but had never heard them stated in such a clear manner. Or if I had, it didn't make a huge impression the first couple of times. If you listen, I'm sure you'll find your own.

Thanks to Joe Colantonio  and Gerald Weinberg for a great interview. Check out the episode yourself at "Test Talks".

Wednesday, June 15, 2016

The Cost of Innovation: Influenced by the Movie "Spare Parts"

Lest everyone think I'm just a comic book movie fan-girl, I realized I need to expand my blog writing out to other movies, other genre, and discuss what I've learned from those. The movie "Spare Parts" hit me in the feels.

While I can't identify with being an undocumented immigrant in the US, I did identify with being the poor kid and trying to turn nothing into something.

When your organization doesn't have the latest and greatest, finding a way to make something out of nothing is a boon. Learning anything that could help streamline a process. Testing things and letting the results influence methods and practices is no small feat! But organizations need to be open to this kind of influence. I think the ones that are, typically keep more people and benefit from a healthy, diverse environment of thinkers. (Note that I used the word thinkers, not just testers and/or developers.)

The trap might be in looking at other organizations and seeing what they have and comparing it to yours. I've done this. I've thought this or that organization was doing was so much better and we should absolutely model those ideas and incorporate them ASAP! This kind of thinking can and does limit the creativity of your own organic growth. We should be sharing and learning on a regular basis, but if you rush to be like someone else, what have you lost in the process? A forced process is rarely maintained past the person who implemented it.

A friend reminded me the other day that while I might not be a wiz kid at writing code, yet, I'm still learning and I can still learn and continue to learn at my own pace and not push myself to know it all by tomorrow. Because A) That's not going to happen, and it's not realistic; and B) I rarely learn in a linear fashion. Pointing this out was something which I hadn't thought about myself. I don't typically pick things up and learn from point A to point Z. I've always seen the picture at a high level, like a puzzle and picked up pieces and popped them into place as I understood where they fit in the fabric of what I'm learning at the moment. Even later, when I'm learning something completely different, and a piece, hanging out on the fringe of the picture, didn't work in the big picture at first, suddenly falls into place because I was focused on something else and now understand the value of that piece from before. My creativity and my ability to look at the big picture and learn from these moments, when I need to, but maybe not at the pace others think I should, is completely me. And I shouldn't disregard this simply because it's not the norm or not at the skill level I see that others have. I need to be creative with what I do understand, and add to my skills as I can master them as the picture clarifies for me. I work with and find mentors and resources to help me incorporate my puzzle pieces. To build my big picture, or in the case of the movie, build my robot.

So how does this relate to the movie "Spare Parts" exactly?

These high school kids totally kicked ass because they dealt with being disadvantaged every day of their lives. They came up with cheaper, faster solutions than the schools with more money and time invested in the competition. They overcame a lot to create a robot, and while it wasn't the best, was exactly what was needed in the time they had to accomplish the task. They beat out MIT. Twice. Software development can follow these same principles. So can personal and career development.

Manage your defects, your people (which are people, not resources), your tech stack and your product with judicious efficiency. Don't go for the biggest shiniest thing because everybody else is doing it. The bleeding edge is called that because people bleed out there, on the edge, discovering issues and trying to staunch the blood flow caused by new code adaptations and the unexpected results from tech and languages that have very little foundation in the market place. There are some organizations that have the capital to do this and they lay the foundation for others, but that doesn't mean that the little-organization-that-could has to use it to stay absolutely relevant. But they shouldn't shy away from adopting new things either when it fits a need rather than a whim.

For those with a software development career, maybe the shiniest, latest JavaScript isn't the best thing to try to learn if you don't have a good foundation of code development. Maybe learning the latest in Data architecture isn't a good idea if you are still struggling with principles. Or maybe it is - only you can decide. Only you know what pace you can learn. Maybe your strengths don't speak to those things right now, but by doing something else, like speaking or going to meet-ups or mentoring others, you gain knowledge and access to those things and they fall into place for you.

Sometimes, you don't need the best, shiniest thing, right now, to do something new and innovative. Sometimes all you need is really clever people that can do some pretty amazing things with PVC pipe and tampons.

Sunday, June 12, 2016

Milestone Week - Speaking, Testing, Coding

Making Milestones Count

This blog has been more about writing up things I've found interesting or found connections between testing and stuff I enjoy. I want to take a moment though, even if it's for myself, and acknowledge some amazing things that happened to me this week.

On Monday, I spoke at a Women Who Code meeting about testing and how to learn about the "Testing Ecosystem" you live in. I received a lot of great feedback from my team members who heard the first version of the talk and from Abby (@a_bangser) and Lisa (@lisacrispin) who reviewed my slides and notes.

It was only supposed to be a 5-10 minute talk. I was the only speaker with a Dell laptop, so that took a few minutes to set up. I was speaking to a crowd of about 15 women, most of them recent to coding or a few years into their careers. While I was setting up, I asked if anyone worked with testers or had a dedicated team of testers. One person raised her hand, and I asked what it was like working with them. She said they were off-shore so she didn't get to interact with them much. My talk was over in about 15 minutes. I took some extra time since there wasn't a long list of speakers that night. The questions afterwards were awesome! I had answers! Mostly. (If anyone knows of a good unit test framework for React, let me know. I didn't know of one.) Questions like, what do you recommend we do if we don't have a dedicated tester? What unit test frameworks can you recommend? What could I use to test the API of my app? Believe it or not, I was able to answer all that. I kind of shocked myself in a way because I hadn't realized I had opinions or knowledge sitting in the back of my head that would be useful to people that really wanted it.

A colleague of mine, Maaret (@maaretp), speaks about not only talking with other testers about testing but also taking the message to developers and finding the support and encouragement to advocate for each other. I think she is absolutely right. I think when you reach across the cubical to the developer next to you, and work together, you can do some pretty amazing things. My short talk gave me all the proof I needed to see it in real-life practice. It was nothing short of an eye-opening, adrenaline charged, good will high that took me two days to come down off of. I think I do indeed have the public speaking bug, and that is mostly because of the mentors I mentioned above and peers who have encouraged me to do so.

Thursday, I met with Holly(@hollyglot), who is the organizer for WWCATX and we talked about testing and ideas for testing an app she was working on. I asked questions. SO MANY QUESTIONS. I didn't code, and she didn't code much either. It was a constant feedback loop of questions and answers, with me writing down a very basic mind map to get a picture and her fielding the answers to questions like it was a thesis defense. I do feel a little bad about that, but I think in the end, we came up with a strategy and more questions she needed to ask regarding requirements to make sure they could cover the system accurately. I think one of the very stand-out moments of that conversation was about the API and her desire to get a mock API working for her app, even though they had created one for the app in-house. She was having problems getting it to work but explained that the real thing was working great. I advocated testing with the real API instead. She was surprised for a moment, and I think a little disappointed since she wanted to get her mock API working. I explained that while I thought was she was doing was important and an awesome learning exercise, it might be easier just to test with the real API. The app nor the API are live yet, so there isn't much of a risk really. And they already had test data they had been passing through the API anyway. She reluctantly agreed and I shared her disappointment about not getting the mock working in enough time to be useful. I gave her the hopeful response of maybe she could get it working with the next project.

I left the coffee shop that night, pretty jazzed about the evening. It was a moment I approached feeling a little scared, thinking about what I could contribute to a project that wasn't just manual testing or really any kind of testing. I didn't even touch the app. I asked questions. We found answers, we discovered things together and I would like to think that awesome things happened afterwards because of it.

Actually, something awesome did happen, I got invited to a coding session on Sunday.

Everybody there had projects they were already working on, and I've been working through myself. I sat and worked through lessons. Chatted and worked and drank coffee and worked. Before I knew it, I was through four hours of work, according to the site, in about two. I stopped when I got to my first project assignment. Parts of the conversation were about coding techniques and differences in libraries and similarities too. Some of the conversations were about experiences and life in general. However, I accomplished something in those few hours, connecting the dots of understanding and having conversations with other women who code on a regular basis. It was a huge confidence booster. I may not be a coder for a living, but I understanding topics and I was holding my own in conversations. I get code. I get how it works and what it's doing, even if I completely suck at remembering syntax. (Hopefully someday I'll find some magical method for remembering different syntax for different languages, but thus far, it eludes me. I thank the internet for being there when I do have to look for these things.)

I feel I have taken a first step into a bigger arena, into a wider collaborative space where it's not just about metrics and test cases, but about community and the work itself. It's very exciting and it has me excited for what's next.

Thursday, June 2, 2016

Maximum Effort! - Deadpool Your Way Through Testing

When I first thought how the Deadpool movie could be tied to testing, I was taking the whole idea, even the movie, too literally. (There is a joke in there somewhere, I just know it!)  A scene in the movie, prompted this initial take on the direction of the article, but really wasn’t the “AH-ha!” I was hoping it would be about Exploratory Testing. (Though if you’ve seen the movie, which I do recommend, I still think my initial thoughts on Exploratory Testing might be entertaining.)

I mentioned this to my manager and he brought up a point that is now the basis of this article. (Thanks Heath!) Superheroes have powers of some kind, and Deadpool’s power, possibly his greatest power, is to break reality, break the fourth wall and talk to the audience directly. He can talk to his creators directly. He talks, a lot. The character is constantly communicating his flippant, sarcastic points of view to everybody regardless of where you exist. 

I’m not advocating being flippant and sarcastic at work, though if you have a good manager and team that you work with, they might appreciate it more than others. I'm also not advocating shooting your dev team when you find defects, even if that seems really tempting at the time. Mostly, the example I’m looking at here comes from a couple of perspectives. Deadpool is aware of his audience, aware that he is a character, and aware that he can affect things on multiple levels. This state is very similar to what a tester should try to achieve in their testing career. 

A tester should be aware of their audience, even when the rest of development focuses on the software or whatever is being created. The tester should know what the creation is, and be aware of how the audience will receive it. Testers should act as different characters within the development world. Whether this is the diplomat, the communicator, the user, the hero, the sidekick, the plot device; testers should be aware of what and even who they are in the process at that point in time and act according to that nature, then know when to break it, to play with it and even move on to a different character or persona. A tester should affect things on multiple levels. From the development stage, to the ship day, to the interaction with users using the product you helped create, or even a competitor’s product, you can affect how your environment takes things in, processes it and then project that back out to the world at-large.

Inside of the product, a tester should have a wicked set of skills to test their environment. While Deadpool knows he’s a character, he does have martial art skills, weapons skills, and tactical skills to help him deal with that environment. Deadpool is also versed in the latest and greatest of pop-culture, but still understands how history can play a part in current events. Testers should be creating their own tool box of things to build skills dealing with the environment they currently working in, and skills that keep a tester moving forward and current in on career path, whatever that might be.

I want to talk about the types of communication in Deadpool. The movie was communicating on so many different levels. Inside the environment of the movie, communication wasn't really important until Wade changed to Deadpool and those caused dynamic changes in the movie itself. From the constant dropping of Easter eggs to the fans and even to Ryan Reynolds fans, but also character dynamics where communication became important. This, to me, seems like a great example of a system under development, which once released, takes on a whole different life of it's own. Even the creator isn't in control any more. Deadpool is his own being. What's cool about Deadpool is that he can communicate back to his creator and influence the creator. Software does that on different levels with different people. Customers using the software communicate defects, change requests, usage issues, and outages, just to name a few. Developers can get feedback from tests and the code itself. Testers can gather all of these things and look at the bigger picture, investigate and then disseminate information as it becomes relevant.

While it might be nice to solve a defect with a bullet, unfortunately or fortunately, software development takes a little more finesse.  The industry is always in flux, always changing. Change with it. Take the opportunities to grow and become a bigger voice. Be the advocate for the story inside and outside the company you work for. Be an advocate for yourself, your team, and the customer. Be a Deadpool-like in your testing. Go break shit for the better.