SpringOne 2019 Links

Thanks to everyone who came to our Time to Good DX presentation!

Time to Good DX

We often hear focus on the customer, but what do you do when you
customers are your coworkers? Developers are the largest group of
individual contributors in software teams. It’s about time Developer
Experience (DX) got the focus it deserves! Devs are users, too!
Wouldn’t it be great if your user needs were met?

I know an hour isn’t enough time to delve deeply into this area, so here are some links to help you to explore this important subset of UX!

Articles

Time to Hello World and this

Drink your own champagne

API docs as affordance and this

Communication and this

Development pain points

Characteristics of good DX

Great APIs – heuristic analysis

Developers as a special case of users

Product management in platform products and in API products

API model canvas

(Vanilla UX)

UX personas

Presentations

Great DX in 5 minutes!

Platform as Product

More platform as product

DX Segments

DX Principles

DX Trends

UX tools for Developer users

Lean Enterprise

Reports

Developer Skills [PDF]

Podcasts

Don’t Make Me Code

Greater than Code

Tooling

git-utils

assertj-swagger

Examples of DX

Jest automation framework

Netflix DX

Faster deployment

Visualizing metrics

Stripe API docs

Twilio API docs

Open source triage

Apigee DX

Salesforce DX and this

Work Horde, Play Horde

I recently hosted a Magic-the-Gathering-themed tween party for 8 players.

Yes, you read that correctly. 8 players in a format I later learned is called Free-for-All (a.k.a. Circle). Little did I know that most MTG games were smaller, with an “epic” game being maybe 6 players… 🤦

While my husband did some excellent turn-based coaching for the new players – about half of the assembled – I noticed something essential was wrong. The kids were disengaged from the game unless it was their turn to play. Considering they’ve been rabid Pokémon fans, I couldn’t understand how they could completely check-out from a “grown up” monster beatdown game…

Then it dawned on me: the turn rotation was too long. The kids had enough time between turns to be restless from the sugaring-up and general high energy of being together outside of school.

This distraction is the same issue that I’ve seen with attempts at mob programming!

For any reasonably sized team (let’s assume <= “2 pizzas”) trying to mob program, short turns are essential. In fact, I’m not sure that group size figures into the turn duration calculation – short turns are just better!

How long is too long? For me, 15 minutes! Bias yourself to less than 10 minutes, preferably 2-5 minute turns. I’m aware that at-a-glance this feels absurd, but let me explain.

The basics of mob programming are 3+ people programming together at a single computer with 1 person directing the current activity, 1 person hands-on executing the current activity, and 1 person observing/commenting/contributing from the “mob” crowd seated around the computer. (In some descriptions, the “mob” may also be considered as part of directing the activity, but 1 person makes the decision about what to do/try next, so I prefer to differentiate between these roles.) Unlike strong-style paired programming, these roles are insufficient to be mob programming: for a mob, you must also have rotation!

As “circus performers” (a.k.a. mob programming facilitators) for Bryan & Bill’s Three-Ring Design Circus at deliver:Agile 2018, my pair Tim Ottinger and I instituted a 5 minute rotation schedule for our mob of conference session attendees (read: strangers). Our task was test-driven development (TDD) and refactoring of a sample programming project.

Short rotations encouraged:

  • low barrier-to-entry experimentation with TDD and mobbing
  • selecting and trying an idea quickly
  • refining communication patterns
  • collective ownership of goals
  • fast feedback

Tim and I were a bit more merciful with our 5 minute rotations in that we encouraged participants to continue the execution of the previous driver where another “circus performer” insisted on a fresh start (read: deleting code) when TDD automation wasn’t passing/green at the end of a 2 minute rotation (the hard-core strategy of one of our other performers). So much excitement!

In the workplace, over the years, I have participated in pseudo-mobs wherein a single programmer or a pair of programmers consult another team member on particularly challenging aspect of a programming problem. Often, this results in another programming team member chiming in with insight or advice and now we have an amorphous gathering around a single programming work station where the work is being implemented. This is even more likely when the consulted team member is also paired programming (i.e. 2+ pairs collaborating on a complex issue in the code).

While pseudo-mobs definitely help with resolving an issue, we miss out on some of the benefits of the mob structure:

  • explicit statements of intent through navigator-driver pattern
  • everyone having hands-on time implementing a solution
  • everyone directly participating in the decision-making and experimentation
  • single piece flow / avoiding merge conflicts (since only 1 unit of work in-progress)
  • novice or new team members developing shared understanding and receiving training opportunities from the explicit exchange of multiple points of view and potential solutions

Now back to the Magic game! Upon reflection, how would I have changed the game play to optimize for faster turns/better rotation?

The common wisdom seems to be smaller groups for quicker decision-making and turn progression, e.g. 2 player (1v1) games or team play (e.g. 2-headed giant, emperor).

I could also imagine a simplification of rules for younger/newer players to lower the barrier to entry…

Upon further investigation, I discovered a co-operative format for MTG: Horde Magic!

All the players form a group working to defeat an automated “horde” deck. The team members all take their turn together to attack and block. (This reminds me a lot of the mob programming format with a product team assembled to “defeat” a difficult software problem.)

In Horde Magic, if some aspect of game-play isn’t fun or isn’t working well within the rules, the team members come to a consensus as to what works best for them. (The mob can iterate on their working agreements as they work through the problem in order to work more effectively together.)

Given what I know so far, I’m looking forward to trying some new things, both at work and at play. Having a good mobbing experience takes a bit of planning and some skillful facilitation, but it’s the game for everyone!

Attending to networks

Martin Grandjean [CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0)]

I have been following Esther Derby with interest for years. I find her wise counsel refreshing and I admire her ability to connect deeply with attendees at conferences and training sessions. You can imagine my excitement upon finding her new book 7 Rules for Positive, Productive Change in my mailbox!

I sat down that evening and applied my customary approach to getting the lay of the land: starting with the index and moving backward to the table of contents. I had one major problem: I kept getting caught on helpful diagrams and interesting anecdotes. Still, I managed to charter a line of inquiry that led me to deep-dive in several parts of the book: networks of relationships in organizations and how they influence the success of change. I didn’t realize how long I’d been at reading up on Rule 4 until I looked up to see it was past midnight!

I love the idea of change by attraction. Change that people want to be part of is the kind of change I want to be an agent of. As I’ve previously written, I have sometimes seen an attitude of “not invented here” that corresponds to the “It won’t work here” argument that Esther’s approach debunks. Experimentation within the walls produces examples of what can work in this context.

I agree with a heuristic approach to figuring things out, so I wondered about the “rules” part of this book’s title. Happily, Esther recognizes that these rules are for “learning and problem-solving, especially when a bit of trial and error is involved… when there isn’t an obvious path.” Accordingly, I found helpful heuristics to guide my questioning when trying to understand how to help others with change.

In particular, I’ve become quite curious about the informal networks that quickly spread ideas, the people “whose opinions are trusted and respected and whom people go to for advice.” I couldn’t help geeking out about the graph theory aspects of the organizational network analysis (ONA), but strategies to “reshape the network to make it more useful both for sharing information about the teams and for sharing ideas and expertise” really got my attention. So I ordered a spare copy of this book to share with my local network.

I’m already thinking up different experiments that I might try to increase information sharing and connectedness of communities, both at work and among professional contacts. Now that my initial investigation has been fruitful, I’ve switched to working my way methodically through each page of the 7 Rules for Change and it’s helping me to sort out and prioritize those potential interventions. Providing more serendipity and more informal opportunities to connect with each other matters to me – and I’m so glad to have Esther’s insights to help guide my exploration. As she says, “Heuristics point a way, and methods and models guide action.”

DevNexus 2019 links

Thanks to everyone who came to our Time to Good DX presentation!

Time to Good DX

We often hear focus on the customer, but what do you do when you
customers are your coworkers? Developers are the largest group of
individual contributors in software teams. It’s about time Developer
Experience (DX) got the focus it deserves! Devs are users, too!
Wouldn’t it be great if your user needs were met?

I know an hour isn’t enough time to delve deeply into this area, so here are some links to help you to explore this important subset of UX!

Articles

Time to Hello World and this

Drink your own champagne

API docs as affordance and this

Communication and this

Development pain points

Characteristics of good DX

Great APIs – heuristic analysis

Developers as a special case of users

Product management in platform products and in API products

API model canvas

(Vanilla UX)

UX personas

Presentations

Great DX in 5 minutes!

Platform as Product

More platform as product

DX Segments

DX Principles

DX Trends

UX tools for Developer users

Lean Enterprise

Reports

Developer Skills [PDF]

Podcasts

Don’t Make Me Code

Greater than Code

Tooling

git-utils

assertj-swagger

Examples of DX

Jest automation framework

Netflix DX

Faster deployment

Visualizing metrics

Stripe API docs

Twilio API docs

Open source triage

Apigee DX

Salesforce DX and this

Keep your options open

Tags

, , , , , ,

In DevOps, there’s a pervasive theme of automating toil, which many would say contains all of testing. I’m just gonna say it: I come from the testing community. We’re people who constantly look for things we haven’t seen yet, who collaborate across roles, who explore the unknown, and who care about doing the right thing. Does that characterization surprise you? Yes, testing is complex enough to be a viable career and not just a thing we do until we can script it for a computer to execute.

So when I reached my limit of “X is going to kill Y” (in this case, DevOps and the testing profession), I finally went for it and joined a DevOps team as an agile tester. I wanted to see for myself that DevOps was the cultural sea change that would make my job role obsolete. If giving up my vocation was the right thing to do, I wanted to be ready with a deep understanding of the value of the new practices and to embrace the mindset shift. I wanted to be ready to bring others along with me on my voyage.

Free electron
Free yourself, electron!

When I attended DevOpsDays Atlanta 2018, I didn’t know what the community would be like. Sure, I’d helped to review their proposals as part of the program committee, but who would I meet who would change me for the better? It was my first time hanging out at an event for people who might identify as “operators” instead of just “developers.” Would they welcome me, a person without any operations background?

Inclusive collaboration wasn’t just the theme of the conference: attendees and speakers shared their authentic selves and wholly embraced it.

Although my discernment of future direction is ongoing, I see as much diversity of thought in DevOps as in agile. The afternoon unconference was my favorite experience! This format is less structured, as you might expect from the name, allowing for free-flowing conversations that address the most current burning questions of the attendees. I found operators wrestle with similar collaboration conundrums. My questions and concerns found ready listeners and new proposed solutions (in addition to new questions!). This diversity of thought helped to open up my perspective on what is possible.

Collaboration with people from diverse backgrounds and viewpoints is a competitive edge. It’s also the right thing to do. We want to keep our professional and organizational options open. Distinct perspectives provide a greater ability to handle the breadth of competitive situations we face. We need new voices and different perspectives to make change possible.

I’m particularly excited about the possibilities this year in bringing 3 communities together! Whether you’re someone looking to refine your role in the context of today’s accelerating software delivery cycles or just curious about how much DevOps, serverless, and (Wardley) mapping enthusiasts have in common, this year’s event is for you!

Our call for proposals ends February 28th (that’s today, procrastinators!), so there’s still time to share the unique experiences that only you can bring, whether through a 30 minute session or a 5 minute ignite talk. If you prefer to attend and then propose topics on the fly like I do, the afternoon unconference provides that space for emergent value.

Let me assure you that constant learning isn’t easy! Change is hard – and worth it. I expect the supportive environment I’ll find at DevOpsDays Atlanta / serverless days Atlanta 2019 / Map Camp 2019 is exactly what I need to just keep swimming. We could all use some help staying afloat.

Minimum Viable Product Manager

At Agile2018, I attended Richard Seroter’s Product Ownership Explained session, where I heard about bad and good product owners. Product ownership/management has many facets including

  • advocating processes and tools
  • style of leadership
  • customer interactions
  • relationship with engineers
  • approach to continuous improvement
  • product lifecycle perspective
  • sourcing backlog items
  • decomposing work
  • running through a sprint
  • meeting involvement
  • approach to roadmap
  • outbound communication

Now I’ve been working alongside many customer proxy team members (e.g. business analyst, product owner, product manager) over the years. I’ve learned how to create testable, executable, deliverable user stories in a real-world setting. I wasn’t going into this talk blind. I just haven’t always focused on the Product role.

This time, I looked at the role with the mindset of what it would take for me to check all the boxes in the “good” list. As each slide appeared, my list of TODOs lengthened. I started to feel overwhelmed by the number of things I wanted to improve…

“How you doin’, honey?” “Do I have to answer?!?”

I walked out of that talk thinking I’m not sure I want to sign up for this epic journey. The vision of the idyllic end state was more daunting than inspiring. How could I possibly succeed at this enormous task? Would I want to sign up for that? My initial reaction was no! How could I take on all the technical debt of stretching into a new role like Product? How long would the roadmap to “good” take?

Analysis

When I evaluate things off the cuff, I often consider good-bad-indifferent. Maybe knowing what “good” and “bad” look like wasn’t helping me. I knew I didn’t want to be merely “indifferent”… maybe what I really wanted to know was this:

What does a minimum viable product manager look like?

One of my big takeaways from Problem Solving Leadership (PSL) with the late, great Jerry Weinberg was limiting work in process (WIP) or “one thing at a time” (as close to single piece flow as possible) improves effectiveness. If I take that approach to a PO/PM role, I’m afraid that I would completely fail. So I will reduce the practices to as few as I possibly can without completely losing the value of the role. I want only the *critical* path skills or capabilities! Everything else can be delegated or collectively owned or done without. So what can I discard?

In this thought experiment, I’m proposing finding the least possible investment in each essential aspect of the PO/PM role that would move from bad past merely indifferent to viable (but only just!). I needed to reduce my expectations! If I allow minimum viable to rest somewhere in my default scale, then it fits between indifferent and good. That means I deliberately do *not* attempt to inject all of the good practices at once. So let’s revisit the axes of expertise and the lists of behaviors that are good and bad…

What’s the least I could do?

Decomposition

Advocating processes and tools

Good: contextual & explanatory & collaborative (fitting process to team + pragmatic tool choices + only important consistency + explains process value + feedback leading to evolving)
Minimum viable: pragmatic minimalism (choose a simple process & let practices earn their way back in as value is explained + choose an available tool + allow consistency to emerge + request feedback)
Indifferent: status quo (follow existing process/ceremony w/o questioning + let others choose tools + don’t justify)
Bad: dogmatism (one practice fits all + adhere to ceremony + prescribed toolchain + standardization + trust process + don’t justify)

Style of leadership

Minimum viable: leads by example (models behaviors for others without trying to modify their behaviors) + doesn’t worry about respect + consultative decisions + experiments/loosely decides + sometimes available to the team but not constantly + flexible + defaults to already available metrics

Customer interactions

Minimum viable: meets with customers at least once + builds casual relationship with a key customer + gets second-hand reports on Production pain + occasional customer visit + default information sources

For me, this one slides a bit too far toward indifferent… I’m not sure how little I could care about customers and still get away with being acceptable at PO/PM…

Relationship with engineers

Minimum viable: physically co-locates when convenient + T-shaped when it comes to the technical domain (i.e. aware but not trying to develop that skill as an individual contributor) + attends standup + shares business/customer/user information at least at the beginning of every epic + champion for the product & trusts everyone on the team to protect their own time

Approach to continuous improvement

Minimum viable: default timebox + takes on at most 1 action item from retrospective, just like everyone else + plans on an ad hoc/as needed basis (pull system) allowing engineers to manage the flow of work to match their productivity + prioritizes necessary work to deliver value regardless of what it’s called (bug, chore, enhancement, etc)

Product lifecycle perspective

Minimum viable: tweaks customer onboarding in a small way to improve each time + cares about whole cross-functional team (agile, DevOps, etc) + asks questions about impact of changes + allows lack of value in an existing feature to bubble up over time

Sourcing backlog items

Minimum viable: occasionally talks to customers + cares about whole cross-functional team (including Support) + backlog is open to whole team to add items that can be prioritized + intake system emerges + tactical prioritization

I do have twinges about the lack of strategy here, so I guess I’m looking at this part of minimum viable Product *Owner* (i.e. the mid-range focus that Richard points out in his 10th slide).

Decomposing work

Minimum viable: progressive elaboration (i.e. I need to know details when it’s near term work and not before) + thin vertical slices and willing to leave “viable” to the next slice in order to get a tracer bullet sooner + trusts the team to monitor the duration of their work & to self-organize to remove dependencies (including modifying story slicing)

Running through a sprint

Minimum viable: doesn’t worry about timeboxes (kanban/flow/continuous/whatever) + focus on outcome of each piece of work (explores delivered value) + releases after acceptance (maybe this is just continuous delivery instead of continuous deployment, depends on business context)

Meeting involvement

Minimum viable: collaborates with team members to plan as needed (small things more often) + participates in retrospectives + ongoing self-study of PO/PM

Approach to roadmap

Minimum viable: priorities segmented by theme + roadmap includes past delivery/recent accomplishments + adjusts communication as needed/updates for new info + flexible timeline in a living document + published roadmap accessible to all stakeholders on self-serve basis

Outbound communication

Minimum viable: allows org to self-serve info + shares priorities with manager & customers + environment for continuous self-demo/trying features + transparency

What are the minimum viable versions of the tools of a product owner?

  • Backlog – list of ideas not fleshed out until it’s time to run them
  • Sprint planning – ad hoc meetings in a pull system initiated by the need for work definition to execute
  • Roadmap – technical vision of system capabilities + compelling story of the product value proposition
  • Prototyping, wireframing – whiteboard pictures + text-based descriptions
  • Team collaboration – a big TODO list that everyone can access
  • Surveying/user testing – chat program that both team & user can access
  • Analytics – NPS score informally collected from customer conversation
  • Product visioning – I think this goes in with Roadmap for me?

So I’ll agree that the PO/PM role is critical and necessary. I would like for creative problem solvers to fill the role – and to be fulfilled by the role! In order for that to be viable, for people to grow into a Product role, there needs to be education on how to begin – and it can’t be spring-fully-formed-from-the-head-of-Zeus! Christening someone PO/PM doesn’t endow them with sudden wisdom and insight. Skill takes time to develop.

Set realistic expectations for beginners. Help teams to welcome people to grow in the role by offering both challenge and support from all the team members. As with any team need, the agile team has collective ownership to solve the problem, not relying on a single point of failure in the role specialist. Having a beginner PO/PM is an excellent time to reinforce that!

Don't worry, people. I so got this!

If I were a Product Manger, I would definitely prefer to be a full-featured representative of that specialization! However, I encourage you to revisit Richard’s presentation and do your own decomposition of the Product role. What is absolutely essential? What can you do without?

What is *your* minimum viable Product Manager?

Agile2018 links

Here are some sources to dig in more after my Agile2018 session Everything You Wanted To Know About DevOps But Were Afraid To Ask:

Slides & Handouts

Abstract:
As a career software tester, I’ve heard rumors DevOps culture will put me out of a job, so I took a job testing for a DevOps team. I’m new to DevOps, but aren’t we all? What matters most is our teams’ intentional decisions to grow our DevOps practices along with our development community.
Join me as I share my experiences blending disciplines, companies, levels of experience, and differing expectations as a member of efficient and effective delivery teams. I’ll describe common cultural and interpersonal problems I experienced while transforming a cross-functional agile team dogfooding a DevOps implementation.
Whether you’re into development, operations, testing, customer support, or product ownership, you’ll leave with concrete strategies for improving your DevOps working relationships to keep the technology running smoothly. People factors strongly affect your DevOps technical outcomes, so optimizing your flow includes improving your people practices.
Don’t feel afraid to ask about DevOps anymore!

Learning Outcomes:

  • The people factors that strongly affect your DevOps technical outcomes
  • How to blend teams from different companies
  • To sort through process and role differences
  • Apply the Agile mindset in support of DevOps

 

Other DevOps sessions from Agile2018

AppSec in a DevOps World

DevOps Metrics 101

Software & Pipeline Architecture for Continuous Delivery

Principles of Self-Service Infrastructure

Evolutionary Cloud Infrastructure

The Twelve-Factor Pipeline

“Three Ways” of DevOps

Creating Chaos … Engineering

Blameless Continuous Integration

Continuous Delivery & Testing

Bonus: old presentation from Agile2017: DevOps Explained

Sources I found useful when preparing for this talk:

Books

book Accelerate

book The Phoenix Project (business parable), which calls back to Industrial Engineering business parable The Goal

book Lean Enterprise

book Continuous Delivery

book The DevOps Handbook

book The Site Reliability Workbook (free download right now!)

eBook: Katrina Clokie’s A Practical Guide to Testing in DevOps

Podcasts

DevOps Defined

 

Audio

Beyond the Phoenix Project audio series

 

Videos

7 min intro

DevOps: Who Does What?

DevOps is Dead

Deep dive into container security w/Elissa Shevinsky

All Day DevOps 2017

 

Events

DevOpsDays Atlanta

 

Blogs

BizDevOps

Chef DevOps

DevOps is Dead: Rugged Enterprise DevSecNetQAGovOps

Bridging the Gap between Dev & Ops

IT Infrastructure Agility

DevOps Silo

DevOps user stories

Westrum model + organizational culture & safety

Deployment pipeline

High Performance Practices [PDF]

Continuous Testing

DevOps Odyssey

DevOps for Execs

Notes from The DevOps Handbook + More notes + Even more notes

Small-scale DevOps

DevSecOps

DevOps 2018

What is DevOps? + a different What is DevOps?

CALMS framework + Framework & practices

DevOps conversation

 

Specifically to dig into background for the DevOps personas I created:

What kinds of variables are useful to represent in personas? Persona-based testing + Persona variables + Pragmatic personas

Gartner on DevOps persona

Presenting pipeline data for DevOps personas

User stories for DevOps

SRE vs DevOps

DevOps Revolution

Who Does What? Part 1 + Who Does What? Part 2

Agile Testing Days USA links

Here are some resources we’re using in my Agile Testing Days USA workshop Refactoring Test Collaboration

Slides

Abstract

Collective ownership for testing starts with understanding testing. Rework your team dynamics to evolve past duplication and improve performance through whole team testing. Take home practical patterns for improving your team’s collaboration on testing. Because teams who own testing have more confidence in the customer value of their results.

As the Pragmatic Programmers say, “refactoring is an activity that needs to be undertaken slowly, deliberately, and carefully,” so how do we begin? In this session, we will experience the complex interactions of an agile team focused on demonstrating customer value by answering a series a questions:

  • Where do testers get their ideas?
  • How are you planning to accomplish this proposed testing, tester?
  • Why not automate all the things?
  • Who is going to do this manual testing and how does it work?
  • How do we know whether we’re testing the right things?

Build your own list of TODOs from these various practical collaboration approaches and begin deduping your team’s testing for a better first day back at the office.

Key-Learning

  • Approaches to handle objections to executing the testing work
  • Ways to mentor test helpers, including pairing
  • Investing in testing the team believes in
  • Understand how other team members have been testing the work so far
  • Advising on opportunities to inject test thinking into all of the team activities, from story writing through to unit testing, to make the system more testable

Resources

Refactoring

Collaboration + failing at collaboration

WHOSE testing skills + Exploratory testing + Elisabeth Hendrickson’s Test Heuristics Cheat Sheet [PDF] + book Explore It!

Agile Manifesto

Walking Skeletons, Butterflies, & Islands + my blog post elaborating on the conference

Big Visible Testing + my blog post elaborating on the presentation

Testing pyramid + critique of the testing pyramid/alternatives

Extreme programming lifecycle

eBook: Katrina Clokie’s A Practical Guide to Testing in DevOps + Role mapping

Westrum model + organizational culture & safety

Linda Rising’s change patterns & books on Fearless Change

Deployment pipeline

High Performance Practices [PDF] + book Accelerate

Continuous Testing

Empathy-Driven Development + empathy practices

Many interactive aspects of my workshop were inspired by Sharon Bowman’s book Training From the Back of the Room

facilitation book Collaboration Explained

metrics book Measuring and managing performance in organizations

book Testing Extreme Programming + some follow-up thoughts

Soon to come! Claire Moss on Let’s Talk About Tests, Baby podcast

deliver:Agile2018 Links

Here are the links we’re using in my deliver:Agile2018 workshop Beyond Waste: Exploratory Testing Charters in Action

Slides

Abstract:
Think manual testing is waste? Think again! If you’re not learning when you’re testing, you’re doing it wrong! People exploring systems can be your best defense against unknown problems and your greatest way of finding unexpected opportunities.
While automation is well adapted for repeating the same thing over and over again, human beings are great at doing things differently.
Doing is not enough! We need to think during our review and examination processes to improve outcomes. How do we design manual exploration to provide value in today’s fast-moving development culture?
Come to this workshop for hands-on experience with the full lifecycle of exploratory testing charters.

Learning Outcomes:

  • Structuring manual exploratory testing for transparency
  • Charter guidance during test execution
  • Outcomes of exploratory testing
  • Value delivery through debrief of testing session

Elisabeth Hendrickson’s Test Heuristics Cheat Sheet [PDF]

Which world do you prefer?

UI: https://xkpasswd.net/

UI: http://correcthorsebatterystaple.net

UI: http://password.optionfactory.net/

NodeJS: https://github.com/fardog/node-xkcd-password

Ruby: https://github.com/rasmus-storjohann/xkcdpass

Python: https://github.com/redacted/XKCD-password-generator

Shell: https://github.com/danielmcgraw/xkcdpass

PHP: https://github.com/cesarzavala/xkcd

Perl: https://github.com/CS-CLUB/xkcd-936