What are incident logs?  These types of logs boil down to detailed records of unexpected errors, and deviations from expected system behavior, that we discover while testing or even in the live environment. Incident logs can be used to identify new risks, keep track of them, give us insight into what needs resolving, and generally help us improve the quality of our product.

A risk policy is a set of rules, guidelines, and procedures that are meant to help us identify, determine, and deal with risks related to software development and testing. Risk policy can help us make more informed decisions regarding resource allocation and prioritisation of our testing efforts.

The risk matrix serves to give us a visual representation of the relation between the likelihood of a risk occurring and the ramifications of its potential impact. Each risk is given a rating of the impact of the risk occurring and how likely it is to occur. The most essential components of the risk matrix table are the likelihood of the risk occurring and its potential impact. Each cell in the table represents a different level of risk.(Module 6 STEC)

A risk register is a useful document or tool that can be used in software testing to capture risks, manage them, and make risk assessment possible. All of which can impact the work on our product and the development timeline. It could also affect the budget, or degrade the quality if not maintained.

Web Content Accessibility Guidelines (WCAG) is a set of international standards that provide a set of recommendations for making web content more accessible to people with disabilities.  These principles also foster inclusivity as they cover a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.  Essential for compliance, as in many jurisdictions, WCAG compliance is legally required for websites and various digital content.  ​You can learn about the WCAG through the World Wide Web Consortium's (W3C) Web Accessibility Initiative (WAI): https://www.w3.org/WAI/standards-guidelines/wcag/ 

Quality coaching focuses on: Changing team and organizational culture to promote shared ownership of quality Helping the team improve soft AND technical skills Facilitating learning and adaptability Building toward long-term continuous improvement.

As a general rule, test plans serve as a roadmap for our testing process, in which we describe activities needing to be undertaken to ensure the software is properly tested. Once major risks have been identified they will probably be included in the test plan in some way. The test plan usually contains information about assessing new risks and how to plan for more detailed testing in more risky parts of the system. A test plan doc can also contain sections on how to help with risk mitigation, risk monitoring, and managing incidents.

Test setup refers to the actions performed before the execution of a test case to prepare the environment and ensure that the test can run correctly. This is the part where we prepare any test data needed for our test to run. This might include:  Initializing objects or variables.  Setting up the test environment (e.g., configuring a database, starting a server).  Creating test data. Logging in to an application.  Navigating to a specific page or state in the application.  The goal of test setup is to bring the system under test into a known and consistent state so that the test results are reliable and repeatable. 

TDD is a software development methodology where tests are written before the code they are intended to test. Its purpose is to reduce the number of bugs early on and to increase testability. It follows a short, iterative cycle:  Write a test that fails because the code doesn't exist yet.  Write a minimal amount of code to make the test pass.  Refactor both the test and the code to improve quality.  Repeat.  TDD helps to ensure that code is testable, well-designed and meets its requirements.

In software testing, an assertion is that a specific condition should be true at a particular point in the code's execution. It's a way to verify that the code is behaving as expected. If the assertion fails (the condition is false), it indicates a bug or an unexpected behavior. Assertions are commonly used in unit testing frameworks to check the results of a test. For example, you might assert that the value returned by a function is equal to the expected value. In general, the assertion is the last part of the test, if the condition is met the test passes. It’s a good idea not to assert too different many things in one test, ideally, we want it to have a single point of failure so it’s easier to debug 

In testing, a mock is a simulated object that mimics the behavior of a real object used in production- we use mock in cases where we need to test something that requires a feature that is not yet available, so we simulate it. Mocks are used to isolate the code under test from its dependencies, such as databases, APIs, or other classes. By using mocks, you can control the inputs to the code being tested and verify how it interacts with its dependencies. This makes tests more reliable and easier to write. For example, if you're testing a function that interacts with a database, you could use a mock database object to simulate the database's behavior without actually connecting to a real database. 

Test teardown refers to the actions performed after the execution of a test case to clean up the environment and restore it to a previous state. Since automation can create a lot of data, we might want to delete that data, once our tests have finished running. This might include:  Closing connections (e.g., database connections).  Stopping servers or services.  Deleting test data.  Logging out of an application.  Resetting the application's state.  The goal of test teardown is to prevent tests from interfering with each other and to ensure that the test environment remains clean and consistent. It also prevents resource leaks. Proper teardown is crucial for repeatable and reliable test execution.