Business Rules of software testing

Every system operates on business rules. If one were to document the business rules on which a system is based – it would be an exhaustive list to write down and track. Most business rules become implicit in the design and mind.

Business rules are typically implemented separately from presentation, application and data logic. To add to this, they are under constant change due to market requirements, user needs and software upgrades. Business Rules testing will help validate that your system is performing as expected, thus enforcing correct business practices on the user and the system code.

A typical way to gather business rules for your system is by talking to the business analyst and trying to understand what the analyst expects the system to do or how he/she expects the system to behave. A meeting with a developer will be helpful to understand how he/she thinks the system should behave. You may get conflicting ideas here, and it is important that these are sorted out before you have begun testing.

You can expand the table above to suit your needs in order to understand the various normal and alternative flows of the system. Again, mould the table and the data that you gather to suit the type of testing that you will do for your system. If you are doing unit testing, you will use more business rules like the first example (min char length), than like the third example (available only if Option A..)

Keep the following in mind:

1. Divide the system into modules as done by development.

2. For each module, take views based on the kind of testing you intend to do.

3. Direct your questions to the right people. E.g. If you are unit testing a product, a developer would be the right person to talk to. If you are system or user testing a product, a business analyst or end user would be able to answer your questions.

4. If you are short on time, document your business rules in order of decreasing priority.

5. Be specific with your questions. Run through the product or the system yourself, and make a list of questions, before you attempt to ask other team members.

6. Know the difference between a business rule and UI design. For e.g. a warning message to indicate that all information may be deleted is not a business rule, but a UI design.

7. Check if the business rules are incorporated in the system as code logic or are stored in the database and are made use of through a rules engine. This will help you organize your questions better.

related post

UNIT TESTING PART ONE

UNIT TESTING PART TWO

UNIT TESTING PART THREE

GUI TESTING

WINDOWS COMPLIANCE GUI TESTING PART ONE

WINDOWS COMPLIANCE GUI TESTING PART TWO

WINDOWS COMPLIANCE GUI TESTING PART THREE

WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING

WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING

WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO


No comments:

Post a Comment