Think right scenarios

Thing right scenarios

Many organizations are aiming the most optimal product quality while development and QA processes. One side developer develop the product according the specifications provided by the business teams. Other side tester and QA teams test the product quality by various quality assurance processes, manual and automated testing and attempt to find the maximum defects during the QA process and testing. During this process QA team trying to ensure that client and/or end user consuming the product should not see the abnormality with respect to product functioning and it’s feature.

While designing the software product, BA, developer and tester’s goal is design or craft the right architecture, right test cases scenario, to make sure that particular application and product platform the way it is supposed to. At one hand it is absolute important to verify that the product perform it’s function as per the functional need, on the other hand it is equally or more important to verify that application or product gracefully handle the abnormal situations. It is obvious that most of the engineering and QA teams are working on the stated functionality by business teams and develop the software and test cases.

Handling of abnormal scenarios depends on the developers and tester’s creativity and knowledge/experience of eco system. But relying on developer and tester creativity cannot ensure the best quality product. For this we need to do more. In this paper I will discuss the right and wrong scenarios.

What are Positive and Negative Scenarios?

Positive scenario: Generally while defining the business scenario we define the happy situation.

Case1: Taking very basic two examples of the positive scenarios. Let’s take the case of user entry form of kid’s school admission and user input is “Date of Birth” of kids and parents “Date of Birth”. In the happy scenario developer provides a date control and tester create test case input field containing the date of birth for the kid and parent both.

Case2: As a complex example let’s consider that consumer withdraw money from the bank ATM.

# Business Scenario Steps Expected Result
1 Withdraw Money from the ABC Bank ATM –        Insert/Swipe the card in ATM.

–        Authorize and select Account

–        Enter Amount to withdraw.

–        Confirm the transaction

–        Collect cash

–        Collect Receipt

–        Money will be dispense from the ATM

–        Account will be debited.

–        User receives SMS and mail notification.


Developer will create the application based on the functionality provided in the above use case. These scenarios are “Happy Scenarios” and generally works fine because developer and tester both are focusing on the same.

Negative Scenarios: Now in all the above cases negative scenarios makes an impact for the quality of application/product. We dill discuss all the cases for the negative scenarios and also the owner of the scenarios.


  • In case of “Date of Birth” Date should be always less than the current date else someone can put the future date.
  • Parent date should always be greater than the kid’s birthday; otherwise data entry operator can enter the parent date of birth in kid’s date of birth field.
  • Most important that for the school kids age should be greater than ‘X’ month. It cannot be yesterday in the kid birthday field.


  • If customer inserts the card machine is not accepting the other bank’s card.
  • If customer is of same bank he enter wrong pin.
  • If customer enters the amount more than the limit of ATM money combination to dispense.
  • If customer is about the complete the transaction at the same time machine dispense system is malfunctioning and his money is debited in his book of accounts.

For thinking negative scenarios there are multiple owners and their creativity.

  • “Date of Birth” should be less than current date scenario should be covered by the designer, developer and QA team,
  • Parent’s date should be always less than kid date of birth also be covered by designer, developer and QA team
  • While for third case business team must define Age factor, this cannot be left on the developer and tester creativity.

In the above scenarios if everyone start right user cannot make mistake, so if BA defines possible negative business cases in requirement, developer define the technical negative scenarios and develop and tester defines the usability negative test cases and test in order to provide the softer to have expected output of product.

Factors to consider the negative scenarios:

Following are factors, which should be considered to define the negative scenarios.

  • Usability and handling mistakes
  • Business driven negative scenarios
  • Human Errors
  • Technology malfunctions
  • Environmental Glitches
  • Development Time Scenarios

Let’s discuss this in details.

Usability and Handling Mistakes

In the above example if data entry operator interchange the parent and kid date of birth then it is usability and handling mistake and for this developer and tester and BA should make it fool proof. In order to handle this there should be a check that parent DOB should always be greater than kid DOB.

Also DOB should always be less then current date. It is very similar to credit card expiry date field where month and year is always greater or equal to current date.

Business Driven Negative Scenarios

Business driven negative scenarios are those scenarios where BA must define the proper handling of business failure cases and negative scenarios. Like kids can start school after 36 month or amount in the ATM machine cannot exceed to a limit are basic examples.

Human Errors

Human errors are very common and it needs to be taken care in the system. For example user leaves certain column blank, or enters the wrong value in relevant field. Such cases require basic checks and negative scenarios of testing and in general making eliminates 90% of errors of the system.

Technology Malfunctions

None of the technology is perfect, every technology malfunction some or other time. ATM machine consist of many important technologies like machine, modem, Internet, and electricity, in this any part can malfunction. So all the failure scenarios must be defined in the negative scenarios.

Environmental Glitches

Many times system expected output changes because of the environment where system is operated. For example poor network can result in the non-performance of application while graphics loading; heavy pages may not be transmitted accurately but still it is part of allocation and system is not working as expected. So while developing and testing these things should be taken care.

Development Time Scenarios – Technical Exception

These are called technical exception handlings. Technical exceptions happen when a technical component of a business process acts in an unexpected way. When using Java based systems, this often results in a literal code Exception being thrown by the system. Technical components used in a process can fail in a way that cannot be described using process. In this case, it’s important to handle these exceptions in expected ways.

Generally developer creates a try catch and finally block and for all the exceptions they are using single exception, which is not correct. Every different exception scenario must be handled independently.

Let’s discuss some scenarios, which should be taken care by different roles.

Negative Scenarios and Exceptions Thinking

Business Exception Handling.

A business scenario is essentially a complete description of a business problem, both in business and in architectural terms, which enables individual requirements to be viewed in relation to one another in the context of the overall problem. Without such a complete description to serve as context:

  • There is a danger of the architecture being based on an incomplete set of requirements that do not add up to a whole problem description, and that can therefore misguide architecture work. So clearly create define all the alternative paths.
  • The business value of solving the problem is unclear
  • The relevance of potential solutions is unclear

Also, because the technique requires the involvement of business line management and other stakeholders at an early stage in the architecture project, it also plays an important role in gaining the buy-in of these key personnel to the overall project and its end-product – the IT architecture. Thinking of the business exception scenario can only be done by the business stakeholders, though developer and tester can add value but it is not their prime area to work on.

Creating a business scenario involves the following

1 – Identifying, documenting and ranking the problem driving the scenario

2 – Identify the business and technical environment of the scenario and documenting it in scenario models

3 – Identifying and documenting desired objectives (the results of handling the problems successfully)

4 – Identifying the human actors (participants) and their place in the business model

5 – Identifying computer actors (computing elements) and their place in the technology model

6 – Identifying and documenting roles, responsibilities and measures of success per actor; documenting the required scripts per actor, and the results of handling the situation

7 – Checking for “fitness for purpose” and refining only if necessary.

Technical Exception Handling

There are multiple areas in technical design and development which need to be taken care while handling negative scenarios, and these consists of the coding, information store, network, deployment etc. Here are some cases of Java, DB (oracle) ways to handle exception and negative scenarios.

  • Handle the common use negative scenarios
  • Use appropriate validation at each input and output level
  • Use Checked Exception for Recoverable error and Unchecked Exception for programming error.
  • Close or release resource in finally block
  • Including cause of Exception in stack-trace
  • Always provide meaning full message on Exception
  • Avoid overusing Checked Exception
  • Converting Checked Exception into Runtime Exception
  • Remember Exceptions are costly in terms of performance
  • Avoid empty catch blocks
  • Use Standard Exceptions
  • Document Exception thrown by any method
  • Have proper database exceptions handles at each level.

Below are oracle database standard exception and messages to deal the negative scenario.

Exception Name ORA Error SQLCODE Raised When …
ACCESS_INTO_NULL 06530 -6530 A program attempts to assign values to the attributes of an uninitialized object
CASE_NOT_FOUND 06592 -6592 None of the choices in the WHEN clauses of a CASE statement is selected, and there is no ELSE clause.
COLLECTION_IS_NULL 06531 -6531 A program attempts to apply collection methods other than EXISTS to an uninitialized nested table or v-array, or the program attempts to assign values to the elements of an uninitialized nested table or v-array.
CURSOR_ALREADY_OPEN 06511 -6511 A program attempts to open an already open cursor. A cursor must be closed before it can be reopened. A cursor FOR loop automatically opens the cursor to which it refers, so your program cannot open that cursor inside the loop.
DUP_VAL_ON_INDEX 00001 -1 A program attempts to store duplicate values in a column that is constrained by a unique index.
INVALID_CURSOR 01001 -1001 A program attempts a cursor operation that is not allowed, such as closing an unopened cursor.
INVALID_NUMBER 01722 -1722 n a SQL statement, the conversion of a character string into a number fails because the string does not represent a valid number. (In procedural statements,VALUE_ERROR is raised.) This exception is also raised when theLIMIT-clause expression in a bulkFETCH statement does not evaluate to a positive number.
LOGIN_DENIED 01017 -1017 A program attempts to log on to the database with an invalid username or password.
NO_DATA_FOUND 01403 +100 A SELECT INTO statement returns no rows, or your program references a deleted element in a nested table or an uninitialized element in an index-by table.

Because this exception is used internally by some SQL functions to signal completion, you must not rely on this exception being propagated if you raise it within a function that is invoked as part of a query.

NOT_LOGGED_ON 01012 -1012 A program issues a database call without being connected to the database.
PROGRAM_ERROR 06501 -6501 PL/SQL has an internal problem.
ROWTYPE_MISMATCH 06504 -6504 The host cursor variable and PL/SQL cursor variable involved in an assignment have incompatible return types. When an open host cursor variable is passed to a stored subprogram, the return types of the actual and formal parameters must be compatible.
SELF_IS_NULL 30625 -30625 A program attempts to invoke a MEMBER method, but the instance of the object type was not initialized. The built-in parameter SELF points to the object, and is always the first parameter passed to a MEMBER method.
STORAGE_ERROR 06500 -6500 PL/SQL ran out of memory or memory was corrupted.
SUBSCRIPT_BEYOND_COUNT 06533 -6533 A program references a nested table or v-array element using an index number larger than the number of elements in the collection.
SUBSCRIPT_OUTSIDE_LIMIT 06532 -6532 A program references a nested table or v-array element using an index number (-1 for example) that is outside the legal range.
SYS_INVALID_ROWID 01410 -1410 The conversion of a character string into a universal rowid fails because the character string does not represent a valid rowid.
TIMEOUT_ON_RESOURCE 00051 -51 A time out occurs while the database is waiting for a resource.
TOO_MANY_ROWS 01422 -1422 A SELECT INTO statement returns more than one row.
VALUE_ERROR 06502 -6502 An arithmetic, conversion, truncation, or size-constraint error occurs. For example, when your program selects a column value into a character variable, if the value is longer than the declared length of the variable, PL/SQL stops the assignment and raises VALUE_ERROR. In procedural statements, VALUE_ERROR is raised if the conversion of a character string into a number fails. (In SQL statements INVALID_NUMBER is raised.)
ZERO_DIVIDE 01476 -1476 A program attempts to divide a number by zero.

At the end I would like to emphasis  on the need of negative scenarios and exception handling and every team must define the negative scenarios in their capacity and understanding, it should start from the business team then designer, developer and at the end by testers. It is good if we involve the customer as well in this Journey.

Daya Shanker
Date: 5 Sept 2015