Saturday, January 18, 2020

Say It Out Loud - it's Testing


Sitting in front of they're computer, with a focused expression on their face, the tester is testing a new feature. Armed with their notes from all the whiteboard sessions, from design review and passing by comments of what we're changing and whatever requirements documentation they have, they've built their own list of functions they are about to verify that exist and work as expected.

"Error handling" says one of the lines in the functions list. Of course, every feature we implement should have error handling. Into the user interface fields where a sum of money is expected, they type away things that aren't numbers and make no sense as money. With typing of "hundred" being ok'd and just saved away to be reviewed later, it is obvious that whatever calculations we were planning to do later to add things up will not work, and armed with their trusty Jira bug reporting tool, they breathe in an out to create an objective step by step bug report explaining that the absence of error reporting is indeed a bug.

Minutes later, the developer sharing the same room just pings back saying the first version did not yet have error handling implemented. The tester breathes some more.

---
The thing is, errors of omitting complete features are very common finds for us testers. Having found some thousands of them over my tester career, I'm also imagining I see a pattern. The reactions to errors of omitting complete features very often indicate that this did not come as a surprise to the developer. They were giving you a chance of seeing something they build incrementally but weren't guessing *you* would start your testing from where they would go last in their development.

A Better Way

When you build your lists of functions you will verify, how about sharing your lists with the developer. Having a discussion of what of these they expect to see work would save you a lot of mental energy and allow you to direct it to their claims, going deeper than just the function. With that list, you would most likely be learning with them that "Error handling" for this feature won't yet be in the Wednesday's builds, because they planned on working on it only from Friday on.

You could also ask in a way that makes them jump into showing you where the function is in code. Even if you did not understand code, you understand sizes of things. Seeing something is conceptually one block of code, another one is sprinkled around when they show it, and something is very big and makes you want to fall asleep just looking at it are all giving you hints on how you would explore in relation to what your developer just showed you.

If you read code, go find some of that stuff yourself. But still, drag your developer into the discussion as soon as you suspect something might not be there.

Code Reviews vs. Testing

When organizations review code through for example pull requests, errors of function omission are hard ones to spot without someone triggering this particular perspective. If you have a list of things that you expect to see implemented and one of them is missing, there is no way that functionality could end up working in testing.

Sometimes, when you have a hunch of something that was discussed in the design meetings being forgotten from the implementation, the way to go about figuring it isn't to install and test - it is to ask about the feature. Say your idea out loud, see a developer go check it, and learn that something not implemented has no chance of working.

Jumping always to testing isn't the only tool you have as a tester, even if you didn't write (or read) code.

Sunday, January 5, 2020

Hundreds of hours Mob Programming over Four Years - Is it Still Worth It?

With four years mob programming (and testing) with various groups, I feel it is time to reflect a little.
  • I get to work with temporary mobs
  • I often teach (and enable learning) in a mob
As people have spent majority of their careers learning to work well apart, supported by other people, learning to work well together is something I cannot expect as a new mob comes together. 

Mob programming is a powerful learning tool. It has helped me learn about team dynamics and enabled addressing patterns that people keep quiet and hidden. It has helped me learn how people test, how different skillsets and approaches interact, and come to appreciation that it is totally unacceptable way of learning and working for some people, uncomfortable for others while some people just love it. Most people accept it for the two days we spend together, but would opt out should the mechanism find its way to their offices. 

One thing remains through the four years - people are curious on how could five people doing the work of one be productive. What does it really mean if we say that working together, at the same time, we get the best out of everyone into the work we're doing? 

Contributing and Learning

There's two outputs of value for us working, individually or in a group. We can be contributing, taking the work forward. Or we can be learning, improving ourselves and being better solving work problems better later on. 

Contributing enables our business to distribute copies of the software we are creating, and and in short and medium term, it scales nicely in value if we manage to avoid pitfalls of technical debt dragging us down, or building the wrong things no one cares to scale. There's a lot of value in not just delivering the maximum contribution over a longer period of time, but being able to turn an idea into software in use fast. Delivering when the need is recognized rather than a year later, and distributing copies of value in scale for an extra year turns into money for the company. We're ok paying a little more in effort as long as the we receive more in the timeline of it paying itself back. 

Learning enables the people to be better at doing the work. And as the work is creative problem solving, there's a lot of value seeing how the others do things in action to help us learn. Over time, learning is powerful. 
If my efforts in learning allow me to become 1% better every single day of the year, I am 37.8 times the version of myself in a year. That allows for a significant use of time today, to continuously keep things improving for the future me. 

There's a lot of value in contributing effectively to having the best work from us all in the work we are doing. Removing mistakes when they are being made. Caring for quality as we're building things. Avoiding technical debt. Avoiding bottlenecks of knowledge so that support can happen even when most of the team is on a vacation and just the little me is left to hold the fort. 

Mob Programming helps with this. And it helps a lot. 

Question Queue Time

Have you ever been working away with something, and then realize you need a clarification. It's that busiest person in your team who at least knows it, but since they are the busiest, you will take the minute to type in your problem to a team chat hoping someone answers. Sometimes you need to wait for that one busiest person. With a culture like ours, responding to others pulling information is considered a priority, and others stop doing what they were doing to get you to an answer that is not immediate.

If getting that answer takes you 10 minutes, it takes 10 minutes for someone else too. With that chat channel, probably it takes 10 minutes for a lot of people to think about, including the ones curious on the answer they too find themselves not having (but also not needing right now). 

If they put that question into an email, the wait time is more like a day. And the work waits, even if other work may happen. 

If your mob includes people with the answers, getting to a place where you have no question queue time could be possible. 

It's not just the questions through. It is any form of waiting. Slow builds to get to test. Finding a set of tools when you need it. Getting started for a new microservice. Discussing rather than trying. 

When the whole mob waits, the wasted time is manyfold. This seems to drive groups to innovate on the ways they work, and take time to do work that removes the wait time in places where individuals suffer in silence, mobs take action. 

If a mob works with something boring, they often end up automating it. If a mob works with something an individual alone has hard time solving, they get it done. And usually they get it done trying out multiple approaches, deciding through action what way they do things. 

What I find though that even in mobs, we don't have all the answers. For my work, the over reliance on waiting for an answer we already had confirmed by a product owner lead us to no product owner - just to emphasize that we don't need to wait for an answer as waiting costs just as much as potentially making a mistake. Removal of product owner revealed that there are answers not available from a person, but ones that require a discovery process. 

Growing Your Wizard

Mobbing is a challenge, but also rewarding. It has amplified my learning. Knowing it exists and not being able to use it, I look at the juniors who learned a lot but not as much as they could if we were mob programming as a wasted opportunity to optimize for the convenience of our seniors. 

We need to help our different team members level up to find their unique superpowers. We need to grow our wizards, and not just expect them to somehow either get through or give up trying. And answering their questions when they don't know what they don't know is just not enough.

In four years, I haven't ended up with a team that would try mobbing for a significant portion. The year of once every two weeks in my previous place of work is the furthest I got with a single team. But I have spent hundreds of hours mobbing, and even if I have more to try, I have learned a lot on how to get started



Saturday, January 4, 2020

Tester Superpowers

In August 2019, on a lovely day after the Conference for Association for Software Testing (CAST), a small group of people got together for a day to discuss Exploratory Testing. As second in the series of Exploratory Testing Workshops, I today remembered the piece that excited me most to learn in this one. I learned that testers have insightful and unique ways to describe what they do at work that seems to surprise people and make them unique. We called them Superpowers, and I collected what I could in tweets, recognizing commonality to what I find myself doing.
Synthesis is about information collection, pattern creation and use of information in ways that are surprising. Testers, with their cognitive focus on digesting and sharing information, become knowledgeable on the products and decisions. It is not the same as having good memory, but a very selective memory to collect pieces that turn useful later.
Holding space is a superpower I dedicated a talk into at TestBash NL some years back, coming to the realization that sometimes quality and testing happens by just having me in the room. The holding space for people may be slightly different than holding space for themes. The idea that we don't only focus on the negative but build people (because people build quality) as their colleagues is a powerful one.
Listening sounds easier than it is. Hearing beyond words, getting to what people mean and how that connects in time with other things people say is an information intake method crucial for action. We don't listen to respond, we listen to learn. Much of what we listen to requires later processing for the learning to emerge - the connections are both in the moment but also over time.
Structuring is seeing patterns and not only keeping the learning about patterns to yourself, but digesting it for others. Reporting in testing is based on finding ways of explaining things that are complex, but still explaining them in an actionable way is possible.

With a small group, I wrote down only a few - and not my own one. Months later, I can't remember what I said in the round of describing our superpowers, or if I was using my to scribe things for further analysis. What's your superpower?

Friday, January 3, 2020

More Words is Better Than Less

Recently, I've found myself teaming up on Agile Alliance initiatives Seb Rose is facilitating.

Agile Alliance is not big in popularity in the speaker fairness circles. They would seem to make quite a lot of money from the big Agile conference in the US, and only pay hotel not travel or honorarium to their speakers. They're established. They draw thousands of people. Feels unfair. Add the "agile" with no support for pair presenting where the second presenter needs to even buy a ticket for the event to come speak, it's fair to state there's unhappiness around these choices.

On the other side, Agile Alliance has helped new conferences get started (remembering them fondly for support in starting European Testing Conference on its 1st year), support a lot of local chapters and meetups, and probably are of a size that needs paid stuff to run in the first place. There isn't that many other sources of financing, so they might need to make some (even if on the expense of speakers) from their big conference.

All of the financials are speculation. I have absolutely no visibility on where they make money and where the money goes, other than the few friends I know rightfully benefit from their support making the world a better place and that alone earns a little bit of my respect.

Around end of the year 2019, Seb Rose shared the news of two initiates he was preparing for Agile Alliance around changing the face of speakers in Agile 202x conferences.

The first initiative was a one time experiment of handing out a lump sum of money to pay speaker expenses under a diversity flag for Agile 2020 conference. This 25k could enable new and seasoned voices that were unable/unwilling to make their voices available without the travel compensation to add to diversity (in the large definition of it).

The second initiative that was very clearly a match for what we do with TechVoices was on mentoring new voices, with the idea that this initiative would be a continuous one for multiple conferences. Without skipping ahead beyond Agile 2020, as experimenting with approaches seemed like a smart thing to do.

As I have my perceptions of what these programs are and I am not writing in Agile Alliance official channels, I thought I'd use more words to explain what these are and why I believe they are a good thing.

The Diversity Initiative

A few days ago, I saw this launch and today I tweeted in support of this initiative:
I love the step. I don't love how the invitation reads, and have provided ideas on how to improve it. While it has not been improved, imagine it saying something like this.

Agile Alliance allocated a lump sum on 25 000 dollars for diversity initiative led by Seb Rose. Seb is lovely and really cares for this stuff. The initiative is an experiment to figure out the reality of what the Agile 2020 conference could be getting if they were paying the speaker's travel (and other participation preventive) expenses against receipts.

This initiative is to seek those voices that really are unavailable for this conference as per financial constraints. Getting listed gives us a feel of scale of the problem and a mechanism to help some portion of these.

There are still two parts: get listed for financial limitations diversity initiative AND submit your proposal. Give us a chance of considering your great content part of the Agile 2020 program. Here is where you can join on making your appearance financially conditional: https://www.agilealliance.org/agile2020/agile-2020-speaker-diversity-initiative 

The lump sum is limited, and the impact we'd love to make with this money is changing the face of speakers in Agile 2020, even if just a little bit. There are people who quietly (or loudly) can't join a Pay to Speak conference and the reasons for this are many fold. A working  theory is that people in particular groups might be hitting financial constraints, making their voices unavailable in proposals where acceptance would have a financial implication.

It is clear 25 000 dollars will not be sufficient for all Agile 2020 speakers (I believe there is over hundred of them) and organizing all of this dependency to finances needs to somehow fit together with multitrack multichair Agile 2020 Call for Proposals process. The chairs cannot deal with distributing responsibility of this initiative on top of what they already do. So the proposals need to come in normally and we need to experiment with this on the side.

Registering for this initiative tweaks the usual proposal as little as possible. If you registered with this program, you are saying it is ok to bundle together your financing decision according to diversity prioritization and decision on your paper's acceptance. Your paper could be great and acceptable, but if finances are unacceptable, that totals in hoping for another time when finances can be sorted. Your withdrawal is part of the process and there is no blame assigned to you for having to say no. Your availability is strongly conditional on the finances.

Even if the form asks for your sad story, feel free to skip it. Focus on explaining what the conference diversity is missing out with your person being absent. And particularly, focus on making the conference call for proposals a proposal they feel bad at losing for making speakers pay so that we have better chances of changing this in the future years.

The Mentoring Initiative

The mentoring initiative targets 1st time speakers. There are so many great sessions we don't get to fully consider, because while new speakers can make great sessions, they also greatly benefit from help in making their idea shine by focusing it, ensuring its specialty and usefulness, and just giving some ideas of improvement. Mentoring is great for this, and the conference normal format includes the track chairs and volunteers giving feedback on submissions added early on into the submission system.

The mentoring initiative adds a little extra support. We are currently collecting a group of mentors, who volunteer to spend 15-minutes in collaboration calls helping find the core of the speakers idea. https://www.agilealliance.org/agile2020/first-time-speaker-mentoring-initiative/ 

Next week we open the calls for people who want to try this extra support for getting their proposal ready. A personal touch with someone who has done it before can do wonders and at worst, you'll have a lovely 15-minute discussion about your idea with someone who wants to see you succeed with it.

Out of this we get a quick view of what is out there, and get you started with writing the proposal into the call for proposals system. The mentor you spoke with online can jump in to help you get what you said in the call in the writing you submit as they will know more of what you're trying to say than someone who did not spend the 15 minutes with you.

Give us a change of hearing your ideas. We can't change the teaching the sessions do if the sessions repeat the same people's experiences. And we have a whole agile journey ahead of us where different experiences are crucial for us to get the hang of what others can teach us.

---
See, I use more words. I don't need to try to say things in a nutshell. I believe there are people who need to read more words to feel welcome to what we are trying to do here. Our intentions are good, and we are listening.


Tuesday, December 31, 2019

2019 and Me

Every year I look back and see how things turned out. While I'm one of those people who collects numbers, the relevant insights are hardly ever quantitative in nature.

At work, I looked at how our team had evolved based on the tracks we left in the world and learned that we've grown more used to uncertainty, incremental plans and delivering great with continuous flow. I learned about ways people had grown, and exceeded their past selves.

My past self sets me a standard that I work against. Not the other people. Past me. And how the current me is learning to be more of me, more intentional and accidental, and free to make my choices. I don't want to live my life on other people's defaults, I want to tweak my own settings and explore where they take me.

I tried many different settings in 2019:
  • I allowed myself to be *less responsible* and let things fall forward when I was low on energy. I learned I have people close to me who catch things, take balls forward and don't blame me for being a human. 
  • I tried not blogging for six months. It was hard to stop a routine but also felt liberating to confirm why I blog when I do. I have not written for an audience in general, but just allowed people to see what I write for myself.
  • I tried blogging for audience, behind paywall. I did not enjoy it and came to the idea of blogging and making videos for audience in 2020. Can't wait to try that one. 
  • I said yes to all speaking that pays minimum of travel but applied for none. Turned out with 20 talks. 
  • I auto blocked 700 people on twitter to learn about enforcing boundaries and doing what I needed over other people's comfort. 
Some things I will remember this year from:
  1. FlowCon talk in France and my talk #400 - with standing ovation. 
  2. DDD EU keynote in the Netherlands and finding my crowd. 
  3. Making it to 100 most influential in ICT in Finland list and having a 4-page article of me in ITViikko magazine
  4. Talking to 150 people for Calls of Collaboration to choose speakers for my own conference (European Testing Conference) but also others with TechVoices (Agile Testing Days USA, Selenium Conference London keynote)
I have some numbers too:
  • 45 blog posts with half-a-year break from blogging (2018: 110), but on split to 3 platforms
  • 20 talks, out of which 6 keynotes
  • +2 countries I have spoken at, totaling 26 now
  • 8 graduated TechVoices mentors (I helped them become speakers!)
  • 2 conferences organized
  • 2 Exploratory Testing Peer Conferences organized for #35YearsOfExploratoryTesting
  • 50 flights, sitting in planes for 165 hrs to fly total of 107 878 km (2018: 120 hrs)
  • 5662 twitter followers - after blocking 700 (2018: 
  • +58 556 page views in the year totaling to 631 004 page views all time to my blog (2018: +81820, 582 448)
While all of the above are on my "on the side of work" achievements, work is where I go to learn.

I learned about business value, and how to discuss it a little better at office, creating a business value learning game. 

I learned about making space for people to discover what they are capable of doing, and not pointing out when they contradict their past selves before they are ready to see it. 

I learned that manager role is exactly like my tester role except for three things: 1) having to click "approve" as manager comes with the role 2) feeling equal with the most intimating, wonderful and special developers I did not realize I wasn't feeling equal with even though I already was 3) *lack of performance* management is hardest job I have ever done.

I learned I am a master of procrastination as I can turn ideas into code without writing code myself and I want to overcome my internal excuses of not just doing it. 

I was there to witness us moving to great and improving results and might have had something to do with some of it. 

Turning the "impossible" to possible should happen any moment now, when my consistent push for 3 years turns into continuous deployment for our product type.  

2019 was great. 2020 just needs to be different. 

Happy new year y'all. 




Thursday, December 5, 2019

A New Style for Conference Speaker Intake: Call for Collaboration

Drawing from a personal experience as conference speaker and conference organizer wanting to see change in how conference speakers are selected, I have been experimenting with something completely different. 

The usual way for conferences to find their speakers are casting two nets:
  • Invite people you know
  • Invite everyone to submit to call for proposals/papers (CfP) and select based on the written submission
Inviting works with people with name and fame. If you want to find new voices with brilliant stories from the trenches, the likelihood of you now knowing all  those people (yet) is quite high. Asking them to announce themselves makes sense.

This way of how a speaker announces their existence to conference is where I have discovered a completely new way of dealing with submissions creates a difference.

What is a Call for Proposals/Papers

In the usual world of announcing you might be interested in speaking in a conference, you respond to a Call for Proposals/Papers. The Papers version is what you would expect in more academically oriented conferences, and the paper they mean is usually an 8-page document explaining result of years of research. The Proposals version is what you would expect in a more industry-oriented conference, and the proposal is a title, 200-words abstract and 200-words bio of yourself, and whatever other information a particular conference feels they want to see you write that would help them make selections.

While speaking in public is about getting in front of a crowd to share, conference CfPs are about writing. The way I think of it is that writing is a gate-keeping mechanism to speaking in conferences.

As a new speaker, learning to write in this particular style to be accepted may be harder than getting on that stage and delivering your lessons by speaking about them. At the very least, it is different set of skills.

In my experiences in working to increase new voices and diversity at conferences, there are two things that most get in the way:
  1. Finances - underrepresented groups find it harder to finance their travel if conference does not address that
  2. Writing to the audience - unrehearsed people don't write great texts of their great talk ideas. Many feel the writing to be a task so overwhelming they don't submit. 
Conferences try to help people in multiple ways, usually seeking writing based ways. It is fairly common to expect a conference to provide some feedback on your written text, especially when using supportive submission systems where you then improve your text based on feedback. But the edits are usually minor even when you could frame your talk different to make it better presented. Many ask for speaking samples (videos), adding to the work expected on the competition towards a conference speaking slot. Some conferences shortlist proposals and then call people, to ensure the speaking matches the writing. Some conferences realize after selection you could use help and call mentors like myself to help bring out the better delivery of an already great idea.

What is a Call for Collaboration

Call for Collaboration is a submission process I have been discovering for the last five years, coming to terms with my discomfort on choosing a speaker based on writing instead of speaking. I have felt I don't appreciate the purely competitive approach of writing for a CfP to win a speaking slot, and wanted to find something different.

Call for Collaboration is about aspiring speakers announcing their existence and collaborating on creating that proposal. It's a process where the conference representatives invest online face to face time to getting to know great people they could invite. And it's a process where the investment from the speaker side is smaller, creating less waste in case of not fitting the scarce conference slots. It's a human-human process where people speak and instead of assessing we build the best possible proposal from whatever the aspiring speaker comes in with.
In Call for Collaboration (CfC), we appreciate that every voice and story belongs on a stage, and making the story the best form of itself increases it chances to this conference, but has a ripple effect of improving it for other conferences too.

This submission process was first created for European Testing Conference, and later used for TechVoices track for Agile Testing Days USA 2018 and 2019, and TechVoices keynote for Selenium Conference London. So far I have done about 500 15-minute calls over the years of discovering this.

How Does This Work?

It all starts with an aspiring speaker thinking they want to make their existence and idea known for a particular Call for Collaboration a conference kicks off and being willing to invest 15 minutes of their life to have a discussion about a talk idea they have.

 Image. TechVoices version of CfC + Activity Mentoring

Schedule a Call

To announce their existence, they get a link created with Calendly that shows 15-minute timeslots available to schedule.

Behind the scenes, a conference representative has connected Calendly to their calendar knowing when they are not available and defined time frames when they accept calls and limits to numbers of calls per day. They can define questions they want answered, and I usually go for minimum:
  • Your talk's working title
  • Optional abstract if you want to pass us one already
  • Your pronouns
Each call from a conference representative perspective is 15 minutes, like a coffee break. It includes taking an online call to someone anywhere in the world and meeting someone awesome.

If the aspiring speaker has something come up, they can reschedule with Calendly. Calendly also handles timezones so that both parties end up expecting the same time - at least if you have the tool create a calendar appointment for you.

Show Up for the Call

The 15-minute call is for collaboration. It starts with establishing we don't need to discuss credentials but just the talk idea and that everyone is awesome. We are not here to drop people away from the conference, but to understand the world of options and make this particular option shine, together.

It continues with the aspiring speaker telling how they see their talk: what is it about, what they teach and what the audience would get from that.

The usual questions to ask are on "Would you have an example of this?" and "What is your current idea of how you would illustrate this?" or on "Have you considered who is your audience?" or "Why should people care about this?" or "We know you should be talking of this, but how would you tell that to people who don't know it yet and have many options in similar topics?".

I have had people come to the call with the whole story of their life in agile, and leave with one concrete idea of what they are uniquely able to teach. There are talks in this world that exist because they were discovered through these 15-minute discussions.

For some of the calls, we've had a whole group of people from the conference - this serves as a great way of teaching the mechanism further - mentoring the mentors to take the right mindset. We are there to build up the speaker and idea, not to test it for possible problems.

Share to the World

In the end of the call, the conference representative asks for permission to summarize what they  learned about the talk in a tweet with reference to the aspiring speaker, and with permission share that. Sharing serves three purposes: it helps remember what the talk was about (to prioritize for invitation to work on the talk further); it allows the aspiring speaker to confirm if their core message was heard and to correct; and it creates a connection for the aspiring speaker to other people interested of this theme in the community.

Prioritize to Invite

Now we are at a point where there isn't really an abstract, but there is a tweet and there are the lessons of what the abstract could be about from the aspiring speaker to the conference representative. We can make a selection based on how people speak in that call, and particularly, what unique content they would bring to that conference.

If  someone isn't quite there yet on how they deliver their message, we can invite them and ask them to pair up with an activity mentor for rehearsing the talk. This is the only way to  get some of the unique new experiences from people who are not accustomed to speak in public. With rehearsing, people can do it. The only concern around rehearsing I have sometimes is on English skills - I have mentored people who would either need a translator (used a translator in our call) or a few more years of spoken English.

This is a point where you have usually used about same effort on the person as you would if you were carefully reading their written abstract - but you might have now a different talk to consider as a result of the collaboration. 

If you invite, the next step is needing the abstract for the conference program. Or, it could be that this is the abstract use for yet another round of selections if you want to pin this process on a more traditional CfP.

Activity Mentoring for Conference Proposal - What Is This?

The activity of creating that title, abstract and bio to show the best side of the talk is the next part. The newer the speaker, the harder this is to get right without help. A natural continuation of CfC is activity mentoring, ensuring the written test as a deliverable of the process reflects the greatness of the talk.
  • 1st draft  is what comes out of the aspiring speaker without particularly trying to optimize for correctness. It is good to set up expectations, but also encourage: something is better than nothing. This is just a start. 
  • 2nd draft is what comes our when the conference representative from the call puts together 1st draft, their notes on what the talk is about, the tweet they summarized things into and their expertise on abstracts. Its usually an exercise of copypasting together my notes of their spoken words and their written words in an enhanced format. 
  • Submission is what the conference system sees, and it is an improved version of 2nd draft. 
Example

The latest effort from this process will be soon published as the TechVoices Track of Agile Testing Days USA 2020. 9 speakers with stories from new speakers that are not available without taking the effort to get to know the people. Many of these voices would not be available if the choice was done on what they wrote alone. Every single one of these voices is something I look forward to, and they teach us unique perspectives.

I still have another activity  mentoring period ahead of me with a chance of hearing the premiers of these talks before conference and helping them shine with yet another round of feedback

We chose 9 talks out of 45 proposals invited from USA, South America and Canada. I also had a few calls with ideas from people not from invited geographies and helped them figure out their talks in the same 15 minute slots.

As a mentor, I had time to talk to all of these people and feel privileged to having had the chance of hearing their stories and tell about their existence through tweets. I would not have had time to help all of them get the proposals to a shape where they could get accepted to the conference. The activity mentoring is a focus draining activity, whereas having a call is more easily time-boxed and happens without special efforts.

I spent 11 hours over timeframe of a month talking to people and getting to know them. I spent another 10 hours on the 9 people that were selected.

The hours the 15-minute slots make have been the best possible testing awareness training I could have personally received. It has given me a lot of perspective, and made me someone who can drop names and topics for conferences that have a more traditional Call for Proposals.


Tuesday, December 3, 2019

The First Test On a New Feature

Testing various features, I have just one rule:
Never be bored.
Sometimes I try to figure out a template to what I do when I test and how I end up doing what I do, and it always boils down to this. Do something that keeps you engaged.

Today I was testing a feature about scheduling tasks of all sorts, and as I was thinking about getting started, I told myself I should test the basic simple positive scenario first. Not that I thought that wouldn't work, but to show myself how the feature could work. I've used that rule a lot, but today that rule did not make me feel excited.

Instead, I started off with a list of examples that was provided. I quickly glanced the list through, and selected one that looked complicated telling myself that if something wouldn't work, that would probably be it.

It turns out I was right. Instead of seeing the feature work, I got to see a fairly non-explanatory error message on the log I was monitoring.  So I run a second test, the simplest sample from the list to see how it could work. From starting testing to discussing a bug with the developer was just minutes away.

Meanwhile, I was having a discussion with another developer to refresh my ideas of test strategy: would we test these types of things in long term reliably with unit tests, yes - getting to a confirmation that while fixing what I complained about, the first developer had already improved the unit tests on it. 

Similarly, the fix for the bug was also just minutes away, and I needed to chip in some more ideas.

I ended up asking a lot of questions. Questions around how things would work on leap years and days, impossible combinations of months and days and instead of ending up testing these, the developer volunteered. Questions around how time could be too short or too long for our taste. Questions around what the log would show. Discussions changed my perspectives, and clarified our shared intent around what we were building.

I ended my day of testing with googling evil cron for testing, and had lots of fun with online tools generating me test data I could try. Things that were not supposed to work did and things that really stretched what was supposed to be valid were confirmed. I explored time calculation, passing valid and invalid values. And as always with testing, had a great time.

These are first tests, and I'm not done. Instead of testing this all by myself, I invited a group of people to do mob testing with me on this, to test my own thinking and improve our test strategy around what makes sense to automate even further.

There is no first absolute test. It is never too late to do the thing you thought you should have done first. With testing, very few options expire. You just need to keep track of your options.