One of the biggest perks of my job is being able to travel abroad to attend and contribute to conferences (or run corporate training sessions) every now and then. I mean, seeing foreign countries, meeting new people and getting paid to do so, what’s not to love?

Earlier this week, I had the absolute privilege of attending and speaking at the 2023 Targeting Quality conference (TQ2023), organized by KWSQA, the Kitchener-Waterloo Software Quality Association. This is a regional conference held once a year in Cambridge, Ontario, Canada.

Being a regional and ‘boutique’ conference (a direct quote from the organizers), it doesn’t attract the numbers of the larger conferences out there, but it definitely makes up for that when it comes to friendly people and making you feel welcome and at home away from home.

I had the pleasure and privilege of running no less than three sessions at this conference:

• A full-day workshop on contract testing
• A talk on the importance of craftsmanship in test automation
• A talk on and live demo of mutation testing

As I said, Targeting Quality is a regional conference, run completely by volunteers, but the conference was impeccably organized and it managed to attract speakers and attendees not just from the wider Toronto area, but from the rest of Canada and the world as well, with speakers coming from the Netherlands, the UK, Germany, the US and of course from Canada as well.

After spending the weekend in Toronto, I arrived in Cambridge on Sunday afternoon (the conference was scheduled for Monday and Tuesday) and was immediately welcomed by the organizers and some of the other speakers. I’d met a couple of them on previous occasions, but for the most part they were new acquaintances. A very warm welcome indeed.

Monday was workshop day, and as I mentioned, I was scheduled to run a full-day workshop on contract testing. What the audience lacked in numbers (there were seven people attending the workshop) they more than made up for in friendliness, attention and a lot of questions throughout the day.

As usual, time flies when you’re having fun, and for me that definitely was the case. We managed to go through all the material I wanted to get through, hopefully giving the participants a good idea of what contract testing is, what problems it aims to solve, how to write, run and maintain contract tests with Pact-JVM and how to use the Pact Broker / Pactflow.

Monday night saw the speaker dinner at Beertown, which provided plenty of opportunity to wind down, have a chat with the organizers and fellow speakers, and enjoy food and drinks while doing so.

Tuesday was conference day, and I really enjoyed delivering my talks, as well as listening to some of the others, most notably the talks by Thomas Haver and Josh Grant, as well as the closing keynote by Jenny Bramble and Jenna Charlton.

I also really enjoyed finally meeting and having a chat with Janet Gregory and Lisa Crispin, as I’ve heard about and learned so much from them over the years.

After a pleasant social gathering it was unfortunately time to go back home again, but I’m looking back on a fantastic time in Canada and a wonderful Targeting Quality conference.

I really hope to make it back some day, and I can wholeheartedly recommend visiting or applying to speak at Targeting Quality 2024 to anyone considering it.

A final, special thanks to Tina, Graeme, Nicola, Ed, Rob, Lee and Bailey for having me and making me feel so welcome. You put on a great show and I’d love to be part of it again some time.

The post Targeting Quality 2023 – experience report appeared first on Association for Software Testing.

In AST, we use Slack for internal communication and Google Drive for file sharing.
Since we are all volunteers, many people are active only in evenings.
And since there are many people in US, their evening might be well in the night for me.
So it happens that someone sends a link to Google Doc on Slack, I want to check it out, but I’m not in a mood to turn on my computer.

I use iPhone.
I have all Google apps installed and AST account logged in.
However, Slack can only open links in Safari or open Share Sheet, and Google apps did not register themselves in Share Sheet for whatever reason.
So there’s no easy way to open a link directly in an app.

Luckily, there is a solution.

As Apple StackExchange user points out, Google apps register secret protocols that can be used to open current page in a specific app.
I guess these are used by “Open this page in $APP” bars that appear on top of page in a browser?
Either way, if you have a link to Google doc, something like https://docs.google.com/document/d/somerandomhashhere/edit, you can prepend Googledocs:// protocol and Safari will open Google Docs app automatically.
In other words, https://docs.google.com/document/d/somerandomhashhere/edit opens Safari, but Googledocs://https://docs.google.com/document/d/somerandomhashhere/edit opens the same document in Google Docs app.

Of course copying a link, opening Safari, typing secret protocol and pasting a link gets boring very fast.
This is where Apple Shortcuts come in.

If you didn’t know, Shortcuts is built-in application that allows you to write scripts in something resembling Scratch.
Interface is rather clunky and debugging is a PITA, but Shortcuts has two things that make it stand out: it comes with built-in interfaces to most parts of the system, and it allows you to run custom programs on iOS device without thinking about Apple development ecosystem.

Here’s a recipe for a shortcut I have created.
I won’t explain precisely how to create a new one and where to click to modify it, as such instructions are at risk of getting outdated really quick.
See also a screenshot of how full shortcut looks on my phone, below.

1. Add “Receive input from” action. In first placeholder, I unchecked everything but “Safari web pages” and “URLs”. In second placeholder, I checked “Show in Share Sheet”. I also selected that if there’s no input, it should “Get Clipboard”.
2. Add “Get text from” action. I have “Shortcut Input” selected here. I’m actually not 100% sure if this action is even needed. Maybe it just passes data verbatim to the next step.
3. Add “Combine with” action. In first placeholder, I have “Text”, which is a text from previous step. In second placeholder, I selected “Custom” and then typed “Googledocs://”. I feel I should be able to just concatenate two text streams, but I haven’t found more straightforward way of doing this.
4. Add “Open URLs” action. As only placeholder I have selected “Combined Text”, which is result of previous action.

When you click a name on top, you can change the shortcut name and icon.
There are no Google apps icons and only few predefined colors are available, but you can make up something that looks close enough to Google branding.

As far as I can tell, you can send Google Slides link to Google Docs app and it will still do the right thing.
So you probably don’t need more than single generic “Open in Google app” shortcut.
But if it ever stops working like that, or you like selecting apps explicitly, you may duplicate your new shortcut and create new ones for Google Sheets, Google Slides and Google Drive (for links to directories).
For reference, here’s a list of protocols that they use:

• Googledocs:// – Google Docs (text documents)
• Googlesheets:// – Google Sheets (spreadsheets)
• Googleslides:// – Google Slides (presentations)
• Googledrive:// – Google Drive (folders, directories)

Now whenever someone sends a link to Google drive on Slack, I can long-press it, select “Share…” and pick one of my shortcuts from near the bottom.
This automatically opens a document in specified Google app.

The post iOS: Opening Google Drive links directly in an app appeared first on Association for Software Testing.

A panel room supplier review is definitely the process of checking a vendor’s expertise and reputation. It also includes examining their particular software offerings to ensure they will meet the majority of, if only a few, of a company’s needs. The best board web site company offer a variety of tools to streamline the control process, which includes e-signature features, impair utility area, and video conference-calling. Their program should be quoted for mobile devices and provide a secure environment for your info. They should in addition have a tech support team.

values board meeting instrument allows users to share info securely and easily and execute meetings internet or offline. Its features include aboard book themes that match a meeting’s pattern that help directors get ready for meetings and make decisions during the function. Users can easily simpleboardroom.com/ also use the system to create and update digital advice books, schedule gatherings, and leave notes.

The board of directors is known as a group of people chosen by shareholders to oversee a company’s operations and protect all their passions. A typical mother board is composed of several subscribers who are tasked with developing a organization strategy, building governance, and ensuring that the corporation adheres towards the law. A board member’s duties also include maintaining close communication with the CEO and other executive representatives, facilitating strong management continuity, and preserving corporate dependability.

When choosing a board of directors program, you should consider the following factors:

The post Panel Room Hosting company Review appeared first on Context Driven Testing.

The post Panel Room Hosting company Review appeared first on Association for Software Testing.

Recently, Melissa Fisher asked a Slack community I’m in for ideas on creating successful workshops. Community members who are highly experienced in delivering excellent training and workshops shared some excellent tips, and I asked them if I could share them here too. They agreed, so here goes.

Training from the back of the room

Ahsley Hunsberger was the first to recommend my own favorite resource, Sharon owman’s Training from the Back of the Room. This book transformed my ability to turn my workshops into effective learning opportunities for participants. It’s based on science about how our brains work and how we learn. We learn by doing, using our hands, talking with others, moving around the room. We don’t learn much from one person just lecturing us. I personally did not apply all of her techniques. Some of them are things I wouldn’t be comfortable with myself, as a participant. Generally, Bowman’s guidelines have worked so well in my workshops.

Some examples of what I learned to do in workshops, thanks to TBR:

• Limit lecture portions to 5-10 minutes, followed by 15-20 minutes of hands-on activity
• Get people moving. Have table groups work with flip chart paper on the wall, collaborating with sticky notes and markers
• Mix things up, make each exercise a bit different. Have one with table groups, one with people paired up, have groups give each other feedback, get people walking around

The ADDIE model

Jenna Charlton says she loves the ADDIE model for developing training. She notes that some steps will be less relevant, since in a workshop setting, you haven’t been able to observe and identify the learning needs. Yet, you probably already know what it is, given that these people signed up for your workshop. I wasn’t familiar with this model before. I see lots of useful ideas there that I will try out.

Emphasize activity!

Fiona Charles, who’s been designing and facilitating workshop for decades, shared her expertise. i I’m just going to quote her:

Remember that people in a workshop are there to be participants, not to be an audience. Emphasize activity and keep your talking part to a minimum. Don’t schedule too rigidly and be prepared to abandon what you planned in favour of following the energy in the room. (You can guide it back if participants go too off-topic.) Most important is to remember to allow ample time for debriefing the exercises, to give people a chance to consolidate their learning, share it with everyone, and learn from everyone.

Fiona shared more details in her blog post a few years back, “How to Evaluate a Workshop“. Looking at your own workshop from the perspective of potential participants is helpful!

Be open to fun!

Trish Khoo recalled a particular workshop she facilitated at an Agile Testing Days conference. The helpful organizers asked her if she wanted anything for her session, anything at all. So, she asked for some silly hats. Which they delivered! She was able to work the hats into her workshop, which made it a little more fun. (As an aside, I highly recommend watching the video of Trish’s keynote at ATD 2018). (And for that matter, you can find videos of talks from Fiona, Ashley and Jenna on the AgileTDZone YouTube channel!)

Craft and practice effective exercises

My own advice to Melissa was this: People are responsible for their own learning. All we can do as facilitators   is create to an environment where they can learn. Applying the principles and techniques such as those in Training from the Back of the Room helps us do that. I find that crafting the exercises is the hardest, and most fun, part of creating a workshop. I much prefer doing workshops over talks!

Janet Gregory had an important suggestion: Practice the workshop exercises with someone before the conference. She often finds that what she thinks will work, doesn’t, or goes in a different direction than she anticipated. I try to find willing victims on whom I can practice new workshops. Either volunteers where I or my co-facilitator work, or teams at other companies who are willing to spend a lunchtime trying the exercises.

Be sure to get feedback from participants! My pairs and I like to keep it simple. Ask participants to write on an index card – what was most valuable? What was least valuable? And keep tweaking your workshop to make it even better.

Pairing FTW

Which brings up my best advice – find someone to pair with to design and facilitate the workshop! When I started out, I did them solo. I soon learned that pairing reduces my stress, is more fun, and provides a much better experience for participants. Since the topic is often my pair’s special expertise, I get to learn a lot about new areas!

For me, facilitating workshops is much less stressful than giving talks! It’s a good feeling at the end of the session to see that at least some people engaged enthusiastically in the exercises and helped each other learn some new stuff.

Many thanks to Melissa, Ashley, Jenna, Fiona, and Trish for offering their ideas to our community and letting me share them!

The post Ideas for creating successful workshops appeared first on Agile Testing with Lisa Crispin.

The post Ideas for creating successful workshops appeared first on Association for Software Testing.

Input validation is a topic that’s been following me around for years. I’ve came across countless resources speaking about the importance of input validation, or input filtering as it’s called at times. What stuck with me is the recommendation to validate any input coming from any source, no matter if we’re speaking about third parties, public interfaces we offer ourselves, internal services behind a firewall or accessible only from inside a private cluster. No matter if the input comes via clients, APIs, messages, data sources, or anything else. Based on my experience of working in testing and quality focused roles for over 14 years, I couldn’t agree more. All that makes a lot of sense to me. Not only from a security point of view, yet also from a holistic quality perspective as input validation can help prevent errors, improve usability, increase observability, and more.

Here are a few interesting resources speaking about input validation from a security standpoint.

• Tanya Janca‘s book “Alice and Bob Learn Application Security” includes a great decision tree for input validation.
• OWASP’s Input Validation Cheat Sheet offers a good introduction including examples.
• Kevin Smith‘s post on “Sanitize Your Inputs?” includes not only advice on input validation yet also touches on other topics to consider like sanitizing and escaping outputs.
• Cenk Kalpakoğlu‘s post on Defensive Programming Tips-1: Bad URL Handling Patterns showcases a specific example where validation is used as general mitigation approach.

Well. Seems convincing people to validate input is also a common challenge in AppSec; it definitely is in my bubble advocating for better quality outcomes. Most frequently I’ve seen these discussions when working with backend for frontend (BFF) services. This architectural pattern is often applied when you develop mobile applications, yet not limited to it. It is usually found along with having a bunch of downstream services that are all tasked with different duties. The BFF acts as the main entry point or proxy for a single client (e.g., the mobile app), hence only this API is public to the outside world. Any requests are routed through the BFF to the respective downstream backend services (which are usually protected further). Doing so, the BFF orchestrates incoming requests to different services; it can take care of authentication and authorization, as well as filter and aggregate data in order to respond with the needed information.

If you’d like to learn more about BFFs and see visual or code examples, I found the following resources useful.

• Pattern: Backends For Frontends by Sam Newman
• BFF @ SoundCloud by Lukasz Plotnicki
• BFF Pattern — Dos and Don’ts by Viduni Wickramarachchi
• Backend-for-Frontend: the demo by Nicolas Fränkel
• A Deep Dive into the Back-End for Front-End Pattern by Joydip Kanjilal

What about input validation for BFFs now? What I’ve heard frequently from colleagues can be summarized in the following statements.

• “The BFF is just an API gateway.”
• “The BFF should not contain any logic, just pass through anything it receives to the backend services and vice versa.”
• “Only the downstream backend service behind the BFF should validate input as it’s their responsibility, otherwise we replicate the same logic everywhere.”
• “Well, it’s okay for the BFF to do sanitization, yet not validation.”

Here’s my viewpoint, and I’m very curious to hear further opinions.

Any modular component of our system needs to sanitize and validate input coming from outside in order to prevent falling into an unknown state. This is both causing poor user experience as well as presents an attractive situation for malicious actors looking for further insights that can be used for exploits. Components include frontend clients in favor of usability, even though malicious actors can easily circumvent them. As long as there is an interface accepting data from another source, there should be validation. Under that premise, I do think that also BFFs should validate incoming data, especially from the public facing side, yet also from internal backend services or other data sources. The BFF is one of the first layers of defense we have, hence if input is validated, we leave the door less wide open. We cannot rely on underlying backend services having foreseen anything that could enter the system from the outside and having sufficient mitigations in place; especially if they are developed by other teams in other contexts who might not even realize the impact of their local decisions. Also, lots of people tend to underestimate threats coming from within the company, like malicious insiders or mere human mistakes. I do understand that it’s not always pragmatic or feasible to validate input on all boundaries. Yet if we have to decide, I choose validation at trust boundaries, like between the BFF as public interface and the outside world, as a minimum.

That being said: context is crucial, as always. Maybe the policy to only validate on the most downstream service works well in your situation. Maybe this is considered way too dangerous as you might be aware that specific services are not in good shape. Or maybe your product domain’s nature means you’re dealing with lots of confidential, sensitive data and you are more invested in keeping people out right at the door (aka the BFF API) without letting them any farther in. As usual, it depends on the risk appetite of the company, combined with your own ethics of what potential impact and harm you deem acceptable or not.

One thing I learned over and over again in my career is that arguments might convince rationally, yet they often don’t reach people in a way that they change their behavior. They usually need to experience it, and usually a few times (and I’m not excluding myself in this equation). The trouble with security and similar quality aspects: I want to prevent the experience of harmful impact as much as possible. Speaking of the topic of whether it makes sense to validate input also for BFFs. I could of course invest in exploiting lack of validation, or showcasing a close to real situation, yet it’s effort that still does not easily change the narrative and then behavior. If you have any further idea or tactic for these kinds of situations, your input is appreciated.

All in all, I do have a strong opinion on this topic, yet I hold it loosely enough to allow myself to be convinced by better ones. I did find posts that support my standpoint, like “Web App Security: Understanding The Meaning Of The BFF Pattern” by Syed Wahaj – yet that might be pure confirmation bias. So, I’d sincerely love to hear your thoughts and experience about this and learn more: should BFFs validate input?

The post AskAppSec – Input Validation appeared first on Association for Software Testing.

I often review and collaborate on unit tests at work. One of the patterns I
see a lot is this:

• there are a handful of tests, each about a
  page long
• the tests share a lot of functionality, copy-pasted
• the test data is a complex object, created inside the test
• the test
  data varies little from test to test.

In Kotlin-ish pseudocode,
each unit test might look something like this:

@Test
fun `test input against response for endpoint`() {

	setupMocks()
	setupTestContext()
	...
	
	val input = Object(a, OtherObject(b, c), AnotherObject(d))
	...
	
	val response = someHttpCall(endPoint, 
		method,
		headers,
		createBodyFromInput(input)
		)
        ...

	val expected = Object(w, OtherObject(x, y), AnotherObject (z))		
	val output = Object(process(response.getField()), otherProcess(response.getOtherField()), response.getLastField())
	
	assertEquals(expected, output)
}

...

While
these tests are generally functional, and I rarely have reason to doubt that
they’re useful, getting an idea of the intent versus the implementation of
each test, and the coverage of the tests as a whole, is difficult or
time-consuming, or both, and readers pay some kind of cost every time they
come to the tests. 

The machinery is in the way of the work. Rage!

At its heart, the example above is
checking, for some function, that an input (a, b, c, d) produces an output (w, x, y, z). So, what I try to do, if the investment seems worthwhile given other
priorities, is refactor to separate the test machinery from the test data.

For
our example, it might look something like this:

@ParamterisedTest("testDataSet")
fun `test input against response for endpoint`(testData) {

	setupEverything()
	
	val input = createInputObject(testData.input)
	val expected = createExpectedObject(testData.expected)
	
	val response = callEndpoint(input)	
	val output = extractOutputObject(response)
	
	assertEquals(expected, output)
}

fun testDataSet() {

    // each row is a pair of input, expected output
    val testData = [
		([a, b, c, d], [w, x, y, z]),
		...
		]
}

This
has a single unit test that loops against rows of data (in testDataSet) and
boilerplate is moved to standalone functions with intentful names.

Key
to this for me is that the data appears as cleanly as possible in the test
data set. I want to have only the stuff that varies in the test data and all
the constants factored away. This means that once I understand the function
being checked by the test, I can review the data alone and look for patterns or missing cases, and adding new cases is quick.

If I feel I need it, I can add
names or comments as part of the data and dump it on failure. I might also
use formatting to make the visualisation more helpful:

testData = [
		("customer C special case", [a, b, C], X),
		("vanilla case",            [a, b, _], Y),
		...
		]

If you’re thinking that this
looks like data-driven tests, you’re right. One of the things I enjoy about
frameworks like Karate is that they have a human-readable syntax for this kind of setup that removes even more boilerplate noise:

		| case                    | input     | expected|
		| customer C special case | [a, b, C] |     X   |
		| vanilla case            | [a, b, _] |     Y   |
		...

I think this is a healthy way to set up the unit
tests when there are sets of similar cases that vary only in data.

But there’s another benefit too: this is effectively a little test
rig inside the tests and I can use it to explore the feature that I am
testing. See The Love of a Loop and a List for more on that. This
means that part of my calculation about whether it’s worth performing the
refactoring is the extent to which I think it might help me to test right
now. 

If I decide that I can’t pay the refactoring tax, but think it might still be useful to explore from the unit tests, I can parameterise one of the cases and write a for loop that calls it with my data. Yes, that sounds horrid but it’s throwaway code, created to help me answer the questions that I want to ask the system under test.

The machinery should serve my needs, not trigger my rage.
Image: https://flic.kr/p/2mtwLRd
Syntax highlighting: Pinetools

The post Rage Against the Machinery appeared first on Association for Software Testing.

I’m used to seeing my feeds (especially LinkedIn) full of “automate everything” nonsense posts in the field of testing. This stream of misinformation seems to be flowing ever faster as more and more folks jump on the AI bandwagon, whether it’s in “testing tools leveraging AI” or the use of LLM models such as ChatGPT to reduce or remove the need for those pesky human elements of testing.

It’s less common to see this “automate everything” mantra in the mainstream news, so I was somewhat surprised to read an article in Melbourne’s The Age newspaper recently, titled “ASIC wants to ‘intelligently automate’ everything. Experts aren’t sure that will work” and written by Charlotte Grieve.

She writes:

The Australian Securities and Investments Commission (ASIC) has listed “intelligently automate everything we do” as one of five principles of its internal digital strategy, according to documents obtained by this masthead [The Age] under freedom of information laws.

One of ASIC’s key roles is to investigate reports of serious misconduct and its existing use of automation in this regard has already been criticized:

The use of automation within ASIC garnered controversy earlier this year after liquidators claimed reports of serious corporate misconduct were dismissed in as little as 38 seconds, allowing thousands of company directors to avoid scrutiny over five years.

The article goes on to quote Helen Bird, part of ASIC’s corporate governance panel:

Bird … warned the technology behind automation and AI was not ready for wide deployment within the regulator.

Bird said it was inevitable that AI would eventually be used across all regulators because of the significant cost-saving opportunities from removing time-consuming manual tasks and reducing or redeploying staff.

It was only a matter of time before “manual” entered the narrative here, just like when reading the automation versus “manual” testing posts littering my feed every day. Despite the problems already identified with trying to automate the difficult task of investigating financial misconduct, in this case the regulator seems intent to go further down the automation and AI path – but maybe we can take solace in the fact that at least they’ll be doing it “intellgently”. Ironically:

Earlier this year, [ASIC chair] Longo warned traders and investment banks against rushing to use artificial intelligence technology. He said inappropriate use of AI could create “unintended consequences” if adopted without proper controls and governance.

It’ll be interesting to see how ASIC’s journey to “intelligently automate everything” pans out. In the meantime, in case there’s any confusion about whether software testing can be completely automated, I’ve covered this topic in a previous blog post, Common search engine questions about testing #5: “Can you automate software testing?”

(Photo by Nick Fewings on Unsplash)

The post “Intelligently automate everything” appeared first on Association for Software Testing.

I nearly didn’t go to SoCraTes this year, the “International Conference for Software Craft and Testing”. My speaking budget was already
strained, my schedule overbooked, and it would have meant going on vacation
time. But then the organizers reached out and offered me yet another slot on
the training day this year. They were even fine with me giving a workshop I
already had prepared, and I changed my mind. I seized the opportunity and went to
SoCraTes on vacation. What can I say, I don’t regret it one bit! Granted, I’m
super tired, and at the same time I’m super happy. It was so much worth it and convinced me to reserve this time of the year for 2024 as well!

Coming Back

It’s always super exciting to join a conference for the first time. The second
time around, a few things are already clear – you know the venue, more people,
the procedures and other things that reduce your cognitive load. Still, the
second time is curious as well – how will they welcome me this time? How
easily can I reconnect to where we left things last year?

The first moments are awkward for me, at any conference. At SoCraTes, this
very quickly vanished into a feeling of belonging. I felt welcomed, I was included, I had a right to be there. This is the foundation for everything
coming afterwards.

My first contact after seeing familiar faces at registration was a person
being there for the first time,
Lydia Leifels
– such a pleasure right from the start! At dinner, I met dear
people I already know for a while, like
Tobias Göschel, Thierry de Pauw (along with their daughter),
Juke Trabold,
and
Woody Zuill. There were so many awesome folks I got to know or meet again over the
course of the conference! Like Janina Nemec, Marc Kalmes, Stefan Scheidt, Claudius Link, Lea Rosema, Waldemar Tomme, Martin Schmidt,
Markus Tacker – well, the list could go on and on.

Training Day

The second edition of the training day was even better than the first one.
Trainers were amazing both times, yet for this year organizers listened well
to the feedback and crafted a schedule of three tracks with each session
having enough time to dive into the topic and generous breaks in between. Just
awesome. Here’s the choice of sessions I made.

• “Enforcing Architecture Using Tests” by Javiera Laso. This was the first time I heard about
  ArchUnit, a
  library to check for conventions like file names, structure, dependencies
  and more.  Writing tests was quite straightforward, and I can see how these could
  support maintainability and reduce friction by codifying agreements.
• “Modernize CI/CD Session” by
  Raimo Radczewski
  &
  Chris Neuroth. Very interesting talk sharing fundamental principles for a pipeline
  optimized for quick feedback while going small, safe steps. They
  demonstrated live how fast a change can be on production. A few statements I really related to were these:
  “minimize the time from code written to code on mainline, deployed
  to real users, running in a real environment, ready to be
  evaluated – there is no other way to develop software
  sustainably”, “influence the loops you can”, “the moment we stop
  slicing we deliver slower”, “skip the review, pair with someone”.
• “Ensemble Exploratory Testing” by me. Fun fact, I’ve given this workshop now
  for the 10th time so it became my most repeated conference session ever so
  far. Good thing is, it seems it doesn’t get old! This time again, people were eager to join and seemed to enjoy the learning experience (which hopefully convinced them to try
  new approaches back at work). Well, I had fun observing people having lots of aha
  moments together.
  
• “Take a mess, make a mess, fix the mess” by Aki Salmi. A very interesting session on refactoring code that’s untestable and contains hidden
  domain concepts, code that’s still valuable yet needs to be modified. How?
  Together, we tried an approach many of us had not seen before: not even
  trying to understand the code in the first place. Instead, using the IDE’s automated refactoring tools to slice
  it up first, turning hard to test code into easy to test code. Then we
  can document its behavior in tests, and hence gain our safety net to make
  the required changes. Check it out, you can
  follow every small commit Aki made.
  Nicolas Carlo
  also wrote a great post on this where you can follow an example: “Another way of refactoring untested code” (by the way, his newsletter is super insightful and a clear
  recommendation).

After the training day ended, the main part of the conference was opened with a world café.
Find a group of people you don’t know, take a question as starting point, see
where the conversation leads you and doodle your insights on a shared canvas. After a given time box is over, everyone find themselves new groups besides one person
staying at the table and getting the newcomers on the same page. Repeat until
you finished three rounds. Really nice exercise, perfect to get to know first
people ahead of the main conference part and have interesting conversations
emerge. One main theme we had was on people, community,
culture and how that’s foundational. In case you’re wondering where to start,
I have a
resource collection on inclusion
that really helped me.

That’s not the end of the day, of course – SoCraTes goes all in! Everyone is
at the same place, we’re together the whole time, so of course there’s an
evening / anytime during the night / morning schedule with bonus activities
suggested by anyone. Such a good thing our hotel rooms are right there to
retreat and rest any time. I love how Juke as facilitator and also organizers
continuously emphasized the importance of caring for your needs and taking
breaks.

Having learned from last year that joining all sessions can be quickly very exhausting, I decided to use the evening time for conversations and enjoying
both atmosphere and company of wonderful people.

Open Space Day 1

Days start early at SoCraTes for me being a night owl, yet it’s worth it. In
its core it’s an
unconference
offering an open space for everyone to bring their topics. Things they want to
share, conversations they’d like to have, apps they want to build, tools to
try out, skills to practice – and also challenges they’d like to get help on. With so many different people, there’s a whole range of topics offered, covering a spectrum of deep dive tech
topics to humans and culture as foundation for everything. No matter if it’s
very personal, related with our professions, challenges in society, or all combined, everything is represented. There are also sessions like doodling together, painting your nails, talking about sheep, whatever is most valuable to people right now. Be
prepared to be surprised! This format of building your own schedule together
on the fly works amazingly well. It definitely worked out well for me again
this year.

• “Web accessibility – building beautiful web sites that don’t make you puke”
  by
  Njan Völker and Lina Sievering. I had hoped to learn more about accessibility at
  the conference, and already the first session was right on spot! Awesome workshop focused all
  around motion sickness induced by websites and apps. A topic close to
  my heart as I’m affected myself. Njan and Lina provided mindful and
  enlightening exercises to convey the problem and think of more accessible
  options together. Thanks to them, I also learned about the
  European Accessibility Act becoming effective as of 28 June 2025
  – which means accessibility will be enforceable in Europe which hopefully gives us more
  leverage for accessible solutions when making product decisions.
  
• “Capture the flag together” by me. As part of my personal AskAppSec challenge, I recently tried out further services offering hacking labs like
  TryHackMe and
  Hack The Box to practice penetration testing. The
  first challenges were good fun to me, so I thought why not offer a session
  and do it together during the open space. I was
  positively surprised how many people came and joined me! I opted for Hack The Box and their starting point machines. It worked super well, people were
  engaged, shared lots of knowledge and we captured a flag together (the
  second we missed only due to my VPN interfering). A very insightful
  experience, validating my assumption that there’s interest and these could
  be great sessions for more people to learn about security in a fun way.
• “Security for devs (& everyone)” by
  Claudius Link
  and me. The more security sessions the better, right? So why not host another one,
  together with Claudius who had the same idea. We had a great conversation
  with people bringing up all kinds of insights and common challenges. Nothing was immediately new
  for me, and yet it was validating to hear experienced people share similar
  views.
  
• “Documentation as Code” by
  Markus Decke. We work together at the same company, and we are transitioning to having
  more and more documentation as code, so I was curious about other people’s
  ideas, struggles and in general experiences. We talked about benefits and
  use cases, shared tooling options and their limitations. One of the main
  themes was around what problem we’re trying to solve and then aim for
  tackling exactly that, nothing else not to document only for the sake of documentation.

What about the evening? Well, after open space is before open space! As mentioned, there’s
always an evening schedule people are building up. Once more, I opted for dinner,
conversations and more fun time! Last year I discovered that Janina Nemec is an absolutely pro in playing Set, a card deck game I’ve learned to love
through the testing community. At first we didn’t spot any deck so decided to opt
for a round of Exploding Kittens (so much fun) – and finally discovered a
Set deck in the end. Well, next year we’re prepared to bring our own decks.
Such a good way to close the day.

Open Space Day 2

New day, new schedule. Every day starts a tiny bit later, which is still early for me.
And yet it was awesome again and worth the early start.

This was the last day for the main part of the conference, so we closed it
with a retrospective. The best part here was that it didn’t merely gather feedback for organizers and Juke as facilitator, it also was  intended to provide feedback for each other as participants. Over half of my
group were here for the first time, and I just loved hearing their feedback
and also input to make it even better for each other.

A gratitude round followed. The challenge was to thank five people we have not
thanked yet. Honestly, this experience was a bit overwhelming, in all the best
ways – and more than one feedback took me by surprise. I haven’t mentioned
yet, this conference goes big on hand-written kudos cards you can hand out any
time for anything you appreciated the other person doing. The ones I received
I will keep with me for long, they present such a dear memory.

Dinner followed with more great conversations. Then further sessions were hosted (remember, the evening schedule). I had a great time joining a code
kata ensemble. We did the “Vending Machine Kata” which was an insightful exercise itself, yet my main takeaways were on the
collaboration part. It was fascinating to see an ensemble start off quite free
style and converge to more structure like having a dedicated navigator, using a timer
for rotations, having the navigator stand up to be more prominent, etc. It just
worked better with folks who have never worked with
each other in this way. Also, we used the fish-bowl approach to ensembling, having outside observers and always open spots to join the ensemble. This
exercise made me realize once again that this approach is simply not for me,
despite having super kind and safe people around me it felt exclusive. I’m
very sure it’s actually more inclusive for other people to opt in. For me I much prefer
the “all together just one ensemble without observers” format.

Last but not least, a retro gaming session! We played the old adventure game
“Zak McKracken and the Alien Mindbenders” all together on a C64 system provided by Tobias Göschel – how
awesome was that?

Workshop Day

Have I said the conference is over? There’s still the additional workshop day!
And what better format to have than asking people to bring their topics for hands-on
sessions also on this day. It’s also the time of the traditional code retreat, practicing the whole
day solving the same kata in various ways. Originally, I was adamant to join the code retreat again, it was simply
an amazing experience last year. And then Claudius Link came and suggested the only thing that could possibly lure me away:
co-facilitating a security workshop. Well, what shall I say? I couldn’t
resist, this fit way too perfectly to my
personal AskAppSec challenge
this year.

We aligned on our main thoughts of what to aim for, pitched it to a fellow
participant, incorporated the feedback, and came up with a workshop on
“Painless Security”. We crafted the agenda shortly before and went
ahead with it, playing it by ear and experience in giving workshops. Having
co-hosted a session the other day helped, too. Co-facilitation worked super
well together, we often thought along the same lines and built on each others
ideas. People shared many painful experiences and we gathered potential things
to try out and what we related with most to bring back to work. I took a lot
with me myself.

During lunch time, the security theme continued for me. First thinking about security
conferences and ideas to contribute to the space together with Claudius Link and Susanne Neunes. Heading back towards the conference rooms, I noticed another table
where Martin Schmidt and Philipp Zug, who also both participated in our security workshop, were scheming on a new
security card deck. I loved the idea and they were so kind to invite me in.
Well, it seems I got myself involved in two new topics – and yet I feel these
are very much worth it.

I decided to check out what other sessions might still run that I could join.
First, coffee though – and that’s when
Matthias Klass approached me and asked whether we might have another capture the flag
session together, as a couple of people expressed their interest. Well, I didn’t need to
check the schedule anymore, security theme it was for the whole day! Of course
I’ll host another capture the flag session. What can I say, it was awesome! We
spent the whole time until we officially had to leave the room and head
for dinner. Nearly instantly, the idea popped up whether we could ask the hotel for opening
the room once more during the evening. Asking was worth it, we got the keys
and went all in after dinner. Many more rounds of capturing flags followed
until everyone was so tired we couldn’t think anymore – while being just super
happy. Some of the challenges tackled were very familiar to us and hence solved a lot faster, others required us to piece
together knowledge we usually don’t need. All of them were very insightful and fun.
So much fun. I loved that we all worked together so effectively as a big ensemble again. I really want to do more of this.

There’s a traditional count of code katas done at SoCraTes, counting each
exercise by everyone. I was really moved seeing so many people join me on
practicing penetration testing, staying with me for so long and sharing my
enthusiasm. It felt we just established a new counter at SoCraTes next to the
code kata counter: the captured flags counter, aka the number of security
secrets discovered. We collectively increased it to 8 overall! 

Why again next year?

Heading home, my heart was full, my brain energized, my body tired, and me
super happy. I was certain that if I have any chance to be back next year I
will take it.

Besides the obvious reasons of self-selected, very insightful content and just
amazingly kind and inspiring people, there’s a reason that is even more important. This
conference is the best I’ve seen so far in intentionally designing welcoming
and inclusive spaces. They continue to reduce friction and make it more
accessible and safer to more and more people. Literally every year. There are
lots of aspects of this to be found everywhere. Not only in the code of conduct
that’s actually being lived and enforced, or offering all gender toilets, or giving away tickets based on a lottery to level the playing field. It’s
in every little detail. Less noisy applause by waving hands. Exact food labelling
and plenty of options for everyone. Child care service so lots of parents could
join this year. Sharing Covid tests upfront for every day and encouraging
masks.

The level of diversity already achieved has a huge positive impact on the
quality of conversations and insights gained. A lot to learn and take with me
to do better myself.

The post SoCraTes 2023 – A Place Where I Belong appeared first on Association for Software Testing.

When I reflect back over my career and who I reported to, it has been defined by a lack of test managers.

My first two jobs were for large finance organizations: insurance and banking. In both orgs I reported to a "QA" Manager. I never saw a career ladder but testers could progress into management. I remember testers holding roles up to the VP level.

The only other time I saw a test manager in my career was at my fourth job. My small startup was acquired by a big telecom company. Shortly after we got acquired I flew to India for several weeks to train the testing team on our product. The test teams in India were large and they had several test managers.

That was it. The rest of my jobs have been at startups where I was usually the only tester. To date, this equates to 25% of my career where I’ve had a direct manager with experience in my discipline. (Technically I also reported to a manager who started his career in testing and that was nice. He had lots of insights and practical understanding of testing).

Challenges

From what I can tell there have been two challenges to this:

1. I’ve had to look outside my organizations to develop my testing skills
2. I’ve never seen an exemplar test manager

Looking outside of my organizations to learn turned out to be a good. I found online testing communities. They led me to conferences, blogs, books and training programs like BBST and RST. Lots to learn from and challenge myself with. Most testers don't have any testing education and I avoided that trap.

A few years ago as the startup Promenade was growing, I built a few test teams and became a test manager. Having never seen an exemplar test manager, I was a bit lost. I did some research online and tried things and reflected back on the good managers I'd had.

I created a Community of Practice, built a career ladder and pushed my people to learn more about their craft. I spent time 1:1 talking and working on their problems. I emulated the good managers I knew and got coaching from my current manager. I also started reading books and blogs about management with the hope of taking some courses in the near future.

Shortcuts

Good managers give us shortcuts. They help us understand bigger problems and grow in our positions. Despite the lack of reporting to test managers I've found good managers that supported, challenged and helped me grow. That's what I look for and recommend others do to.

The post What’s a testing manager? appeared first on Association for Software Testing.

Last week, I had the pleasure of being a guest on the Test Automation Experience show with Nikolay Advolodkin. In this episode, we talked about RestAssured.Net, I released version 4.1.0 during the podcast, and we discussed some features that have been added to the library in the last couple of releases.

If you want to watch the episode, you can find it on YouTube here.

In this short blog post, I want to highlight the most important new feature of RestAssured.Net version 4.1.0, which is the ability to inject a custom System.Net.Http.HttpClient (docs) into your tests.

Where is this useful?

By default, RestAssured.Net creates its own HttpClient to send the requests you create using the fluent syntax that the library provides, for example:

[Test]
public void GetDataForUser1_CheckName_ShouldBeLeanneGraham()
{
Given()
.When()
.Get("https://jsonplaceholder.typicode.com/users/1")
.Then()
.StatusCode(HttpStatusCode.OK)
.Body("$.name", NHamcrest.Is.EqualTo("Leanne Graham"));
}

In many situations, the default HttpClient created by RestAssured.Net is perfectly capable of running the tests you want to perform.

In some cases, however, you either

• are working with a framework that provides and manages its own HttpClient, most notably Microsoft.AspNetCore.Mvc.Testing, which can be used to write tests for ASP.NET Core APIs
• want to do some custom configuration on the HttpClient and/or the associated HttpClientHandler (docs)

In those cases, it would be useful to hand-roll an HttpClient and inject it into your RestAssured.Net tests.

And that’s exactly what you can do starting from RestAssured.Net 4.1.0:

[Test]
public void UsingACustomHttpClient()
{
var webAppFactory = new WebApplicationFactory<Program>();
var httpClient = webAppFactory.CreateDefaultClient();

    Given(httpClient)
    .When()
        .Get("http://localhost:5154/weatherforecast")
    .Then()
        .StatusCode(HttpStatusCode.OK);
}

This example contains a test for an ASP.NET Core minimal API, which is contained in the Program class. To be able to write efficient tests, where the Microsoft.AspNetCore.Mvc.Testing library handles managing configuring and starting and stopping the API in-memory, you’ll need to use the HttpClient returned by the CreateDefaultClient() or the CreateClient() method.

As you can see, RestAssured now supports this by passing the HttpClient as an argument to the Given() method. If an HttpClient is supplied, RestAssured.Net will use that one, if none is supplied, it will generate its own and use that to send requests and receive responses.

I’m very happy that this feature is now finally available in RestAssured.Net, because I believe that it makes the library much more versatile, and it opens up a lot of new use cases.

As always, I’d love to hear what you think!

The post Using a custom HttpClient in RestAssured.Net appeared first on Association for Software Testing.

In my recent experience, I’ve found a few things that help set up a successful collaborative testing session. I’ve used these to collaborate with members of my team, across multiple disciplines from Product and Data, to Software Developer, for context I’m the only software tester on my team, but not the only one doing testing. I’ve also used these techniques when setting up cross-team session…

The post Successful collaborative testing sessions appeared first on Association for Software Testing.

When I opened Blogger the other morning I saw that the Hiccupps all-time page view counter had ticked up to exactly 500000.

My initial feeling was pleasure. Ooh! A milestone! Half a million views! Get me!

But that was fleeting. 

As with many metrics, today’s value is almost the least engaging aspect. What’s more interesting is what the number represents, what it is desired that it should represent, and how closely those two concepts align on axes that matter.

Also interesting: who wanted this metric (and there may be multiple interested parties) and whether they still want it, what assumptions are being made about it, what values (or milestones) matter, what it is being plugged into, and what decisions are made using it.

That’s not all, of course, because one sample is just one sample. More interesting is where it sits in context to others, if and how it is trending, and whether it correlates with relevant related metrics over the same period.

I could go on.

I don’t know how Blogger calculates these page views. I know that I’ve experimented a handful of times over the years and found the counting to be unreliable and inconsistent with the Google Analytics data that is also provided. 

I’ve also seen posts get published and immediately have tens of page views which seems at best unlikely. So I’ll continue treat this number with the same caution that I do lots of the metrics I encounter. 

But that doesn’t mean I can’t take anything from it. For example, I think it’s a reasonable assumption that something related to views is being counted because I see a rough correlation between an individual post’s page views and its level of engagement on social media.

I think I can say that people are reading my posts still, and that, since Twitter went off the rails, they are probably doing it less than they did before.  Which is interesting, but not enough that I’m going to try to do anything different over here. 

So, 500k? Yeah, it was definitely fun for a minute, and my immediate reaction shows the power of culturally significant values, but really in my logical mind I’m thinking more five hundred? schmivehundred!

The post Schmivehundred! appeared first on Association for Software Testing.

So, a couple of months ago, just before summer, I started a new part-time project with a financial services provider here in the Netherlands. They were looking for someone to help two of their testers grow into automation engineers, and someone else within the company (who I worked with on a different project ages ago) referred them to me.

Now, apart from the corporate training courses that I provide, I’ve done some 1-on-1 or 1-on-2 mentoring earlier in this year, but the time we would be able to spend together was much more limited, i.e., about an hour, sometimes 2, per week. This engagement, however, would be for a full day every week, which obviously means there’s much more time for learning, for practicing, for building solutions, etc..

I think it’s amazing that there are still companies out there that want to invest in this way in their employees. I mean, it’s not cheap to hire someone like myself for 8 hours per week, for 5-6 months (right now, the contract we’ve got runs until the end of 2023), all to train two of your engineers in test automation.

But I think it is a very smart move from this company.

First, they agreed to onboard me as any other contractor they bring in, meaning I have access to their systems, their applications and their environment. This makes a big difference in the effectiveness of the training and the learning we do together.

Normally, as a trainer, I don’t have this kind of access, which means that the exercises we run in a ‘standard’ corporate training session will be hypothetical and fabricated by me. I’ve learned that one of the biggest drawbacks here is that it’s often hard for people, especially those less experienced, to relate what they see and learn to their daily work.

In this case, however, we are working in their environment, writing tests against their systems, from day 1. This means that every exercise we do, and every test we write, brings value in two different ways:

• That test teaches their engineers something they didn’t know how to do before, and thereby improves their knowledge, experience and skill set, AND
• That test increases the coverage of their actual systems

But it gets even better, since we run all tests as part of an automated nightly build, so that test delivers value over and over again. And yes, of course the engineers also learned how to set this up themselves. They did all the work, I just showed them how.

We could have never created this value, and this connection between what the engineers learned and how to apply that to their own daily work, in a ‘traditional’ corporate training course.

A second reason why I think this is a very smart move from this company is that it shows their employees that they are really willing to invest in their growth and their career. Having been an independent consultant for close to 10 years now, I’m not too familiar anymore with the way full time employment works, but I’m pretty sure that these engineers will not complain about the opportunities to learn new things that their employer gives them. It certainly beats giving someone a Pluralsight account and an instruction to ‘go figure it out yourself’.

So, that’s a lot of value for the company, and I think it’s a great return on the (again, substantial) investment that they are willing to make.

Seeing these engineers grow more skilled and more confident from week to week is amazing, and it makes this gig one of the most enjoyable experiences I’ve had in my career so far. I get to work with others and see them grow, I get to see how a reputable company approaches their testing and automation, I learn new things myself as well, and I get paid for it. Not bad!

I’d love to work with more companies and their engineers in a similar way in the future, so I’ll definitely start spreading the word about this project (this blog post is just one of the ways to do that) and see if there are other companies out there that are interested in investing in their employees in this way.

Again, it’s not cheap, especially compared to a Pluralsight or Udemy account, or even compared to a ‘traditional’ corporate training course for a larger group of people, but the return on investment is way, way better.

So, if you read this and you or your company is looking to grow a few (I’d say max 3) of your engineers in a similar way, please do get in touch. I’d love to have a chat and see if we can work together.

The post An alternative to corporate training appeared first on Association for Software Testing.

Each month I artisanally handcraft a newsletter for TestingConferences.org. In it, I summarize upcoming conferences and workshops, calls for participation and discounts. I put pressure on myself to deliver them consistently since they are sponsored.

Creating the newsletters is difficult. It takes hours to pull out the information, check to make sure it’s up to date and then format it for MailChimp. (That’s why I refer to them as "artisanally handcrafted".)

A month ago I decided to see what parts of that process I could automate. The script wouldn't need to do everything I do, only help do a few things.

This is roughly what I do:

1. Open _data/current.yml
2. Grab the data for the conferences in the newsletter (e.g. all events in July, August, September)
3. Grab the data for any events with a status of CFP
4. Grab the data for any events with a status of discounts (Early Bird, Super Early Bird, etc)
5. Copy all that data and paste it into many sheets in Visual Studio Code
6. Start to remove all the yaml formatting → remove quotes, dashes, keys, and upper case a few words
7. Remove the twitter data
8. Check each link to make sure the data is up to date. When it isn’t, update it and push the updates forward
9. Copy the name, date, location, status and URL and paste into the sections of the newsletter based on month and/or status. Hope Mailchimp doesn’t crash in the process

I haven’t written Ruby for a long time but TestingConferences.org is written in it. This seemed like a good use case for GPT by OpenAI. I'd break down what I need the script to do, GPT would compose it and then I would test and iterate on it.

A Quick Script

I shared a partial current.yml file with ChatGPT to provide context. I asked it to create a ruby script that would iterate through the key:value pairs and delete the rows with twitter data in it. Great, that worked right away and it only took a few minutes.

Next, I want the script to locate the monthly data I need. I asked ChatGPT to update the script so it asks me for a month, finds all events with a matching month and writes them to a separate text file.

In about 30 minutes I was able to create a script that handles items 1, 2, 7 and part of 6. (I have the script removing quotes from the date field. More to do with that going forward.) Each time ChatGPT would spit something out, I would test it. There were small problems but nothing I couldn’t fix.

This is the code it generated (albeit with a few changes for myself):

require 'yaml'

yaml_data = File.read('../_data/current.yml')
conferences = YAML.safe_load(yaml_data)

print 'Enter the month: '
input_month = gets.chomp.downcase

filename = input_month + '_conferences.txt'

filtered_conferences = conferences.select do |conference|
  dates = conference['dates']
  next false unless dates.is_a?(String)

  month = dates.split(' ')[0]
  month.downcase == input_month
end


filtered_conferences.each { |conference| conference.delete('twitter') }

modified_yaml_data = YAML.dump(filtered_conferences)

File.write(filename, modified_yaml_data)

puts "Output saved to #{filename}"

After this script worked, I wrote a second to handle items 3 and 4. It took roughly an hour to create some tools to help reduce the amount of time I spend on a regular task.

The Value

It would have taken a lot longer for me to figure out how to import, decode and re-encode yaml on my own. Even though I had to correct obvious bugs, ChatGPT added a lot of value.

We often get sold a storyline of automation replacing the work of a human. However, this is a good example of the power of AI helping extend capabilities. There’s a lot to be gained by professionals who can leverage these tools effectively.

Did you know TestingConferences.org is an open-source project that anyone can contribute to? If you are looking to get involved in the project, it’s pretty easy to update the list of conferences. This makes it an easy introduction to using git, GitHub and making changes.

The post Using ChatGPT to help write scripts appeared first on Association for Software Testing.

In our new Agile Testing Fellowship Donkeys & Dragons video chat episode, Janet Gregory switched from being co-host with me, to being a guest with Selena Delesie! We talked about assessing quality practices with their Quality Practices Assessment Model, aka QPAM. Selena and Janet explain how they came up with the model. They explain the quality aspects and dimensions, and give a brief overview of how to use it. we talked about the benefits, too. And their books about QPAM! Lots of information in just 18 minutes, I hope you will watch!

I’ve used the model and found it so effective to help an organization see where they are in their quality journey. It’s a great way to understand where to focus efforts to improve quality practices. I wrote about my experiences in my post “Enabling better quality”.

Are you curious where your team or organization stands in its ability to delivery a quality software product consistently and confidently? Book some time to talk with me. I do quality practices assessments for engineering organizations remotely. If your team wants to self-assess or you want to facilitate one yourself, I can give you some guidance.

The post New video chat: Assessing Quality Practices with QPAM appeared first on Agile Testing with Lisa Crispin.

The post New video chat: Assessing Quality Practices with QPAM appeared first on Association for Software Testing.

In October of last year, I met Andrew Knight at the 2022 AutomationSTAR conference in Munich. It was great to finally meet him in person, and during one of our chats, he asked me if I’d be interested in creating another video course for the Test Automation University platform.

I’d already done one on REST Assured back in 2019, so I knew what I signed up for… Through creating that course, I learned that doing video is hard work, and that it takes a lot of time to do it well, so I wasn’t immediately jumping at the opportunity.

However, when Andy said he was specifically looking for a course on BDD with SpecFlow, I knew I had to say ‘yes’, simply because

• I love SpecFlow and know the people behind SpecFlow quite well, and it is a tool that I think deserves more attention
• I think there are a lot of courses (and a lot of content in general) out there that don’t do justice to SpecFlow and to BDD in general

So, while the title of the course would have ‘SpecFlow’ in it, I proposed that we didn’t just focus on SpecFlow as a tool, but also take the time to explain the process of BDD in general and how SpecFlow (and other tools) fit in there.

It has taken me much longer to create the videos for the course than I expected, and I can really only thank Andy for being patient with me for the months I went over the initial deadline.

But, the good news is: the course is live and available for all to enjoy and learn from.

And, as with all Test Automation University courses: it is completely FREE.

I’m really, really happy with how the course turned out, and thanks once again to the Applitools team for giving me the opportunity to do this, and for making it look as good as it does.

You can find the course at https://testautomationu.applitools.com/bdd-with-specflow/

I would love to hear what you think!

The post My BDD with SpecFlow video course is live! appeared first on Association for Software Testing.

When my dad retired around 20 years ago, I got him a second hand PC and have been serving as first, second, and third-line tech support for him and occasionally his mates ever since. 

He’s an inveterate story teller and, for a laugh, one time I told him he should write all of his tales down and give them numbers. Then, instead of telling them (again) he could just say the number and we’d all laugh, saving everybody time.

Well, he called my bluff so I’m now mid-way through editing a 300-page Word document he sent me and if I ask him about a detail of one of the stories, he recounts the entire thing. Clearly my idea has backfired spectacularly.

Even funnier, this opus only describes his early life in Smethwick and the various jobs he had
between leaving school with no qualifications and retirement. Our family stories are in another epic file I haven’t even seen yet! The joke is well and truly on me.

Still, the pages are full of gold and here I’m sharing an escapade from the 1960s while he was working as a telephone installation engineer at the GPO, the General Post Office, later known as British Telecom. This one reminded me so much of what I do, in terms of getting a report of “it doesn’t work,” taking testimony, finding evidence, observing and checking behaviour, experimenting to generate data, and reporting what I’ve found to to stakeholders. The quick and ugly solution was sadly familiar too. 

I hope you enjoy it and my Dad does too.

–00–

The GPO supplied and fitted several types of extension bells
ranging from a small bell for home use, through a six-inch gonged bell for
noisy places, up to a mains-operated klaxon hooter, and a DC (direct current)
bell for VERY LOUD locations.

Right, lecture over. 

I went to Albion Bottle in Rood End
Road, Oldbury, to move a 24-inch DC bell. In the factory where bottles were made
the noise level was immense but the workers would soon be aware of a new noise on top.

The foreman’s office had been moved and so his phone and
bell had to be moved too. This was no problem at all but re-hanging the bell
was something of a chore because it took two people. That being said, we
connected everything up and received a test call. All was working,
and the foreman was happy, so we packed up and went to the next job.

A couple of days later Albion
Bottle reported the bell not working correctly. I called in to find out
what was wrong and the foreman told me that it only rang intermittently.
I went down the factory and looked at the bell but an inspection showed
nothing untoward. I arranged for a test call and the bell went
off as expected.

The foreman agreed that the bell was working just then
but he said that once I had gone it would stop. So, I hung around in the switchboard
room for a while and, sure enough, the foreman called to say the bell wasn’t
working.

I went down the factory again and quickly discovered why.

One of the workers, Big Dave I think his name was, built like
Desperate Dan, was sitting beneath the bell reading his paper and drinking his tea. 

He looked at me and said “if you think I’m sitting here while that goes off
you’ve got another thing coming.”

He had stuck a piece of card between the hammer and the
gong.

I looked at this giant and said “no problem, mate.”  Then I went back and told the foreman what was
causing his intermittent fault.

Albion Bottle arranged for the bell to be moved higher up the wall out of anyone’s reach.
Images: Society for Historical Archaeology, Mighty Ape

The post The Bell at Albion Bottle appeared first on Association for Software Testing.

Ahh, summer holidays. The time to relax, take a break from work, spend more time outdoors and with family, and also the time to take a step back and think about what you’re doing, where you’re spending your time and whether that makes you happy.

I’ve just returned from a three-week summer holiday break, and I definitely spent quite some time thinking about what I want my professional and personal life to look like, and what I might want to or even need to change to get there.

After quite a bit of thinking (and this started way before I went on vacation), I’ve decided that one of the things that has to change for me is wasting less time and energy on the mental drain that is LinkedIn.

Why?

Well, ever since I first signed up for LinkedIn way back in 2007, I’ve been spending a lot of time on the platform, especially in the last couple of years. Posting, liking, commenting, I couldn’t and can’t seem to get enough of it. However, where I used to absolutely love LinkedIn, my attitude towards the platform over the last year or so has evolved into what can only be described as a love-hate relationship.

I still love (or, well, appreciate is probably the better word) LinkedIn for all the opportunities it has given me, the genuine connections I’ve made and the things I’ve learned from others posting on there. I’d even go as far as saying I wouldn’t be where I am now in my career were it not for LinkedIn and the opportunities that have come through my network on there.

On the other hand, there are a couple of things on LinkedIn that I’ve grown to seriously dislike, and they seem to be slowly turning the scales to the platform and my activity on there becoming a net-negative instead of a net-positive for me.

First, the quality of the posts. These days, I’m seeing a lot of content on LinkedIn that might be relevant for some people, but definitely not for me. Political views. Personal stuff that is nowhere nearly related to what you do for a living. Endless ‘discussion’ (bashing, more like) of things that were beaten to death ages ago, like Scrum, SAFE, ‘no-code’ and (A/a)gile.

And recently, although in retrospect this might have been going on for a while, I just didn’t see it, the ongoing whining (I really can’t think of a better word to describe it) of parts of the testing community about ‘how people don’t understand us’.

But Bas, you might say, why don’t you just check and use LinkedIn less often? Well, that’s where the second thing I’ve grown to dislike comes in, and it is probably a much bigger dislike than the first one.

While LinkedIn is definitely much more business-oriented than, for example, Twitter, which I left a couple of years ago, it is a social media platform, carefully engineered to keep people interacting with it as long and as often as possible. When you start looking for the effect of social media on your brain, you’ll find a lot of articles that tell you exactly this: you didn’t lose your attention, it was stolen from you.

And big tech must be doing something right (at least, regarding their own interests), because I spend a lot more time than I should on LinkedIn, time that I suspect I can put to much better use.

Having read a lot of articles about people struggling with and quitting social media (here are some examples) and recognizing myself a lot in the symptoms described in there, I’ve come to realize that something needs to change.

I have started to wonder whether or not I should spend such a big part of the finite amount of time and energy that I have available throughout the day on browsing and refreshing LinkedIn, with all its humblebragging, broetry and other content that’s much more about the eyeballs and the likes than it is about providing actual value to those who read it.

And that’s why I’ve decided to take a break from LinkedIn, at least for a while. I don’t want to give it up altogether (at least not yet…) like I did with Twitter, especially because again, I have been getting a lot of value out of the platform over the years. I do want to see how much of that is directly related to me being on LinkedIn, though, and how much of that is purely because of the quality of my talks, my articles and my courses.

You might call it an attempt to reset the way I use the platform. You might call it a LinkedIn detox. You might call it whatever you want, I don’t know exactly how to describe it myself. However, I feel that an extended break is the only right thing to do at the moment.

So, from today, August 10, 2023, I’m staying away from LinkedIn until at least January 8, 2024. That’s right, I’m going on a five month break from LinkedIn. Full stop, no exceptions.

Early 2024, I’ll re-evaluate and decide on whether I’ll get back to using LinkedIn more actively.

This is probably going to be very hard for me, especially in the first couple of weeks, but I feel that I need to do this. I hope that this will help me clear my mind, restore my ability to focus on tasks (in other words, do more deep work) and reduce the continuous anxiety and urge to ‘just check LinkedIn once again’.

This, in turn, hopefully enables me to produce more valuable content. Open source contributions, talks, new courses and workshops, … I think there’s a lot more value in that than in writing social media updates and comments that are inherently much more ephemeral in nature.

I am fully aware that I still have a business to run, and that in the past, LinkedIn has been my main channel for promotion and marketing. During my break, I will, and will need to, therefore explore alternative ways of bringing my services to the attention of potential clients. I’ve been exploring some ways to do this for a while, but haven’t really taken a lot of action in that area yet. I’m really curious to see how dependent I am on LinkedIn, really.

Being less ‘visible’ online, or at least on LinkedIn, might result in me getting fewer requests for conference talks and workshops, too. And that’s OK. While I love traveling, seeing new places and meeting new people at conferences, I am totally fine if the number of travel opportunities offered goes down. If anything, it will allow me to focus and try to get to the places that I would really like to go to and do some work, be it a conference or an in-house training gig. Examples of these destinations are Canada (I will be there in September, but definitely open to more opportunities there), Australia and New Zealand.

I also hope that this break from LinkedIn will give me more time and the attention required to focus on some goals outside of work. I do read quite a lot of books already, but most of the time I stick with the ‘lighter’ stuff because I just don’t seem to possess the attention span required for reading and processing more demanding literature anymore, and that’s something I would like to change.

I’m also aiming to finally get enough training in to be able to work towards some fitness goals I’ve been eyeing for years now. Achieving these goals will take a significant amount of time, but it will also require both focus and proper sleep, two things that for me easily deteriorate if I spend too much time and mental energy on attention black holes such as LinkedIn.

I’m definitely not going to disappear from the planet, or even from the Internet, so if you want to get or stay in touch, please email me instead (bas@ontestautomation.com). I am more than happy to discuss opportunities for collaboration, or just to have a chat.

If necessary, I’m happy to give you my telephone number, so you can text me, or so that we can have an actual call. Old-fashioned, I know, but much more personal, too.

I am really looking forward to going back to those slightly more traditional and ‘slower’ means of communication, networking and marketing. I sometimes joke that part of my brain is permanently stuck in the 90’s, and I think this might be an example of my actions matching that.

If you’re looking for fresh content from me, there’s always this blog to look out for. I do hope to get back to regular writing soon.

In any case, by all means feel free to get and stay in touch. I just ask you to not use LinkedIn messages, invites, comments or tags to do so. Cheers!

P.S. Apart from the articles I linked to earlier in this post, here are a couple of books that have really changed my thinking about social media and my presence on these platforms. I highly recommend you read them.

Cal Newport – Digital Minimalism

Adam Alter – Irresistible

Johann Hari – Stolen Focus

P.S.: I’ve rewritten, published and then deleted this post several times over the last year and a half or so. That in itself is telling me something: I struggle with the addictiveness of social media. I go off it for a while, a few weeks later I’m back on as if nothing happened. This prolonged break I’m taking is therefore much, much needed.

The post Taking a long break from LinkedIn appeared first on Association for Software Testing.

 English

כתות מטען הן תופעה שצצה במלנזיה בעקבות מלחמת העולם השנייה. התושבים הילידים ראו את האדם המערבי מגיע, בונה שדות תעופה, משרדים, מגדלי פיקוח ומסלולי נחיתה  ובעקבות זאת מצליח לגרום לאלים (או לרוחות האבות) לשלוח לו אוכל, נשק ומשאבים נוספים. כשהחיילים עזבו, הילידים ניסו לחקות את מה שראו כדי לגרום לחלק מכל השפע הזה להגיע גם אליהם. היה חסר להם רק חלק קטן אחד – האנשים בצד השני של הטיסה שבנו את המטוס ומילאו אותו בכל הציוד הנדרש. מאז שהביטוי הזה נטבע הוא משמש כדי לתאר מקרים בהם מישהו מחקה את הצורה אבל מחמיץ לחלוטין את המהות של מעשה מסויים. 

ואיך כל זה קשור לבדיקות תוכנה? ובכן, מדי פעם אפשר למצוא באינטרנט (ובמקומות אחרים) הרצאות עם הנושא החשוב “איך למצוא עבודה”. באופן די טבעי, חלק נכבד מההרצאות האלה יעסוק במי שאין לו ניסיון. יש כל מיני דברים שאנשים חסרי ניסיון יכולים לעשות, אבל מתישהו מישהו יפלוט אמירה בסגנון של “בחר לך איזה אתר אינטרנט ולך לבדוק אותו, כתוב תוכנית בדיקות ומצא באגים”. ככה, לפחות על פי הרציונל, יהיה לנו מעין “תיק עבודות” שנוכל להראות. 
עצה טובה, לא? הרי זה בדיוק מה שמתכנתים עושים. הם לוקחים בעיית צעצוע שלא חשובה לאף אחד וכותבים קוד בסיסי שמטפל בה. ככה הם מראים כמה הם יודעים למי שאולי ירצה לראיין אותם. 

כמו במקרה של כתות מטען, חסר פה רק חלק קטן אחד – בדיקות תוכנה מקצועיות. כל בודק תוכנה מנוסה ידע לספר שאת רוב הערך משיגים עוד לפני שכתבנו או הרצנו בדיקה אחת. שזה לא חשוב כמה יפה כתובה תוכנית הבדיקות או כמה מפורט הבאג שפתחנו. מה שחשוב זה השיחות שיש לנו מסביב כשאנחנו מתכוננים. זו השאלה שנשאלה בדיוק ברגע הנכון כדי לשנות לחלוטין את איך שמפתחים פיצ’ר וחסכה לכולם מלא שעות של תסכול, זו הפרספקטיבה השונה שמביאים לסקירת הדרישות או העיצוב, אלה שיחות המסדרון בהן חושבים יחד עם המפתחים על דרך טובה לפתור איזו בעיה. זה כשאנחנו מתפקדים כמתרגמים או כשאנחנו מסתכלים על “מה יכול להשתבש” במקום על “איך לגרום לזה לעבוד”. הם ידעו לספר שכשעובדים כבודקי תוכנה ועושים את העבודה היטב אנחנו לומדים המון על המערכת הנבדקת ועל איך היא בנוייה. על הארכיטקטורה שלה ועל המוזרויות של הספריות הספציפיות בהן היא משתמשת, על האילוצים הטכניים ועל הדברים שנשברים באופן תדיר יותר. אנחנו גם לומדים קצת על הצד העסקי – על אילו תלונות מגיעות מהלקוחות שלנו, על מה חשוב לנו מספיק כדי לעצור גרסה או אילו תכונות עוזרות לנו למכור את המוצר על פני המתחרים. מה דחוף וממה לא אכפת לנו בכלל ולא נתקן גם אם הוא שבור. אנחנו מנצלים את כל הידע הזה בתכנון הבדיקות ובשיחות שלנו עם אנשים. 

החלקים האלה נעדרים לחלוטין מ”תיק העבודות” שנוכל לבנות אם נעקוב אחרי העצה המטופשת הזו. אם אנחנו משקיעים זמן בדברים האלה, או אפילו מצטרפים לפלטפורמת בדיקות המון ומקבלים דמי כיס על בניית תיק העבודות. בהחלט יכול להיות שנוכל לשפר ולהדגים כמה כישורים טכניים, ואפילו כאלה שנמצאים במודעות הדרושים, אבל צריך לזכור שזה לא נוגע בכישורים הספציפיים של בדיקות תוכנה. במצבים האלה אנחנו לא נגיע לדיונים על סדרי עדיפויות או על מה אפשר לא לבדוק, לא נצטרך להתווכח על תכנון תאריכים ולא נדע אם המשוב שלנו הועיל למישהו. פשוט חבטנו קצת על המקלדת בלי שיש לנו מושג ירוק מה חשוב לחברה. הסתכלנו על קצה הקרחון שחשוף באתר האינטרנט בלי שיש לנו גישה לכל הקרחון העצום שמתחת לפני השטח של האתר החמוד שבחרתם לעצמכם כקורבן. 

 או, אם לסכם את כל הפוסט במשפט קצר ורק קצת מוקצן – בודקי תוכנה טובים לא מבזבזים את הזמן שלהם על בדיקות. 

The post על בדיקות ועל כתות מטען appeared first on Association for Software Testing.

  עברית

Cargo cults were a set of practices and beliefs that sprang in Melanesia post WWII, where the native population saw the westerners arrive, set up some rudimentary airfield, landing stripes, control tower, etc. and started getting supplies by planes. When the war was over, the natives tried to achieve the same results by maintaining their own airfields, trying to lure the gods to send them food and weapons as well. They were missing only one part: The people sending supplies from the other side of the airplane flight. Since it was coined, this term was used to indicate situations where someone is mimicking the form but missing out the essence.

And how does this relate to software testing? Well, every now and then there’s a public talk on “how to get hired”. Naturally, talks like this focus on people with less experience and so, eventually, someone will spurt “go and test a public website or product”. Sounds legit, right? it’s just like coding – you can demonstrate your skill by creating a useless pet project and present it to whomever it is you might want to hire you. 

Just like the cargo cults, however, there’s only one part that’s missing – The actual, professional testing. Ask any experienced tester and they’ll be able to tell you that the important things are not test cases ran, bug reports written or the excessive documents produced. The real value is in the conversations you have, in bringing a different perspective to reviews, in translating between different functions, highlighting the risks and improving design by presenting just the right question at the right time. When you work (effectively) as a tester on a product you gain a profound understanding of its inner workings, of its tech stack, architecture and technical debt. You gain some insight on the business side: what’s important, what’s less urgent, what sort of problems we don’t care enough to bother fixing and what properties of the product are the ones that help sell it. You then use this understanding in the conversations and test design.

Those parts are completely missing from the so0called “experience” you’ll get if you follow such advice. If you are investing your time on that, or even on the paid version in crowdsourced testing, you might be gaining or demonstrating some technical capabilities, but you are not dealing with nor growing the core skills required in a testing position. You are not negotiating schedule difficulties, you are not involved in prioritization debates and you are smashing your keyboard without the slightest idea of the priorities of the company whose product you are testing or the entire iceberg beneath the nice looking website you chose as your target.

Or, if we sum it all in a click-baity fashion: Good software testers shouldn’t waste their time testing.

The post Cargo-cult testing appeared first on Association for Software Testing.