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


What is Scalability

Scalability is a system’s ability to process more workload, with a proportional increase in system resource usage (mainly hardware like CPU, Memory, Threads etc.). In other words, in a scalable system, if user doubles the workload, then the system would use twice with system resources (most vital parameters like CPU, Memory, disk usage will proportionately change). This sounds obvious, but due to conflicts within the system, the resource usage might exceed twice the original workload.

Examples of bad scalability due to resource conflicts include the following:

  • Applications requiring significant concurrency management as user populations increase or increase in transaction
  • Increased locking activities and IO of the system.
  • Increased data consistency during the load
  • Increased operating system load
  • Transactions requiring increases in data access as data volumes increase and IO becomes bottleneck.
  • Poor SQL and index design resulting in a higher number of logical I/O for the same number of rows returned
  • Reduced availability, because database objects take longer to maintain

An application is said to be non-scalable if it exhausts a system resource to the point where no more throughput is possible when it’s workload is increased. Such applications result in fixed throughputs and poor response times. In resultant we have bad user experiences during the system usage.

Examples of resource exhaustion include the following:

  • Hardware exhaustion
  • Table scans in high-volume transactions causing inevitable disk I/O shortages
  • Excessive network requests, resulting in network and scheduling bottlenecks
  • Memory allocation causing paging and swapping
  • Excessive process and thread allocation causing operating system thrashing and bottleneck on CPU.

This means that application designers must create a design that uses the same resources, regardless of user populations and data volumes, and does not put loads on the system resources beyond their limits.

Scalability of System

Now days there are multi device applications are being used where communication is carried out via IP protocol, USSD, SMS which have more complex performance and availability requirement. Some applications are designed only for the back-office use and some are designed for the end users like telecom, hospitality segment and financial segment.

End-user based application require more data to be available online. In these segments not only the availability of data but also the real time service is very important.

Following are important for the current era application.

  • Availability of system 24 hours 365 days means no downtime.
  • Unpredictable and non-specific number of users at any point of time.
  • Difficult in sizing as capacity changes frequently.
  • Availability for any type of requirement at all time.
  • Stateless of middleware
  • Multi-tier and multi layer architecture
  • Multi device requirement.
  • Rapid development requirement as market is moving fast.
  • Less or no time for testing
  • Agile methodology of development.

As the current application workload growth multifold and system grow exponentially year on year. Have a look on the Amazon, Flipkart, and Netflix all has grown in their areas rapidly and increased their usage exponentially by e-commerce, telemarketing. With such dynamism every system has adopted the new technology, and moved to scalable architecture in its own way. One thing is clear that none of the scalable architecture if 100% future proofs. Any newly adopted architecture today will become obsolete in two year due to growth in system, users behavior, update in technology change and pattern of user adoption and we search for the new scalable architecture.


Factors Preventing the Scalability

While designing the system Architects and designers should target the perfect scalability model but in reality it is not happening. Most reliable and scalable model is known as linear scalability model. In linear scalability model system throughput is directly proportional to the resources of the system means double the resources like (CPU and memory) and double the capacity. But actually this is not the case in real world where application is tightly coupled with some technology and predefined architecture.

Following are areas, which prevent scalability:

  • Poor design of system; this is one of the biggest factors for the scalability.
    • Poor application, database design that causes more processing.
    • Poor transaction system design which cause locking and serialization problem.
    • Poor interconnects and complete synchronous design or too many hops in system.
    • Non-EDA (event driven architecture) design, which are interdependent of multiple systems.
    • Outdated software and plug-ins.
    • Older design patterns which does not fit in current era.
  • Implementation of System, sometime system is properly designed but implementation is not correct.
    • System moves in Production with bad I/O strategies.
    • Additional modules/queries applied in production while it was not planned in actual design.
    • As per production environment, configuration of application and hardware resources are not carried out.
    • Insufficient memory usage or memory leaks put high workload on virtual/OS memory and CPU exhaustion.
  • Incorrect sizing of hardware
    • Poor Capacity planning.
    • All components are not in resonance.
    • Outdated hardware and technologies.
  • Software components limitation
    • Used sub systems software, third party software may not be linearly scalable.
    • Scalability of database, operating systems like database is not linearly scalable and Risk based OS like Solaris; AIX gives more scalability then Linux.
  • Limitation of hardware and it?s peripherals
    • Each server has it?s own capacity and it should be sized properly.
    • Most of multiprocessor systems are close to linear scalability with finite number of CPU but beyond a point adding CPU can increase the performance but not proportionately. Some time it also possible that adding CPU decrease the performance of system as well.
    • For the higher scalability should use the engineered system like EXADATA, EXALOGIC, PURESYSTEM, PURESCALE, and PUREAPPS etc.
    • System should have compatible components like Network system should be adequate,
    • IO of storage and disk should be proper, maybe using the SSD.
    • Adequate capacity of backup system.

Right way of architecture

There are two parts of system architecture

  • Hardware and Software components
  • Configuring the right system architecture for your requirement.

Hardware and Software Components

Hardware components – In todays world solution architects are responsible with software architects and designers for sizing and capacity planning of hardware at each layer of multi layer architecture environment. It is responsibility of architects to design the balanced system. Designers are bridge to develop the rightly designed system. So designer should be sensitive about this because he could be the strongest or weakest link of the system.

In the balance design all components must be reach their design limits simultaneously.

Below are main components of system.

  • Processor Units (CPU)
  • Memory
  • I/O subsystems
  • Storage
  • Network

Processor Units (CPU)

Right selection of CPU is very important; this is costly and most important part of entire eco system. There can be one or more CPU, and it can vary in processing power from simple CPU from the mobile device to high powered and engineered system. Right sizing of this component is very important as CPU provide the power to system but at same time cost is a factor. Though CPU may not cost high but other software components are licensed based on CPU and core like Oracle, DB2 database, Middleware like Websphere, Weblogic. It is trade off between cost and performance while designing the right system. Following should be kept in mind while selecting the CPU.

  • For transactional system use the multithreaded system.
  • For databases select the higher processing capacity system, higher the CPU clock-speed higher the database performance.
  • For the data processing with NOSQL commodity hardware.


Now a day?s application required lot of memory to cache the data so appropriate memory is necessity of hour. Even handheld devices are available with 3-4 GB of memory. Enterprise systems require more memory so we need to be provision good amount of memory where caching of data, memory gird, in memory data makes system more scalable.

I/O Subsystems and Storage

I/O of any system can make or break of the system, when we have good I/O system performs well but small glitch in I/O drag the performance of entire eco-system. I/O subsystems can vary from the small disk of system to a disk array. In market there are so many smart storage and disk arrays are available, so while designing system we should consider the following.

  • For the OLTP system consider the high IOPS storage and high bandwidth.
  • Use solid-state drives for high IO system.
  • Use commodity storage for the document servers
  • Use high capacity storage for backup and archive.
  • Progressive storage is also the one of the best option in varied situation.


In any of the solution design network is one factor where most of us are ignorant. In the initial days we did not had any choice of network. One gbps network has ruled on us quite a long. But in recent past bandwidth of Internet and internal LAN and WAN has grown significantly. So we should plan in such a way that network should not be bottleneck and at the same time it should be scalable, use of 10 gigabyte network, and infini-band are good choices for high scalability. Most engineered system like EXADATA, EXALOGIC designed with high bandwidth network.

Software and Third party Components

Similar to hardware component software components and third party software are equally responsible factor for the scalability of system. By dividing software components into functional and non-functional components, it is possible to better comprehend the application design and architecture. Some components of the system are performed by existing software bought to accelerate application implementation, or to avoid re-development of common components.

The difference between software components and hardware components is that while hardware components only performs one task, a piece of software can perform the roles of various software components. For example, a disk drive only stores and retrieves data, but a client program can manage the user interface and perform business logic.

Following are major software components involved in system

  • Management of User interface ? Desktop clients, Web, Mobile, Apps, USSD, SMS, and IVR etc.
  • Management of Business logic ? backend holds the logic of application and have specific request response format
  • Management of User Request and Resource allocation
  • Management of Data and Transactions

User Interface

This component is visible to application user. All the interaction with users are performed via this layer as mentioned earlier Web, Client desktop applications, Mobile App, IVR, USSD, SMS and other machine apps are part of this. This include the following functions

  • Rendering the screen and information to user
  • Collecting user data and transferring it to business logic layer.
  • Displaying processed information to user.
  • Validating entered data
  • Navigating user to next requirement and page/intent.
  • Notification and alert to users like email alert or application notifications.

While choosing this layer scalability should be kept in mind because if this layer is not scalable entire system is useless. Following should be factored:

  • Right tool like mobile app native app, framework or related technology.
  • No of con-current users to be supported
  • Peak time of system, day, week, festive etc.

Business logic layer

This component contains the core business of system that are central to the application function. Any problem occurs in this part of system or error made in this component can be very costly to repair. A mixture of declarative and procedural approaches implements this component. An example of a declarative activity is defining input and output of system. An example of procedure-based logic is implementing a loyalty or accounting strategy.

Common functions of this component are as follows.

  • Defining Input and Output of system
  • Defining required variables and parameters
  • Defining rules and constraint of system
  • Validation of Business logic
  • Coding of Procedural logic to implement business rules.

To make this component scalable following is required

  • Right tools for Business logic
  • Right protocols and API for interaction with User interface and third party.
  • Synchronous and asynchronous calls
  • Proper EDA (Event Driven Architecture) architecture
  • Notification to other system and users like SMS, Android notification.

User Request and Resource allocation

This component is implemented in all pieces of software. However, there are some requests and resources that can be influenced by the application design and some that cannot. In a multiuser application, the application and database server or the operating system handles most resource allocation by user requests.

However, in a large application where the number of users and their usage pattern is unknown or growing rapidly, the system architect must be proactive to ensure that no single software component becomes overloaded and unstable.

In order to make this system scalable we should take care of following:

  • Understand the load on each component like user interface, business logic, database and its underlying hardware components.
  • Choose right tools and technology
  • Select proper protocol of communication internal components and external system.
  • Separate the transaction, reporting, auditing, logging, analytics and notification.
  • OLAP and OLTP should go in different path both should not co-exist together.

Data and Transaction Layer

This layer is mainly takes the responsibility of database and transaction. This layer is bridge between the user requirement and the background data stored in storage. Here proper design of database is very important.

Following are important to make system scalable.

  • Proper Data Modeling ? OLAP, OLTP and document servers all must be designed based on requirement
  • Table and Index Design ? Storage and I/O should be managed by right normalisation of system and proper indexes.
  • Using Views
  • SQL Execution Efficiency – This drags the system performance significantly so user and designer should be very careful.

For details see

SQL Mistakes which Drag System Performance Java, JDBC, Hibernate ? Part1

SQL Mistakes which Drag System Performance Java, JDBC, Hibernate Part2

  • Proper storage of data

In the next Article part II I will explain about “Configuring the right architecture for your requirement”