Why Do We Need Framework for Test Automation?

For the same reason, we carry a map when commuting and we draw a blueprint before building a house.
Not convinced?
Let us try to find the answer to why test automation framework- through thorough deliberation.
Automation is tricky- not just technically but also economically. It is best suited for areas where there is a substantial amount of tests that have to be repeated across multiple test cycles. And always, automation testing happens in addition to manual testing or complements it- but cannot, does not and should not replace it altogether.

Now, we testers know that the success of any testing endeavor- manual or automation- depends mainly on thorough planning. Typically, we are to spend 1/3 of the entire testing effort on planning- it’s the standard. This planning usually involves 2 main areas- managerial information like dates, schedules, milestones, people information etc., and technical testing related information on – Deliverables, how many cycles, tools, data etc. For an automation project, a framework is everything- a technical implementation guideline, as well as the managerial part of it.
The three technical entities (resources) in an automation project are roughly:

1. Code- script
2. Data
3. Objects and their definition on the AUT

The economical (expenditure-wise in addition to the manual testing team’s presence) ones are:

1. Tool – licensing. This might also include licenses for additional Add-ins required for the specific AUT on hand
2. Specialized man power
3. Time- effort in terms of man hours
4. Infrastructure (could be anything, starting from the physical space you provide for an automation tester to work from.)
5. Test Management tool if using any

In an industry where it is tough to get the buy-in for testing itself (although this has come a long way from where it used to be), it is going to be exceedingly difficult to prove the importance of automation, unless a sure result can be promised. In other words, we better figure out all the details and assure success or not venture into automation at all. This is where a solid framework can be the foundation that we need to set foot on solid ground and make sure that we don’t fall.
We are not going to go into the economic aspects in depth, because we get it. There is an X amount of money put in and we need to make sure that it stays a successful investment.

Why Test Automation Framework?

Let’s try to understand the technical part better:
We all know that, a good automation script should launch the AUT, supply the data, perform the operation, iterate/repeat itself as directed, validate and close the AUT, report results and finally, exit. Yes, it is a tall order!
Once we create a script that does all this, it reduces the execution and reporting time (especially if linked to a test management tool) to a few milliseconds as opposed to minutes or even hours. There is no overlooking or a typographic error etc., and overall efficiency is improved.
However, imagine how long it will take to write a perfect script that does it all. How long would it take to understand the test objective, come up with a solution, implement it in code, customize, debug and finalize?
As you see, the real time consuming factor is the test script creation. The more efficient and time-effective the automation scripts- the better the chances of success.
An example here:
1) Gmail.com page is the AUT.
2) Features to test:

• Compose email
• Create contacts
• Receiving an email

3) Automation testers- assuming each one is working on one feature
Yes, this is a little bit of an over simplified example. But, personally I feel that there is no concept on earth that cannot be broken down into easy-to-understand pieces. After all, the earth itself is made of tiny atoms.
Now, roughly, the scripts should have code that performs the operations as below:

1. Compose email : Gmail.com launch->Login authorization->Compose email->Write the contents, add attachments(email parameters)->Send email->Logout
2. Create contacts: Gmail.com launch->Login authorization->Select contacts->Create contact->Save->logout
3. Receive email: Gmail.com launch->login authorization->check email->read email-> logout

All the above scripts have to be tested for multiple users with multiple parameters in each operation.

------------

It is clear from the above representation that the following components are recurring/ repeating:

1. Gmail.com launch
2. Login authorization
3. logout

We can significantly reduce effort and time, if we create these components only once and make them available for all the other tests to use as needed – Reusability – create once, debug once, finalize once and reuse many times.
Reusability also makes sure that if a change has to be made, it can be done in a centralized way.
For example, if the gmail.com home page changes (the first component in every script) – we don’t have to modify each script (3 times in our case). We can simply change it once (in the reusable component) and all the others scripts that use it will automatically use the centrally changed code. This reduces rework and makes sure that changes are consistent over all.
Also, automation scripts recognize the elements on the AUT based on the definitions/properties they store of them. This is yet another major asset for an automation script. If many scripts are accessing the same object, there is no need to duplicate it every time. A common repository with definitions of the objects can help centralize several small local repositories- again, a huge plus for efficiency.
To summarize – the resources Code and Objects can be optimized by maximum reusability. When components are to be made reusable:
a) A correct order has to be followed in creating them (because if we write the code for login last, all the other scripts that need that step can’t be validated in full- same rationale applies to objects as well)
b) An identifiable (readable, with-in context) name has to be assigned
c) Stored in a location that is accessible and/or available for all the other scripts.
All this information about – What, where, how and when to implement these factors- is part of a framework.
Finally, the data. You have an option to hard code your data into the code/script- which will force you to create a new script every time a new data has to be supplied. The solution – separate the data from the code. Reuse the code to the maximum and provide the data separately. Again, where will you find the details on how to implement this decision? Framework.
Framework plays a major role in determining how to organize your automation project in order to maximize results. Apart from the above discussed areas, Framework can also guide the automation testers on how to execute scripts, where to store results, how to present them, etc.
In short, test automation framework is your overall game plan and it can take you where you want to go. So, don’t find yourself without it.

How to Review SRS Document and Create Test Scenarios:

Let us now get into a detailed analysis of how an SRS walkthrough happens, what is it that we need to identify from this step, what pre-steps we need to take before we begin, what are the challenges we could face etc. in a detailed manner.

SDLC’s Design Phase:

The next phase in the SDLC is “Design”- this is where the functional requirements are translated into the technical details. The dev, design, environment and data teams are involved in this step. The outcome of this step is typically a Technical Design Document- TDD. The input is the SRS document both for the creation of the TDD and for the QA team to start working on the QA aspect of the project- which is to review the SRS and identify the test objective.

What is an SRS review?

SRS is a document that is created by the development team in collaboration with business analysts and environment/data teams. Typically, this document once finalized will be shared with the QA team via a meeting where a detailed walkthrough is arranged. Sometimes, for an already existing application, we might not need a formal meeting and someone guiding us through this document. We might have the necessary information to do this by ourselves.

SRS review is nothing but going through the functional requirements specification document and trying to understand what the target application is going to be like.

The formal format and a sample were shared with you all in the previous article. It does not necessarily mean that all SRSs are going to be documented that way exactly. Always, form is secondary to the content. Some teams will just choose to write a bulleted list, some teams will include use cases, some teams will include sample screenshots (like the document we had) and some just describe the details in paragraphs.

Pre-steps to software requirements specification review:

Step #1: Documents go through multiple revisions, so make sure we have the right version of the reference document, the SRS.

Step #2: Establish guidelines on what is expected at the end of the review from each team member. In other words, decide on what deliverables are expected from this step – typically, the output of this step is to identify the test scenarios. Test scenarios are nothing but one line pointers of ‘what to test’ for a certain functionality.

Step #3: Also establish guidelines on how this deliverable is to be presented- I mean, the template.

Step #4: Decide on whether each member of the team is going to work on the entire document or divide it among themselves. It is highly recommended that everyone reads everything because that will prevent knowledge concentration with certain team members. But in case of a huge project, with the SRS documents running close to 1000 pages, the approach of breaking up the document module wise and assigning to individual team members is most practical.

Step #5: SRS review also helps in better understanding if there are any specific prerequisites required for the testing of the software.

Step #6: As a byproduct, a list of queries where some functionality is difficult to understand or if more information needs to be incorporated into functional requirements or if mistakes are made in SRS they are identified.

What do we need to get started?

The correct version of the SRS document
Clear instructions on who is going to work on what and how much time have they got.
A template to create test scenarios
Other information on- who to contact in case of a question or who to report in case of a documentation inconsistency
Who would provide this information?

Team leads are generally responsible for providing all the items listed in the section above. However, team members’ inputs are always important for the success of this entire endeavor.

Team leads often ask- What kind of inputs? Wouldn’t it be better to assign a certain module to someone interested in it than to a team member who is not? Wouldn’t it be nice to decide on the target date based on the team’s opinion than thrust a decision on them? Also, for the success of a project, templates are important. As a general rule, templates have a higher rate of efficiency when they are tailored to the specific team’s convenience and comfort.

It should therefore be noted that, team leads more than anything are team members. Getting your team onboard on the day-to-day decisions is crucial for the smooth running of the project.

Why a template for test scenarios – isn’t it enough if we just make a list?

It sure is. However, software projects are not ‘one-man’ shows. They involve team work. Imagine in a team of 4- if each one of them decide to review one module of the software requirements specification each. Team member A has made a list on a sheet of paper. Team member 2 used an excel sheet. Team member 3 used a notepad. Team member 4 used a word doc. How do we consolidate all the work done for the project at the end of the day?

Also, how can we decide which one is the standard and how can we say what is right and what’s not if we did not create the rules to begin with?

That is what template is- A set of guidelines and an agreed format for uniformity and concurrence for the entire team.

How to create a template for QA Test scenarios?

Templates don’t have to be complicated or inflexible.

All they need to be are an efficient mechanism to create a useful testing artifact. Something simple like the one we see below:

test scenarios template

The header of this template contains the space required to capture basic information about the project, the current document and the reference document.

The table below will let us create the test scenarios. The columns included are:

Column #1: Test scenario ID
Every entity in our testing process has to be uniquely identifiable. So, every test scenario has to be assigned an ID. The rules to follow while assigning this ID have to be defined. For the sake of this article we are going to follow the naming convention as: TS(prefix that stands for Test Scenario) followed by ‘_’ , module name MI(my Info module of the Orange HRM project) followed by ‘_’ and then the sub section (eg: MIM for My info module, P for photograph and so on)followed by a serial number. An example would be: “TS_MI_MIM_01”.

Column #2: Requirement
It helps that when we create a test scenario we should be able to map it back to the section of the SRS document where we picked it from. If the requirements have IDs we could use that. If not section numbers or even page numbers of the SRS document from where we identified a testable requirement will do.

Column #3: Test scenario description
A one liner specifying ‘what to test’. We would also refer to it as test objective.

Column #4: Importance
This is to give an idea about how important certain functionality is for the AUT. Values like high, medium and low can be assigned to this field. You could also choose a point system, like 1-5, 5 being most important, 1 being less important. Whatever the value this field can take, it has to be pre-decided.

------------

Column #5: No. of Test cases
A rough estimate on how many individual test cases we might end up writing that one test scenario. For example: To test the login- we include these situations: Correct username and password. Correct username and wrong password. Correct password and wrong username. So, validating the login functionality will result in 3 test cases.

Note: You can expand this template or remove the fields as you see fit.

For example, you can add “Reviewed by” in the header or remove the date of creation etc. Also in the table, you can include a field “Created by” to designate the tester responsible for a certain test scenarios or remove the “No. of Test cases” column. The choice is yours. Go with what works best for the entire team.

Let us now review our Orange HRM SRS Document and create the test scenarios

Tip: check out the table of contents in this SRS Document example to get a good idea on how any document is going to flow and how much of work it might involve.

Section 1 is the purpose of the document. No testable requirements there.

Section 2.1 – Project Overview- Audience- no testable requirements there either.

Section 2.2- Hardware and hosting- This section is talking about how the Orange HRM site is going to be hosted. Now, is this information important to us testers? The answer is Yes and No. Yes, because when we test we need to have an environment that is similar to the real time environment. This gives us an idea on how it needs to be. No because, it is not a testable requirement- a kind of prerequisite for the testing to happen.

Section 3: There is a login screen here and the details of the type of account we need to have to enter the site. This is a testable requirement. So it needs to be a part of our Test scenarios.

Please see the test scenarios document where test scenarios for a few sections of the SRS have been added. For practice, please add the rest of the scenarios in a similar manner. However, I am going right to section 4 of the document.

Section 4: Aesthetic/HTML Requirements and Guidelines- This section best explains how some requirements might not make sense to the test team at the time of SRS review, but the team should make a note of them as testable requirements all the same. How to test them and if we need specific set up/any team’s help to validate it are details we might not know at this point of time. But making them a part of our testing scope is the first step to ensure that we do not miss them.

Sample Test Scenarios for OrangeHRM Application: (click to enlarge image)

test scenarios template

=> Please refer and download the test scenarios document for more information.

Some important observations regarding SRS review:

#1. No information is to be left uncovered.
#2. Perform a feasibility analysis on whether a certain requirement is correct or not and also if it can be tested or not.
#3. Unless a separate performance/security or any other form of test teams exists- it is our job to make sure that all nonfunctional requirements have to be taken into consideration.
#4. Not all information is targeted at the testers, so it is important to understand what to note and what not.
#5. The importance and no. of test cases for a test scenario need not be accurate and can be filled in with an approximate value or can be left empty.

To sum up, SRS review results in:

Test scenarios list
Review results – documentation/requirement errors found by statically going through/verifying the SRS document
A list of Questions for better understanding- in case of any
Preliminary idea of how the test environment is supposed to be like
Test scope identification and a rough idea on how many test cases we might end up having- so how much time we need for documentation and eventually execution.
Important points to note:

#1. Test scenarios are not external deliverables (not shared with Business Analysts or Dev teams) but are important for internal QA consumption. They are our first step towards 100% test coverage goal. Test scenarios once complete undergo a peer review and once that is done, they are all consolidated. For more details on how QA documents are reviewed, check out the article: How to Perform Test Documentation Reviews in 6 Simple Steps.

#2. We could use a test management tool like HP ALM or qTest to create the test scenarios. However, the Test scenarios creation in real time is a manual activity. In my opinion, it is more convenient manually. Since it is step 1 we do not need to bring out the big guns yet. Simple excel sheets are the best way to go about it.

Top 10 Negative Test Cases

Negative test cases are designed to test the software in ways it was not intended to be used, and should be a part of your testing effort. Below are the top 10 negative test cases you should consider when designing your test effort.

Top 10 Negative Test Cases ______________________________

1. Embedded Single Quote - Most SQL based database systems have issues when users store information that contain a single quote (e.g. John's car). For each screen that accepts alphanumeric data entry, try entering text that contains one or more single quotes. 

2. Required Data Entry - Your functional specification should clearly indicate fields that require data entry on screens. Test each field on the screen that has been indicated as being required to ensure it forces you to enter data in the field. 

3. Field Type Test - Your functional specification should clearly indicate fields that require specific data entry requirements (date fields, numeric fields, phone numbers, zip codes, etc). Test each field on the screen that has been indicated as having special types to ensure it forces you to enter data in the correct format based on the field type (numeric fields should not allow alphabetic or special characters, date fields should require a valid date, etc)

4. Field Size Test - Your functional specification should clearly indicate the number of characters you can enter into a field (for example, the first name must be 50 or less characters). Write test cases to ensure that you can only enter the specified number of characters. Preventing the user from entering more characters than is allowed is more elegant than giving an error message after they have already entered too many characters. 

5. Numeric Bounds Test - For numeric fields, it is important to test for lower and upper bounds. For example, if you are calculating interest charged to an account, you would never have a negative interest amount applied to an account that earns interest, therefore, you should try testing it with a negative number. Likewise, if your functional specification requires that a field be in a specific range (e.g. from 10 to 50), you should try entering 9 or 51, it should fail with a graceful message. 

6. Numeric Limits Test - Most database systems and programming languages allow numeric items to be identified as integers or long integers. Normally, an integer has a range of -32,767 to 32,767 and long integers can range from -2,147,483,648 to 2,147,483,647. For numeric data entry that do not have specified bounds limits, work with these limits to ensure that it does not get an numeric overflow error. 

7. Date Bounds Test - For date fields, it is important to test for lower and upper bounds. For example, if you are checking a birth date field, it is probably a good bet that the person's birth date is no older than 150 years ago. Likewise, their birth date should not be a date in the future. 

8. Date Validity - For date fields, it is important to ensure that invalid dates are not allowed (04/31/2007 is an invalid date). Your test cases should also check for leap years (every 4th and 400th year is a leap year). 

9. Web Session Testing - Many web applications rely on the browser session to keep track of the person logged in, settings for the application, etc. Most screens in a web application are not designed to be launched without first logging in. Create test cases to launch web pages within the application without first logging in. The web application should ensure it has a valid logged in session before rendering pages within the application. 

10. Performance Changes - As you release new versions of your product, you should have a set of performance tests that you run that identify the speed of your screens (screens that list information, screens that add/update/delete data, etc). Your test suite should include test cases that compare the prior release performance statistics to the current release. This can aid in identifying potential performance problems that will be manifested with code changes to the current release.

Globalization

Use Case Examples

Your use cases are only as good as the use someone's getting from them. What looks good to you may not be readable to your developers. The success measurement for an effective written use case is one that is easily understood, and ultimately the developers can build the right product the first time.

A great way for writing effective use cases is to walk through a simple use case example and watch how it can be leveraged to something complex. By absorbing the meaning of use case diagrams, alternate flows and basic flows, you will be able to apply use cases to your projects. In some of the tips below, we'll use eBay features for example use cases.

Tip 1. Be productive without perfection

Be agile, be lean, don't be afraid to make mistakes. Often so many new product managers think being perfect will impress their audience, but having strongly written use cases with a few mistakes is FAR better than an over complicated detailed list that confuses and bores an audience. 

When it comes to writing effective use cases, you don't need to be a perfectionist and concern yourself with getting it right the first time. Developing use cases should be looked at as an iterative process where you work and refine. You can always refine it later, so again, don't go for perfection from the get-go. Loosen up and have some fun while you're doing it. Remember, humans are reading your use cases, not a bunch of robots, so keep it interesting. 

Tip 2. Get a good working list of your use case actors

What is an actor? (no not Brad Pitt in this context) Any "object" or person that has behavior associated with it. Generally, the users are actors but often systems can be actors as well. 

There are possibly over a dozen actors that interact with Ebay, from buyers and sellers, down to suppliers, wholesalers, auditors, and customer service. But we're going for grass-roots, so who are the basic users of Ebay? BUYERS and SELLERS. So lets put them down as our first actors. (The visual notation in the figures below is based on UML -- Unified Markup Language for Use Cases) 

 

Do you notice how the actors aren't John and Sue which would be people? While John may be a seller and Sue may be a buyer, an actor is a Role. And a role in this case would be that of a buyer and that of a seller. Now that things are clicking, lets throw some more actors on your paper just so we can try and identify more possible users.

 

Now we have a bunch of actors. Wait a minute? Paypal? That's not a person. An actor can be a system, because a system plays another role in the context of your new system and has goals and interacts with other actors as you will see later. 

Tip 3. Define your Sunny Day Use Cases For those of you who haven't heard the expression, "Sunny Day" use cases, it is in reference to the use cases that are most likely going to occur when all goes well. These are somtimes referred to as your primary use cases. You always want to focus on the sunny day scenarios first because you can then pivot off these and figure out your "rainy day" scenarios (or edge cases) later.  Use the 80/20 rule -- if you write an exhaustive list of all possible use cases, typically 20% of the use cases will account for 80% of the activity. The other 80% of the use cases would support 20% of the activity. In my experience in various offices, the perfectionists will say, "well what about this? isn't that possible?" referring to an edge case. The product manager should be able to discern a common use case from the edge case and prioritize accordingly. So, once you are done with your sunny-day use cases, distribute it among your project team and get consensus that you have covered them all.  Now Collect your Rainy Day Use Cases After you have a well-defined list of your primary use cases, you'll want to collect the list of edge cases (rainy-day) and with the help of the product manager or stake-holder, prioritize them in terms of likelyness. It should be a business question as far as how much software development costs do you want to spend on something that is not likely to happen.

Tip 4. Identify reuse opportunity for use cases

In this step, you are going to cross the bridge into object modeling. Don't get overly concerned about terms like generalization, inheritance and extends. The goal of this Ebay use case example is to keep it understandable so we will explain this concept in terms of the example. 

What does the word general mean? Something is broad and not as detailed. Generalization is when you "inherit" from something general and then add more detail. A "person" is very general. A "man" is still general, but not as general as a "person". You can say that a "man" inherits behavior and atributes of a "person". 

Look at the requirements management use case diagram above and you will see there is duplicate behavior in both the buyer and seller which includes "create an account" and "search listings". Rather than have all of this duplication, we will have a more general user that has this behavior and then the actors will "inherit" this behavior from the new user. 

 

The above use case example diagram illustrates that a generic user creates accounts and search listings and that a buyer and a seller have their own behavior but also have the behavior of the generic user. The benefits of generalization are that you eliminate duplicate behavior and attributes that will ultimately make the system more understandable and flexible. We will see in later steps that this inheritance applies both to use cases and to the actors.

Tip 5. Create a use case index

After producing your initial visual list of use case actors and goals, we can take this list and create an initial use case grid which provides the basis for the use case index. Every use case will have various attributes relating both to the use case iteself and to the project. At the project level, these attributes include scope, complexity, status and priority. 

 

This use case index should be used by the project team to define the use cases against. It will serve as a master inventory to help writ effective use cases for the requirements phase of the project. 

Tip 6. Identify the key components of your use case

The actual use case is a textual representation illustrating a sequence of events. In our use case example, you will see that there are several components of a use case which we will review. In the mean time, review the table below to get a basic understanding of what is in the use case and then we will review each element as we progeress through our use case example.

Use Case Element	Description
Use Case Number	ID to represent your use case
Application	What system or application does this pertain to
Use Case Name	The name of your use case, keep it short and sweet
Use Case Description	Elaborate more on the name, in paragraph form.
Primary Actor	Who is the main actor that this use case represents
Precondition	What preconditions must be met before this use case can start
Trigger	What event triggers this use case
Basic Flow	The basic flow should be the events of the use case when everything is perfect; there are no errors, no exceptions. This is the "happy day scenario". The exceptions will be handled in the "Alternate Flows" section.
Alternate Flows	The most significant alternatives and exceptions

Tip 7. Name and briefly describe your use case

Now that you have a general understanding of what a use case consists of, we are ready to start creating our use case. Typically, while the name of your use case is being discussed, people will start briefly describing the use case. Use plain english and keep it simple. Getting back to our use case example, I will begin with use case #1 from step number four. 

Use Case Number:	1
Use Case Name:	Buyer Places a Bid
Description:	An EBAY buyer has identified an item they wish to buy, so they will place a bid for an item with the intent of winning the auction and paying for the item.

Tip 8. Create the use case basic flow

The basic flow of a use case represents the most important course of events or what happens most of the time, sometimes referred to as the 'Happy Day Scenario' because it is what occurs when everything goes well -- no errors or exceptions. Another reason why the basic flow is so critical is because it's much easier to fully comprehend the exceptions once the norm is understood and if the basic flow represents 70% of the system, the development staff is much more prone to implementing the correct code in the first pass.

For our use case example, the basic flow should be to describe the happy day scenario for your use cases such as "placing a bid". For a consumer to play a successful bid, what is the primary flow when everything goes as planned. An effective use cases needs to have the basic flow before moving forward with writing the alternate flows. 

Tip 9. Create the use case alternate flows

The basic flow is the key ingredient to your use case and some can argue that you can stop once you're done with the basic flow. It really depends on the level of detail you wish to achieve. However, providing more detail to the consumers of your use case is always a good thing. 

The alternate flows providing the following:

·         An exception or error flow to any line item in your basic flow

·         An additional flow, not necessarily error based, but a flow that COULD happen

A few examples of alternate flows are:

·         While a customer places an order, their credit card failed

·         While a customer places an order, their user session times out

·         While a customer uses an ATM machine, the machine runs out of receipts and needs to warn the customer

Tip 10. Produce your effective use case document

Recently at a new project assignment, I introduced a mid level developer to the concept of use cases which was totally foreign to him. Once walking him through the basic concepts and showing him the use case example, the lightbulb went off in his head on how convenient and simple it was to grasp the project.

A few reasons why it's that much easier to learn a system through use cases then a traditional requirements document is probably because with use cases, you are introduced to concepts at a high level, walk through a living scenario and then presented with specifications last. 

In several places in this document, I have stated "effective use cases" rather than just "use cases". The purpose of the use cases is for effective knowledge transfer from the domain expert to the software developer -- these use cases will serve as software requirements. If they don't make sense to the person building the software, they are not effective. There are several sources on the web for writing effective use cases including the book by Alistair Cockburn.

Tip 11. Generate a Use Case Model Diagram

You can use the Gatherspace.com use case modeling tool to produce a use case model within a few clicks. Once you define your use cases and actors, just go into the reporting section and click on the 'Use Case Model' report and that's it. From the main use case model, you can continue to drill down into the use cases.

To see what this looks like, click the use case model sample now. 

In several places in this document, I have stated "effective use cases" rather than just "use cases". The purpose of the use cases is for effective knowledge transfer from the domain expert to the software developer -- these use cases will serve as software requirements. If they don't make sense to the person building the software, they are not effective. There are several sources on the web for writing effective use cases including the book by Alistair Cockburn.

Tip 12. What's the difference between a User Story and a Use Case?

With so many engineering teams making the paradigm shift from waterfall to Agile Software Development, people often get caught up in having a pure Agile process which would include the use of User Stories. So what's all of the hoopla with User Stories? What are they, how are they different from use cases, do I need them, and where do they fit in the process? 

·         What is a User Story? Simply put, written from the context of the user as a simple statement about their feature need. They should generally have this format. "As a -role-, I want -goal/desire- so that -benefit-"

·         How is a User Story different than a Use Case? While a use case is highly structured and tells a story, the User Story sets the stage by stating the need. A User Story is the prelude to the use case by stating the need before the use case tells the story.

·         How does the User Story fit into the process? User Stories are great as an activity in collecting and prioritizing the high level features. Getting this initial feedback from the customer is a simple way of trying to get all of their needs identified and prioritized. The User Stories will then morph themselves into the business requirements and use cases.

Tip 13. In Agile Development, Keep Use Cases Agile, Mean and Lean

A common myth with Agile Development is that you *must* use user stories, and not use cases. Like anything else in life, nothing is black and white -- being Agile is really about smaller iterations, learning and adapting to the market.

If you are using Agile, Scrum and moving away from waterfall, what you want to do is make sure to iterate with your use cases. All that means is that your flows will be smaller and less feature rich. While the theme of the use case may appear the same from iteration to iteration, what is changing is the level of detail and the features inside the particular sprint. 

Creating a use case to long winded with too many features can potentially put a product at risk. What happens is that you can extend your release to market from two weeks to several months without the ability to learn from the iteration and adapt to the market. Keep those use cases learner! 

Defect Age

Defect Age can be measured in terms of any of the following:

• Time
• Phases

DEFECT AGE (IN TIME)

Definition

Defect Age (in Time) is the difference in time between the date a defect is detected and the current date (if the defect is still open) or the date the defect was fixed (if the defect is already fixed).

Elaboration

• The ‘defects’ are confirmed and assigned (not just reported).
• Dropped defects are not counted.
• The difference in time can be calculated in hours or in days.
• ‘fixed’ means that the defect is verified and closed; not just ‘completed’ by the developer.

Defect Age Formula

Defect Age in Time = Defect Fix Date (OR Current Date) – Defect Detection Date

Normally, average age of all defects is calculated.

Example

If a defect was detected on 01/01/2009 10:00:00 AM and closed on 01/04/2009 12:00:00 PM, the Defect Age is 74 hours.Uses

• For determining the responsiveness of the development/testing team. Lesser the age better the responsiveness.

DEFECT AGE (IN PHASES)

Definition

Defect Age (in Phases) is the difference in phases between the defect injection phase and the defect detection phase.

Elaboration

• ‘defect injection phase’ is the phase in the software life cycle where the defect was introduced.
• ‘defect detection phase’ is the phase in the software life cycle where the defect was identified.

Defect Age Formula

Defect Age in Phase = Defect Detection Phase – Defect Injection Phase

Normally, average of all defects is calculated.

Example

Let’s say the software life cycle has the following phases:

1. Requirements Development
2. High-Level Design
3. Detail Design
4. Coding
5. Unit Testing
6. Integration Testing
7. System Testing
8. Acceptance Testing

If a defect is identified in System Testing and the defect was introduced in Requirements Development, the Defect Age is 6.

Uses

• For assessing the effectiveness of each phase and any review/testing activities. Lesser the age better the effectiveness.