In software development, scope creep refers to the uncontrolled and gradual growth of a project's requirements, features, or work beyond what was originally agreed upon. This often happens without proper evaluation, documentation, or adjustment to the project's budget, resources, or timeline. Managing scope creep is important as it helps us minimize delays in project delivery, misunderstandings, and breaches of deadlines.

SMART is an acronym for a widely used goal-setting framework. It’s short for:  S - Specific: Goals should be clear, well-defined, and unambiguous. They answer the "who, what, where, when, why, and how" of the objective.  M - Measurable: Goals must have measurable indicators to track progress and determine when they've been achieved. This involves setting metrics or benchmarks.  A - Achievable: Goals should be realistic and achievable given available resources, time, and capabilities. While challenging, they shouldn't be impossible.  R - Relevant: Goals should align with broader objectives, values, and the overall mission. They should make sense in the context of the larger picture.  T - Time-bound: Goals need a defined deadline or timeframe for completion. This creates urgency and provides a target for completion.  These are often used so individuals and organizations can set more focused, actionable, and trackable goals, increasing their chances of success and making things like performance evaluation easier.

Automated checks in software testing are essentially tests executed by software tools rather than human testers. These checks automatically compare the software's actual behavior against expected outcomes, often defined in scripts. They are designed to be repeatable and efficient and can cover various aspects of an application, from functionality and performance to security.Ultimately, automated checks aim to provide faster feedback on software quality and improve testing efficiency. It is best to use them when outcomes are predictable and the feature we cover has been stable for a while. 

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.