Eighteen months, 19 modules, and 59 amazing contributors later, the MoT Software Testing Essentials Certification is complete! Looking back, my favourite part has been seeing so many community m...

Discover how testers are using MCP servers, debate the reality of mandatory AI tracking at work, and celebrate community milestones from STEC to new job wins

Technical documentation in software development refers to any documents, knowledge repositories (such as internal wikis), or architecture and system designs. Even user guides can be technical documentation. They are anything that explains how software works, how to use the software and what technologies the software is made of.As well as explaining the software and possibly hardware involved, it can also guide users, help teams work better together, and improve development, maintenance and further development. All documentation has the risk of becoming out of date, so it is as important to maintain them as it is the software itself.Types of technical documents can include requirements in many forms, architecture schematics and designs. API documentation, troubleshooting guides, code comments, reference documents and user manuals.Testers can gain all sorts of knowledge, insights, and test ideas from them, as well as assessing risks.

Linting is an automated process that analyses code to flag up potential errors, enforce coding styles, and identify suspicious constructs. It's a bit like having a very particular editor constantly looking over your shoulder as you write, but for test code.In software development, especially in test automation, it's about keeping the codebase clean, consistent, and free from common bugs that aren't syntax errors. These tools look for things like unused variables, incorrect indentation, overly complex functions, or adherence to specific naming conventions. They don't run the code; they simply read it, much like a static analysis.Think of it like this. When you write an essay, most of us will use a spell and grammar checker. Linting is that, but for code, and a good deal more complicated. It catches not just spelling mistakes (syntax errors, which a compiler would find anyway), but also stylistic inconsistencies or structural bugs. Those things that might not break the program, but could lead to problems later, or make the code hard for others to read and maintain.For test automation, linting can be incredibly valuable. It helps ensure test scripts are well-written, consistent, and robust. This prevents introducing preventable bugs into test code itself, which could give false negatives or positives. A clean, linted test suite is far more reliable and much easier to debug when a real product bug surfaces. It's an essential step in maintaining high-quality automation.

Maintainability describes how easily a software product can be modified to correct bugs, add functionality or adapt to a new environment. It goes beyond just having tidy code. Clear documentation, a modular design and a reliable suite of automated tests all feed into making changes straightforward.When maintainability is high, fixing a bug might only mean updating a single component and running a test suite. At the other extreme, low-maintainability feels like a tangled ball of wool. Every tweak and pull risks unravelling the whole thing. Or in software terms, triggering hidden dependencies and spawning fresh bugs.Improving maintainability starts with consistent naming conventions, breaking large components into smaller modules, embedding clear README files alongside your code, and having clear and up-to-date documentation. Static analysis tools, peer reviews and tracking how long simple changes take turn maintainability from a vague goal into a measurable part of your workflow.To assess maintainability, look at code readability, the time and effort required for minor changes, and ensure key paths are covered by stable automated tests. If adding a new field sends you down a rabbit hole, you’ve probably caught a maintainability bug.

Continuous learning is the mindset and practice of constantly seeking out new knowledge and skills, both professionally and personally. At its most fundamental level, the human experience is one of continuous learning. We never truly stop adapting and growing throughout our lives.In the context of software development and testing, continuous learning is not just a nice-to-have, it is an absolute necessity. Technology changes rapidly these days, with new frameworks, tools, languages, and security concerns appearing all the time. A tester who is committed to continuous learning keeps their skills sharp and relevant, allowing them to adapt to new challenges and remain an invaluable part of the team. This can mean anything from picking up the basics of a new language, tool, or technique to attending a conference to hear about the latest in testing. Or simply spending an hour each week reading articles on a testing specialism you are interested in. It is the practice of continuous learning that turns a good tester into a great one.

HTTPS stands for HyperText Transfer Protocol Secure. In plain terms, it's the secure version of the common protocol (HTTP) that your web browser uses to talk to websites. Think of it as putting a very strong, tamper-proof bubble around all the information you send and receive over the internet. What it does, is add a layer of security, typically using something called TLS (Transport Layer Security) or its older version, SSL (Secure Sockets Layer). This layer encrypts the data that travels between your web browser and the website's server. So, if you're typing in your password, your credit card details, or even just browsing sensitive information, HTTPS scrambles that data. If anyone tries to intercept it, they'll just get gibberish, not your actual details. The importance of HTTPS really boils down to three main things:  Confidentiality: Your data is kept private. No one can easily intercept your communication with the website.  Integrity: It ensures that the data you send or receive hasn't been secretly altered or tampered with along the way.  Authentication: It helps verify that you are actually connected to the genuine website you intend to visit, not a cunning imposter trying to trick you.  You'll usually see a padlock symbol in your browser's address bar when you're on an HTTPS site. For testers, verifying proper HTTPS implementation is a fundamental part of security testing. It means ensuring that crucial communication pathways are encrypted and secure from potential bugs or attacks.

A foreign key is a crucial concept in relational databases. It is essentially a column, or a set of columns, in one database table that refers directly to the primary key in another table. Think of it as a special kind of link or a pointer between two different sets of data. The main purpose of a foreign key is to create and enforce a relationship between two tables and, crucially, to maintain data integrity. It ensures that relationships between data remain consistent and valid. For example, imagine you have one table for Customers and another table for their Orders. Every order should belong to a real customer, shouldn't it? So, in the Orders table, you would have a column called CustomerID. This CustomerID column would be a foreign key that references the CustomerID column (which is the primary key) in your Customers table. What this means in practice is that you cannot create an order for a CustomerID that doesn't actually exist in your Customers table. It prevents you from having 'orphan' orders floating around without a customer, which would be a real data bug. For testers, understanding foreign keys is important in database testing. They are fundamental to how data is related and kept consistent across a system. Knowing how they work helps you design better tests for data integrity and identify issues where relationships might break down or where invalid data might sneak in. It is all about making sure your data is trustworthy and connected as it should be.

Pseudo-localisation is a clever technique used in software testing to simulate how an application will look and behave when translated into other languages, without actually performing a full translation. It is a quick and efficient way to find many common localisation bugs long before real translation work even begins. How it works is quite simple. You process the original user interface text through a specialised tool. This tool automatically replaces each character with an equivalent from another script, often adding accents or expanding the string length. For example, "Hello World" might become "[Ĥéļļõ Ŵõŕļđ! --á--]" or similar. The extra characters and expanded length mimic what happens in real languages like German or Polish, which often use longer words. The big benefit here is that these 'fake' translations immediately highlight layout bugs. If text gets cut off, if buttons suddenly overlap, or if character encoding issues crop up, you see it straight away. It's much cheaper and faster to fix these layout and encoding problems in the development phase than waiting for a real translation to come back, only to find the entire user interface has broken. It effectively provides an early warning system for localisation issues, without the cost or time involved in a full translation.

A CI/CD pipeline is an automated assembly line for your software, designed to get code from development to your users faster, safer, and more reliably. It breaks down into two main parts.  Continuous Integration (CI): This refers to the continuous stream of automated checks. Every time a developer commits changes, the code is automatically built and tested. It means quick feedback, catching bugs early and keeping the main codebase stable.  Continuous Delivery (CD) / Continuous Deployment (CD): This handles the release side. Continuous Delivery means that the code, after passing all CI tests, is always ready to be released to an environment such as testing or staging. Continuous Deployment takes it further, automatically sending that code straight to production if all checks pass.  Essentially, CI builds and tests the code rapidly, and CD ensures it's released efficiently. It's about automating the journey of your code, eliminating the need to wait for intervention and action and finding potential problems quickly.

Whether you’re organising a protest, sharing on socials, or updating your office noticeboard, these graphics do the talking. They’re bold, unapologetic, and totally free to use.

National Air Traffic Services (NATS) reported a technical issue (bug). Best part so far, and who am I to say it’s not true! They've turned it off and turned it back on again