Boundary Value Analysis ( BVA) Testing

Boundary value analysis is the method of making sure that behaviour of system is certain for the input and output boundary conditions. the reason why boundary conditions are necessary for testing is because defects could be inserted at the boundaries very easily.

let us see this following example :
Input should be greater than equal to 5 and less than 10
Probably you will write something like
if (input >=5 AND input <10)>
then
do this
else
do some thing else.

So, according to this input values from 5 to 9 are valid, but if you make mistake in specifying the conditions, following things can happen
input >5 AND input <10-------> Input value 10 in invalid now
input <=5 AND input <10> Input value 4 is valid now
input >=5 AND input <=10 -----> Input value 10 is valid now
input >=5 AND input >10 -----> Input value 9 is invalid now

Because it is very easy to introduce defects at boundaries, boundary values are important. So for the above example, at the minimum we should have following test cases for boundaries
4,5,6 and 8, 9, 10
lower_boundary - 1, lower_boundary, lower_boundary + 1 and upper_boundary - 1, upper_boundary, upper_boundary + 1.

what is off-by-one
off-by-one: An exceedingly common error induced in many ways, such as by starting at zero when you should have started at one or vice-versa.

Related Topics:

Unit Testing

The aim of Unit Testing is to take a small piece of software from the application, isolate it from the reminder of the code and check whether it works exactly as you expect. like wise each unit is testing in this manner seperately before intergrating them into modules to test into interfaces between modules, and most of the defects are identified during this unit test.

Unit testing requires drivers and stubs to be written, here the driver simulates a calling unit and the stub simulates a called unit. though the Driver and Stub costs time and money, unit testing provides some unquestionable advantages, this allows automation of testing process, reduces troubles of exploring errors contained in more complex pieces of the application, test coverage is often raised because attention is given to each unit.

Example: if we have 3 units, lets see how to check it..

• check is the error due to unit1
• check is the error due to unit2
• check is the error due to unit3
• check weather it is because of the problem with 3 units
• check is the error due to interfaces between units
• it might be due to defect in the process of testing

Identifying the error (or errors) in the integrated module is much more complicated than first insulating the units, testing each module and integrating them as an integrated unit and testing thee whole system.

Driver and Stub can be reused to reduce the time and cost instead of writing large amount of code.

Related Topics:

Code Coverage?

Code Coverage - which indicates to measure the quality of code in a software, this degree describes the degree to which the source code of a program has been tested, Code Coverage is a form of testing that inspects the code directly and is therefore a form of white box testing. now the the use of code coverage is extended to the field of digital hardware, the contemporary design method of which relies on Hardware Languages.

To know the metric level of this method, we need to know what are the coverage criteria that need to be exercised, there are few important criteria's that i mentioned below:

• Function Coverage - Here needs checking of each function in the program been executed
• Statement Coverage - To check each line of code is been executed
• Decision Coverage - To check each control structure evaluated both to true or false
• Condition Coverage - To check each Boolean sub-expression evaluated both to true and false
• Path Coverage - to check weather every possible route through, a given part of code been executed
• Entry/Exit Coverage - To check weather every possible call and return of the function been executed

safety critical applications are often required to demonstrate that testing achieves 100% of some form of code coverage.

Related Topics:

• mutation testing
• Inspection
• static testing
• function point
• Peer Review

Function Points

A function point is a unit of measurement to express the amount of business functionality an information system provides to a user.

Function Point Analysis:

The method of measuring the size of an information system and expressing it in a number of function points is called function point analysis (FPA). A function point analysis expresses the functional size of an information system in a number of function points (for example: the size of a system is 314 FPs). There are many uses and benefits of function points & the functional size may be used as input into many projects and organization decisions, some of the aspects are shown below:

• budget for application development or enhancement costs.
• budget for the annual maintenance costs of the application portfolio.
• project productivity after completion of the project.
• size of the software for cost estimation.

Criticism of Function Points:

Function points have been criticized as adding little value relative to the cost and complexity of the effort, the effect on this is very marginal error reduction. because much of the variance in software cost estimates are not considered like business changes, scope changes, unplanned resource constraints or reprioritizations, and there may be many more reasons. Also, if the measurement is used for the decision of whether to invest in the software, then a given measurement effort, it is argued, is more valuable if it is applied to measure benefits than costs

Related Topics:

• mutation testing
• Inspection
• static testing
• fault injection
• code coverage

Fault, Fault Tolerance, Fault Injection Method

Fault - An incorrect step, process, or data definition in a program is called a fault.

Fault Tolerance - The capability of the software product to maintain a specified level of performance in cases of software faults (defects) or of infringement of its specified interface.

Fault Injection - The process of intentionally incorporating errors in code in order to measure the ability of the tester or processes to detect such errors is called fault Injection.

Related Topics:

• mutation testing
• Inspection
• static testing
• function points
• code coverage

What is Mutation Testing?

Mutation Testing is a powerful method for finding errors in software programs. It was introduced as a way of measuring the accuracy of test suites. Generally, there is no easy way to tell if the test suite completely tests the program or not. If the program passes the test suite, one may say that program works correctly on all the cases that are included in the test suite. The more cases a test suite contains, the higher the probability that the program will work correctly in the real world. However, there is no method to measure how accurate the test suite is and the probability that the program will work correctly.

In mutation testing, one is in some sense trying to solve this problem by inverting the scenario. The thinking goes as follows:

Let’s assume that we have a perfect test suite, one that covers all possible cases. Let’s also assume that we have a perfect program that passes this test suite. If we change the code of the program (this process is called mutating) and we run the mutated program (mutant) against the test suite, we will have two possible scenarios:

• The results of the program were affected by the code change and the test suite detects it. We assumed that the test suite is perfect, which means that it must detect the change. If this happens, the mutant is called a killed mutant.
• The results of the program are not changed and the test suite does not detect the mutation. The mutant is called an equivalent mutant.

If we take the ratio of killed mutants to all the mutants that were created, we get a number that is smaller than 1; this number measures how sensitive the program is to the code changes.

we got another scenario when in the case of not having perfect program and perfect test case suite, the below scenario will be raised.

• The results of the program are different, but the test suite does not detect it because it does not have the right test case.

If we take the ratio of all the killed mutants to all the mutants generated, we get a number smaller than 1 that also contains information about accuracy of the test suite.

Benefits of Mutation Testing:

• Automatic mutation testing brings a new level of error-detection to the software developer.
• Tools that automate mutation testing are able to uncover ambiguities in code previously thought impossible to detect automatically.
• By using tools that incorporate mutation testing into state-of-the-art error-detection technology, developers are able to flush out more faults than with any other technology.
• Software developers and testers using tools that incorporate this approach to mutation testing will benefit enormously, as such tools automatically uncover more bugs than any other technology.
• The customer also benefits from mutation testing, as the program a user receives is less buggy and more reliable. This increased confidence will in turn benefit your company where it matters most- the bottom line.

Related Topics:

• static testing
• black box testing
• Types of Performance Testing
• Dynamic Testing
• white box testing

White box Testing

White box Testing is just opposite to Black box Testing, when the tester has access to the internal data structures and algorithms.

Now let us know how many types of white box testing are there:

Code coverage - creating tests to satisfy some criteria of code coverage. the test designer can create tests to cause all statements in the program to be executed atleast once.

Mutation testing methods.

Fault injection methods.

Static Testing - white box testing include all static testing.

Code completeness evaluation

White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested.

Two common forms of code coverage are:

• function coverage which reports on functions executed
• statement coverage which reports on the number of lines executed to complete the test.

They both return a coverage metric, measured as a percentage.

Related Topics:

• mutation testing
• Inspection
• static testing
• function points
• code coverage

Peer Review

Peer Reviews are considered an industry best-practice for detecting software defects early and learning about software. It is been taken with reference to walkthroughs and inspections made on the work product and are integral to software activities. A collection of collective knowledge, skills, and behaviors facilitates the best possible practice of Peer Reviews. The elements of Peer Reviews include the structured review process, standard of excellence product check-lists, defined roles of participants, and the forms and reports.
Software inspections plays most rigorous form of Peer Reviews and fully utilize these elements in detecting defects. Software walkthroughs draw selectively upon the elements in assisting the producer to obtain the deepest understanding of an architecture and reaching a consensus among participants. Measured results reveal that Peer Reviews produce an attractive return on investment obtained through accelerated learning and early defect detection. For best results, Peer Reviews are rolled out within an organization through a defined program of preparing a policy and procedure, training practitioners and managers, defining measurements and populating a database structure, and sustaining the roll out infrastructure.

Related Topics:

• Inspection
• walkthroughs
• Reviews

Inspection

Inspection in softare Testing refers to peer review of any work product by trained individuals who search for defects using a well defined process. lets us see this Inspection in detail...

Goal of Inspection: it is to satisfy all of its inspectors to reach consensus on that work product and approve it to be used in the project. a product is selected for review and a team will gather for reviewing that particular products, a moderator is choosen to moderate the meeting, and the participant first read and prepare with the work products to raise the defects that come in the work flow as it is the main goal to identify the defects this meeting is conducted.

The process will be in this manner:

• Planning: The inspection is planned by the moderator.
• Overview meeting: The author describes the background of the work product.
• Preparation: Each inspector examines the work product to identify possible defects.
• Inspection meeting: During this meeting the reader reads through the work product, part by part and the inspectors point out the defects for every part.
• Rework: The author makes changes to the work product according to the action plans from the inspection meeting.
• Follow-up: The changes by the author are checked to make sure everything is correct.

The process is ended by the moderator when it satisfies some predefined exit criteria.

Related Topics:

• mutation testing
• Fault injection
• static testing
• function points
• Fault Tolerance

Black Box Testing

Black box testing takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid input and determines the correct output. There is no knowledge of the test object's internal structure.
The design is applicable to all levels of software testing: unit, integration, functional testing, system testing and acceptance testing. the higher the level, and hence the bigger and more complex the box, while this procedure is used remove the cover of all the unimplemented parts of the specification, one cannot be sure that all the existing paths are completely tested.

Related Topics:

• Boundary Value Analysis ( BVA Testing )
• White Box Testing
• Sanity Testing
• Smoke Testing
• Stress Testing

Verification and Validation

Verification & Validation is the process of checking that a software system meets specification and fulfils its intended purpose, it is the process of software testing in the project., this is also called as V&V Model.

Verification: to determine if the process that was followed to develop the final product is right.

Validation: if the product is built according to the requirements of the user. Other methods, such as reviews, when used early in the Software Development Life Cycle provide for validation.

Verification can be called as a part of validation process.

Related Topics:

• Walkthroughs
• static Vs dynamic Tesing
• staitc Tesing
• dynamic tesing

Dynamic Testing

Dynamic Testing is the the term used in software engineering to describe the testing of the dynamic behaviour of the code at different situations. In dynamic testing the software must actually be compiled and Run, and it in real involves working with the software, giving input valves and checking whether the output is as expected, these are called the validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the dynamic Testing methodologies, dynamic testing means testing based on a specifi test cases by execution of the running programs.

Dynamic testing is used to test software through executing it, it is almost similar to static testing.

Related Topics:

• Static Testing

Static Testing

Static Testing is a type of software testing where the software is not actually used, this is in contrast to Dynamic Testing. It is genrally not detailed testing, but it checks mainly for the sanity of the code, algorithm or document. it is primarily systax checking of the code and manually reading of the code or document to find errors. This type of testing can be used by the developer who has written the code, in isolation. here Code Reviews, inspections and walkthroughs are also used.

when we think from black box tesing point, Static tesing involves review of requirements and specifications. this is done with an eye toward completeness for the task at hand, this is actually the verification portion of verification and validation.

Even Static Testing Can be automated, as this suite consists in programs to be analized by an interpreter/compiler that asserts the programs syntactic validity. Bugs discovered at this stage of development are less expensive to fix then in the later development cycle.

Related Topics:

• Black Box Testing
• Identifying Performance Acceptance Criteria
• Types of Performacne Testing
• Why software performance Testing Required
• Plan and Design Test
• Code Review
• Dynamic Testing

Reverse Walkthrough

Reverse Walkthrough: when the consumer of the product takes the author through it, then we can call it as Reverse walkthrough.

A reverse walkthrough is a confirmation that the consumers of a technical product have the same understanding as the author of that product. The authors ask questions about the content to confirm that the consumer has understood it. this is common in software engineering for software reviews or business process reviews when the developer reads the source/usecase/process back to the author.

The reverse walkthrough should be made when the consumers of the technical product have reviewed it and there is a risk that their understanding may not be reflective of the original intent.

Objectives & Participants:

A Reverse walkthrough is meant to confirm a common understanding about the content from consumers of a technical product.

Related Topics:

• Walkthrough

Walkthroughs

In Software Engineering, a walkthrough is some thing like a software peer review, in which a designer or programmer leads members of the development team and other interested parties through a software product and the members keep asking questions and making comments about possible errors, voilation of development standards and other problems.

A Walkthrough differ from software technical reviews in its openness of model and its objective of familiarization, it differs from software inspection in its ability to suggest direct alterations to the product reviewed, it lacks of a direct focus on training and process improvement and its removal of process and product measurement.

Objectives and Participants:
The main objctive of this Walkthroughs is to gain feed back about the technical quality/content of the document.
To familiarize the audiance with the content
This Walkthrough is organized by Author of the Technical document.

Related Topics:

• Reverse Walkthrough

Code Review

Code Review can often find and remove vulnarablilities such as format string exploits, race conditions, memory leaks and buffer over flows, there by improving software security.
types of Code Reviews:

• Code review practices often fall into two main categories: formal code review and lightweight code review.
• Code review practices often fall into two main categories: formal code review and lightweight code review like Fagon Inspection involves a careful and detailed process with multiple participants and multiple phases. Formal code reviews are the older, traditional method of review, in which developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review. However, some criticize formal reviews as taking too long to be practical.
• Lightweight code review typically requires less overhead than formal code inspections, though it can be equally effective when done properly, Lightweight reviews are often conducted as part of the normal development process:

1. Over-the-shoulder: One developer looks over the author's shoulder as the latter walks through the code.
2. Email pass-around: Source code management system emails code to reviewers automatically after checkin is made.
3. Pair Programming: here Two authors develop code together at the same workstation, such as is common in Extreme Programming.
4. Tool-assisted code review: Authors and reviewers use specialized tools designed for peer code review. Programmers often find tool-assisted code review to be less tedious and more efficient than some other methods

Criticism:

Some argue that code review is less important when certain rules or secure coding methodologies are followed from the software's inception, the Extreme programming approach includes the practice of pair programming, which can be argued to be code review during development. Extreme Programming proponents argue that other Extreme Programming practices, such as refactoring and creating tests before even writing the code, produces code that doesn't need to be reviewed or rewritten as often and thus speeds software development.

Related Topics:

• Walkthroughs
• static Vs dynamic Tesing
• staitc Tesing
• dynamic tesing

Static Vs Dynamic Tesing?

Static Vs Dynamic Testing

There are many approaches to software testing, Riviews, walkthroughts or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. The former can be, and unfortunately in practice often is, omitted, whereas the latter takes place when programs begin to be used for the first time - which is normally considered the beginning of the testing stage. This may actually begin before the program is 100% complete in order to test particular sections of code (modules or discrete functions).

Eg: Spreadsheet programs are, by their very nature, tested to a large extent on the fly during the build process as the result of some calculation or text manipulation is shown interactively immediately after each formula is entered.

Related Topics:

• Identifying Performance Acceptance Criteria
• Types of Performacne Testing
• Why software performance Testing Required
• Plan and Design Test
• Code Review

common problems that occur during software development

what are the common problems that occur during software development

Poorly Written Requirements: Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems.
Unrealistic Schedules: The schedule is unrealistic if too much work is crammed in too little time.
Inadequate Testing: Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes.
Adding New Features while development is underway: It's extremely common that new features are added after development is underway.
Poor Communication: Miscommunication either means the developers don't know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed.

Related Topics:

• Identifying Performance Acceptance Criteria
• Types of Performacne Testing
• Why software performance Testing Required
• Plan and Design Test
• Quality Software

Quality Software

What is Quality Software.

Quality software is software that is reasonably bug-free, delivered on time, with in budget, meets requirements and expectations and is maintainable. However, Quality is a subjective term.
Quality depends on who the customer is and their overall influence in the scheme of things.

Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organization's management, test engineers, testers, salespeople, software engineers, stockholders and accountants.
Eg: Every customer will have his or her own slant on quality. The Finance department might define quality in terms of profits, where as the end-user might define quality as user friendly and bug free.

Related Topics:

• Identifying Performance Acceptance Criteria
• Types of Performacne Testing
• Why software performance Testing Required
• Plan and Design Test