Communication: Informing people when there is a problem, and when they depend on you ..

You are providing a service to some clients, and they have come to totally depend on you. Like the post before this one, if you are providing analytics information to external teams, you have a lot of responsibility on your head. They would come to depend on you and if you are doing a good job for them, more and more, they will not think about any problems at your end and will depend on you to inform them if you are running into any problem. And that places an awful lot of responsibility on your end. Towards this purpose, you have to have a strategy to figure out what to do if something goes wrong at your end, and informing your clients quickly should be a part of such a strategy,
We recently had a big shock when it came to our analytics program, where we were using an external component. We were integrating such a component, and passing it parameters from within our code. What this ended up doing was passing data from our user base to the database maintained by the external team, and they would let us mine this information through a web front end, and they would also help us if we needed some new queries or new reports.
All this was perfect, and we did not bother anymore to check whether there could be a problem of any kind (so part of the problem was at our end before of a lack of checking for variables that could impact the program). We were looking at some data pursuant to the launch of a new version of the application, and in the second to fourth week of the launch, we saw data that indicated that the number of people using the older version of the program had reduced. This enthused the Product Management and other senior stakeholders, and a decision was made to target the older users through an email campaign sent to those users who were on our email list and had purchased previous versions of the program. This campaign would build on this conversion and offer some benefits if they did an upgrade, the idea being that if there are people doing an upgrade, it would help to push even more people.
This campaign was made ready in record time, and pushed live for a week. Like any other campaign, this program had some large costs because of the resources used, and the infrastructure cost for tracking of the email campaign, including measuring the conversion numbers. However, at the end of the week, it was very surprising that the conversion rate did not show any uptick; and in a coincidence, a day later we received an email from the analytics team that they were suspecting some configuration issues on their side, and they have probed, and finally figured out that some data had been lost, which also overlapped the weeks that made us decide that people using the older versions had dropped.
This was like a big blow, and since the analytics team was part of the same organization, we bit back the strong words, put in the issue for being more careful the next time that we did a campaign based on data. However, senior stakeholders did not hold back and had an interesting discussion with the head of the analytics team about not sending out a message to the various client teams when they suspected some data issues. The analytics team wanted to be sure before sending out a message to the client teams, but it was a learning to all of us. Since none of us really knows when another team is in a critical position and are dependent on us, as soon as we run into some problem, it is imperative to quantify the risk position and send it out the client teams that are dependent on us. This helps them avoid business decisions that are impacted if the data turns out to be problematic; even if it was a false alarm, there is some loss, but in general, the loss might be less than making a decision based on data that is incorrect.

What is meant by code coverage? What are different types of code coverage?

Code coverage is one of the important measures that comes across while carrying out the software testing. 

What is Code Coverage?

- Code coverage is the measure that gives the degree up to which the source of a software system or application has been tested. 

- Code coverage earlier was recognized as one of the methods that were developed for carrying out a systematic software testing. 

- The term code coverage was first referenced under the “communications of the ACM” in the year of 1963 by Maloney and miller.

- Code coverage is measured using a specialized tool called code coverage analyzer for instrumenting the binaries in order to add all the tracing calls and run all the automated test cases against the software system or application under question. 

- A good code coverage analyzer will not only give you the degree of the coverage but will also allow you to dig deeper in to the data and check out for the lines of the code that are executed during a particular test. 

- Today we have a large number of code coverage criteria that amount to the total code coverage. 

Types of Code Coverage

- The software system or application that is under testing is adorned with certain options that run under a particular environment. 

- Each and every function of the program that is executed is traced back to the function calls in the source code which allows the easy checking of the rarely accessed, never accessed parts of the program under normal conditions. 

- This gives the software testers an assurance that the most important conditions of the source code have been tested. 

- The outcome is then subjected to analyzation for sorting out of the code that has been analyzed. 

- The process is a combination of several code coverage methods that aim to provide a manageable and rigorous set of regression tests. 

- The output of the code coverage analyzation can be used by the engineers for devising the test cases and configuration sets that in turn will increase the code coverage relating to the vital functions. 

- Mostly two common forms of the code coverage are used by the software testers namely:

1. Line coverage or statement coverage: 

- This type of the code coverage reports regarding the execution foot print of the software testing in terms of the lines of code which are executed for the completion of the test.

- The statement coverage provides you with the benefit of the identification of the bugs that arise in the constructs of the control flow of the source code like consecutive switch labels and compound conditions. 

- The major setback of this code coverage type is that even though it seems like you have achieved 100 percent of the code coverage, there might be 100s of wicked and uncaught bugs.

- This disadvantage of the statement or line coverage is over-comed by a more advance form of code coverage called the branch coverage.

2. Edge or branch coverage: 

This type of code coverage reports regarding the branches or the code decisions that like statements are executed for the completion of the tests.

- Both of the above mentioned types of the code coverage provide the result in the form of code coverage metric in terms of percentages. 

- Out of the two, the branch code coverage is considered to be quite comprehensive that the equivalent percentage of the statement code coverage.

- It is also very easy to determine the number of branches that have to be tested since the Boolean decisions have only two outcomes i.e., either true or false. 

Multiple Condition Coverage is a white box testing technique - Explain?

There are so many types of the code coverage and the multiple condition coverage is also one of them and that is what has been discussed all about in this article.

What is code Coverage?

Code coverage as we all know is a process that aims at the following purposes:

- Creation of the additional test cases for increasing the coverage.
- Looking up for such areas of the software system or application code that have not been exercised by any of the test cases.
- Determination of the quantitative measure of the extent of the code coverage which can be thought of as an indirect measure of the software quality.
- Identification of the redundant test cases which does not affect the code coverage.

The whole process is a time consuming one and thus is helped by an automating tool called the code coverage analyzer.

What is Multiple Condition Coverage?

- Multiple condition coverage is a modification of the condition coverage type of the code coverage.

- As the term “multiple condition coverage” itself suggests that it implements almost all the possible combinations of the conditions in order to check whether those possible combinations do occur in the execution of the test cases or not.

- A large number of the test cases are required for carrying out a full multiple condition coverage of a decision and these are supplied by the truth tables of the logical operators obtained for that particular decision.

- The multiple condition coverage offers an added advantage in the languages such as C, C++, Java and so on which have short circuit operators which is that it helps in implementing a thorough testing.

- It in turn makes the multiple condition coverage in such languages very similar to the condition coverage.

Disadvantage of Multiple Condition Coverage

But, one should not think that the multiple condition coverage is void of any disadvantages.

- It does have one which is that the deciding up on the minimum number of test cases required for the coverage proves to be very difficult job.

- The problem worsens as the complexity of the boolean expressions implemented in the decisions increases.

- Another disadvantage adds to the problem of the test case designer which is that the minimum number of the test cases required for the coverage varies substantially from condition to condition having the similar level of complexity.

Lets take an example:

For example, in a decision, first condition may require 5 test cases while the second one may require 11 test cases and both the conditions are having the same number of operators and operands.

In contrast to the condition coverage that includes the decision coverage also, the multiple condition coverage does not include any decision coverage.

Now what about the languages like Pascal and visual basic that do not have short circuit operators? For such languages the multiple condition coverage is implemented in the form of the path coverage for logical expressions.

One point to be noted here is that the advantages and disadvantages remain the same in the path coverage form also since in the path coverage the number of each additional logical operator is doubled the number of the required test cases.

Multiple condition coverage takes in to consideration two or more conditions and then makes them in to a group and then they are tested. "Since the multiple condition coverage requires a very detailed knowledge of the software system or application’s code in order to understand all the decision aiming statements in that and in turn decide for the minimum requirement of the test cases, therefore it has been categorized under the white box testing techniques."

Basis Path Testing is a white box testing technique - Explain?

As we all know in a typical software system or application, there exist so many possible paths between the entry and exit of the paths and the number of such potential paths is doubled by every decision that comes in the way.

On top of this every case statements adds to the number of the potential paths by multiplying the number of cases with the number of potential paths and this is further incremented by the loops which multiply all the different possible iteration values with the number of potential paths.

So you see with so many paths all over, a single unit of the code makes it extremely difficult to provide a 100 percent coverage to that unit. This can be illustrated by the following example:

- Consider a software program consisting a straight line code having only a single loop that is to be executed 50 times.
- For such a code we can easily make out that it will have 50 paths.
- Like all the other processes, the testing also does not have any unlimited amount of resources.
- There are a limited number of people to perform testing, limited resources, time, efforts and equipment to make up to the successful testing in a stipulated period of time.
- The testing processes always face a challenge of covering all the possible paths without going out of the specified limits.
- But this seems like very difficult to be achieved!

"This all can be possibly achieved if all the redundancy is eliminated from the source code to the maximum extent that is possible and at the same time, adequate coverage must be maintained."

How was basis path testing developed?

- Basis path testing was developed as a hybrid between the two testings namely the path testing and the branch testing.

- The path testing is the testing methodology that has been defined to execute paths all over a computer program whether all or selected and the branch testing is the testing methodology that has been defined for the execution of all the outcomes of every decision in a software source code.

- It can be thought of as a testing methodology that tests every branch and also all the independent paths throughout the software program.

- A path can be a sequence of statements or instructions to the system that starts at one junction and ends at the other and in between it may encounter several other junctions.

- An independent path is a bit different from the normal path in the way that it introduces a new set of processing statements or conditions.

What steps are involved in basis path testing?

It is a path that takes in to account only the paths with the linear combination of the iterations and in no other way. The following steps are involved in the basis path testing:

1. Drawing out of the control flow graph
2. Calculation of the cyclomatic complexity
3. A basis set of paths is chosen
4. Generation of the test cases for the execution of each and every path in the code

Benefits of Basis Path Testing

1. It clearly defines the number of the independent paths and the number of the test cases required.
2. It executes every statement at least once.
3. It executes every condition for both outcomes i.e., true and false at least once.
4. It pays attention to the logic of the program.
5. It facilitates the arbitrary test case design in contrast to the analytical test case design.

Basis path testing is a white box testing technique since one requires an in-depth knowledge of the program.

What are the different attributes of the use cases?

Use cases sound similar to test cases. But the two are not same. Where the test cases are used in software testing, the use cases are used in the general software systems engineering. We have dedicated this whole article to the discussion of the use cases.

What are Use Cases?

- The use case is a set of steps which are implemented to define the interactions occurring between the software system and a role.

- This is basically done to achieve a predefined goal. The role is commonly called as an actor and can be an external software system or simply a human.

- The use cases are often used at the higher levels of the software systems engineering.

- The goals to achieve for which the use cases are developed are often defined by the stake holders.

- The requirements are stated by the stake holders in a separate documentation.

- This documentation serves at a contract between the two i.e., between the software developers or programmers and the stake holders or the clients.

- The structure of a use case has been a quite debated topic. Many opinions were given regarding the how the structure of a typical use case should be.

- But usually the structure defined by the Alistair Cockburn is followed. It is popularly known as the “fully dressed use case structure”.
It consists of the following aspects:

1. Title of the use case
2. Primary role
3. Goal of the use case
4. Scope
5. Level
6. Interests
7. Stake holders
8. Preconditions or requirements
9. Guarantees (both minimal and success)
10.Success scenario
11. Technology
12. Data variations
13. Extensions and
14. Related information

He gave some other many useful aspects related to the use cases like:

1. Casual use case structure
2. Design scope icon
3. Goal level icon

ROLE OF AN ACTOR

- The role of an actor in a use case is to make effective decisions and so calls for the need of good decision making ability.

- It is not necessary that an actor should always be a human. It can be a computer system also.

- Though the decisions of an actor influences the whole use case implementation, there does not exist any direct link between the system and the actor.

ATTRIBUTES OF USE CASES

- Certain necessary attributes have been discovered so far that are needed by the use case to accomplish the goal for which it has been developed.

- The attributes need not be only functions; they can be in the form of data variables also.

- Not all the attributes have been extracted from the preceding steps; some have been taken as the general assumptions out of common knowledge of the use cases.

1. System requirements: These requirements form the basis for thedelopmnt of a use case.
2. The requirements need to be complete and correct and of quality.
3. Software requirements specification testing
4. User- centred approach for the specification of the requirements.
5. Unified modelling language: this language based on the object oriented paradigm is employed for the construction, visualization and documentation of the system.
6. Use case diagrams

The below mentioned are the three attributes of the use cases:

1. Level of validity
This attribute is concerned with the validation of the use cases. It queries about the completeness of the use case, achievement of the goals, changes to be made, addressing of the additional goals and representation of the additional actors and so on.

2. Metrics
This use case attribute deals with the factors like the ambiguity, completeness, trace-ability and volatility of the use case.

3. Risk indicators
Typical 3 risk indicators have been identified namely incompleteness, options and weak phrases.

What are different error handling defects?

Errors are a major headache to the software programmers, developers as well as testers. They cause the whole software system or application to falter, produce unexpected results and behave abnormally. Some errors cause more harm while some cause less, some are easy to discover whereas some are hideous, some are as active and disruptive like a volcano and others are dormant. Therefore error handling becomes an important factor in deciding the success of a program.

WHAT IS MEANT BY ERROR HANDLING?
- Error handling is the way of a program to handle the errors that disturb its functioning.
- The error handling procedure should be very strong and smart.
- Error handling requires a lot decision making.
- The error handling process like other processes also is a victim of defects.

STEPS IN ERROR HANDLING PROCESS & DEFECT CAUSING FACTORS

1. The main steps involved in an Error handling process are namely detection, anticipation and resolution of the errors that occur during the execution of the software program or application.

2. Some applications even employ programs called “error handlers” developed specially for handling the errors.

3. A software system or application is said to have good error handling capabilities if it is able to recover from the errors without causing the whole program to terminate or if it is not able to handle that error, properly terminates the program without causing any data loss.

4. Such forceful termination is nothing but an error handling defect.

5. The basic factors causing the run time errors are invalid input data and adverse function parameters.

6. Lack of memory is another defect causing factor.

A Software application comprises of various small programs.These programs may conflict with each other during the run time. Similarly web applications also experience due to electrical noise and malware or undue pressure on the server.

ERROR HANDLING PROCESS
A software system or application can overcome these errors by its error handling process. But this error handling process also faces some risks from any defects in its source code. Thus we can define the error handling defects as the defects that reduce the efficiency of the error handling process.

1. On the initiation of the error handling process, the discrepancy between the expected behavior and actual behavior is identified.
2. Whenever there is some discrepancy in the behavior of the program, a defect is created.
3. The test script that was being executed at the time of encounter of the defect is tested.
4. This process is called defect creation.
5. After this, the discovered defect is verified i.e., whether or not the defect is valid.
6. A severity level is assigned to the defect.
7. This severity level indicates the impact and visibility of the defect on the program.
8. The defect can cause the core functionality to go out of order or stop working.
9. It can affect the operational environment.
10. Such defects prevent the user from accessing the features and functionalities of the software system or application.
11. Incorrect navigation links are also a defect.
12. According to the level of the severity the encountered errors can cause, they are assigned priorities.
13. This process is defect prioritization.
14. Several priority codes have been defined.
15. There are some defects that do not even allow the testing to take place.
16. Defects causing such errors are given the highest priority.
17. The defect is once again confirmed and this process is called defect confirmation.
18. After the defect confirmation the defect is analyzed, the affected code is redesigned, developed and tested again for any shortcomings.
19. This process following the defect confirmation is called defect resolution.
20. The defects after being resolved are once again reviewed by the developer and certain test scripts are run to confirm that the defect has been resolved.
21. After the verification the defect is closed.

What are the qualities of a good tester?

The quality of the software testing depends up on the skills of the tester since the whole software testing process revolves on the instructions of the tester. Even a single wrong decision can cause the whole testing process go wrong.

A tester makes a decision based on his testing skills and capabilities. So a tester has to be very careful while taking any decisions regarding the software testing process.

ATTRIBUTES OF A GOOD TESTER

1. GOOD TECHNICAL & PRACTICAL KNOWLEDGE
- It is not necessary that a good tester might be an experienced one.
- A fresher having good technical and practical knowledge about the software testing methodologies and strategies can also perform effective software testing. - Though one learns from experience, it is often seen that there are many testers who even after having much experience are not able to carry out the software testing process efficiently in a well mannered way.
- They often keep bumping into the problems.

2. KNOWLEDGE ABOUT TESTING PROCESS
- A good tester keeps the overview of the whole testing process in mind while drafting out the test plan.
- He/ she include all the aspects to be tested in the test plan.

3. FAULT FINDING
- He insists on finding the faults earlier in the software system or application since discovering the bugs and errors in the earlier phases of the development helps a great deal.
- It takes less effort to fix a bug or an error in the initial stage of the development when compared to the efforts required in the later stages of development.

4. KNOWLEDGE ABOUT COMPUTER PROGRAMMING
- Testers know computer programming well.
- They are capable of maintaining good credibility with the fellow programmers.
- They have senior computer programmers working over them.

5. KNOWLEDGE ABOUT APPLICATION SOFTWARE
- They know the application software under testing very well.
- He/ she should be able to exploit the application software like an end user.
- Thinking like a user open ups new ways in which the application can be used.

6. SMARTNESS
- Good testers are really smart people and know how to exploit the application.
- Their intelligence is at par with the programmers.

7. NOTICING THINGS
- Good testers tend to notice those minute and little things that do not come to the notice of the other people.
- They keep a sharp eye on the behavior of the program.
- Even a little unusual happening can be an indication of a bug or error.

8. HANDLING CHAOS
- Obviously when a team comprising of people at different designations there will be a lot of chaos.
- Handling such chaos depends on the individual character.
- A good tester is expected to have good tolerance capacity or we can say he/ she should have patience.

9. HANDLING CRITICISM
- Testers have to suffer a lot of criticism from the programmers.
- A tester having good sense of humor can easily get through such a trap.

10. TENACITY
- Another social skill called tenacity is found in good testers.
- Tenacity is the ability of an individual to compromise with the opinions of the others.
- A good tester knows how to socially smart and is a good diplomat.

11. KEEPING TRACK
- A good tester keeps a track of his testing.
- He/ she keeps his observations organized.

12. SKEPTICAL NATURE
- A good tester is a bit skeptical.
- He/ she do not takes anything for granted and questions every thing suspicious for bugs and errors.

13. TOUGH
- A good tester is tough since he/ she has to suffer a lot of criticism and questions of the programmers.

14. SEARCHING NEW WAYS
- They are always searching for new ways of testing an application.
- They are technology hungry. Testing is quite a laborious task.

15. HONESTY
- Finally a good tester is honest with his duty and doesn’t follow any corruption.

What is meant by code coverage? What are different types of code coverage?

- Code coverage can be defined as a measure to measure the extent to which the source code of a software system has been tested.
- Code coverage is categorized under white box testing techniques since the inspection of the code is carried out directly.
- Code coverage methodology was initially developed for systematic testing of software system. It was developed by two researchers:Miller and Maloney in year of 1963.
- Code coverage is regarded as one of the important considerations concerning the safety certification in the field of avionics equipment.
- Code coverage is not centralized on one idea. There are several different criteria or types to choose from. The criteria or type is chosen as per the requirement of the extent of testing. At a time one or more coverage criteria (types) can be used.

Different Coverage types have been discussed in details below:

Basic coverage type:
This category again has following criteria:
- Statement coverage: It determines whether or not each node in the program has been executed.
- Function coverage: It determines whether or not each function or sub routine in the program has been called.
- Decision coverage: It determines whether or not each edge in the program has been executed and it also ensures that requirements of every branch have been met.
- Predicate coverage: It is also known as condition coverage. It determines whether or each and every Boolean expression in the program has been evaluated to either true value or false value.
- Predicate/ decision coverage: It is combination of both predicate and decision coverage and determines whether or not both the types of coverage are satisfied. Fault injection technique becomes necessary here. It is done to ensure each and every part of the software system has got sufficient coverage.

Modified predicate/ decision coverage: It is usually abbreviated as MC/ DC. Some applications like avionics software applications are safety critical and they require satisfying the modified form of predicate/decisions coverage. The modification here is that each and every individual criterion for condition and decision should have a distinct affect on the outcome and it should be separately visible.

Multiple condition coverage: \
As the name suggests, this type of coverage has two or more conditions. The group of conditions is then tested. Multiple condition coverage determines whether or not all the combinations of the conditions in each decision are tested.

The above mentioned 3 code coverage types are frequently and mostly used coverage types. There are other types which are not so in use. They have also been discussed below:
- JJ path coverage:
It determines whether all the jump to jump kind of paths has been executed.
- Linear code sequence and jump coverage: It determines whether or not all LCSAJs have been executed.
- Entry coverage:
It determines whether or not every possible call has been executed.
- Exit coverage:
It determines whether or not every possible return of the functions has been executed.
- Path coverage:
It determines whether or not every possible path through a given unit has been executed.
- Loop coverage:
It determines whether or not all the loops have been executed.

Testing often achieves 100 percent of code coverage. This is verified through safety critical applications. Attaining full one kind of coverage is practically impossible. Most parts in a program are such that they cannot be accessed easily and therefore remain void of code coverage.There are certain things that are needed to be considered while implementing a code coverage type:

- Requirements of the code coverage for the certification of the finished product.
- Level of code coverage required.
- Testing of code coverage against the tests to verify the requirements.
- Direct generation of object code.

The Make/Buy Decision - Decision Trees and Outsourcing

Software engineering managers face the make or buy decision. The make/buy decision is based on following conditions during the final analysis. These conditions include:
- Whether the software product is available sooner than the internally developed software?
- Whether cost acquisition + customization < cost of software development internally?
- Whether outside support cost < internal support cost?

Decision Tree
Suppose X is the decision tree of a software based system. Three cases derive:
- building X from scratch.
- reusing the existing components to construct X.
- buy software from market and make the necessary changes.
- get a vendor and and hand him the software development.

If X is built from scratch, chances are 70% that job is difficult. In a decision tree, different paths are taken and the projected costs for reuse, buy and contract are evaluated. Based on the output, the probability and projected cost is the lowest when we buy the software from the market.

during the decision making process, there are many criteria to be considered and not just the cost. Factors like availability, experience of developer/vendor/contractor, local politics, conformance to requirements and likelihood of change can affect the final decision to build, buy or contract.

Outsourcing
Outsourcing decision is basically a financial one. The way in which the software and systems that we need at lower price is outsourcing. It is a simple concept. All the engineering activities are handed over to the third party who is responsible to complete the work at low cost and most probably good quality.

At strategic level, decision of outsourcing is based on the fact whether a significant portion of all software work can be contracted to others. At tactical level, decision of outsourcing is based on the fact whether a part or all of a project can be accomplished by sub-contracting the software work.

Advantage of outsourcing:
Cost savings are achieved by reducing number of people and facilities that support them.

Disadvantage of outsourcing:
The company loses some control over the software that it needs.

What makes a good Software Test Engineer, SQA Engineer, Test Manager?

A good software test engineer has the following qualities:
- a software engineer should focus on having a high quality product.
- a software engineer should understand customer's needs and requirements.
- a software engineer should maintain a tactful and diplomatic relationship with developers.
- a software engineer should maintain a good relationship with non technical people.
- a software engineer should be able to have a judgment skill when needed.

A good Software Quality Assurance engineer has the following qualities:
- a software quality assurance engineer should focus on having a high quality product.
- a software quality assurance engineer should understand customer's needs and requirements.
- a software quality assurance engineer should maintain a tactful and diplomatic relationship with developers.
- a software quality assurance engineer should maintain a good relationship with non technical people.
- a software quality assurance engineer should be able to have a judgment skill when needed.
- a software quality assurance engineer should have a proper understanding of software development life cycle.
- a software quality assurance engineer should understand business approach and goals.
- a software quality assurance engineer should have good communications skills.
- a software quality assurance engineer should be able to find problem areas.

A good QA/Test Manager has the following properties
- he should have a good understanding of software development life cycle.
- he should have a good and healthy relation with the technical and non technical people.
- he should be able to increase his team's productivity and efficiency.
- he should be able to create enthusiasm about work among team members.
- he should be able to make correct and quick decisions.
- he should be good at handling pressure.
- he should have diplomatic skills.

How to design conventional components - Graphical Design Notation and Tabular Design Notation

There were some logical constructs developed from which any program could be formed. Each construct has a logical structure. The constructs are sequence, condition, and repetition.
- Sequence implements processing the steps that are essential in the specification of any algorithm.
- Condition provides the facility for selected processing based on some logical occurrence.
- Repetition allows for looping.
Structured programming is a design technique that constrains logic flow to three constructs: sequence, condition and repetition. The structured constructs were supposed to limit the procedural design of software to a small number of predictable operations.

GRAPHICAL DESIGN NOTATION
Activity diagram allows a designer to represent sequence,condition and repetition. Flowchart, like an activity diagram, is quite simple pictorially.
The dogmatic use of only structured constructs can introduce inefficiency when an escape from a set of nested loops or nested conditions is required. Additional complication of all logical tests along the path of escape can hinder the control flow, increase the possibility of error and have a negative impact.
There are two options:
- procedural representation is redesigned so that escape branch is not required at a nested location.
- structured constructs are violated in a controlled manner; that is , a constrained branch out of the nested flow is redesigned.

TABULAR DESIGN NOTATION
Decision tables translates actions and conditions in a tabular form. It is difficult to misinterpret. A decision table is divided into quadrants:
- Upper left quadrant: contains a list of all conditions.
- Lower left quadrant: contains a list of all actions that are possible based on combinations of conditions.
- Right hand quadrant: a matrix that indicates condition combinations and corresponding actions. Each column of matrix may be interpreted as a processing rule.

-