In my previous post: Use Case Template i post about use case template. In this post i'm posting general SAP CML Volume Testing template:
Volume Testing
Duration and Timing:
1. The duration of the volume test strongly depends on the complexity of the tested business scenarios.
2. Planning the timetable for testing.
Test Scenarios and Requirements:
For each of the core business processes, identify the relevant steps and arrange them in several test scenarios. Dependencies between the steps need to be identified and the critical success factors for the steps must be defined.
Test Scenarios:
1
2
3
SAP CML Business Processes for the Test
1. Business Partner
2. Contracts
3. Disbursements
4. Payments
Time Table:
Business Process//Processing Time//Frequency Type// Single user processing time per line
Create BP //15.00-15:30//Daily//Interface, Online//800 ms
Master Data Transfer//22.00-24.00 (Europe) 9.00-17.00 (CT)//Weekly//Interface//800 ms
Create correspondence //07.00-19.00//Daily//Online, Background//400 ms
Create invoice //22.00-01.00//2 per month//Background//150 ms
Create cheque //9.00-10.00//Daily//Background//800 ms
Create PAP //9.00 – 12.00//Daily//Background//600 ms
Implement Test Tools:
Manual Testing or Load Generators
Tuesday, October 27, 2009
Sunday, October 25, 2009
Agile Quality Assurance
Agile Quality Assurance
The Agile approaches are changing the conversation about software development. Agile shifted our attention to small teams incrementally delivering quality software. The old ideas about testing at the end of the coding phase no longer applicable. We need to think new about the role of Quality Assurance in Agile Projects.
Agile Testing abandons the old notion about how Testers communicate. Requirements and design docs are insufficient, as are test plans and bug reports. Agile Testing sees docs as interesting texts, partly fictional, often useful. Documents are as good as they are going to get. Testers need to join in the conversations with developers and users.
New models for Test Development
Testing may be degraded by poor or late docs, but it should not be blocked entirely.
Testers should use sources of information other than project docs when designing tests.
Test design must take into account what is learned from running tests.
The tester must take explicit, accountable action in response to dropped handoffs, new handoffs and changes to the contents of handoffs.
Source: http://www.mcbreen.ab.ca/
The Agile approaches are changing the conversation about software development. Agile shifted our attention to small teams incrementally delivering quality software. The old ideas about testing at the end of the coding phase no longer applicable. We need to think new about the role of Quality Assurance in Agile Projects.
Agile Testing abandons the old notion about how Testers communicate. Requirements and design docs are insufficient, as are test plans and bug reports. Agile Testing sees docs as interesting texts, partly fictional, often useful. Documents are as good as they are going to get. Testers need to join in the conversations with developers and users.
New models for Test Development
Testing may be degraded by poor or late docs, but it should not be blocked entirely.
Testers should use sources of information other than project docs when designing tests.
Test design must take into account what is learned from running tests.
The tester must take explicit, accountable action in response to dropped handoffs, new handoffs and changes to the contents of handoffs.
Source: http://www.mcbreen.ab.ca/
Monday, October 5, 2009
Agile 3: Quality Assurance and Agile projects
Quality Assurance and Agile projects
This post is part 3 of an Agile series; my last post was about measuring an Agile progress. In this post I’m talking more about, what are the QA Agile practices we are using in my company? Quality Assurance and Agile projects are very complex combo in any agile project. It’s true QA decrease the speed of any project and if project is on Agile, it certainly create complexity in an Agile methodologies. However being an Agile project that does not mean you can kick out the QA and close project on time with in budget. At the end stakeholder don’t appreciate if deliverable are on time and in budget but quality is shit. That’s the point mostly all project manager miss when they push team to complete project.
Anyway that an other story, but let’s talk about different dimensions in an QA world for an Agile project. I’m not explaining any dimension in this post, because the topic is so horizontal and wide that we can write whole book on it. So just focus on our scope, and they are not unique to QA world.
~ Functional Testing
~ Test Management
~ Independent Testing
~ Performance Testing
~ Security Testing
~ Service-Oriented Architecture (SOA) Testing
~ Transport Testing (SAP)
You can argue with me that there are so many other QA dimensions, which I can add. That’s true, but the thing is “IT Best Practices are not about right or wrong; it’s more about what and how.”
This post is part 3 of an Agile series; my last post was about measuring an Agile progress. In this post I’m talking more about, what are the QA Agile practices we are using in my company? Quality Assurance and Agile projects are very complex combo in any agile project. It’s true QA decrease the speed of any project and if project is on Agile, it certainly create complexity in an Agile methodologies. However being an Agile project that does not mean you can kick out the QA and close project on time with in budget. At the end stakeholder don’t appreciate if deliverable are on time and in budget but quality is shit. That’s the point mostly all project manager miss when they push team to complete project.
Anyway that an other story, but let’s talk about different dimensions in an QA world for an Agile project. I’m not explaining any dimension in this post, because the topic is so horizontal and wide that we can write whole book on it. So just focus on our scope, and they are not unique to QA world.
~ Functional Testing
~ Test Management
~ Independent Testing
~ Performance Testing
~ Security Testing
~ Service-Oriented Architecture (SOA) Testing
~ Transport Testing (SAP)
You can argue with me that there are so many other QA dimensions, which I can add. That’s true, but the thing is “IT Best Practices are not about right or wrong; it’s more about what and how.”
Sunday, October 4, 2009
Use Case Template
Use Case Template
Before i explode with template, lets talk first what is Use Case?
Use Case: A use case describes "who" can do "what" with the system in question. The use case technique is used to capture a system's behavioral requirements by detailing scenario-driven hreads through the functional requirements.
There are many different styles and templates for use cases. These elements constitute a reasonable framework for a bare essentials use case.
Name
The name of the use case captures the essence of the use case and provides a recognizable reference for readers. It should also appear on an accompanying use case diagram.
Unique IdentifierThe identifier is often a number, and is essential to requirement traceability. It is used to cross reference requirements to design and test artifacts, and needed to verify delivery of the requirements. The identifier must be unique in both the scope of the project and the scope of the solution.
Brief Description
The description provides an informal, natural language description of the use case and the goal that is being satisfied. Functionality may be implied in this section, but no designs or tests should trace to it. All functionality must be identified in the elements below.
Preconditions
Preconditions describe what must be true for the use case to be triggered or started. They can relate to conditions either within the solution or outside of the solution under study. For example, when withdrawing money from an ATM at a specific bank, the customer must be an existing customer of that bank.
Basic flow of events
The basic flow is the ‘guts’ of the use case and describes the sequence of user to solution interactions and related solution behavior or rules. It is commonly referred to as the "primary scenario" or "happy path." It indicates what happens when there are no exceptions or complications.
Alternative flows
These describe what happens when things don’t follow the "happy path." Called a variation if the flow rejoins the happy path, and an exception where an error occurs, these prevent the actor from achieving their goal.
Post-conditions
Post-conditions are things that are true at the conclusion of a use case. Traditionally, these things are always true, regardless of what path is taken through the use case. If the use case has many alternate flows, there may be several outcomes with different post-conditions. It may be useful to identify post-conditions for the basic flow and each of the alternate flows.
source: www.theiiba.org/
Before i explode with template, lets talk first what is Use Case?
Use Case: A use case describes "who" can do "what" with the system in question. The use case technique is used to capture a system's behavioral requirements by detailing scenario-driven hreads through the functional requirements.
There are many different styles and templates for use cases. These elements constitute a reasonable framework for a bare essentials use case.
Name
The name of the use case captures the essence of the use case and provides a recognizable reference for readers. It should also appear on an accompanying use case diagram.
Unique IdentifierThe identifier is often a number, and is essential to requirement traceability. It is used to cross reference requirements to design and test artifacts, and needed to verify delivery of the requirements. The identifier must be unique in both the scope of the project and the scope of the solution.
Brief Description
The description provides an informal, natural language description of the use case and the goal that is being satisfied. Functionality may be implied in this section, but no designs or tests should trace to it. All functionality must be identified in the elements below.
Preconditions
Preconditions describe what must be true for the use case to be triggered or started. They can relate to conditions either within the solution or outside of the solution under study. For example, when withdrawing money from an ATM at a specific bank, the customer must be an existing customer of that bank.
Basic flow of events
The basic flow is the ‘guts’ of the use case and describes the sequence of user to solution interactions and related solution behavior or rules. It is commonly referred to as the "primary scenario" or "happy path." It indicates what happens when there are no exceptions or complications.
Alternative flows
These describe what happens when things don’t follow the "happy path." Called a variation if the flow rejoins the happy path, and an exception where an error occurs, these prevent the actor from achieving their goal.
Post-conditions
Post-conditions are things that are true at the conclusion of a use case. Traditionally, these things are always true, regardless of what path is taken through the use case. If the use case has many alternate flows, there may be several outcomes with different post-conditions. It may be useful to identify post-conditions for the basic flow and each of the alternate flows.
source: www.theiiba.org/
Subscribe to:
Posts (Atom)