Error Guessing

Error Guessing

"A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made, and to design tests specifically to expose them", per ISTQB.

Error guessing technique involves the tester making guesses about mistakes (errors) that a developer might make and then designing tests for them. Error guessing requires the tester to have knowledge and experience of common programming errors and their impact on code produced, the nature of bugs that can be introduced and how those may be reproduced. The tester needs to have some experience with programming and the technologies used by development. This enables the tester to make guesses about potential errors that may be introduced and create tests to find bugs associated with those errors. Error guessing may be used as a standalone technique or to complement other techniques. Error guessing can be applied at any stage of testing and may be used to even identify potential risks.

The effectiveness of using the Error guessing technique lay on the creativity and ability of the tester to guess errors and find bugs. Each tester is unique in this case and likely to approach this technique distinctly. Error guessing may also be used as a means to perform a quick smoke test. Trying to lay down guidelines and documentation requirements for this technique may constrain the tester's freedom and creativity which are important for Error guessing to be effective.

Needless to state it, error guessing is normally used as an additional test technique and not the sole or primary testing technique. Error guessing can help find bugs that may be missed by other techniques. Once tests are executed, it is recommended to capture them and automate as much as possible.

As you may have realized by now, the success of this technique to a certain extent is dependent on both the developer making similar mistakes as in the past and the tester having some experience with finding bugs that are similar to the ones that are in the current system-under-test.

Software Testing Types: A Practical Map for Risk-Based Coverage

A list of software testing types is useful only when it helps a team choose the right evidence for the risk in front of them. Memorizing names does not improve quality; matching risks to effective test approaches does.

This is the distinction senior QA professionals need to make. The question is not how many types of testing a team can name. The question is which failure modes matter, where those failures are most likely to appear, and what kind of testing will expose them early enough to influence the release decision.

Start with the quality risk

Functional testing checks whether the system does what it is supposed to do. Integration testing checks whether boundaries between components behave correctly. Performance testing checks whether the system holds up under realistic load. Security testing looks for misuse, exposure, and abuse paths. Accessibility testing checks whether people with different abilities can use the product effectively.

Each type answers a different question. Treating them as interchangeable creates gaps. A strong regression suite will not prove scalability. A penetration test will not prove workflow correctness. A usability session will not prove data integrity.

A practical map

• Business workflow risk: acceptance, exploratory, workflow, and end-to-end testing.
• Service behavior risk: unit, component, API, contract, and integration testing.
• Change regression risk: automated checks at the cheapest reliable level.
• Operational risk: performance, reliability, observability, backup, recovery, and deployment testing.
• Trust and compliance risk: security, privacy, accessibility, audit, and data-quality testing.

The best teams do not run every test type with equal weight. They build a portfolio. The portfolio changes when architecture, customer usage, compliance obligations, or defect history changes.

What this means for QA leadership

A QA leader should be able to explain why a release needs certain evidence and why other evidence is intentionally lighter. That explanation is much more credible than saying the team completed a standard checklist.

Testing types are not bureaucracy. They are choices about where confidence will come from. The craft is in choosing deliberately.

How to use this as a working habit

The practical value of this topic is in daily test design. Use it when reviewing a requirement, creating examples, selecting data, choosing boundaries, or explaining why a particular test matters.

Fundamentals are not junior concepts. Senior testers use them with more judgment: less ceremony where risk is low, more discipline where ambiguity, impact, or repeatability matter.

A useful habit is to ask what decision this concept supports. If the answer is unclear, the testing activity may need refinement. Good fundamentals should make the work sharper: clearer scope, better examples, stronger evidence, and more honest communication about what remains unknown.

Non-Functional And Risk-Focused Testing: The Quality Attributes Users Notice

Functional correctness is necessary, but not sufficient. Users also experience performance, reliability, security, accessibility, usability, recoverability, and trust.

Many teams test whether the feature works and treat non-functional testing as a late activity. That is risky. A product can pass functional tests and still be too slow, insecure, inaccessible, unreliable, difficult to recover, or impossible to diagnose.

Performance, Load, Stress, And Soak Testing

Performance testing evaluates responsiveness, throughput, resource usage, and scalability. Load testing checks expected usage. Stress testing explores behavior beyond expected limits. Soak testing reveals long-duration degradation such as memory leaks, queue buildup, or connection exhaustion.

The best performance testing starts with workload modeling and observability, not tool selection.

Security Testing

Security testing examines authentication, authorization, input validation, sensitive data handling, session behavior, configuration, dependency risk, and abuse cases. It should not be left only to a late penetration test.

Quality engineers do not need to replace security specialists, but they must understand enough security risk to include negative, misuse, and access-control scenarios in everyday testing.

Accessibility And Usability Testing

Accessibility testing verifies whether people with different abilities can use the product effectively. Usability testing evaluates whether intended users can complete meaningful tasks with clarity and confidence.

Automated accessibility checks are useful but incomplete. Keyboard navigation, focus management, labels, error messages, screen-reader behavior, and workflow clarity require human judgment.

Reliability And Recovery Testing

Reliability testing asks whether the system can perform consistently over time and under imperfect conditions. Recovery testing asks what happens after failure: can the system restore state, prevent data loss, avoid duplicate actions, and give users truthful status?

In distributed systems, retries, idempotency, timeouts, circuit breakers, and compensation logic are quality concerns.

Compliance And Standards Testing

Compliance testing verifies whether the system meets required legal, regulatory, contractual, or industry standards. The risk is not only failing an audit; it is creating customer, legal, financial, or reputational harm.

Non-functional testing is not secondary testing. It is often where user trust is won or lost. A mature QA strategy treats quality attributes as first-class requirements, not optional checks if time remains.

Integration, Workflow, And Compatibility Testing: Where Systems Really Break

Many serious defects appear not inside isolated components, but between them. Integration and workflow testing expose the risks created by boundaries, data movement, dependencies, and user journeys.

Modern software is assembled from services, APIs, databases, queues, identity providers, browsers, devices, third-party platforms, and operational infrastructure. A feature can work in isolation and still fail when it meets the rest of the system.

Integration Testing

Integration testing verifies that components interact correctly. The risk is not only whether a call succeeds. It includes schema compatibility, error handling, authorization, retries, timeouts, data consistency, version skew, and observability.

In microservice and event-driven systems, integration testing should be supported by contract tests, API tests, message-schema validation, and targeted end-to-end journeys. Relying only on a large shared environment is usually slow and brittle.

End-To-End Testing

End-to-end testing validates a complete user or business workflow across the system. It is valuable because users experience integrated journeys, not isolated services. It is also expensive because failures can be slow to diagnose.

Use end-to-end tests for critical flows: login, checkout, payment, onboarding, order fulfillment, claim submission, data export, or other workflows where integrated confidence matters. Do not use them as the primary way to test every business rule.

Interface And API Testing

Interface testing focuses on the points where systems communicate. Good interface tests include positive paths, invalid inputs, missing fields, duplicate requests, backward compatibility, authorization boundaries, and error payloads.

API tests are often the backbone of modern quality engineering because they validate behavior below the UI and closer to service contracts.

Compatibility And Configuration Testing

Compatibility testing asks whether software behaves correctly across supported browsers, operating systems, devices, versions, networks, locales, integrations, and infrastructure configurations.

The key is risk-based selection. Testing every possible combination is rarely feasible. Quality engineers should prioritize supported configurations by user population, business criticality, technical risk, and production history.

Installation, Deployment, Upgrade, And Migration Testing

Deployment and migration risks are often underestimated. A feature may be correct, but the release can still fail because configuration is wrong, data migration corrupts records, rollback is impossible, or older clients are incompatible.

Quality strategy should include deployment validation, upgrade paths, data reconciliation, backward compatibility, and recovery procedures.

Systems often fail in the spaces between components. Senior QA professionals focus there because integration risk is where many escaped defects, incidents, and customer-impacting failures originate.

Types Of Software Testing: A Practical Taxonomy For Quality Engineers

The value of knowing test types is not vocabulary. The value is knowing which kind of evidence each test type provides and when that evidence is worth the cost.

Lists of software testing types can become overwhelming. Acceptance testing, exploratory testing, regression testing, performance testing, security testing, usability testing, contract testing, and many others all appear important. The senior QA question is not "can I define each one?" The senior question is "which risks does this test type reduce?"

Start With The Risk, Not The Label

A test type is a tool for answering a quality question. Acceptance testing asks whether stakeholders can accept the delivered behavior. Exploratory testing asks what we can learn when requirements and scripted checks are incomplete. Regression testing asks whether existing trust has been damaged by change.

Good quality engineers choose test types based on product risk, lifecycle timing, cost, speed, and confidence value.

Foundational Test Approaches

• Unit testing: fast checks around small pieces of logic, usually owned by developers.
• Component testing: validation of a service, module, or component in controlled isolation.
• API testing: direct verification of service behavior, contracts, validation, authorization, and error handling.
• Integration testing: evidence that components work together across boundaries.
• System testing: validation of the complete system against functional and non-functional expectations.
• Acceptance testing: confirmation that business or user expectations are sufficiently met.

Human-Led Discovery

Exploratory testing is not random testing. It is simultaneous learning, test design, and execution. It is especially valuable when requirements are ambiguous, user workflows are complex, or the team needs to investigate risk beyond documented acceptance criteria.

Ad hoc testing, by contrast, is often informal and unstructured. It may find issues, but mature teams should prefer exploratory charters, session notes, and explicit learning goals when the risk matters.

Automation Is Not A Test Type By Itself

Automated testing describes how a check is executed, not what quality question it answers. A poor automated UI test may provide weaker evidence than a thoughtful manual exploratory session. A strong automated API test may provide fast, reliable decision support. The automation decision should follow the risk and the economics.

How To Use A Taxonomy Well

• Map each important product risk to one or more evidence sources.
• Prefer the cheapest reliable test level that gives useful signal.
• Use end-to-end tests sparingly for critical journeys.
• Keep exploratory testing for ambiguity, usability, and emergent behavior.
• Review escaped defects to identify missing or weak test types.

A testing taxonomy is useful only when it improves judgment. The strongest QA professionals do not collect test-type definitions; they choose evidence deliberately.

What Quality Means In Software Engineering

Software quality is not one attribute and not one team's responsibility. Quality is the degree to which software creates trusted value for the people and systems that depend on it.

Quality has many classic definitions. Juran described quality as fitness for use. Crosby emphasized conformance to requirements. Both are useful, but modern software delivery requires a broader view. A product can conform to documented requirements and still disappoint users. It can satisfy users today and still be difficult to operate, secure, scale, or change tomorrow.

Quality Is Contextual

Quality depends on who is using the software, what they need, what failure costs, and what constraints exist. An internal dashboard, a banking API, a medical workflow, and a consumer mobile app should not be judged by the same quality model.

The right quality conversation starts with context: what outcomes matter, what risks matter, and what evidence would convince us that the system can be trusted?

Important Software Quality Attributes

• Functional correctness: the software does what it is intended to do.
• Reliability: it behaves consistently under expected and imperfect conditions.
• Performance: it responds within acceptable latency, throughput, and capacity constraints.
• Security and privacy: it protects users, data, and systems from misuse and exposure.
• Usability and accessibility: intended users can complete meaningful tasks effectively and inclusively.
• Data integrity: data remains accurate, complete, consistent, traceable, and recoverable.
• Maintainability: the system can be changed safely without excessive cost or risk.
• Operability: teams can deploy, monitor, diagnose, and recover the system in production.

Why This Matters For QA

If QA defines quality only as defect absence, the strategy becomes too narrow. Good quality engineering asks how each relevant quality attribute will be designed, tested, observed, and improved.

For example, performance cannot be solved by a late load test alone. Security cannot be solved by one penetration test. Accessibility cannot be solved by an automated scan. Operability cannot be solved after production incidents. These attributes need engineering attention throughout the lifecycle.

The Senior Quality View

A senior QA leader helps the organization define quality explicitly. That means translating vague expectations into quality attributes, risk thresholds, acceptance evidence, release criteria, and production learning loops.

The question is not "is the software high quality?" in the abstract. The question is "does this software provide enough value, with acceptable risk, for the people and business processes that depend on it?"

Quality is value plus trust. Testing contributes to quality by generating evidence, but quality itself is produced by the entire engineering system.

TaaS - Testing as a Service

This is an introductory post to TaaS (Testing as a Service). If you have prior TaaS experience, feel free to share your thoughts.

What is TaaS?

TaaS leverages the cloud to offer scalable testing services to clients on an as-needed/on-demand basis. The goal is to offer highly accessible and available testing services at lesser cost. Test tools reside and test execution occurs on the cloud. Interfaces to access this service are provided e.g. via a web service, web app, etc. Normally, when talking of TaaS people think that only automated tests would be supported. However, TaaS involves the following models - all automated testing, manual (human run) or a hybrid model. Manual testing would be similar to an outsourced testing model which most of you may be familiar with.

Why move to TaaS? 

Increasing costs - human resources, Labs & equipment - hardware/software, challenges with handling larger and complex products, several different types of testing to be performed, etc. As software gets more complex, inter-dependencies increase, support matrices multiply and the overall costs & complexity associated with testing keep rising.

TaaS offers to reduce hardware costs associated with maintaining labs in-house with elastic virtualized resources on the cloud at a much lower price point. Additionally, the number of testers needed in the TaaS model may be lesser than the traditional (non-cloud) model. In the non-cloud model, we can have large suites of tests that take a long time to execute and consume significant hardware resources which may block multiple parallel runs. On the cloud, given the ability to auto scale and spawn systems on demand, it is possible to parallelize execution of tests across multiple different topologies/configurations.

What can TaaS do?

TaaS can handle various categories/types of testing. Here are the more popular ones -

• Standalone product testing - upload a product/application and the test service runs a set of pre-defined checks and reports back on tests run and issues observed ranked by severity. More suited to small and some medium size apps
• Continuous Testing - checkout latest code from a repository, build, deploy, run a defined set of tests and report results back to enable Developers to improve their code/fix issues
• Application certification - offers more flexibility in determining what to test and provides a certification report. Useful to run against release/milestone drops of an application
• Load/Stress/Performance testing - an advantage with TaaS is the ability to quickly and often seamlessly scale on demand, mimic real world usage easily - perform cross-geo deployments and test, offer the necessary bandwidth and resources as needed
• Functional testing, localization (l10n) and i18n, Security testing, Unit testing, etc.

Benefits of TaaS

• Efficient use of test infrastructure and tools - with TaaS you normally pay only for what you use unlike a traditional model where you have a significant outlay of investment for setting up the infrastructure, obtaining dedicated tools, getting resources, etc. TaaS payment models are generally of the type - pay-as-you-go or pay-per-unit
• TaaS offers a scalable cloud based environment - unlike the traditional model where you are limited by the amount of hardware and platforms you have on site, with TaaS you can virtually scale up and down to the necessary extent based on your needs
• Related to the above point - the benefit of being able to scale in a TaaS model allows you to run really large tests and simulations
• With TaaS, you can share test tools and computing resources. Moreover, these tools and resources can be obtained when you need them - on-demand.
• Potential savings in costs with TaaS - operational, maintenance, etc.
• Potential for reduction in test times in a TaaS model which may help speed up releases

***

Liked this post? Join my community of professional testers to receive fresh updates by email. Use this link to add your email address to the community. Rest assured, I will neither spam nor share your email address with anyone else. Subscriptions are handled automatically by Google's FeedBurner service.

Testing in an Agile World: What Still Matters

Agile changed the timing of testing, but it did not change the purpose of testing. The purpose is still to provide useful evidence about product risk, only now the evidence must arrive continuously rather than at the end of a long delivery cycle.

When teams misunderstand this, Agile testing becomes shallow. QA is asked to test faster, attend more ceremonies, and accept less documentation, while the real quality conversations still happen too late.

The tester's work starts before implementation

The most valuable Agile testing often happens during refinement. A good tester challenges unclear acceptance criteria, asks about data conditions, identifies edge cases, and helps the team turn vague intent into testable examples.

That does not mean QA owns quality alone. It means QA brings a risk perspective into product and engineering decisions while the work is still easy to change.

Short cycles need better feedback, not weaker standards

A two-week sprint does not justify ignoring performance, accessibility, security, migration risk, or supportability. It requires the team to decide earlier which of those risks matter for a given change and how evidence will be collected.

• Use examples to clarify requirements.
• Automate stable checks at the right level.
• Keep exploratory testing focused on ambiguity and workflow risk.
• Make residual risk visible before the sprint review or release decision.

The real Agile quality test

A team is not mature because it uses Agile vocabulary. It is mature when quality information moves quickly, defects lead to better upstream decisions, and every role understands its part in creating a releasable increment.

Testing in an Agile world is not less testing. It is earlier, sharper, more collaborative testing.

How to apply this inside an Agile team

The practical move is to bring this thinking into refinement and sprint planning. Before implementation starts, ask what risk the story carries, which examples clarify the expected behavior, and what evidence will be needed before the work can be considered releasable.

Agile quality improves when testers influence the conversation early. If QA only reacts after development is finished, the team may be using Agile ceremonies while still operating with a late-inspection quality model.

Agile Testing: Quality Engineering Inside The Delivery Flow

Agile testing is not compressed waterfall testing. It is continuous quality thinking embedded into product discovery, design, development, automation, exploration, release, and production learning.

The most important difference between Agile testing and traditional phase-based testing is not sprint length. It is feedback timing. In a weak delivery model, testing receives finished work and reports what is wrong. In a strong Agile model, testing helps shape the work before and during implementation so risk is reduced earlier.

Testing Starts Before Code

Agile testers should be involved in backlog refinement, story review, risk analysis, acceptance criteria, example mapping, and definition of done. This is where many defects can be prevented. Ambiguous acceptance criteria, missing edge cases, weak error handling, hidden dependencies, and unclear data rules are cheaper to address before code is written.

The best Agile testing conversations include product, development, QA, design, security, operations, and data perspectives when the risk justifies it. The goal is not more meetings. The goal is earlier clarity.

Testing Happens Throughout The Sprint

Agile teams should avoid the pattern where development consumes most of the sprint and testing becomes a late scramble. That is not Agile quality. It is a smaller waterfall.

Good teams build feedback into the flow: developer tests, code review, static checks, unit tests, component tests, API tests, contract tests, exploratory sessions, and automated regression all contribute at different points. The tester is not waiting at the end. The tester is helping the team ask better questions all along the way.

Automation Matters, But Judgment Matters More

Test automation is essential in Agile because repeated manual regression cannot keep pace with frequent change. But automation alone does not create quality. Automated tests must be fast, reliable, maintainable, and mapped to real product risk.

A mature Agile test strategy uses automation at the right level. Business rules should often be validated below the UI. API and contract tests should protect service behavior. End-to-end tests should be thin and focused on critical user journeys. Exploratory testing remains essential for ambiguity, usability, workflow risk, and unexpected behavior.

The Definition Of Done Must Include Quality Evidence

A strong definition of done should not say only that code is complete. It should describe the evidence required for the story to be considered releasable.

• Acceptance criteria reviewed and met.
• Relevant automated tests added or updated.
• Important negative and edge cases considered.
• Accessibility, performance, security, or data risks addressed where relevant.
• Telemetry, logs, or support visibility added for important workflows.
• Known residual risk documented.

Common Agile Testing Failures

• Testing only acceptance criteria and missing broader risk.
• Leaving QA work until the end of the sprint.
• Using Agile as an excuse for weak documentation instead of useful documentation.
• Automating UI checks for everything because lower-level tests were not designed.
• Ignoring cross-story risks such as data migration, permissions, performance, and integration.

Agile testing is powerful when it improves the speed and quality of feedback. It becomes shallow when teams simply squeeze old testing habits into shorter cycles. The real goal is not to test faster at the end. It is to build quality into the delivery flow.

Ad hoc testing

Also termed as unplanned or unstructured testing. It is a test type where test execution occurs in the absence of documented test cases and plans. It does not make use of any of the test design techniques such as boundary value analysis (BVA), equivalence partitioning, etc.

Ad hoc testing is performed to explore the different areas in the product by applying intuition, knowledge of the product, technology, domain and experience. It is done to find bugs that were not uncovered during planned testing.

Ad hoc tests may be run either prior to or after execution of planned tests. Ad hoc testing when done prior to planned testing helps in evaluating the quality of the product before starting a formal testing campaign. It also helps clarify requirements better.

Ad hoc tests when run post execution of planned tests helps unearth newer defects that planned tests may have missed. It highlights additional perspectives and scenarios which may not have been considered as part of the planned test exercise. Towards the end of the release after the formal test cycles have been run, a round of ad hoc testing serves to increase confidence in the coverage of the planned cycle.

While Ad hoc tests are executed without the need to document test cases, it is recommended to document tests that were executed and steps followed as much as possible to enable us to enhance the existing planned test suite, ensure repeat-ability and increase coverage.

In Ad hoc testing, the tester "improvises" and attempts to find bugs with any feasible means. An approach to ad hoc testing would be to start our tests using the existing documented test cases and explore newer variations from there. Alternatively, the tester(s) can explore the product using their experience and knowledge without referring to documented tests.

Ad hoc testing enables discovery - of new issues, areas that may not have been touched by planned tests, new perspectives that question requirements and assumptions. Ad hoc testing can find holes in your test strategy. Ad hoc testing when run post planned testing, serves as a tool for verifying the completeness of your testing.

A drawback of ad hoc testing is that these tests are not documented and, hence, not repeatable. This prevents ad hoc tests from being used for subsequent regression testing. To overcome this, it is recommended that we document test cases as much as possible once they have been executed. Despite this, it may be the case that some tests and steps may be left out as testers "jump" across functional areas to test and unearth issues. Ad hoc tests can be used to complement the planned testing exercise. On its own, it doesn't inspire much confidence in coverage. There is also the concern regarding repeat-ability despite trying to document as many of the tests and steps as possible.

Do you know the different types of testing? Check this post to know more.

Software Testing Lifecycle (STLC)

Listed below are the typical steps in a Software Testing Life Cycle (STLC). Note that these are not set in stone and can change per your requirements. Phases can collapse or get more granular as needed. I have tried to list steps in a fairly granular fashion. Several of these can be combined into a larger "phase".

Requirements analysis and review

This covers functional and non-functional requirements and their impact on testing. An RTM (requirements traceability matrix) may be prepared along with defining the acceptance criteria/done definition for various requirements. Additionally, any specific testability requirements may be conveyed to stake holders while considering automatability of requirements. In the past, one might consider a formal requirements sign-off too with testing as one of the stakeholders. In the Agile world, a high level set of requirements can be agreed upon (perhaps at an epic level or even high level stories) with changes expected as teams go through each iteration or sprint (e.g. Scrum).

Design review

Continuing from the previous stage, here a greater degree of clarity around requirements is available. Teams may review design and mockups which help the test team with preparation of test plan and cases. Teams may iterate until acceptable designs are identified.

Test planning

This is the stage where test plan(s) is/are prepared including initial effort estimates, resource plans, test tool identification, etc. I listed out test plans to mean both an overall test plan and individual test plans for sub-components or modules as the case may be. Depending on the size and nature of your application, you may have just one over arching plan or an overall plan supported by sub-level plans.

Test design

The test team creates test cases followed by cross-functional reviews typically involving development team and product managers/owners. These could be automated and/or manual tests.

Test environment preparation

Here, the test bed/lab setup is performed. Any 3rd party software required is installed and integrated. Product builds are installed on this environment and sanity/smoke tested prior to starting an extensive test campaign. In summary, all required hardware and software components are setup, integrated and made ready.

A point to note - the ideal goal here is to mimic the real world or production environment. Depending on your resourcing situation, you may either have a replica of your production deployment or a close enough clone.

Test data preparation

Necessary test data required to execute all identified tests is prepared. The nature of data to be prepared is dependent on the type of inputs accepted by the SUT. While this step may sound simple, there are considerations to be made on the data to be selected. Unless you have unlimited time and resources at your disposal, you will need to pick a subset of data which constitutes a representative sample whose successful execution will provide a certain degree of confidence in the ability of your application to handle most (any) inputs. Let's call it the test data selection problem which we will touch upon in a subsequent post. For now, know that selecting the right set of data has a significant bearing on the outcome of your testing exercise/campaign. Note that the necessary workload needs to be simulated to match real world usage.

Test Oracle preparation, Test stubs and driver preparation as needed, Test termination/exit criteria definition

Here we identify a mechanism or an entity which is used to confirm whether the software performed correctly or otherwise. An example would the requirements definition itself which the application must satisfy. For automated tests, we need to develop suitable test oracles (e.g. functions which return a boolean value or some such method) to check if the observed behavior is accurate. Other tasks include preparing any needed stubs and drivers and determining the criteria for terminating your tests.

Test execution

True to it's name, this stage involves running of the tests and reporting results.

Test results analysis and reporting defects

We could combine this with the previous stage but I have separated it out for a little bit more clarity. In this stage, test results are analyzed and defects (bugs) reported.

Fix verification, retest

Defects (bugs) reported are fixed and fixes are verified. Necessary regression tests are run to ensure fixes haven't introduced new defects. In the real world, expect fix failures, unexpected regressions and lot of duh moments.

Test closure

Prepare and submit the report of all testing performed, defects found, etc. and relevant artifacts. You would normally archive it at some location for later reference.