---
menu:
  contribute:
    parent: Contributing and managing patterns
title: Validated Patterns - Tested tier
weight: 54
aliases: /contribute/tested/
---

:toc:
:imagesdir: /images
:_content-type: ASSEMBLY
include::modules/comm-attributes.adoc[]

[id="about-tested-tier"]
= About the {tested-tier-first}

The {tested} tier provides you with additional collateral and reassurance that the pattern was known to be recently working on at least one recent version of {rh-ocp}. Inclusion in this tier requires some additional work for the pattern's owner, which might be a partner or a sufficiently motivated subject matter expert (SME).

[id="nominating-a-pattern-for-tested-tier"]
== Nominating a pattern for the {tested} tier

If your pattern qualifies or meets the criteria for {tested} tier, submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].

[NOTE]
====
Each {tested} pattern represents an ongoing maintenance, support, and testing effort. Finite team capacity means that it is not possible for the team to take on this responsibility for all {solution-name-upstream}.
====

For this reason we have designed the tiers and our processes to facilitate this to occur outside of the team by any sufficiently motivated party, including other parts of Red Hat, partners, and even customers.

In limited cases, the {solution-name-upstream} team may consider taking on that work, however please get in contact at least 4 weeks prior to the end of a given quarter in order for the necessary work to be considered as part of the following quarter's planning process


[id="requirements-tested-tier"]
== Requirements for the {tested} tier

A {tested} patterns have deliverable and requirements in addition to those specified for the link:/contribute/sandbox/[Sandbox tier].

The requirements are categorized as follows:

Must::
These are nonnegotiable, core requirements that must be implemented.
Should::
These are important but not critical; their implementation enhances the pattern.
Can::
These are optional or desirable features, but their absence does not hinder the implementation of a pattern.

[id="must-tested-tier"]
=== Must

A {tested} pattern must continue to meet the following criteria to remain in the {tested} tier:

. A {tested} pattern must conform to the common technical link:/contribute/implementation/[implementation requirements].
. A {tested} pattern must be meaningful without specialized hardware, including flavors of architectures not explicitly supported.
+
Qualification is a {solution-name-upstream} Technical Oversight Committee (TOC) decision with input from the pattern owner.
. A {tested} pattern must have their implementation reviewed by the patterns team to ensure that it is sufficiently flexible to function across a variety of platforms, customer environments, and any relevant verticals.
. A {tested} pattern must include a standardized architecture drawing, created with (or at least conforming to) the standard {solution-name-upstream} tooling.
. A {tested} pattern must include a written guide for others to follow when demonstrating the pattern.
. A {tested} pattern must include a test plan covering all features or attributes being highlighted by the demonstration guide. Negative flow tests (such as resiliency or data retention in the presence of network outages) are also limited to scenarios covered by the demonstration guide.
+
The test plan must define how to validate if the pattern has been successfully deployed and is functionally operational.
Example: link:https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment].
+
//TODO: Convert above link to adoc

. A {tested} pattern must nominate at least one currently supported {rh-ocp} release to test against.
. A {tested} pattern must ensure the test plan passes at least once per quarter.
. A {tested} pattern must create a publicly available JSON file (for example, in an AWS bucket) that records the result of the latest test for each combination of pattern, platform, and {rh-ocp} version. See link:/contribute/test-artifacts/[testing artifacts].

[NOTE]
====
A {tested} pattern *does not* imply an obligation of support for partner or community operators by Red Hat or the pattern owner.
====

[id="should-tested-tier"]
=== Should

. A {tested} pattern should be broadly applicable.
. A {tested} pattern should focus on functionality not performance.

[id="can-tested-tier"]
=== Can

Teams creating {tested} pattern can provide their own service level agreement (SLA).

A technical document for Quality Engineering (QE) team that defines how to validate if the pattern has been successfully deployed and is functionally operational.
For example, see link:https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment].

A {tested} pattern meeting additional criteria can be nominated for promotion to the link:/contribute/maintained/[Maintained tier].