Error guessing in software testing

·          The Error guessing is a technique where the experienced and good testers are encouraged to think of situations in which the software may not be able to cope. Some people seem to be naturally good at testing and others are good testers because they have a lot of experience either as a tester or working with a particular system and so are able to find out its weaknesses. This is why an error guessing approach, used after more formal techniques have been applied to some extent, can be very effective. It also saves a lot of time because of the assumptions and guessing made by the experienced testers to find out the defects which otherwise won’t be able to find.

·          The success of error guessing is very much dependent on the skill of the tester, as good testers know where the defects are most likely to be.

·          This is why an error guessing approach, used after more formal techniques have been applied to some extent, can be very effective. In using more formal techniques, the tester is likely to gain a better understanding of the system, what it does and how it works. With this better understanding, he or she is likely to be better at guessing ways in which the system may not work properly.

·          Typical conditions to try include division by zero, blank (or no) input, empty files and the wrong kind of data (e.g. alphabetic characters where numeric are required). If anyone ever says of a system or the environment in which it is to operate ‘That could never happen’, it might be a good idea to test that condition, as such assumptions about what will and will not happen in the live environment are often the cause of failures.

·          A structured approach to the error-guessing technique is to list possible defects or failures and to design tests that attempt to produce them. These defect and failure lists can be built based on the tester’s own experience or that of other people, available defect and failure data, and from common knowledge about why software fails.

 

Read More

Error guessing in software testing

·          The Error guessing is a technique where the experienced and good testers are encouraged to think of situations in which the software may not be able to cope. Some people seem to be naturally good at testing and others are good testers because they have a lot of experience either as a tester or working with a particular system and so are able to find out its weaknesses. This is why an error guessing approach, used after more formal techniques have been applied to some extent, can be very effective. It also saves a lot of time because of the assumptions and guessing made by the experienced testers to find out the defects which otherwise won’t be able to find.

·          The success of error guessing is very much dependent on the skill of the tester, as good testers know where the defects are most likely to be.

·          This is why an error guessing approach, used after more formal techniques have been applied to some extent, can be very effective. In using more formal techniques, the tester is likely to gain a better understanding of the system, what it does and how it works. With this better understanding, he or she is likely to be better at guessing ways in which the system may not work properly.

·          Typical conditions to try include division by zero, blank (or no) input, empty files and the wrong kind of data (e.g. alphabetic characters where numeric are required). If anyone ever says of a system or the environment in which it is to operate ‘That could never happen’, it might be a good idea to test that condition, as such assumptions about what will and will not happen in the live environment are often the cause of failures.

·          A structured approach to the error-guessing technique is to list possible defects or failures and to design tests that attempt to produce them. These defect and failure lists can be built based on the tester’s own experience or that of other people, available defect and failure data, and from common knowledge about why software fails.

 

Read More

Use case testing in software testing

·          Use case testing is a technique that helps us identify test cases that exercise the whole system on a transaction by transaction basis from start to finish. They are described by Ivar Jacobson in his book Object-Oriented Software Engineering: A Use Case Driven Approach[Jacobson, 1992].

·          A use case is a description of a particular use of the system by an actor (a user of the system). Each use case describes the interactions the actor has with the system in order to achieve a specific task (or, at least, produce something of value to the user).

·          Actors are generally people but they may also be other systems.

·          Use cases are a sequence of steps that describe the interactions between the actor and the system. Use cases are defined in terms of the actor, not the system, describing what the actor does and what the actor sees rather than what inputs the system expects and what the system’s outputs.

·          They often use the language and terms of the business rather than technical terms, especially when the actor is a business user.

·          They serve as the foundation for developing test cases mostly at the system and acceptance testing levels.

·          Use cases can uncover integration defects, that is, defects caused by the incorrect interaction between different components. Used in this way, the actor may be something that the system interfaces to such as a communication link or sub-system.

·          Use cases describe the process flows through a system based on its most likely use. This makes the test cases derived from use cases particularly good for finding defects in the real-world use of the system (i.e. the defects that the users are most likely to come across when first using the system).

·          Each use case usually has a mainstream (or most likely) scenario and sometimes additional alternative branches (covering, for example, special cases or exceptional conditions).

·          Each use case must specify any preconditions that need to be met for the use case to work.

·          Use cases must also specify post conditions that are observable results and a description of the final state of the system after the use case has been executed successfully.

·          The ATM PIN example is shown below in Figure 4.3. We show successful and unsuccessful scenarios. In this diagram we can see the interactions between the A (actor – in this case it is a human being) and S (system). From step 1 to step 5 that is success scenario it shows that the card and pin both got validated and allows Actor to access the account. But in extensions there can be three other cases that are 2a, 4a, 4b which is shown in the diagram below.

·          For use case testing, we would have a test of the success scenario and one testing for each extension. In this example, we may give extension 4b a higher priority than 4a from a security point of view.

·          System requirements can also be specified as a set of use cases. This approach can make it easier to involve the users in the requirements gathering and definition process.

Read More

Traceability in Software testing

            Test conditions should be able to be linked back to their sources in the test basis, this is known as             traceability. Traceability can be horizontal through all the test documentation for a given test level (e.g. system             testing, from test conditions through test cases to test scripts) or it can be vertical through the layers of        development documentation (e.g. from requirements to components).

            Now, the question may arise is that Why is traceability important?  So, let’s have a look on the following       examples:

·          The requirements for a given function or feature have changed. Some of the fields now have different ranges that can be entered. Which tests were looking at those boundaries? They now need to be changed. How many tests will actually be affected by this change in the requirements? These questions can be answered easily if the requirements can easily be traced to the tests.

·          A set of tests that has run OK in the past has now started creating serious problems. What functionality do these tests actually exercise? Traceability between the tests and the requirement being tested enables the functions or features affected to be identified more easily.

            Before delivering a new release, we want to know whether or not we have tested all of the specified                                     requirements in the requirements specification. We have the list of the tests that have passed – was

            every requirement tested?

Read More

Types of reviews

 Types of review

            The main review types that come under the static testing are mentioned below:

    Walkthrough:

·          It is not a formal process

·          It is led by the authors

·          Author guide the participants through the document according to his or her thought process to achieve a common understanding and to gather feedback.

·          Useful for the people if they are not from the software discipline, who are not used to or cannot easily understand software development process.

·          Is especially useful for higher level documents like requirementspecification, etc.

The goals of a walkthrough:

·          To present the documents both within and outside the software discipline in order to gather the information regarding the topic under documentation.

·          To explain or do the knowledge transfer and evaluate the contents of the document

·          To achieve a common understanding and to gather feedback.

·          To examine and discuss the validity of the proposed solutions

Technical review:

·          It is less formal review

·          It is led by the trained moderator but can also be led by a technical expert

·          It is often performed as a peer review without management  participation

·          Defects are found by the experts (such as architects, designers, key users) who focus on the content of the document.

·          In practice, technical reviews vary from quite informal to very formal

The goals of the technical review are:

·          To ensure that an early stage the technical concepts are used correctly

·          To access the value of technical concepts and alternatives in the product

·          To have consistency in the use and representation of technical concepts

·          To inform participants about the technical content of the document

Inspection:

·          It is the most formal review type

·          It is led by the trained moderators

·          During inspection the documents are prepared and checked thoroughly by the reviewers before the meeting

·          It involves peers to examine the product

·          A separate preparation is carried out during which the product is examined and the defects are found

·          The defects found are documented in a logging list or issue log

·          A formal follow-up is carried out by the moderator applying exit criteria

Read More

Types of reviews

 Types of review

            The main review types that come under the static testing are mentioned below:

    Walkthrough:

·          It is not a formal process

·          It is led by the authors

·          Author guide the participants through the document according to his or her thought process to achieve a common understanding and to gather feedback.

·          Useful for the people if they are not from the software discipline, who are not used to or cannot easily understand software development process.

·          Is especially useful for higher level documents like requirementspecification, etc.

The goals of a walkthrough:

·          To present the documents both within and outside the software discipline in order to gather the information regarding the topic under documentation.

·          To explain or do the knowledge transfer and evaluate the contents of the document

·          To achieve a common understanding and to gather feedback.

·          To examine and discuss the validity of the proposed solutions

Technical review:

·          It is less formal review

·          It is led by the trained moderator but can also be led by a technical expert

·          It is often performed as a peer review without management  participation

·          Defects are found by the experts (such as architects, designers, key users) who focus on the content of the document.

·          In practice, technical reviews vary from quite informal to very formal

The goals of the technical review are:

·          To ensure that an early stage the technical concepts are used correctly

·          To access the value of technical concepts and alternatives in the product

·          To have consistency in the use and representation of technical concepts

·          To inform participants about the technical content of the document

Inspection:

·          It is the most formal review type

·          It is led by the trained moderators

·          During inspection the documents are prepared and checked thoroughly by the reviewers before the meeting

·          It involves peers to examine the product

·          A separate preparation is carried out during which the product is examined and the defects are found

·          The defects found are documented in a logging list or issue log

·          A formal follow-up is carried out by the moderator applying exit criteria

Read More

Regression testing

            During confirmation testing the defect got fixed and that part of the application started working as intended. But             there might be a possibility that the fix may have introduced or uncovered a different defect elsewhere in the             software. The way to detect these ‘unexpected side-effects’ of fixes is to do regression testing. The purpose of a             regression testing is to verify that modifications in the software or the environment have not caused any             unintended adverse side effects and that the system still meets its requirements. Regression testing are mostly             automated because in order to fix the defect the same test is carried out again and again and it will be very tedious to do it manually. Regression tests are executed whenever the software changes, either as a result of       fixes or new or changed functionality.

Read More