Sample BRS Document

Sample BRS Document

Business Requirements Specification
Contents

1)     The purpose of the project

2)     The Client, the Customer, and other stakeholders

3)     Users of the product

4)     The scope of the work

5)     The scope of the product

6)     Features and Functionalities

7)     Usability and Humanity Requirements

8)     Performance Requirements

1).  The purpose of the Project

a) Background of the Project Effort

IBEE Solution (P) Ltd has planed to develop an eCommerce (Business to Customer) Portal as a product.

In those days Business Promotions and Business Transactions are done through various Channels like Retail, Whole sale etc. After Internet inception the eCommerce (buying and selling Products/services over the Internet) Concept came into the picture.

Now Days eCommerce is a part of every Industry's Business, if it is a Product based or Service based this channel is very useful.

Ecommerce can be broken into four main categories: B2B, B2C, C2B, and C2C.

v      B2B (Business-to-Business)
Companies doing business with each other such as manufacturers selling to distributors and wholesalers selling to retailers. Pricing is based on quantity of order and is often negotiable.

v      B2C (Business-to-Consumer)
Businesses selling to the general public typically through catalogs utilizing shopping cart software.

Business to consumer sites is generally database-driven e-commerce sites where products are displayed in an online catalog and are stored in a database. Typically, hot new products are pulled from the database and displayed on the homepage daily. The buyer can add items from the database to the shopping cart and prices held in the database will be totaled. The site administrator can easily change product and price information.

v      C2B (Consumer-to-Business)
A consumer posts his project with a set budget online and within hours companies review the consumer's requirements and bid on the project. The consumer reviews the bids and selects the company that will complete the project. Enlace empowers consumers around the world by providing the meeting ground and platform for such transactions.

v      C2C (Consumer-to-Consumer)
There are many sites offering free classifieds, auctions, and forums where individuals can buy and sell thanks to online payment systems like PayPal where people can send and receive money online with ease. eBay's auction service is a great example of where person-to-person transactions take place everyday.

In above areas IBEE Solution (P) Ltd has Chosen B2C category to develop a Product, As 'Business to Customer' area having more potentiality.

b) Goals of the Project

'IBEE Solutions' wants to give 'Online Products/Services Buying and Selling Solution' for various organizations like production oriented Industries, Services based Companies and Distributors through this Project.

It (IBEE) wants to give a complete solution for Products/Services Buying & Selling through Internet.

Through this Solution Industries/Distributors Can Display and sell their products/Services. Customer Can See and Buy the Products/Services. It also Provides Payment Process, Shipping Process and Enquires.

2).   The Client, the Customer, and other stakeholders

2a the Client

*(This item gives the name of the client. It is permissible to have several names.)*

It is an In-house development of IBEE Solutions. IBEE has planed to develop this Product as per current Market trends.

2b the Customer

*(The person intended to buy the product. In the case of in-house development, the client and the customer are often the same person)

As it was a Product, initially it hasn't had any customers but 'IBEE solutions' is planning to get offers from some Organizations.

2c the Stakeholders

*(The roles and (if possible) names of other people and organizations who are affected by the product, or whose input is needed to build the product.)

§         Sponsor                  :IBEE Solutions        

§         Testers                   :NRSTT (P) Limited

§         Business analysts      :Vijay Sarma and Ram Manohar

• Technology experts   :James & Suzanne Robertson

§         System Analysts       :Prasanna Yadav & Durga Prasad

§         Marketing experts     :Venkata Murthy & Kareemulla Shaik

§         Legal experts           : Vihar Consultants

§         Domain experts         : Atlantic Systems (P) Ltd

§         Usability experts       : Skyline Technologies        

§         Representatives of external associations

3) Users of the Product

*(A list of a special type of stakeholders-the potential users of the product.)

Administrator:

Admin responsible for Users Management, Product Definition, adding & modifying products and Services Management.

Registered Users: 

Registered Users can view the Catalog and get the information and also can Buy Products. As per availability they can use Payment options to make payments.

They can enquire about their Status (Orders) and Cancel their Orders as per norms.

Guest Users:

Guest Users can access the Portal and view the Catalog and get the information.

Guest Users can become Registered Users by submitting (filling registration form) their details through online for free of Cost.

Business Users:

Business users can interact with this application with their applications as per permissions and they can track permitted information.

[Motivation

Users are human beings who interface with the product in some way. Use the characteristics of the users to define the usability requirements for the product. Users are also known as actors.

Examples

Users can come from wide variety of (sometimes unexpected) sources. Consider the possibility of your users being clerical staff, shop workers, managers, highly trained operators, the general public, casual users, passers-by, illiterate people, tradesmen, students, test engineers, foreigners, children, lawyers, remote users, and people using the system over the telephone or an Internet connection, emergency workers, and so on. ]

 

4).  The scope of the work

Ecommerce

Ecommerce simply means selling over the Internet — goods, services, information, whatever. Such businesses began in 1995 and are expected by 2008 to generate sales in the USA alone of $ 109 billion.

How do we get our share of the action?

§         Creating a website that promotes products

§         Obtain an Internet address

§         Hiring space on a web-hosting company

§         Uploading pages

§         Adding a payment system, and then

§         Using  various promotion services to get the site noticed

Electronic Commerce or e-commerce is the trade of products and services by means of the Internet or other computer networks. E-commerce follows the same basic principles as traditional commerce that is, buyers and sellers come together to swap commodities for money. But rather than conducting business in the traditional way in shopping stores or through mail order catalogs and telephone operators — in e-commerce buyers and sellers transact business over networked computers.
E-commerce offers buyers maximum convenience. They can visit the web sites of multiple vendors round the clock a day to compare prices and make purchases, without having to leave their homes or offices from around the globe. In some cases, consumers can immediately obtain a product or service, such as an electronic book, a music file, or computer software, by downloading it over the Internet.
For sellers, e-commerce offers a way to cut costs and expand their markets. They do not need to build, staff, or maintain a physical store or print and distribute mail order catalogs. Automated order tracking and billing systems cut additional labor costs, and if the product or service can be downloaded then e-commerce firms have no distribution costs involved. Because the products can be sold sell over the global Internet, sellers have the potential to market their products or services globally and are not limited by the physical location of a store. Internet technologies also permit sellers to track the interests and preferences of their customers with the customer's permission and then use this information to build an ongoing relationship with the customer by customizing products and services to meet the customer's needs.
E-commerce however has some drawbacks. Consumers are hesitant to buy some products online. Online furniture businesses, for example, have failed for the most part because customers want to test the comfort of an expensive item such as a sofa before they purchase it. Many people also consider shopping a social experience. For instance, they may enjoy going to a store or a shopping mall with friends or family, an experience that they cannot duplicate online. Consumers also need to be reassured that credit card transactions are secure and that their privacy is respected.
In the existence of these few disadvantages e-commerce has opened new horizons to versatile the modern age. It puts away time, energies, labor and money.

5) The scope of the Product

Already so many ecommerce portal products available in the market, to attract more customers 'IBEE Solutions' has to plan this product with more features and facilities.

It should have following features:

 This is one of the most basic options that help establish a framework of an Online Shopping With a simple shopping cart, catalog creation facility, a custom storefront appearance and online payment facilities it helps Online Shopping take off to efficient sales online.

A product catalog that allows portal owners to create a catalog of all the products that they want to sell and display online.

A shopping cart that allows customers to select the products of their choice and check them out at the online counter.

A search facility to search for products

Customer accounts: Personalized areas where members can login, register, add and delete and edit product information or any other relevant information. A web master would be in control and edit the information before publishing the information.

An online payment facility that will help users pay online in a secure manner. Payment Options compatible with leading payment gateways (enter just merchant account details) to process payments online; Secure online credit cards/e-checks payments through SSL protocol and encryption of sensitive data.

Currency: This feature will help to organize multiple currencies as per design and modify the exchange rates.

Shipping:
This feature will help Portal owners to integrate shipping/courier options with leading shipping service providers.

Inventory online

For a store with more than 1000-10000+ product and facility to stock products be it retail or wholesale.

6)  Features and Functionalities

Businesses to consumer portals are generally database-driven e-commerce sites where products are displayed in an online catalog and are stored in a database. Typically, hot new products are pulled from the database and displayed on the homepage daily. The buyer can add items from the database to the shopping cart and prices held in the database will be totaled. The site administrator can easily change product and price information.

The E-commerce Portal Preferable Features are:

customer (Buyer) side:

• Product catalog based on Manufactures
• Product catalog based on Categories
• Product Search facility
• Advanced Product Search facility
• Reviews on Products & their ratings
• Products Comparison
• Product of the Month
• Hot Products
• Products on Sale
• User Account creation
• Shopping cart status

§         Selection of multiple attributes against each product (ex: size, color etc)

Customer Business operations:

• Customer can create an account online for free of cost.
• Customer address books (other shipping destinations)
• Order history
• Temporary (not logged on) and permanent (logged on) shopping carts
• Search catalog for products or manufacturers or price range
• Product reviews by customers
• E-mail notifications
• Number of products in each category are shown

Buyer Business Operations

• Add/Edit/Remove categories, products, manufacturers, customers, and reviews
• Categories-to-categories structure
• Statistics for products and customers
• Dynamic product attributes
• Tax zones, classes, and rates
• Attributes
• Managing Orders

List of Other Features/Functionalities:

Inventory management, catalog & import/export:

• Packing slips (fax/email delivery) for each order
• Bulk updates (amount/percentage) of products inventory
• Inventory update (CSV spreadsheet file)
• Option to disable sales of unavailable/out-of-stock
• Products reports (new arrivals, RMA, on order, in stock & backordered)
• Batch printing of mailing labels & returns forms
• Catalog with unlimited products and categories
• Common product structure/definition
• Ability to sell hard goods and electronic products
• Web-based file/image manager to upload files online
• Ability to set min/max quantity per order
• Unlimited attributes: images, options, files, and features
• Product reviews and custom (user defined) fields
• Different price implication for combination of options
• Easy-to-use wizard to import products/customers (CSV file
• Export customers, products & invoices into QuickBooks

Shopping cart, customer account & order processing:

• Cart (sales coupon, gift note and saving for later purchase)
• Account (orders, subscriptions, payments history)
• Automatic sales receipts (#, billing/shipping info & taxes)
• Invoices with payment type/delivery, discounts, etc
• Merchant sales follow-up notifications
• Ability to track orders status online
• Ability to review of outstanding/completed orders
• Sales receipts to customers & merchant
• Email alerts when new orders are submitted

Payment & shipping options:

• Pre-integration with leading payment processors
• Secure online credit cards/e-checks payments
• Payments by check, credit/debit card, money order, COD
• Ability to process credit cards online
• Creation a new credit card entry with custom fields
• Multi-currency support (settlement into basic currency)
• Dynamic shipping calculation (flat, linear/table) within regions
• National/global shipping options
• Optional pre-integration with leading real-time shipping carriers (UPS, USPS, FedEx)

Custom storefront appearance:

§         Custom storefront appearance: add logo, header/footer, etc

§         Variety of pre-integrated pages

§         Ability to create new custom pages

§         Full customization of presentation layer

§         Any regional language (UNICODE support)

System settings & services:

§         Settings (general, currency, language, etc)

§         Workability with the back office on the Internet

§         Web services interface to manipulate all data queries

§         Fully scalable package to add any new rules

§         Full 1 year subscription to upgrades/updates

Sales management & promotions:

§         Sales journal (order & refund documents) and secure download option

§         Ability to accept payments online (secure transactions

§         Tracking of orders received: Web, phone, fax, mail, and email

§         Catalog sales with ability to create customer's account

§         Advanced search by documents, customers, suppliers & products

§         Intelligent search by time period (day, week, month) and transactions

§         Printing/emailing of invoices and packing slips in bulk/per-order

§         Management reports: sales revenues, taxes, profits & payments

§         Price lists for customers and membership

§         Free shipping based on amount, weight and quantity

§         Coupons (products range, departments/categories), rebates & vouchers

§         Bulk mailing campaigns to email newsletters, special offers, etc

7).  Usability and Humanity Requirements

As it is an Internet application intended users are Unlimited and Users have no limitations for accessing the application through Internet. As our Intended Customers are from different areas and untrained, so our site must have easy navigations, attractive colors and Understandable Screens.

Our application should have multiple ways to perform any Operation and for completing any task less number of navigations preferable.

The application requires easy search capability to find what ever user wants and we have to provide facility for Customers feedback.

8). Performance Requirements

The very nature of the web and the fact that different users interact differently with the application greatly effect performance. Several aspects that can affect performance including high activity and volume at launch, activity spikes due to marketing promotions, download time, Usage patterns, user arrival rates and Internet access speeds.

We can't restrict users; our application has to support Different types of environments, networks and Internet services.

Open source QA tool for automated Web application testing

Q- Could you recommend a quality assurance (QA) tool for automated regression/functional testing (open source or free tools are preferred) for testing a Web application that contains a lot of JavaScript for opening pop-up windows, redirects, etc.? I'm using HTTPUnit and Selenium but these tools are not handling pop-up windows and redirects well. Thanks

A- My preferred automation solution for Web applications is a combination of *Unit and Wati* -- for instance, JUnit plus Watij. I like Watij over Selenium RC simply because it seems a little more object-oriented than Selenium. But this is totally personal, I've used both tools successfully.

Handling pop-ups and other interactive display changes can be a challenge, regardless of the tool. You might consider a couple of approaches. First, be active in the tool's user group, seeking solutions. There are several groups available on the Internet -- just pick one or two. Be polite: post your question once, rather than blasting across multiple groups. If you post to the Selenium user's group, you will definitely encounter other testers who have faced similar challenges in the past -- they'll probably have tried-and-true solutions for you. Secondly, pay close attention to your implementation. If your Web app uses a lot of rich Internet applications (RIAs), your might get away with the use of divs rather than handling each window (in RIA, developers can "pop up" windows which are, in fact, just hidden divs being exposed). Experiment with different programming solutions and see which is more reliable. There is generally more than one way to accomplish what you're trying to do. You're looking for the way which is 1) feasible, 2) most reliable and 3) most performant (in that order).

The third approach may be the most challenging and, in the short term, costly. However, if you're working on an ongoing, long-term project it will have payoff. If the current implementation is not very testable, propose alternative implementations to the development team. For instance, if the current project creates multiple pop-up windows (rather than using Ajax to expose elements), ask that the team take time to change this, implementing a solution which you can test more reliably and in a shorter amount of time. You need to be very, very detailed in your reasoning -- you will need to include schedule and cost savings. Point to gains down the road when your automated regression and functional tests run more reliably. By implementing testability, you will be addressing what Agile teams call "technical debt." You take a short-term hit on schedule, with the outcome being a long-term improvement in effectiveness and efficiency.

Will penetration testing be replaced by preventative tools?

by michaeldkelly

I recently read the article "Penetration Testing: Dead in 2009" by Bill Brenner. In the article Mr. Brenner follows a small debate around the idea that over time penetration testing will be largely replaced by preventative checks.

The debate opens with some quotes from Brian Chess from Fortify Software. Fortify creates code analysis tools that scan for security concerns and adherence to good secure coding practices. That potential bias aside, I suspect that Mr. Chess' statement — that "Customers are clamoring more for preventative tools than tools that simply find the weaknesses that already exist [...]. They want to prevent holes from opening in the first place" — is absolutely true. I know I clamor for those tools, and I'm just a lowly test manager.

I'm a big fan of the work companies like Fortify, IBM and HP are doing in this space. If my project team can find a potential issue before we deploy the code, I'm all for it. It can save us time and helps us focus on different and potentially higher-value risks. However, I've yet to see a tool that can deal with the complexity of a deployment environment (setup, configuration, code, etc…) and while I'm a big believer in doing everything you can up front (design, review, runtime-analysis, etc.), I believe there will always be a roll for a skilled manual investigation of what gets deployed.

Testing (penetration or other) is about applying skill and judgment to uncover quality-related information about the product. That's not just code — it's more than that. Your typical penetration tester today covers more than today's automated tools can cover. While there are different tools to test various components (some that focus on code, some that focus on the network, etc.), and they should absolutely be used, those tools will never be able to uncover all the potential issues with a system. And, what's sometimes worse, is they can lead to a false sense of security.

 

Two-minute guide to determining software testing coverage

By Michael Kelly

Deciding what to test really involves two different questions. The first is a question of scope: "Out of everything that I could possibly test, which features are the right ones to test?" There will always be more to test than you will have time to test. The second is a question of technique and coverage: "For each feature I am testing, how do I want to test that feature?" Different quality criteria will lead to covering different product elements and different testing techniques.

In this two-minute crash course, I'll provide some details on how I answer those questions and how I structure my test execution to ensure I'm testing for the right risks at the right time.

2:00: Figure out the scope of your testing
For the question about scope -- what features should we test -- I like using Scott Barber's FIBLOTS mnemonic (which he presents in his Performance Testing Software Systems class). Each letter of the mnemonic helps us think about a different aspect of risk. Here's a summary of how I apply FIBLOTS when thinking about scope:

• Frequent: What features are most frequently used (e.g., features the user interacts with, background processes, etc.)?
• Intensive: What features are the most intensive (searches, features operating with large sets of data, features with intensive GUI interactions)?
• Business-critical: What features support processes that need to work (month-end processing, creation of new accounts)?
• Legal: What features support processes that are required to work by contract?
• Obvious: What features support processes that will earn us bad press if they don't work?
• Technically risky: What features are supported by or interact with technically risky aspects of the system (new or old technologies, places where we've seen failures before, etc.)?
• Stakeholder-mandated: What have we been asked/told to make sure we test?

1:33: Understand the details of each feature you're testing
Once I understand what it is I want to test, I move on to understanding what aspects of each feature I'd like to cover. For that, I pull out the Satisfice Heuristic Test Strategy Model. I use the product elements list in that document to determine what aspects of the feature I need to focus on. At a high level, I think of coverage in terms of:

• Structure: This is everything that comprises the physical product or the specific feature I'm looking at (code, hardware, etc.).
• Functions: Everything that the product or feature does (user interface, calculations, error handling, etc.).
• Data: Everything that the product or feature processes (input, output, lifecycle).
• Platform: Everything on which the product or feature depends (and that is outside your project).
• Operations: How the product or feature will be used (common use, disfavored use, extreme use, etc.).
• Time: Any relationship between the product and time (concurrency, race conditions, etc.).

1:03: Structure your work in a way that makes sense to you
I typically start by structuring my work in lists or spreadsheets. Then, once I know what I'm going to test, I start to think of how I'm going to test it. It's not real to me until I can visualize the testing taking place. Do I need specialized software to help (like runtime analysis tools)? Will I need to write code or coordinate some activity (like a network failure)? Even visualizing something as simple as the data that I'll need can sometimes trigger a new idea or obstacle I'll need to tackle. As I think about each test, I'll start to group my tests into charters.

Once I have my charters figured out, I'll start to tackle whatever obstacles or setup tasks need to be done to allow me to run them. Some charters won't have any, and others might require a joint effort across teams. Generally, I'm ready to start testing once two conditions are satisfied:

1. There is software somewhere that's ready for some level of testing.
2. I have at least one charter that's ready to be executed (setup is completed or wasn't required).

0:35: Get your hands on the software you're testing
You'll notice I don't have a lot of entry criteria for my testing. That's because I'm always interested in seeing the software as soon as possible. I don't care how buggy it might be, once I see what I'm going to be testing, often my test ideas change. So the sooner I see it, the sooner I can provide feedback to the developer and start refactoring my tests.

While this philosophy won't work for all of my testing (in general I need something that's functionally sound before I can really start performance testing), it's reflective of a value I have to be an asset to the rest of the team. While I of course always want the most bug-free code I can find (well-designed, unit-tested, peer-reviewed), I'm a realist. Sometimes my feedback is more valuable to the team if I can get eyes on the product sooner rather than later.

0:21: Start with the components and build your way out from there
That said, I do have some general timing heuristics I use when thinking about when to test what. In general, I won't start doing any sort of end-to-end testing (following data through multiple parts of a system or subsystems) until I'm fairly confident each piece of the system is working to some degree (basic functionality has been confirmed, it's relatively stable and so on).

I typically don't try to do much automation or performance testing until I get at least one "stable" interface. The interface could be a Web service, a user interface, or even a method call, but I want it to be through at least one or two rounds of preliminary testing and I want to have some indication from the programming team that they don't plan to make major changes to the interface any time soon. I'm not looking for a promise it won't change, things change all the time -- I just want us to agree that right now we don't expect it to change.

0:05: Don't forget to regression test
Finally, I typically won't start regression testing until I've completed my first round of chartered test execution. Schedule constraints can of course override that, but I like the idea of regression testing being the last thing I do. It makes me more comfortable with the changes made as a result of my testing, and it gives me one last (often more relaxed) look at the product.

7 Tips to be More Innovative in the Age of Agile Testing to Survive an Economic Crisis

What is Agile Testing?
"Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing." - A wikipedia definition.

Why Need of Innovations in the Age of Agile Testing?

Global Recession/Economic downtime effect
Current Events are not Current Trends –

When global downturns hit, there is certain inevitability to their impact on information technology and Finance Sectors. Customers become more reluctant in giving software business. Some customers are withdrawing their long term projects and some customers using the opportunities in quoting low price. Many projects that dragged much longer than expected and cost more than planned. So, Companies started to explore how "Agile with different flavors" can help their Enterprises more reliably deliver software quickly and iteratively. The roles and responsibilities of Test Managers/Test Architects become more important in implementing Agile Projects. Innovations are increasingly being fueled by the needs of the testing society at large.

The Challenges in Agile Testing

Agile Testers face lot of challenges when they are working with Agile development team. A tester should be able to apply Root-Cause Analysis when finding severe bugs so that they unlikely to reoccur. While Agile has different flavors, Scrum is one process for implementing Agile. Some of the challenging scrum rules to be followed by every individual are

•  Obtain Number of Hours Commitment Up Front
•  Gather Requirements / Estimates Up Front
•  Entering the actual hours and estimated hours daily.
•  Daily Builds
•  Keep the Daily Scrum meetings short
•  Code Inspections are Paramount

So, in order to meet the above challenges, an agile tester needs to be innovative with the tools that they have. A great idea happens when what you have (tangible and intangible) meets the world's deepest hunger

How Testers Can be More Innovative in the Age of Agile Testing?

Here are Important Keys to Innovation:

1. Creative

A good Agile Tester needs to be extremely creative when trying to cope up with speed of development/release.  For a tester, being creative is more important than being critical.

2. Talented

He must be highly talented and strives for more learning and innovating new ideas. Talented Testers are never satisfied with what they have achieved and always strives to find unimaginable bugs of high value and priority.

3. Fearless

An Agile Tester should not be afraid to look at a developer's code and if need be, hopefully in extreme cases, go in and correct it.

4. Visionary

He must have a comprehensive vision, which includes client's expectations and delivery of the good product.

5. Empowered

He must be empowered to work in Pairs.  He will be involving in Pair Programming to bring shorter scripts, better designs and finding more bugs.

6. Passionate

Passionate Testers always have something unique to contribute that may be in terms of their innovative ideas, the way they carry day-to-day work, their outputs and improve things around them tirelessly.

7. Multiple Disciplines

Agile Tester must have multiple skills like, Manual, Functional, Performance testing skills and soft skills like Leadership skills, Communication skills, EI, etc. so that agile testing will become a cake walk.

 

What's the difference between priority and severity of bugs in Software Testing?

Source: one stop software testing

Priority" is associated with scheduling, and "severity" is associated with standards.

"Priority" means something is afforded or deserves prior attention; a precedence
established by order of importance (or urgency).

"Severity" is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles, e.g. a severe code of behavior.

The words priority and severity do come up in bug tracking. A variety of commercial, problem tracking/management software tools are available. These tools, with the detailed input of software test engineers, give the team complete information so developers can understand the bug, get an idea of its 'severity', reproduce it and fix it.

The fixes of bugs are based on project 'priorities' and 'severity' of bugs. The 'severity' of a problem is defined in accordance to the customer's risk assessment and recorded in their selected tracking tool. A buggy software can 'severely' affect schedules, which, in turn can lead to a reassessment and renegotiation of 'priorities'

How to write effective bug report?

"The purpose of a bug report is to let the developers see their faults and failures of the application under test. The bug report explains the gap between the actual result and expected result, and the details of that how to reproduce the bug."

Many times it happens that if the bug report is not effective or incomplete then programmers face many problems while fixing the bugs.

Due to the Bad bug report:
1. bug is not reproducible by developers
2. bug is fixed but with incorrect functionality.
3. delay in bug fixes
and many more….

Sample of bad bug report:

Bug Title: Error message

When running the application, I get an "Internal Server Error" that says "See the .log file for more details".

Steps to Recreate:
Happens when "Document.create = null". It is not happening when changed to " Document.create".

Expected results:
this error message should not appear when status is "Document.create = null"

Observed results:
See above.

So now how to write effective bug reports? Below I am giving some Bug report best practices:

1. Once the bug is found
Check the bug repository and search that if the bug is already exist. If exists, then check whether the status of bug is CLOSED OR OPEN. If the Status of bug is closed then REOPEN it.
Now, if the bug is not there in the repository and it is a new bug, then you need to report the bug.

2. If the bug is Reproduce able, then report it, Otherwise avoid reporting of non-reproducible bugs (best practices).

3. Report a new bug: "Bug description" also known as "Short description" or "Bug Summary": It should be a small statement, which briefly points towards the exact problem. Writing a one line description is an ART. Bug Summary helps everyone quickly review outstanding problems. It is the most important part of the bug. It should describe only the problem, not the replication steps.
If it is not clear then managers might defer the bug by mistake and also it affects the individual performance of a tester.

4. The Language of the bug: Language should be as simple as possible and as straight as possible. Don't point any developer through your words. Remember – the nasty is the bug, not the programmer.

The language should be such that is the bug report should be easily understandable by developers, fellow testers, managers, or in some cases, even the customers

5. Steps to Reproduce:
- The steps should be in a logical flow. Don't break the flow or skip any step.
- Mention the Pre-requisites clearly.
- Use attachments and screenshots of errors, and annotate the screenshots.
- The details must be elaborated like which buttons were pressed and in what order.
Note – Please don't write an essay on it. Be clear and precise. People do not like to read long paragraphs

6. Give Examples: either with actual data or the dummy scenario. It will be easy for developers to recreate the bug.

7. Provide the Test Case ID, requirement ID, and Specs Reference.

8. Define the proper Severity and Priority.
The impact of the defect should be thoroughly analyzed before setting the severity of the bug report. If you think that your bug should be fixed with a high priority, justify it in the bug report.

This justification should go in the Description section of the bug report.
If the bug is the result of regression from the previous builds/versions, raise the alarm. The severity of such a bug may be low but the priority should be typically high.


8. Read what you wrote. Read the report back to yourself, and see if you think it's clear. If you have listed a sequence of actions which should produce the failure, try following them yourself, to see if you missed a step.

9. Mention the correct environment, application link, build number, and login/password details (if any).

10. Common issues: Many times it happens that the bug is not reproducible (even though the bug report is good) by developers, the don't worry, arrange go to meeting/walkthrough with them and help them in order to recreate the bug. And sometimes it happens like first day the bug is appearing then on next day the same bug is not appearing. In this case, the bug can be assigned back to you. Now you need to accept it and close the bug with appropriate comments like
"It is working fine now, but previously this problem was appearing. So, will close this bug after verifying in next build."
Of course, you need to close the bug after verifying in the next release/build/patch because it is an inconsistent bug.
Thus a good tester needs to be patient & always build a defense mechanism in the form of preserving test data & screenshots etc. to justify his statements.

11. Don't Assume the Expected results. Write the expectations which are mentioned in the test case, requirements documents, FDD or in Specification documents.

That's all. Practices make us perfect.

Code Coverage " A White Box Testing Technique

What is code coverage – An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.

As per wiki – "Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing."

Code coverage measurement simply determines those statements in a body of code have been executed through a test run and those which have not. In general, a code coverage system collects information about the running program and then combines that with source information to generate a report on test suite's code coverage.
Code coverage is part of a feedback loop in the development process. As tests are developed, code coverage highlights aspects of the code which may not be adequately tested and which require additional testing. This loop will continue until coverage meets some specified target.

The main ideas behind coverage:
- Systematically create a list of tasks (the testing requirements)
- Check that each task is covered during the testing

Code coverage is defined in six types as listed below:

• Segment coverage – Each segment of code b/w control structure is executed at least once.
• Branch Coverage or Node Testing – Each branch in the code is taken in each possible direction at least once. Branch Coverage Gives a measure of how many assembler branch instructions are associated with each line. In addition, a measure of the number of branches taken/not taken is given.
• Compound Condition Coverage – When there are multiple conditions, you must test not only each direction but also each possible combinations of conditions, which is usually done by using a 'Truth Table'
• Basis Path Testing – Each independent path through the code is taken in a pre-determined order. This point will further be discussed in other section.

Basis path testing is a white box testing technique first proposed by Tom McCabe. The Basis path method enables to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Test Cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.

• Data Flow Testing (DFT) – In this approach you track the specific variables through each possible calculation, thus defining the set of intermediate paths through the code i.e., those based on each piece of code chosen to be tracked. Even though the paths are considered independent, dependencies across multiple paths are not really tested for by this approach. DFT tends to reflect dependencies but it is mainly through sequences of data manipulation. This approach tends to uncover bugs like variables used but not initialize, or declared but not used, and so on.
• Path Testing – Path testing is where all possible paths through the code are defined and covered. This testing is extremely laborious and time consuming.

Path coverage
- Goal is to ensure that all paths through program are taken
- Too many paths
- Restrict to paths in a subroutine
- or to two consecutive branches

• Loop Testing – In addition to above measures, there are testing strategies based on loop testing. These strategies relate to testing single loops, concatenated loops, and nested loops. Loops are fairly simple to test unless dependencies exist among the loop or b/w a loop and the code it contains.
This white box technique focuses exclusively on the validity of loop constructs. Four different classes of loops can be defined:

1. simple loops,
2. nested loops,
3. concatenated loops, and
4. unstructured loops.

Simple Loops:
The following tests should be applied to simple loops where n is the maximum number of allowable passes through the loop:

1. skip the loop entirely,
2. only pass once through the loop,
3. m passes through the loop where m < n,
4. n - 1, n, n + 1 passes through the loop.


Nested Loops:
The testing of nested loops cannot simply extend the technique of simple loops since this would result in a geometrically increasing number of test cases. One approach for nested loops:

1. Start at the innermost loop. Set all other loops to minimum values.
2. Conduct simple loop tests for the innermost loop while holding the outer loops at their minimums. Add tests for out-of-range or excluded values.
3. Work outward, conducting tests for the next loop while keeping all other outer loops at minimums and other nested loops to typical values.
4. Continue until all loops have been tested.

Concatenated Loops:
Concatenated loops can be tested as simple loops if each loop is independent of the others. If they are not independent (e.g. the loop counter for one is the loop counter for the other), then the nested approach can be used.

Unstructured Loops:
This type of loop should be redesigned not tested!!!

The role of a software test manager

By David W. Johnson

The role of the software test manager or test lead is to effectively lead the testing team. To fulfill this role, the lead must understand the discipline of testing and how to effectively implement a testing process while fulfilling the traditional leadership roles of a manager. What does that mean? The manager must manage and implement or maintain an effective testing process. That involves creating a test infrastructure that supports robust communication and a cost-effective testing framework.

What the test manager is responsible for:

• Defining and implementing the role testing plays within the organization.
• Defining the scope of testing within the context of each release/delivery.
• Deploying and managing the appropriate testing framework to meet the testing mandate.
• Implementing and evolving appropriate measurements and metrics.
• To be applied against the product under test.
• To be applied against the testing team.
• Planning, deploying and managing the testing effort for any given engagement/release.
• Managing and growing testing assets required for meeting the testing mandate:
• Team members
• Testing tools
• Testing processes
• Retaining skilled testing personnel.

The test manager or lead must understand how testing fits into the organizational structure. In other words, he must clearly define its role within the organization. This is often accomplished by crafting a mission statement or a defined testing mandate. Example: "To prevent, detect, record and manage defects within the context of a defined release."

Now it becomes the test lead's job to communicate and implement effective managerial and testing techniques to support this "simple" mandate. Your team, peers' (development lead, deployment lead and other leads) and superior's expectations need to be set appropriately given the timeframe of the release and the maturity of the development team and testing team. These expectations are usually defined in terms of functional areas deemed to be in scope or out of scope. Examples of those in scope include creating a new customer profile and updating a customer profile. Examples of those out of scope may include security and backup and recovery.

The definition of scope will change as you move through the various stages of testing. The key thing is to make sure your testing team and the organization as a whole clearly understands what is being tested and what is not being tested for the current release.

The test lead/manager must employ the appropriate testing framework or test architecture to meet the organization's testing needs. Although the testing framework requirements for any given organization are difficult to define, there are several questions the test lead/manager must ask. The answers to the questions and others will define the short- and long-term goals of the testing framework.

What is the relationship between product maturity and testing?
In the chart below, the first arrow leads to the product being ready for deployment. The second arrow leads to the product being ready to be tested as an integrated or whole system. The third arrow indicates functional testing can be performed against delivered components. The fourth arrow indicates the developer can test the code as an un-integrated unit. And the fifth arrow leads to the product concept being captured and reviewed.

How can the testing organization help prevent defects?
There are really two sides to testing verification and validation. Unfortunately the meaning of those terms has been defined differently by several governing/regulatory bodies. To put it more succinctly, there are tests that can be performed before the product is constructed or built, and there are tests that can be performed after the product has been constructed.

To prevent defects from occurring, you must test before the product is constructed. There are several methods for doing that. The most powerful and cost-effective method is reviews. Reviews can be either formal, technical reviews or peer reviews. Formal product development life cycles will provide the testing team with useful materials/deliverables for the review process. When properly implemented, any effective development paradigm should supply those deliverables. Example of development models and at what point during those models you can get information for the review process:

• Cascade or waterfall
• Requirements
• Functional specifications
• Agile or Extreme Programming
• High-level requirements
• Storyboards

Testing needs to be included in this review process, and any defects found need to be recorded and managed.

How and when can the testing organization detect software defects?
The testing organization can detect software defects after the product or some operational segment of it has been delivered. The type of testing to be performed depends on the maturity of the product at the time. The classic hierarchy or sequence of testing is as follows:

• Design review
• Unit testing
• Functional testing
• System testing
• User acceptance testing

The testing team should be involved in at least three of those phases: design review, function testing and system testing.

Functional testing involves the design, implementation and execution of test cases against the functional specification and/or functional requirements for the product. This is where the testing team measures the functional implementation against the product intent using well-formulated test cases and notes any discrepancies as defects (faults). One example is testing to ensure the Web page allows the entry of a new forum member. In that case, you are testing to ensure the Web page functions as an interface.

System testing follows much the same course (design, implement, execute and defect), but the intent or focus is very different. While functional testing focuses on discrete functional requirements, system testing focuses on the flow through the system and the connectivity between related systems. An example of that is testing to ensure the application allows the entry, activation and recovery of a new forum member. In that case, you are testing to ensure the system supports the business. There are several types of system tests; what is required for any given release should be determined by the scope:

• Security
• Performance
• Integration

What are the minimum set of measurements and metrics?
The single most important deliverable the testing team maintains is defects. Defects are arguably the only product the testing team produces that are seen and understood by the project as a whole. This is where the faults against the system are recorded and tracked. At a minimum each defect should contain the following:

• Defect name/title
• Defect description: What requirement is not being met?
• Detailed instructions on how to replicate the defect.
• Defect severity.
• Impacted functional area.
• Defect author.
• Status (open, in progress, fixed, closed)

This will then provide the data for a minimal set of metrics:

• Number of defects raised
• Distribution of defects in terms of severity
• Distribution of defects in terms of functional area

From this baseline the measurements and metrics a testing organization maintains are dependent on its maturity and mission statement. The Software Engineering Institute (SEI) Process Maturity Levels apply to testing as much as they do to any software engineering discipline:

1. Initial: (Anarchy) Unpredictable and poorly controlled.
2. Repeatable: (Folklore) Repeat previously mastered tasks.
3. Defined: (Standards) Process characterized, fairly well understood.
4. Managed: (Measurement) Process measured and controlled.
5. Optimizing: (Optimization) Focus on process improvement.

How disciplined the testing organization needs to become and what measurements and metrics are required depend on a cost/benefit analysis conducted by the test lead/manager. What makes sense in terms of the stated goals and previous performance of the testing organization?

How to grow and maintain a testing organization?
Managing or leading a testing team is probably one of the most challenging positions in IT. The team is usually understaffed and lacks appropriate tooling and financing. Deadlines don't move, but the testing phase is continually being pressured by product delays. Motivation and retention of key testing personnel under these conditions is critical. How do you accomplish this seemly impossible task? I can only go by my personal experience both as a lead and a team member:

• If the timelines are impacted, modify the test plan appropriately in terms of scope.
• Clearly communicate the situation to the testing team and project management.
• Keep clear lines of communication with development and project management.
• Whenever possible sell, sell, sell the importance and contributions of the testing team.
• Ensure the testing organization has clearly defined roles for each member of the team and a well-defined career path.
• Measure and communicate the testing team's return on investment. If the detected defect would have reached the field, what would have been the cost?
• Explain testing expenditures in terms of investment (ROI) not cost.
• Finally, never lose your cool