A More Advisory Role

Over the last year I have looking to work myself out of the test manager role and into a more advisory role. And by April 2021 I was given the formal title change from Senior Test Manager to Senior Advisory Consultant.

I have had the title “Test manager” probably since 2008, so it’s been a while. In the companies, where I have been employed, the Test manager title has never been with line management (hire/fire). Rather it has been similar to a project manager, with a focus on the testing deliveries of a project, release or program.

I will still be leading test activities, but my role for the future will be more about enabling someone else doing the testing or someone else having a testing problem to solve. There are plenty of test activities done by people in non-testing roles – it’s the activity that matters.

I wrote in “Something about leadership” what I see in the new title:

It turns out the company I work for (a 3000+ IT outsourcing shop) already have people with the new title and already have people doing similarly as me in other domains. So there is actually a job description with some of these activities:

Thought leadership, strategy and execution

Contributing to continuously developing our services and propositions

Sales activities and pipeline management

Consulting and customer engagement

Analyses complex issues and improves methods, concepts, techniques or processes

Being relevant and drive customer relations as trusted advisor at C-level or just below

From “Senior Advisory Consultant Job Description”, 2021

The Usual Career Paths

Career paths for testing specialist usually looks into testers, test engineers / automation specialists and the more coordinating roles (test managers, test coordinators). I wrote about that previously and similarly there is an article on “Navigating A Career Path In Software Testing” on the Ministry of Testing.

Besides the classic “levels” of junior and senior, I do see “Staff” (similar to Staff Engineer) or “Principal” as talked about by Jit Gosai in “What is a Principal Tester“. So in the testing space there are plenty of promotions to make and roles to play.

Some people take the coordinating role to move into either scrum masters or line managers (test leads, delivery managers etc). Though, those two titles are careers in their own right. Being a line manager or engineering manager is both about the staff but also about making the organisational numbers… and politics.

A Career path for Coaching and Advising

But there is also a more advisory and coaching career path – as I discussed in “Less Test Managers, More Test Coaches“. I have seen them labelled differently out there as: Test Coach, Test Owner or Quality Coach.

I do see some similarities to my new title and both the staff roles above and the more coaching specific roles. They align fine with being enabling roles in the Team Topology sense. The difference is probably on level the roles play. My role will (also) address delivery managers and some C-suite (or just below) – while other coaching roles are (mostly) for the delivery team. Let’s see how it plays out.

Team Topologies

Something About Leadership

17yo: Dad, do you not know how old I am - and what I can do myself? 
Me: Oh, I know buddy. As you are learning new stuff, I am unlearning to help you

While this quote from my kitchen about a week ago, as all to do with the young man learning the ropes of life and me unlearning to always to help him and his 15yo brother out – there is an key parallel to leadership and building self reliance in teams. My role these days are less about direction and (micro)managing a team of testers on a project, more about enabling others to succeed with their testing both in the delivery teams and in the board room.

In the Matrix

Since starting in testing in late 2002 (!) I have always worked in two dimensional matrix organisations: Line management and skill management on one axis, project staffing and delivery focus on the other. This also explains why my current title is “test manager“, because that is my role in the delivery focus: managing testing – similar to a project manager managing the project delivery and a program manager conducting a program of projects. yeah it’s some big ships we steer.

Recently I had the opportunity to work with a skilled program manager again – we last worked on a program together in 2016. Working with her reminded me about how things have changed the last five years. Back then the program was both a transition of applications from one data center to another and the migration of data from one platform to another. This time around the program was about transition of hosting and application delivery. Same same – just very different.

How it started, and how it’s going

In 2016, as the test manager, I lead the test part of the project including professional testers and subject matter experts. I was track lead on a similar level as other project managers in the program. This time around I’m more of a staff function to support the work done within the subprojects – the testing is done by the team members (there are no professional testers). So I need to learn new skills in making this happen, and unlearn some others.

The Undoing

For about 17 years it’s all been about following up on things: remember your homework, let me tie your shoes, this is what we are having for dinner, … and similarly have you done your test cases, have you thought about this and prepared that the last 10 years or so in managing testing.

Quite fittingly here at my 9 year anniversary for the first blog post (and post #250) – I can see the topics are more and more about leadership, strategies and the bigger picture, than the mechanics of test cases, tool tricks and various bodies of knowledge.

I know that my preferred style of working is probably the DiSC Dominant, I tend to focus on getting stuff done and will focus on the results. Sometimes I can also be more analytical and strive for objectivity (Conscientiousness). I can be patient and humble, and usually my super power is that things will sort themselves out.

It’s hard for an old dog to learn new tricks – if I can get to do some class room training this year it will be about personal leadership. This past week I have practiced not to be so outspoken in the conversations in the projects, as I would have previously done. It’s up to the project team now, I’m there to support, enable and build self reliance. I need to let go of claiming the accountability, but hand that over to the people going through the motions and emotions.

Naming matters – so currently I’m experimenting with a new title of Test Advisor – with these tasks:

And most importantly: enabling the self-reliance and life skills of the two young men mentioned above.

a snowy February 2021

Trends for the Tester Role

YMWV – this is a model for reflection not to a 1:1 scale of everything in the universe. It might be useful.

The space for the testing professional is under pressure – for my own role and even more for the “traditional” testing professional. At least since 2017 there has been a shift and ongoing disruption. I finally have a form to visualize some of the trends that puts the role of the tester under pressure:

  • SIT / UAT debate
  • Low-code trend
  • Modern Testing
  • Quality Engineering and whole team approach

I still see two key areas (stars below) for the classic tester to move into: exploratory testing based on weak signals and supporting the end-users low-code activities (test tool smith). For the more managerial and coordinating role I will have to get back to you in a future blog post.

Here’s my (Wardley map inspired) model of the whole thing:

SIT / UAT Schism

We used to discuss strongly the schism between UAT and SIT – who did what and why. Sometimes the end-user in a small or medium sized business would do all the formal and informal testing of changes to ERP. Sometimes outsourcing companies would do all the testing (as a service) on behalf of the customer. I have been involved in both – it happens.

Usually, what would go in the SIT would be the repetitive and rule-based confirmations of features and functionality. While the UAT would focus on the more business visible and more intricate activities. In case there is UAT at all – but for large public and enterprise deliveries (B2B) there sure still is plenty UAT around.

Sometimes the business users, subject matter experts doesn’t take it lightly for someone to test on their behalf – and the tools are emerging that allows automation for other roles too.

Low-code trend

The low-code, no-code, RPA and the Citizen developer trend has provided the end user organisations with the tools to automate on their own (to a certain degree). Not only in test automation but in general – for instance with the automation tools of Microsoft Power Automate.

Even Alan Page of Unity / Modern Testing talks about the benefits of low-code for most web problems (as I have):

Modern Testing, Quality Engineering and the Whole Team Approach

Another significant and persistent trend in the testing space is the Modern Testing principles. They are really hard to imagine for many testing professionals – yet the foothold for the principles are strong. (Is it then a best practise?)

Especially two of the MT principles challenges the status quo for the tester, and pushes the testing activity partly up towards more business visible activities and partly to the right as a team embedded/pervasive activity.

5. We believe that the customer is the only one capable to judge and evaluate the quality of our product

7. We expand testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist.

Modern Testing Principles 5 and 7

Lastly the topics and principles of Quality Engineering and the “whole team approach to quality” drives much of the less visible testing activities to be handled by the team as a whole. Developers and others involved on a technical level can test both exploratively for weak signals and unknown-unknowns in the stack – and automate all the boring and repetitive tasks and checks with explicit outcomes. This btw includes visual tests in the UI.

This independent of the system under test being a custom built web page or a commercial SaaS solution. It’s a better solution if more “lower” testing can be performed by the application specialist configuring a commercial standard application.

Spaces for the Tester role

Some testing based on weak signals can be handled by the team of system specialists. Some exploration of the unknown is best handled by the business representatives. Though, as the maps shows there could be a space (the star to on the left of the map) between these two – for the skilled exploratory tester with a technical mindset, who can use relevant test tools to pick the solution apart and explore for issues and findings.

IT systems exists for both rail tunnels and containerships – where it could be relevant to explore the solution before it gets into “actual use” on ships on the oceans and where you just can’t easily recover from a crashed cargo train in the tunnel. The system under test matters – as does the culture of the organisation.

Lastly, there could be a space for the testing tool smith on the very right of the map between the business visible low-code activities and the technology-facing automation practices. Depending on the low-code platform (Visual Tests are Still Code), the system under test and the testing we want to perform.

If the capabilities of the low-code test automation approach requires you to tinker and fiddle a lot, it could be a sign that either the tool is a bad fit or the system under test is not as stable utility as you would have liked. Example the old pitfall of management saying that the COTS solution is 80% standard, yet the implementation project ends up with 20% custom.

Lastly

It’s a general map, so it’s probably missing some trends and weak signals I have yet to spot. The map is not specific for a certain delivery team, but it seems to me that it would be valuable to map in detail using Team Topologies or Wardley maps with a team – to visualize the test strategy.

It’s a model to help my thinking about the patterns and trends in a changing world. I do not want to throw all testers under the bus – but observe and spot the trends. But I also know that by observing I affect the outcome ;).

Imagine That Things Can Be Different

One of the key skills of a knowledge worker – and testing people are knowledge workers – is to imagine that things can be different. I have written previously how to recruit for curiosity – and contributed to the book of “21st-century skills for testers“. But apparently I have missed to highlight the key skill of imagining that things can be different.

Imagination Different System Behavior

A tester is someone who shows you that if you put a bottle o top tilt the trash can at 5 degrees, press on the left side, and then trigger the lid release then it is possible to launch the bottle through the kitchen window and by the way that is a plausible use case...
“A tester is” by Jeff Lucas 2012

First of all imagination helps us to explore and discover the unknown. It’s key to the testers mindset, not to be limited to the specifications and codified knowledge, but to use imagination and implicit knowledge to imagine the unexpected. Testers, to me, are anyone performing the act. Be it developers, technical application specialists, infrastructure and cloud operators and business subject matter experts. It’s the activity – not necessarily the profession.

Imagine Different Delivery Contexts

Yet there are people in the profession who seems not to be able to imagine that companies and teams works in different ways. That there are delivery teams that do not have testers and that there exists IT projects that are not about developing bespoke web software for the consumer market. I have worked with teams that have been maintaining the same system for 25 years – without any testers and with a team application maintenance engineers who have learned intricate business contexts. It’s all about the culture.

https://hbr.org/2017/07/being-the-boss-in-brussels-boston-and-beijing

Leadership cultures matters – and it seems to me that I have experienced working with organisations in all four quadrants – while still being in Denmark.

Imagining Different Organizational Behavior

Recently I have been working with a organization that works in a totally different way that I have been used to. Every document and delivery needs to go through an extensive peer review. I have a test plan with an accompanying 20+ review sheet. While I’m used to effective collaborative reviews, this is way more over the fence than cooperation. Jit Go has an excellent piece on the various ways of collaboration.

It reminds me of the Westrum organizational model mentioned in Accelerate, that I looked into in: Shoot, Neglect or Train? Be aware that while the organizations might see themselves as Generative – the underlying culture might be worse. Remember morale is what happens when no-one is looking.

Screenshot from Accelerate by Forsgren et.al.

Use models to understand and spot the differences – it’s a key skill to imagine that things can be different.

Darlings, Pets, Cattle and GUID’s

Kill your darlings and treat your tests more like cattle than pets, are among some of the heuristics currently around for managing your environments and automation test suites. These heuristics tells me that the environments and automation are in a state of product or even commodity, while previously the tests and environments where like darlings and pets – named and nurtured.

Named and nurtured tests with explicit steps and specific test data on all test cases are are a sign of a team stuck thinking that all problems can be solved with more and more specification and detailed up front design. We have seen numerous times that this is not how you build trust and collaboration – nor when handling systems that are not stable – nor when the subject matter experts test. You cannot structure yourself out of a complex situation.

We do need the darling solutions for the things that sets you uniquely apart and for the unknown of the new incoming features. We need the cattle, structure and standards for factory solutions and stable operations. Not the other way around – FFS!

Gold box problemsSilver box problems
Complex, multifaceted and ambiguous
Unpredictable and uncertain
Rapidly changing or chaotically decaying
Impacted by irrationality, emotion, dishonesty and bias
Rules based
Stable and predictable
Repeatable
Scalable
From Rob Booth, a co-founder of The Bionic Lawyer Project, via John Grant

Previous industry practices told that test cases needed to be richly detailed and hand crafted – with the rise of automation, and especially low-code, there is an alternative ROI.

Put Critical Thinking First

Even the one of the strongest holds for previous practices and structure is now promoting critical thinking over verifying and documenting everything. If you look at the recent FDA recommendation with regards to Computer Software Assurance (Epista has a good primer to the topic) – it starts with the intended use of the software, then drills into test types and approach for the test task in question and lastly appropriate records for assurance of the software. This opens up for continuous validation and continuous compliance in the regulated space! Finally, old chap – now to turn the ship around.

The industry has moved so far the recent years that the previous safe bets and previous “good industry practice” will not get us where we need to go. But we do have parts of the map for the future solutions – what is left for us is to imagine that things can be different.

We already know how to read the landscape

We can use the stages of evolution from the Wardley mapping landscape to position the parts of the systems relative to one and another. On the left we have the uncharted and on the right the industrialized:

Based on Simon Wardley‘s Evolutionary Characteristics Cheat SheetCC BY-SA 4.0

By addressing the system under test and aligning with the business user needs we can understand the relative positions of the technology stack, movements of the business knowledge and practices. We can see that exploration makes sense on the left side, along with subject matter experts intricate knowledge. We can also see that codified and explicit knowledge ties with codified solutions and industrialized on the right. JitGo has an excellent deep-dive into using appropriate methods.

There’s a huge difference in addressing a user need of cloud operated commercial standard systems and systems being held together with duct tape, WD40, gatekeeping and all the other dangerous animals in product management. While there used to be a difference between life science and the business-to-consumer solutions, the former is catching up and similarly needs to deliver faster and validated at the same time.

We already know how to deliver

We do know how to solve the core conflict of delivering quality faster while maintaining steady operations. Readers of the DevOps handbook by (Gene Kim et.al. 2016) will recognize the that the core conflict is addressed in the book. Readers of Accelerate will know the research behind the key drivers of improved deliveries and organizational excellence. Readers of Team Topologies will recognize the need to rearrange the team structures to beat Conway’s law. The book is already out there on A Practical Guide to Testing in DevOps – if that’s the niche.

To me it is about enabling organisations, delivery teams, bid teams and CTO’s to get their core challenges solved – not merely the status symbols and status quo. It’s clear that we cannot solve the challenges of tomorrow with the tools of years gone by. We need to stand of the shoulders of previous giants to reach the stars of the future quality solutions.

My current collection of IT Revolution books – non sponsored post.

The Testing, not the Testers

Occasionally I see posts and discussions, where testers are indignated that this and this company has no testers. How could they! Or similarly when a product is released publicly with significant issues: See – it’s because they have no testers! Or that the testers are not taken seriously. OMG!

Previously, I might have been indignated too about those observations. But as my experience grows, the causation fails. I had failed to see the context and see outside my own box of thinking. I can learn to be better by remembering my favorite Weinberg quotes:

1. Things are the way they are because they got that way

There are plenty of established organisations that don’t have the need for professional testers. Recently I’m working with a large local union. They have no IT team either – besides a small team called IT vendor management. In that team they do have a few release- and test managers, but the testing has to be done either by union office staff or by their IT vendors (and that’s where I come in, I’m more of a test coach though). In this context the testing is done either by those with the business skills or those with the technical skills.

Similarly, in 2018 I was assigned to a 30+ people IT development team that had been existing since the 1990’es. They had never had any testers. What they did have was continuity, about half of the team had been in the team for 10+ years. They knew every nook and cranny of the IT solution landscape: the main system, order entry and processing systems. And they cared deeply about the quality of the whole thing – the IT system consultants did their own testing, and had been doing so for years. With testing, not with testers.

Locally we also have five banks that share the same IT company. The IT organization is an independent company that provides the same domain technology to all the banks. Just with a bit of flavouring and branding, which is actually very common with industry specific solutions. The banks themselves have no testers, neither have the IT organization. But with every new release representatives from the banks are brought in to test and review the solution. The people participating are not testers, but they are doing testing. They go back to do their full-time job as process admins, customer advisors at the end of the testing.

2. No matter how it looks at first, it’s always a people problem

And obviously there’s no causation between lack of testers and buggy releases. Plenty examples exists of IT deliveries with loads of testing – and yet having a buggy launch. Locally I can think of all the large public IT projects that have failed significantly. Both the national land registry solution and a regional hospital solution have taken years to recover from the failures.

While they did have a lot of formal testing that discovered the issues. Management decided that the deadline was more important that quality. Thus they reduced all the formal testing activities to window dressing and cargo cult adherence to what the testing should be about. I have stories to tell over beer about how senior management have added testing activities, for them to look good in a political gameplay.

3. You’ll never accomplish anything if you care who gets the credit

What is left when you actually consider the story and the people aspects – is an indignation on behalf of the tester as unique playmaker in IT deliveries. Really, It’s not. Sorry. I understand if you feel attacked on your brand. I have had that feeling too – other people have been having that feeling for years. You will only be taken seriously if the work you do taps valuably into what matters to the decision makers. If you whine about not being taken seriously, you need to up your game.

Sometimes it happens that the tester is the hero and unique playmaker in making quality happen. While it’s nice to be the hero, a hero culture is not healthy. We know now, the hero becomes the bottleneck. Even a hero needs a team and a whole team approach to quality matters more than the individual role. I am strongly aware that even my current work is under pressure: Someone else will eventually do it.

Let’s continue talking about making the testing smarter and not single out that this is for testers only.

Relations – are about half of IT

You can’t have IT projects without relations. Relations matter more than it seem.

Recently I had an online call with the adults around the 14yo: An autism psychiatrist, the school guide/trainer, his mom and I. Online on teams, obviously. The other adults in the call were struggling with all the online schooling and interaction, and no face-to-face with the young student. Besides all the stress of the pandemic they had a hard time working at all.

To me online meetings are a natural way of working. I have been working primarily through online interactions the last five years or so. The people I work with are distributed away from me, they are in Copenhagen, China, Philippines and other places. It seems the teaching industry broadly has to catch up with the lessons and tricks from the IT industry. Besides the stress of the pandemic and lockdowns IT people can actually do their work. So I mentioned that I only work online.

And the psychiatrist said, but for IT people relationships aren’t so important.

… oh …

Relations matter in IT projects

The psychiatrist probably doesn’t know the inside of an IT project, and are probably only aware of the City IT staff when something is not working or they are rolling out yet another upgrade of her systems. So to her it seems that IT is all about the deliveries – not so much about the relationships. (to bad really)

On the inside of IT projects, relationships are about half of the story – the actual IT thing is the other half. For the clear and simple things relations matter less (the commoditized, as Wardley would point out). When you think about it, IT have a huge range of models and frameworks around the relationship part: Cynefin, Agile Manifesto, Scrum, Team Topologies etc. The more you move around on Cynefin the more relations matters.

3D version from Rob England Cognitive Edge

Relations are obviously important to line managers, coaches, lead roles and people in enablement roles. But for the individual contributors in the teams – relations matter too. First of all, time has run out for the expert douche bags and hero culture. Everyone talks about the whole team approach to quality.

Secondly the research from the Accelerate is clear – besides all the mechanics of delivering IT – the culture of the workplace impacts the business performance. Lastly, when you look at incentives for the individual, the non-monetary matters are becoming a key differentiator. Especially given the pandemic – gone are the bro culture of foosball tables. What’s hot is work from home, team diversity, moral practices and a decent team culture.

There will be a trend in the future, that changes the IT office landscape yet again. The best teams will meet online for some of the work – and join in collaboration spaces or getaways for alignment. Because even for IT work relationships matter – and at the end of the pandemic even we will adjourn in our teams.

Automation is for Other Roles Too

Automation of business tasks is no longer for the software developers only. Similarly test automation is no longer for testers and test engineers only. Both these trends help to create smarter testing performed by non-testers.

As discussed in “No Code, No Test?” and in posts before that, automation tools like IFTT, Airtable and other tools are emerging to enable not only private end-users but also enterprise end-users to do business automation. As an example it’s being actively discussed among the local administrative hospital staff how to apply RPA for data entry and data updates.

I know RPA/low-code implementation is often a symptom of an underlying problem with system integration on one side, and poor process for system optimization on the other. That’s just the way it is, not all systems in the world are based on state-of-the art microservices or processes. It’s a mess of things and your mileage will vary.

XKCD 2347: Dependency

The low-code business tools emerge and gain tracking – and enable what Gartner calls the Democratization of Expertise and Mabl calls customer-centric testing. In either case it allows for some digital transformation of business activities, that are not directly reliant on software development activities. Yet the more complicated and complex even the low-code solutions become, the more important it is to maintain and test. .. and that’s where the automation best practises come in. Visual Tests are Still Code

Similarly for Test Automation.

Low-code automation are not primarily for the testers and test engineers. If your team has access to the source code – you can follow the modern testing principles and build in Observability in (https://charity.wtf/) and a lot of the things in the code (from: When to use RPA in testing). That’s so much talk of the town, that it should be considered a best-practise (in the Wardley sense ;).

To me the best case for low-code testing tools (Mabl, TestProject, Testim, Leapwork et.al) is to apply it in all the other situations. Co-create smarter testing performed by non-testers and non-developers. Give it to the business people involved in testing SAP or ServiceNow, give it to the supporters using ITSM or similar ticket tracking solutions – give it to all the subject matter experts (SME) involved in the testing. But! Don’t let them sink on it, train them, support them. Let them build confidence on the tool slowly – after all they are not testers.

Where do everyone fit in? The testers jobs will be to explore and to train/enable the experts. I see more testers and test coaches being in the Enabling team – while the SME’s are the key persons in the Stream-aligned team – especially if the tools available to the SME’s are low-code. Have tool smiths (Test engineers) at the ready with building blocks of reusable components, automation best practices and coding snippets (Complicated Subsystem team).

Smarter Coding for the Business

What’s the Problem Here?

At the the recent “Online Test Conference – Fall 2020” a workshop reminded me to look at the problem. And it’s always a people problem. Which got me thinking later on in the program – what’s this talk trying to solve?

About the OTC

The fall 2020 version of the Online Test Conference was the 9th version, and the conference has been online only since the start in 2016. I had a talk in 2017: Shifting is more than Shift Left. Since then the conference has expanded to be over three days:

  • One day European-friendly timeslot
  • One day American-friendly timeslot
  • One day Asia-Pacific-friendly timeslot

With little effort you might be able to listen to talks on two days, – and if not the whole thing is available on youtube afterwards. The conference is driven by Joel and his team from PractiTest. Though the only marketing the push is their free and annual State of Testing Report. the State of Testing report has been running for some years too and provides insightful global trends in the field of software testers.

The OTC is great for multiple reasons: It’s free, anyone can join (and many new people to testing does), the talks are recorded and there’s a bit of a chatter on the slack channels. It’s an easy way to step up your learning.

But back to this year

New this year was online workshops. First off I attended “Workshop with Rob Lambert: Building diverse, inclusive and effective teams by focusing on behaviours“. Which was great on two accounts: interactive and had key takeaways. One take-away was the use of DISC profiles to understand yourself and the team around your delivery. I’m usually cautious about personality tests, but Rob did put it very reasonably.

The primary action item from the workshop was though to look at every meeting and consider:

What problem are we solving?

Rob Lambert, OTC Fall 2020

This can be applied is so many ways. And with the addition: Whose problem are we trying to solve – you can get closer to understanding the business and your team. It might sound off, if you are more a testing type that likes to investigate and spot problems and trends – but at the end of the day you too have to consider what business problem your testing taps into. What is the need of your decision maker?

What’s this talk trying to solve?

Due to time constraints and work I didn’t manage to catch many others “live”. Unfortunately one of the talks I did pick, I had to stop watching. While the talk had both a presentation and a video feed, it seemed as the person was just sitting there talking to himself. Watch the full recordings HERE, and judge on your own.

Not that my talk in 2017 was super, but I learned since then that even an online talk can be engaging. As a presenter you have to pause (Dana), you have to ask the audience questions (Angie) and have a theme or a story/stories. I tried my best on “When Subject Matter Experts test” [Available online with subscription: MoT Dojo].

So the question above applies as well to conference speakers and conference attendees. If I can’t tell what problem he’s trying to solve – or for who, then I’m out. The barrier for exiting online talks is so low, that it will be a factor in the future: to engage the listeners and to be clear on What’s the Problem here.


Photo by Miguel u00c1. Padriu00f1u00e1n on Pexels.com

[Media sponsor for the Online Test Conference Fall 2020]

Where Online was First

December 1-2-3 2020 is the 9th Online Test Conference. Since 2016 the OTC has been Online first, Global first and Free first too. Free to attend and free to speak at. Remember: Your learning is on you – take the first step here!

[Media sponsor for the Online Test Conference Fall 2020]