Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Untitled Prezi

No description
by

Zhenya Rozinskiy

on 25 April 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Untitled Prezi

Finally All Information from this presentation with links is available on Confluence

https://confluence.tm.tmcs/confluence/display/ECOM/Resale+Overall+QA+Strategy Integrated Resale Environment Resale Testing Strategy Description: A "unified" environment that is also a QA "integration environment" for the Resale project. Services should be stable, and must either deploy with, or after, their dependencies, to ensure this environment is mostly stable for integration qa testing.

Deployed By: Release Management

Major Components: intqa102, QA10, TicketsNow Staging, and a number of related systems. Release Management Each service is scheduled to be deployed once per week.

Any out-of-cycle release will require approvals from all teams that are dependent on your service/code/functionality. It will also require a communication to all teams. Assumptions and Roles - Because of the project scale each QA team is working closely with their development group and functions autonomously.
- All testing for individual services and components is to be performed by an individual team responsible for the service
- Each test team is expected to follow their existing processes and report status based on their findings
- Vertical QA leads are responsible for coordination and oversight of QA efforts.
- Vertical leads are not expected to manage individual teams and/or control their processes Definition of Terms Reporting Each team is expected to produce a Jira Dashboard showing their progress

Results of Smoke tests and End-to-End Tests are maintained in TestLink

Summary of results is posted in Confluence http://bit.ly/15qLcPp Smoke Test
Intended to demonstrate that any deployment to the integration environment was successful. It is performed by each team post every deployment and is geared to cover basic functionality. Results of each smoke test to be recorded in Test Link upon completion. Time Driven. Resource Constrained. Functional Tests Functional tests are the vast majority of tests performed by each team to ensure that their code meets all requirements and is bug free. Each team will use their existing processes for planning, executing, and recording of functional tests. End-To-End Tests A functionally driven set of tests to be executed in integration environment. These tests are geared to demonstrate that high level functional requirements are met. Majority of these tests are UI driven since those are main entry points for users. All tests to be documented in Test Link and all results to be recorded there as well. Smoke Test Intended to demonstrate that any deployment to the integration environment was successful. It is performed by each team post every deployment and is geared to cover basic functionality. Results of each smoke test to be recorded in Test Link upon completion. Test Documentation Each team is expected to provide test plans for their services

An overall Test Plan will be compiled based on specific documents submitted by each team Test Approach Testing is split in three basic categories. Functional Testing Each team is expected to perform functional level testing for their component/service using their own environment prior to deploying it to Integration. Only QA tested and "done" code should be deployed to Integration. Each team should have their environment pointing to Integration for upstream dependencies to test their product.

Functional Testing is expected to uncover the most number of bugs and to be the most extensive test for the system. Integration Testing Each team is responsible for performing integration testing for their service/component. This testing should occur in the Integration environment and use all upstream dependencies residing in the same environment. Upon deployment to Integration each team must complete a smoke test prior to calling their deployment complete.

Integration testing is expected to uncover issues with one dependencies between different services and/or systems. End-to-End Testing When Resale program gets close to be functionally complete (Middle of May) QA will begin regular End-To-End runs. Those runs will be done in addition to functional testing performed by each team. These end-to-end tests will be performed in the Integration environment as a coordinated effort by all involved groups.

End-to-End tests are use case driven and are intended to validate business functionality Release Criteria QA will identify and communicate risks associated with the project.

Each team will report in details risks for their service/component and vertical leads will report the overall status.

Working with the product team we'll make sure that each product owner has all the facts to make a decision if this product meats business needs. Challenges - Teams follow different processes
- Teams have other priorities, at times more urgent than resale deliverables.
- Some team members are new and not familiar with tools and existing standards
- Teams are getting conflicting instructions from vertical leads and their immediate managers.
Full transcript