Similar to software composition analysis, Static Application Security Testing (SAST) tools scan source code before it runs and without executing it (“white-box testing”).SAST scanners search for “dangerous” patterns, that match security flaws, for example SQL injections, Cross-Site Scripting (XSS) and hardcoded API keys/credentials. SAST tools are most effective when they are used, and their output applied before code is merged.

A commit hook is a script that git executes automatically before or after a specific event in the version control lifecycle like committing, pushing or merging.You can have pre-commit hooks (prevention) and/or post-commit hooks (notifications or automation). A pre-commit hook is arguably more common, running after entering a git commit, with the cabability to abort the commit if certain quality standards aren't met such as linting rules, unit or smoke tests. If the hook outcome passes, git proceeds with the commit as normal, if not, git immediately aborts the commit, and the code stays in your staging area so you can fix it.

The OSCAR mnemonic is a tool that can be used to help understand the context around the problem, when coaching others to consider testing and quality.This model helps quality coaches guide their clients towards achieving their desired outcomes by focusing on their current situation, exploring their choices, taking action, and reflecting on their progress. By providing your testing expertise, you can guide them towards efficient strategies for achieving success.OSCAR stands for; Outcome – help your stakeholder to define their ‘destination’, asking them open questions such as ‘what would success look like?’ or ‘what would you like to achieve in this release?’  Situation – help your stakeholder to define their current situation (the starting point). Choices – generate as many alternative choices as possible and raise awareness around the consequences of each possible choice. Actions – help the team member to clarify their next steps forwards and take responsibility for their own action plan, ‘what needs to be in place for this testing?’, ‘what will you do next?’ and ‘who could support this regression testing?’   Review – outline the conversation that has taken place up to now, create an ongoing process of review and evaluation so that if X needs testing in the future or Y goes wrong again, the team is equipped to perform hands-on testing or root cause analysis on their own. Ask open questions with curiosity to learn ‘are the actions moving you towards your outcome?’

XUnit is a family of testing frameworks like JUnit (for Java), NUnit (for .NET), and pytest (Python) that all follow a similar style and structure. They’re commonly used for unit testing. The X is just a placeholder, meaning each version is adapted for a specific programming language as mentioned.

San Francisco depot is a mnemonic for the SFDPO software exploratory testing heuristic. SFDPO stands for Structure, Function, Data, Platform and Operations. Each of these represents a different aspect of a software product.StructureStructure is what the product is. This is its physical files, utility programs, physical materials, etc. FunctionFunction is what the product does. This is like the product's functional requirements. How does it handle errors? What is its UI? How does it interface with the operating system? DataData is what the product processes. What kinds of input does it process? This can be input from the user, the file system, etc. What kind of output or reports does it generate? Does it come with default data? Is any of its input sensitive to timing or sequencing? PlatformPlatform is what the product depends upon. What operating systems, browsers, runtime libraries, etc. does it run on? Does the user need to configure the environment? Does it depend on third-party components? OperationsOperations are scenarios in which the product will be used. Who are the application's users? Where and how will they use it?

Dogfooding refers to software developers and companies using their own products and services, just like their customers do.Imagine a chef who will not taste their dish. It makes you think, doesn’t it? The same idea applies to businesses that do not use their products. Here is the answer to what is dogfooding. It shows how much a company believes in what creates. It helps the development team see and experience the product value directly.Dogfooding, or Eating your own dog food, helps you see what your customers see. 

SCA (Software Composition Analysis) tools scan your manifest files (e.g. your package.json) against known vulnerability databases. They're looking for known vulnerabilities in third-party libraries, like malicious npm packages. SCA tools match every package and direct dependency in your project, regardless of whether your code actually uses the vulnerable functions which can create alert fatigue.Your teams may already have SCA tools in the pipeline, since it’s common to refer to them by the tool vendor such as Snyk, Endor Labs, Black Duck, OWASP dependency-check, Grype, GitHub Advanced Security and many others.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Clean code is code that is easy to read, easy to understand and easy to maintain. It is written for humans first and computers second.Here are some characteristics of clean code: It expresses its intent clearly, meaning that variables, functions, and classes have descriptive names that tell you exactly what they do. Often following a naming and casing standard so that you cannot identify i ndividual authors. Functions perform a single action. Code adheres to the DRY principle (Don't Repeat Yourself). If you need to change a business rule, you should only have to change it in one place. It isn't longer than it needs to be, including comments. It contains no dead code, unused variables, or speculative features (YAGNI - you ain't gonna need it).  It handles errors gracefully such as network failure, missing files or bad user input, and handles those exceptions explicitly, leaving the system in a predictable state. It has minimal dependencies. Internally, code keeps connections between different parts of the software to a minimum and externally multiple packages aren't brought in for the same action (breaking DRY and increasing security surface area).  It is self-documenting. The code itself explains what it is doing and comments add why an approach was taken or the business logic being implemented, rather than explaining the lines of code they cover.  Similarly to self- documenting, clean code is verifiable. It is written in a way that makes it easy to test and it actually passes those automated tests consistently.

Magic values are values hard-coded directly in your tests without any code extra comment or context. These values make your code less readable and harder to maintain. Magic strings can cause confusion to the reader of your tests. If a string looks out of the ordinary, they might wonder why a certain value was chosen for a parameter or return value. This type of string value might lead them to take a closer look at the implementation details, rather than focus on the test.

 A stub is a controllable replacement for an existing dependency (or collaborator) in the system. By using a stub, you can test your code without dealing with the dependency directly.

What is meant by monitoring?By textbook definition, monitoring is the process of collecting, analyzing, and using information to track a program’s progress toward reaching its objectives and to guide management decisions. Monitoring focuses on watching specific metrics. Logging provides additional data but is typically viewed in isolation of a broader system context.What is the difference between observability and monitoring?Monitoring is capturing and displaying data, whereas observability can discern system health by analyzing its inputs and outputs. For example, we can actively watch a single metric for changes that indicate a problem — this is monitoring. A system is observable if it emits useful data about its internal state, which is crucial for determining the root cause.Monitoring typically provides a limited view of system data focused on individual metrics. This approach is sufficient when systems failure modes are well understood. Because monitoring tends to focus on key indicators such as utilization rates and throughput, monitoring indicates overall system performance. For example, when monitoring a database, you’ll want to know about any latency when writing data to a disk or average query response time. Experienced database administrators learn to spot patterns that can lead to common problems. Examples include a spike in memory utilization, a decrease in cache hit ratio, or an increase in CPU utilization. These issues may indicate a poorly written query that needs to be terminated and investigated.Conventional database performance analysis is simple compared to diagnosing microservice architectures with multiple components and an array of dependencies. Monitoring is helpful when we understand how systems fail, but as applications become more complex, so do their failure modes. It is often not possible to predict how distributed applications will fail. By making a system observable, you can understand the internal state of the system and from that, you can determine what is not working correctly and why.

Time to restore service, also known as time to recovery measures the duration required to recover from an incident. It reflects the time taken to restore normal operations. This metric starts when an outage begins and ends when the system is fully operational again, capturing the total recovery duration.Understanding Mean Time to Recovery helps teams identify areas for improvement in their recovery processes and work towards minimizing downtime.