For me, YAGNI is a great heuristic to help me stay focussed and optimise the work not done.For example, it can be very easy to get sucked into a task, like automating a workflow, and start thinking of all the variations you could automate, functions you could make reusable, and fancy frameworks you could explore.  But what are you trying to achieve right now, and what do you need in order to do that?  What's your minimum viable / valuable product in this situation?  If you don't need it now, how likely are you to need it in future?  YAGNI says you ain't gonna need it.  So don't spend time on it right now.  It's great to future-proof a little, and build something that's good to work with, but don't go putting on all the bells and whistles right now.  If you need it in future, you can get / do / create it in future.  For now, take things one step at a time, and get some feedback on what you already have.

Glue work is often work which is unloved, yet essential successful teams / projects.  While it's usually not large or innovative, glue work is a collection of smaller contributions which keep things running smoothly.Some examples include taking notes, noticing when someone has been missed from an important meeting invite and adding them, or making sure someone responds to an incoming enquiry in a timely manner.  Without this glue work, the team may waste time repeating discussions they've already had, have to postpone important decisions, or cause stakeholders or users to feel unheard or unhappy.One great irony of glue work, in my opinion, is that it often goes unappreciated, yet is a sign of leadership, maturity, and being a team player.  For this reason, it's a good idea to keep an eye on how much glue work you're doing, and what you're getting back from it, so as not to end up sacrificing your personal success and happiness for the sake of the team / project.For more information on glue work and how to deal with it, check out this talk from Tanya Reilly: https://www.noidea.dog/glue

aving joined my first Salesforce project just over six months ago, we’re now ready to consider automating the UI

In the context of software testing, I think of a specialist as someone who is the go-to person for a particular area / topic / technique, etc. A person who is often associated with something specific, because of the level of skill / experience they have in it. A specialist will typically be able to consult on, educate, and train people on the given topic.

In the context of software testing, I’d say a generalist is someone who can do a lit bit of everything, but not to a deep extent. They have basic to good skills in many areas, but no particular area in which they’re highly skilled / experienced.

Another way to test in a larger group is to have a bug bash. During a bug bash, lots of people from different disciplines come together in the same space (or call) to test the same system. Bugs can be called out instantly, domain experts can clarify questions immediately, and lots of feedback can be gathered quickly. Usually with a moderator or facilitator collecting the points raised, so there are fewer duplicates and everyone else can focus on testing. It’s really interesting to see how priorities and testing techniques differ, and ideas bounce and grow. Bug bashes can be a really fun format which helps to boost morale, and they’re great for getting a lot of testing done quickly, for example, before a significant planned release. If you’re holding a bug bash ahead of a big release or feature launch, you can also theme your bug bashes towards those goals and assign different personas, to give it more fun and focus.

TestBash is an annual opportunity for testers across the globe - and MoTaverse - to get together in a single place.  More than just a conference, it's a friendly and welcoming place to meet other people who are passionate about testing, quality, and community.  From scheduled talks to planned workshops to spontaneous chats, there are plenty of opportunities to learn and get to know people from the community.  The MoT team take care of participants by organising a diverse range of contributions and contributors, offering accommodations, and providing quiet spaces.  TestBash is truly something special, which has helped to launch speaking careers, bud friendships, and grow testing and quality enthusiasts.

Test design is both a creative and scientific process for determining what and how to test. The what is about making it something that's going to be useful information that's going to actually help someone in at the end of the day. For me, the how plays a big part in that as well because I've seen that happen where someone maybe thinks that they're testing a certain thing, but the how that they're doing it actually is testing something else.The how is important as well.

A mnemonic I came up with while trying to think of ways to help people test like a tester

Mutation testing is a method used in the context of automated checks / tests.  Rather than testing the code, mutation testing tests the tests.The purpose of automated checks is to detect change.  With mutation testing, one introduces small changes to the code to see whether they are successfully detected.  If they are, the mutation is said to be "killed", but if they are not, then one may have a gap in the coverage of automated checks*.One can also use what I call "reverse mutation testing" - changing the test so that it should fail, even though the system under test has not.  This reveals whether the test can actually fail, and whether you are really testing what you think you're testing.*Side note: A gap in test coverage may be intentional.  It's important to think carefully about one's test strategy, whether 100% code coverage is desired, and on which level(s).

In the formal style of pair testing, there’s typically a “navigator”, who decides what to do or investigate, and a “driver”, who directly interacts with the system under test and follows the instructions of the navigator. The pair will typically swap roles at regular intervals, giving both parties a chance to try out their ideas and observe how the other person navigates through the system. In the informal style, who says what to do next and who interacts with the system is less rigid. This gives room for more discussion and ideation. It may also be a little faster, as you can execute and show your ideas directly, without having to find all the words to explain them.

In my experience, there are two main, but distinct, things people mean when they refer to "end to end" testing.Some people are referring to the complete user journey, from the start of a flow to the finish.Others are referring to the system architecture, meaning that testing cuts through all involved layers of the system under test.Because these two definitions are very different, it's important to understand what is meant by "end-to-end" testing in your specific context, so as to avoid misunderstandings, and meet expectations.