The Agile Quality Assurance Team
The Quality Assurance (QA) team has the awesome responsibility of ensuring that the “Vision of Success” that has been created by the Business Team, communicated to the Architect Team and delivered by the Development Team meets all Client expectations.
This responsibility defines the “QA Objective”.
In Other Words, the QA Objective Ensures
… Delivered Business Solutions Meet
…… Minimum Solution Expectations
The QA Teams success is predicated on a compete knowledge of the Client’s success criteria as defined by the Architect Team’s understanding of the Business Team vision.
Team Justification
The QA Objective can only be achieved by active participation in the review stages of Design, Development and Delivery Integration of the successfully reviewed development code base.
A representative of the QA Team must participate in all three of these review stages in order to accomplish the QA objective.
The Design Review Stage – Empowers the QA Team to understand the required QA Test Cases, Test Harnesses and Test Scripts for each of the design specification SOW’s that defines the abstract code base to be developed
The Development Review Stage – Provides the details, presented in the Design Review, of the concrete delivered code base used to complete the QA Objective used during the Integration Review Stage
The Integration Review Stage – Integrates the QA requirements by enabling the Development Team to be crystal clear about the QA Objectives
The Development Team uses the QA Acceptance Criteria delivered to the Development Team and refined by the Development Review as their acceptance criteria during the integration of the designed code base into the Development Environment.
The Integration Review uses the QA Acceptance Criteria to validate that all design requirements have been met.
As long as the delivered QA Acceptance Criteria from the QA Team meets the Client’s Acceptance Criteria, as it is defined by the Architect Team’s Design Review and by the Development Team’s Integration Review, then the QA Process becomes a simple validation of the Development Team’s successful Integration Reviews that have met the QA Team’s QA Objective.
Roles and Responsibilities
QA Manager – The successful understanding of the Business Solution’s QA Objectives is the primary responsibility of the QA Manager.
The QA Objective is defined as a thorough knowledge of the “Vision of Success” that has been created by the Business Team, communicated to the Architect Team and delivered by the Development Team.
This role ensures that a QA Team member is assigned to attend and participate in the Architect Team’s Design Reviews and the Development Teams Code Reviews.
The QA Manager disseminates the QA testing requirements gathered by the QA Design and Development representatives to the team for generation of the QA Objectives.
The QA Manager is responsible for delivering to the Development Team the QA Objective’s testing criteria that the Development Team will use during its Integration Development stage and validated during the Development Integration Review process.
QA Lead – The QA Manager delegates daily responsibilities to the QA Lead. This role’s primary responsibility is ensuring that the QA Objectives, disseminated by the QA Manager, become concrete Testing Criteria that can be delivered to the Development Team to be used as its Integration validation criteria.
The QA Lead manages the QA Test Analysts and the Performance Analysts.
The QA Lead can participate as a QA Test Analysts or a Performance Analysts but the role’s main responsibility is the successful completion of Integration and Regressive testing as defined by the QA Objectives.
The QA Test Analysts and the Performance Analysts report to and are assigned testing responsibilities from the QA Lead.
The QA Lead works with the Architecture and Development Teams by acting as the QA representative for the Design, Develop and Integration Review teams along with being the QA Team’s Daily Scrum Team representative.
Together with the Scrum Master and QA Manager, the this role facilitates solving any blocks raised during the Scrum Stand Up daily meeting that are related to the QA Objectives.
QA Test Analysts – The QA Test Analyst is responsible for working with the QA Lead to create, validate and execute the Test Suites that ensure the success of the QA Objectives.
The developed Testing Suite is used for Integration and Regressive testing throughout the testing cycles to guarantee the Business criteria defined in the QA Objective has been successfully met.
The QA Analysts are responsible for delivering to the Development Team’s Integration Developers a Test Suite that will reduce the number of bugs that the QA Team will have to locate by allowing the Development Team’s Integration Developers to validate the QA Objectives before the Development Integration Review.
The Development Integration review will certify that the QA Objectives have been met and the delivery of the Developed code base to the QA Team will require a minimum of QA effort.
This process creates a “Double Check” closed loop process that minimizes costly bug resolution at the QA stage and ensures a lower cost of ownership product is delivered during the Sprint deployment stage.
QA Performance Analysts – The QA Performance Analyst is responsible for ensuring that once the code has met the QA Objective by successfully passing the delivered Test suite that its security and performance meets the Business Teams acceptance criteria.
Security certification is the major responsibility of the QA Performance Analyst.
This role documents the integration performance from a highest level of abstraction perspective, the User Experience (UX).
The QA Performance Analyst works with the Development Team Lead to help identify performance “Bottle Necks” caused by the Forces of Software Development.
These forces, Capacity and Latency (Affinity) along with Intermittent Failure and Human factors such as malicious attacks and human error are evaluated and managed by the Architecture, Development and Network Teams.
Memory usage and possible leaks are evaluated and issues are reported to the Architecture team for resolution by the Development Team.
The UX must be regressive tested after every QA Objective validation is successfully completed to ensure that the perceived performance has not been compromised with any new development updates.
Areas of Participation
The QA team supports the same Areas of Participation as the Development Team.
The deliverables from the Development team are validated using the QA Objectives as defined by the QA Manager’s Test Suite development.
Detail Representation – The QA Team certifies the that the development tasks delivered meet the acceptance criteria of the detailed representations of the Business Model.
The Development Team is the Builder of the Technology Domain Entity solution.
The Domain Entity Data Model is create within the selected Development language such as C# and .NET and built on the defined Network Architecture.
The Cross Cutting Aspect of Security is designed to be available and applied as a Domain Component Level Authentication and Authorization concern.
The Software Development Forces of Nature are used as Design Constraints to help manage the forces at work such as Capacity and Latency (Affinity) along with Intermittent Failures.
The “Human Factor” is a design consideration, both intentional malicious attacks and unintentional human error.
Functioning Enterprise – The results of the development tasks must be certified by the QA Team as the Business Enterprise’s realization of a successful audience perception of success: A Functional Enterprise Business Technology Solution.
The Data Entity models must be presented in “Process Flows” that create an “Enjoyable User Experience”.
A Functional Enterprise is extensible through Distributed Systems that can support heterogeneous Clients that can scale with time with minimum of design changes.
Changes in the Organizational Roles should not adversely affect the scalability and extensibility of the Functional Enterprise Business Technology Solution.
The deployed solution that creates the Functional Enterprise should be as non-temporal as possible.
Its Timing Cycles should be defined dynamically and driven by the Strategies of the Enterprise at a single point in space and time.
Participation Requirements
-
Data Definitions
-
QA Manager
-
QA Lead
-
-
Data Enterprise Delivery
-
QA Manager
-
QA Lead
-
QA Test Analysts
-
QA Performance Analysts
-
-
Program Development
-
QA Manager
-
QA Lead
-
-
Enterprise Business Functionality Delivery
-
QA Manager
-
QA Lead
-
QA Test Analysts
-
QA Performance Analysts
-
-
Distributed Network Services
-
QA Manager
-
QA Lead
-
-
Enterprise Services Delivery
-
QA Manager
-
QA Lead
-
QA Test Analysts
-
QA Performance Analysts
-
-
User Access Security Development
-
QA Manager
-
QA Lead
-
-
Enterprise Security Delivery
-
QA Manager
-
QA Lead
-
QA Test Analysts
-
QA Performance Analysts
-
-
Operational Timings Development
-
QA Manager
-
QA Lead
-
-
System Event Scheduling Delivery
-
QA Manager
-
QA Lead
-
QA Test Analysts
-
QA Performance Analysts
-
-
Business Rules Development
-
QA Manager
-
QA Lead
-
-
Enterprise Strategies Delivery
-
QA Manager
-
QA Lead
-
QA Test Analysts
-
QA Performance Analysts
-
-
Daily Scrum Stand Up Meeting
-
QA Team Representative
-
-
Sprint Design Reviews
-
QA Manager
-
QA Lead (Optional)
-
-
Sprint Development Reviews
-
QA Lead
-
QA Manager (Optional)
-
-
Sprint QA Release Reviews
-
QA Lead
-
QA Test Analysts
-
QA Performance Analysts
-
QA Manager (Optional)
-
Wisdom Pearl # 121 – Work Quality Concept
Your Work is Only as Good
… As How it is Perceived by the Next Person who Touches It
…… Positive Acceptance of your Work is Your Preeminent Responsibility
Latest posts by Brad Huett (see all)
- DevOps: A Bridge to Your DevOps Culture - March 25, 2016
- Embracing Test Driven Development (TDD) - March 25, 2016
- DevOps: Delivering Agile Projects - March 25, 2016