Quality Assurance VAG

This is an early draft so scope and focus are still fairly open. Please add comments to the Talk:Quality Assurance VAG if you have slightly different concerns so that we can try to converge on a common viewpoint. This discussion could also expose other similar VAGs that are needed in this area.

Purpose

The Quality Assurance Viewpoint Advocacy Group (VAG) exists to assist with Software Quality Assurance within the architectural design group, both in terms of architectural project quality and also downstream design/implementation quality.

See the Architecture Working Group and the Viewpoint Advocacy Groups for more information.

Areas addressed by this viewpoint

• Creation of QA tools to automate testing of the new architecture.
• Identification of concerns within other AWG VAGs which could benefit from QA.
• Traceability from AWG VAG concerns to the properties of the new architecture.
• Application of QA tools to determine degree conformance with viewpoints.
• Reporting automation and visualization of AWG progress.
• General adherence to the guidelines of IEEE_1471 as found in AWG VAGs.

Areas not addressed by this viewpoint

• Coding practices.
• AWG VAG issues outside of identification of testable concerns.
• Server-side entities not visible from a client-side perspective.

Source of Viewpoint

No existing sources for this viewpoint have (yet) been sought. This viewpoint is however highly reusable, and therefore existing sources are very likely to exist and should be investigated.

Rationale for QA in AWG

• A distributed virtual community of developers tends to be not only larger but also less cohesive than an in-house team, largely due to less effective communications. To counteract this, QA can develop automation that highlights interfacing and functional inconsistencies, as well as providing an inherent "TO-DO" list from all the tests that are currently red-lighted.
• "Requirements" are not always easy to discern up front when developers are using some variant of Agile or eXtreme Programming approaches, but the results of such highly productive methods can be efficiently tied down through test automation. This becomes a form of live functional documentation.
• In a distributed supergrid of multiple, interoperating private worlds and grids, one can't afford to be lax when exporting change to the outside world, on pain of causing major service disruptions. QA becomes really important.
• A distributed supergrid cannot assume in-step upgrades across the whole universe. The environment is inherently a heterogeneous one, and this results in a combinatorial explosion of test cases. The only realistic way of handling this is through automated regression testing, as it can be expected to be far beyond the means of human case testers.

List of concerns in this viewpoint

This is an evolving list of concerns, currently comprising:

• Acquisition of technical information required by the various AWG VAGs.
• Identification of testable scalability concerns in the Scalability VAG.
• Identification of testable REST Services in the Core Grid Services, Protocols, and Structures VAG.
• Specification and delivery of QA tools in the Multi-Process Client VAG.
• Creation of appropriate QA automation using the QA tools.
• Application of these QA facilities and feedback to AWG members.

Use Cases

Use cases for this VAG are derived from normal software development practice. A few representative use cases will be provided, but the general requirement for QA is assumed not to require further justification.

Architectural Descriptions/Views used to express this viewpoint

Conceptually, this section identifies:

1. the general form or representation of ADVs required to express the viewpoint
2. the elements within such ADVs which will be used to express the viewpoint
3. how these elements within such ADVs map to the concerns of this viewpoint
4. the traceability to viewpoint concerns required for conformance with the viewpoint.

As QA has very broad coverage but also highly detailed involvement in some areas (for example interfaces validation and scalability testing), this VAG's ADVs are necessarily diverse:

• Lists of internal documents and references to external work.
• Detailed interface and protocol descriptions which act as an AWG service specification.
• QA tool configurations which define sets of required facilities through regression testing.
• QA tool reports and visualizations through which conformance with specific VAG concerns can be determined.
• Maintenance of traceability, progress and conformance tables on the wiki.

Tools employed by this VAG

• Normal wiki textual and graphic representations are expected to be sufficient for this VAG.
• Programmed tools are expected to be developed for scalability testing and measurement.

• Update: the design of an appropriate client-side QA tool is now being considered in the Multi-Process Client VAG -- draft.

Organization

Joining

Anyone with an interest in this Viewpoint is welcome to join. You should join the AW_Groupies group in Second Life.

In world meetings

All group communication is currently being held in the AW_Groupies IM channel.

In-world meetings can be convened by any stakeholder.

Group members are also active on the wiki.

Chat Logs

• none as yet

References

• IEEE_1471 -- recommended practice for architecture description

External Links

• Software Quality Assurance

Members (Stakeholders)

Please note that the Quality Assurance VAG is a non-hierarchical VAG in every respect, without exception. Any tags supplied with names are purely informational. Stakeholder ordering is alphabetical.

Morgaine Dinova 02:43, 18 October 2007 (PDT) - Founder, analyst

Tillie Ariantho 10:51, 23 October 2007 (PDT)