Module 4

Introduction
• Software testing is the process of executing a program with the aim of finding the error.
• To make our software perform well it should be error-free.
• If testing is done successfully it will remove all the errors from the software.
• Software Testing is a process of evaluation of the software on the requirements gathered from
system specifications and users.
• Software Testing is done at the every phase level in software development life cycle(SDLC).
• Even a seemingly simple program can have hundreds or thousands of possible input and output
combinations.
• Creating test cases for all of these possibilities is impractical.
• Complete testing of a complex application would take too long and require too many human
resources to be economically feasible.
• When you test a program, you want to add some value to it.
• Adding value through testing means raising the quality or reliability of the program.
• Raising the reliability of the program means finding and removing errors.
• Testing is the process of executing a program with the intent of finding errors.
• To combat the challenges associated with testing economics, you should establish some strategies
before beginning.
• Two of the most prevalent strategies include black-box testing and white-box testing.

Black-box testing
• Black-box testing is a type of software testing in which the tester is not concerned with the internal
knowledge or implementation details of the software, but rather focuses on validating the functionality
based on the provided specifications or requirements.
• If you want to use this approach to find all errors in the program, the criterion is exhaustive input
testing, making use of every possible input condition as a test case.
• Exhaustive input testing is impossible.
• Two important implications of this:
(1) You cannot test a program to guarantee that it is error free; and
(2) a fundamental consideration in program testing is one of economics.
• Black box testing can be done in the following ways:
Equivalence Class Partitioning (ECP)

• which is also known as Equivalence Class Partitioning (ECP) and Equivalence Partitioning, is an
important software testing technique used by the team of testers for grouping and partitioning of the
test input data, which is then used for the purpose of testing the software product into a number of
different classes.

• It is a black-box testing technique used in software testing as a major step in the Software
development life cycle (SDLC). It is a logical step in the model of functional testing.

• This testing technique is better than many of the testing techniques like boundary value analysis,
worst case testing, robust case testing and many more in terms of time consumption and terms of
precision of the test cases.
• Since testing is done to identify possible risks, equivalence class testing performs better than the
other techniques as the test cases generated using it are logically identified with partitions in between
to create different input and output classes.
• Equivalence class testing improves the quality of test cases by removing redundancy and gaps that
appear in the boundary value testing.
Examples of Equivalence Partitioning technique

• Assume that there is a function of a software application that accepts a particular number of digits, not greater and less than
that particular number. For example, an OTP number which contains only six digits, less or more than six digits will not be
accepted, and the application will redirect the user to the error page.

1. OTP Number = 6 digits

Advantages and disadvantages of Equivalence Partitioning technique

Advantages Disadvantages

It is process-oriented All necessary inputs may not cover.

We can achieve the Minimum test coverage This technique will not consider the condition for boundary value
analysis.

It helps to decrease the general test execution time and also reduce The test engineer might assume that the output for all data set is right,
the set of test data. which leads to the problem during the testing process.
Boundary value testing
 It is based on testing the boundary values of valid and invalid partitions.
 A boundary value for a valid partition is a valid boundary value.
 A boundary value for an invalid partition is an invalid boundary value.
 For each variable we check-
 Minimum value.
 Just above the minimum.
 Nominal Value.
 Just below Max value.
 Max value.

 It checks for the input values near the boundary that have a higher chance of error.
 Every partition has its maximum and minimum values and these maximum and minimum values
are the boundary values of a partition.
Example: Consider a system that accepts ages from 18 to 56.

Boundary Value Analysis(Age accepts 18 to 56)

Valid
Invalid Invalid
(min, min + 1, nominal, max
(min-1) (max + 1)
– 1, max)

17 18, 19, 37, 55, 56 57

Decision Table Testing
• It is a software testing technique used to test system behavior for different input combinations.
• This is a systematic approach where the different input combinations and their corresponding system
behavior (Output) are captured in a tabular form.
• It is also called as a Cause-Effect table where Cause and effects are captured for better test coverage.
• A decision table helps to check all possible combinations of conditions for testing and testers can also
identify missed conditions easily.
• The conditions are indicated as True(T) and False(F) values.
• Example : How to make Decision Base Table for Login Screen
• Let’s create a decision table for a login screen.
• The condition is simple if the user provides the • Case 3 – Username was wrong, but the password
correct username and password the user will be was correct. The user is shown an error message.
redirected to the homepage. If any of the input • Case 4 – Username and password both were
is wrong, an error message will be displayed. correct, and the user navigated to the homepage
Legend:
• T – Correct username/password R
u
• F – Wrong username/password Conditio l
Rule 1 Rule 3 Rule 4
• E – Error message is displayed ns e

• H – Home screen is displayed 2

Interpretation: Userna
F T F T
me (T/F)
• Case 1 – Username and password both were
wrong. The user is shown an error message.
Passwor
• Case 2 – Username was correct, but the F F T T
d (T/F)
password was wrong. The user is shown an
error message. Output
E E E H
(E/H)
Pairwise Testing

• Pairwise Testing also known as All-pairs testing is a testing approach taken for testing the software
using combinatorial method.
• It's a method to test all the possible discrete combinations of the parameters involved.
Example:
• An application with simple list box with 10 elements (Let's say 0,1,2,3,4,5,6,7,8,9) along with a
checkbox, radio button, Text Box and OK Button. The Constraint for the Text box is it can accept
values only between 1 and 100. Below are the values that each one of the GUI objects can take :
• List Box - 0,1,2,3,4,5,6,7,8,9
• Check Box - Checked or Unchecked
• Radio Button - ON or OFF
• Text Box - Any Value between 1 and 100
• Exhaustive combination of the product B is calculated.
• List Box = 10

• Check Box = 2

• Radio Button = 2

• Text Box = 100

• Total Number of Test Cases using Cartesian Method : 10*2*2*100 = 4000

• Total Number of Test Cases including Negative Cases will be > 4000
• Now, we can still reduce the combination further into All-pairs technique.
• Step 1: Order the values such that one with most number of values is the first and the least is placed as the last
variable.
• Step 2: Now start filling the table column by column. List box can take 2 values.
• Step 3: The Next column under discussion would be check box. Again Check box can take 2 values.
• Step 4: Now we need to ensure that we cover all combinations between list box and Check box.
• Step 5: Now we will use the same strategy for checking the Radio Button. It can take 2 values.
• Step 6: Verify if all the pair values are covered as shown in the table below.
Advantages of Pairwise Testing: Disadvantages of Pairwise Testing:

• Pairwise testing reduces the number of • Pairwise testing is not beneficial if the
execution of test cases. values of the variables are inappropriate.
• Pairwise testing increases the test coverage • In pairwise testing it is possible to miss
almost up to hundred percentage. the highly probable combination while
• Pairwise testing increases the defect detection selecting the test data.
ratio. • In pairwise testing, defect yield ratio may
• Pairwise testing takes less time to complete be reduced if a combination is missed.
the execution of the test suite. • Pairwise testing is not useful if
• Pairwise testing reduces the overall testing combinations of variables are not
budget for a project. understood correctly.
State Transition Testing

• It is a type of software testing which is performed to check the change in the state of the application
under varying input.
• The condition of input passed is changed and the change in state is observed.
• In this type of testing, both positive and negative input values are provided and the behavior of the
system is observed.
Objectives of State Transition Testing:

• To test the behavior of the system under varying input.

• To test the dependency on the values in the past.
• To test the change in transition state of the application.
• To test the performance of the system.
• State Transition Diagram: Transition States:
State Transition Diagram shows how the state of • Change Mode:
the system changes on certain inputs. When this mode is activated then the display
It has four main components: mode moves from TIME to DATE.
1.States • Reset:
2.Transition When the display mode is TIME or DATE, then
3.Events reset mode sets them to ALTER TIME or
ALTER DATE respectively.
4.Actions
• Time Set:
When this mode is activated, display mode
changes from ALTER TIME to TIME.
• Date Set:
When this mode is activated, display mode
changes from ALTER DATE to DATE.
Advantages of State Transition Testing:
• State transition testing helps in understanding the behavior of the system.
• State transition testing gives the proper representation of the system behavior.
• State transition testing covers all the conditions.
Disadvantages of State Transition Testing:
• State transition testing can not be performed everywhere.
• State transition testing is not always reliable.
Use Case Testing
• It is a functional black box testing technique that helps testers to identify test scenarios that
exercise the whole system on each transaction basis from start to finish.
Characteristics of Use Case Testing:
• Use Cases capture the interactions between 'actors' and the 'system'.
• 'Actors' represents user and their interactions that each user takes part into.
• Test cases based on use cases and are referred as scenarios.
• Capability to identify gaps in the system which would not be found by testing individual
components in isolation.
• Very effective in defining the scope of acceptance tests.
Benefits of Use Case Testing Drawbacks of Use Case Testing
• Helps manage complexity: Use case-driven • Missing use case: If there is a use case missing
analysis that helps manage complexity since it from the use case document, then it will impact
focuses on one specific usage aspect at a time. the testing process as there is a high possibility
• Testing from the user’s perspective: Use cases that the test cases for the missing use case will
are designed from the user’s perspective. Thus, also be left out.
use case testing is done from the user’s • Cover only functional requirements: Since use
perspective and helps to uncover the issues cases cover only functional requirements so use
related to the user experience. case testing by default is functional requirements
• Reduced complexity of test cases: The oriented.
complexity of the test cases will be reduced as • Use cases are from the user’ s perspective:
the testing team will follow the path given in the 100% test coverage is not possible in cases as use
use case document. cases are written from the user’s perspective and
• Test functional requirements: Use cases help to there may be some scenarios that are not from the
capture the functional requirements of a system. user’s perspective, so then it may not be included
Thus, use case testing tests the functional in the test document.
requirements of the system.
• Starts from a simple view of the system: Use
cases start from the simple view of the system
and are used primarily for the users.
Example:
The Below example clearly shows the interaction between users and possible actions.
White box testing
• White box testing is a software testing technique that involves testing the internal structure and
workings of a software application.
• It is also called glass box testing or clear box testing or structural testing or transparent testing or
open box testing.
• White box testing is also known as structural testing or code-based testing, and it is used to test the
software’s internal logic, flow, and structure.
Working process of white box testing:
• Input: Requirements, Functional specifications, design documents, source code.
• Processing: Performing risk analysis to guide through the entire process.
• Proper test planning: Designing test cases so as to cover the entire code. Execute rinse-repeat until
error-free software is reached. Also, the results are communicated.
• Output: Preparing final report of the entire testing process.
Testing techniques: • Branch Coverage:
• Statement coverage: • In this technique, test cases are designed so
• In this technique, the aim is to traverse all that each branch from all decision points is
statements at least once. traversed at least once.
• Hence, each line of code is tested. • In a flowchart, all edges must be traversed
at least once.
• In the case of a flowchart, every node must
be traversed at least once.
• Since all lines of code are covered, helps in
pointing out faulty code.
• Condition Coverage: In this technique, all White Testing is Performed in 2 Steps:
individual conditions must be covered as shown • 1. Tester should understand the code well
in the following example: • 2. Tester should write some code for test
• READ X, Y cases and execute them
• IF(X == 0 || Y == 0)
• PRINT ‘0’ Tools required for White box Testing:
• #TC1 – X = 0, Y = 55 • PyUnit
• #TC2 – X = 5, Y = 0 • Sqlmap
• Multiple Condition Coverage: In this • Nmap
technique, all the possible combinations of the • Parasoft Jtest
possible outcomes of conditions are tested at • Nunit
least once. Let’s consider the following example:
• VeraUnit
• READ X, Y
• CppUnit
• IF(X == 0 || Y == 0)
• JSUnit.net
• PRINT ‘0’
• OpenGrok
• #TC1: X = 0, Y = 0
• Wireshark
• #TC2: X = 0, Y = 5
• HP Fortify
• #TC3: X = 55, Y = 0
• #TC4: X = 55, Y = 5 • CSUnit
Advantages of White Box Testing:
• Forces test developer to reason carefully about implementation.
• Reveals errors in "hidden" code.
• Spots the Dead Code or other issues with respect to best programming practices.
Disadvantages of White Box Testing:
• Expensive as one has to spend both time and money to perform white box testing.
• Every possibility that few lines of code are missed accidentally.
• In-depth knowledge about the programming language is necessary to perform white box testing.
Control Flow Software Testing
• Control flow testing is a structural testing strategy.
• This testing technique comes under white box testing.
• This type of testing method is often used by developers to test their own code and own
implementation as the design, code and the implementation is better known to the developers.
• For the type of control flow testing, all the structure, design, code and implementation of the
software should be known to the testing team.
• The aim of this technique is to determine the execution order of statements or instructions of the
program through a control structure.

Control Flow Testing Process:

Following are the steps involved into the process

of control flow testing:
• Control Flow Graph Creation:
From the given source code a control flow graph
is created either manually or by using the
software.
• Coverage Target:
A coverage target is defined over the control
flow graph that includes nodes, edges, paths,
branches etc.
• Test Case Creation:
Test cases are created using control flow graphs
to cover the defined coverage target.
• Test Case Execution:
After the creation of test cases over coverage
target, further test cases are executed.
• Analysis:
Analyze the result and find out whether the
program is error free or has some defects.
Advantages of Control flow testing:
• It detects almost half of the defects that are determined during the unit testing.
• It also determines almost one-third of the defects of the whole program.
• It can be performed manually or automated as the control flow graph that is used can be made by
hand or by using software also.
Disadvantages of Control flow testing:
• It is difficult to find missing paths if program and the model are done by same person.
• Unlikely to find spurious features.
Data Flow Testing
• It is a type of structural testing.
• It is a method that is used to find the test paths of a program according to the locations of definitions
and uses of variables in the program.
• It is concerned with:
• Statements where variables receive values,
• Statements where these values are used or referenced.
• Data Flow Testing uses the control flow graph to find the situations that can interrupt the flow of the
program.
Advantages of Data Flow Testing:
• To find a variable that is used but never defined,
• To find a variable that is defined but never used,
• To find a variable that is defined multiple times before it is use,
• Deallocating a variable before it is used.
Disadvantages of Data Flow Testing Control flow graph of above example:
• Time consuming and costly process
• Requires knowledge of programming languages
Example:
1. read x, y;
2. if(x>y)
3. a = x+1 else
4. a = y-1
5. print a;
Define/use of variables of above example:

Variable Defined at node Used at node

x 1 2, 3

y 1 2, 4

a 3, 4 5
Software Testing Principle
Principle 1: A necessary part of a test case is a definition of the expected output or result.
• In spite of the proper destructive definition of testing, there is still a subconscious desire to see the
correct result.
• One way of combating this is to encourage a detailed examination of all output by precisely spelling
out, in advance, the expected output of the program.
• Therefore, a test case must consist of two components:
1. A description of the input data to the program.
2. A precise description of the correct output of the program for that set of input data.
Principle 2: A programmer should avoid attempting to test his or her own program.
• it’s a bad idea to attempt to edit or proof read his or her own work.
• they really don’t want to find errors in their own work
• After a programmer has constructively designed and coded a program, it is extremely difficult to
suddenly change perspective to look at the program with a destructive eye.
• The program may contain errors due to the programmer’s misunderstanding of the problem statement
or specification.
• If this is the case, it is likely that the programmer will carry the same misunderstanding into tests of
his or her own program.
• This does not mean that it is impossible for a programmer to test his or her own program. Rather, it
implies that testing is more effective and successful if someone else does it.
• this argument does not apply to debugging (correcting known errors); debugging is more efficiently
performed by the original programmer.
Principle 3: A programming organization should not test its own programs.
• The argument here is similar to that made in the previous principle.
• One reason for this is that it is easy to measure time and cost objectives, whereas it is extremely
difficult to quantify the reliability of a program.
• Therefore, it is difficult for a programming organization to be objective in testing its own programs,
because the testing process, if approached with the proper definition, may be viewed as decreasing the
probability of meeting the schedule and the cost objectives.
• this does not say that it is impossible for a programming organization to find some of its errors,
because organizations do accomplish this with some degree of success.
• Rather, it implies that it is more economical for testing to be performed by an objective, independent
party
Principle 4: Any testing process should include a thorough inspection of the results of each test.
• This is probably the most obvious principle, but again it is something that is often unnoticed.
• There are numerous experiments that show many subjects failed to detect certain errors, even when
symptoms of those errors were clearly observable on the output listings.
• Put another way, errors that are found in later tests were often missed in the results from earlier tests.
Principle 5: Test cases must be written for input conditions that are invalid and unexpected, as
well as for those that are valid and expected.
• There is a natural tendency when testing a program to concentrate on the valid and expected input
conditions, to the neglect of the invalid and unexpected conditions.
• Test cases representing unexpected and invalid input conditions seem to have a higher error detection
yield than do test cases for valid input conditions.
Principle 6: Examining a program to see if it does not do what it is supposed to do is only half the
battle; the other half is seeing whether the program does what it is not supposed to do.
• This is a consequence to the previous principle.
• Programs must be examined for unwanted side effects.
• For instance, a payroll program that produces the correct pay checks is still an erroneous program if it
also produces extra checks for nonexistent employees
Principle 7: Avoid throwaway test cases unless the program is truly a throwaway program.
• Whenever the program has to be tested again (e.g., after correcting an error or making an
improvement), the test cases must be reinvented.
• since this reinvention requires a considerable amount of work, people tend to avoid it.
• The retest of the program is rarely as rigorous as the original test, meaning that if the modification
causes a previously functional part of the program to fail, this error often goes undetected.
• Saving test cases and running them again after changes to other components of the program is known
as regression testing.
Principle 8: Do not plan a testing effort under the tacit assumption that no errors will be found.
• This is a mistake project managers often make and is a sign of the use of the incorrect definition of
testing—that is, the assumption that testing is the process of showing that the program functions
correctly.
• Once again, the definition of testing is the process of executing a program with the intent of finding
errors.
• It is impossible to develop a program that is completely error free.
• Even after extensive testing and error correction, it is safe to assume that errors still exist; they simply
have not yet been found.
Principle 9: The probability of the existence of more errors in a section of a program is
proportional to the number of errors already found in that section.
• Errors tend to come in clusters and that some sections seem to be much more prone to errors than
other sections.
• nobody has supplied a good explanation of why this occurs.
• The phenomenon is useful in that it gives us insight or feedback in the testing process.

The Surprising Relationship

between Errors Remaining and
Errors Found.

Principle 10: Testing is an extremely creative and intellectually challenging task.

• The creativity required in testing a large program exceeds the creativity required in designing that
program
Inspections and Walkthroughs
• The three primary human testing methods are code inspections, walkthroughs and user (or
usability) testing.
• Code inspections and walkthroughs are code-oriented methods.
• These methods can be used at virtually any stage of software development, after an application
is deemed to be complete or as each module or unit is complete.
• The two code inspection methods have a lot in common (similarities).
Similarities are given below…
• Inspections and walkthroughs involve a team of people reading or visually inspecting a
program.
• With either method, participants must conduct some preparatory work.
• The climax is a ‘‘meeting of the minds,’’ at a participant conference.
• The objective of the meeting is to find errors but not to find solutions to the errors—that is, to
test, not debug.
• In a walkthrough, a group of developers with three or four being an optimal number performs the
review.
• Only one of the participants is the author of the program.
• Therefore, the majority of program testing is conducted by people other than the author, which
follows testing principle, which states that an individual is usually ineffective in testing his or her
own program.
• Inspections and walkthroughs are more effective, because people other than the program’s author are
involved in the process.
• Another advantage of walkthroughs, resulting in lower debugging (error correction) costs, is the fact
that when an error is found it usually is located precisely in the code.
• Modifying an existing program is a process that is more error prone (in terms of errors per statement
written) than writing a new program.
• Therefore, program modifications also should be subjected to these testing processes as well as
regression testing techniques.
Code Inspections (Program Inspections)
• A code inspection is a set of procedures and error-detection techniques for group code reading.
• An inspection team usually consists of four people.
• The first of the four plays the role of moderator (quality-control engineer ).
• The moderator is expected to be a competent programmer, but he or she is not the author of the
program and need not be familiar with the details of the program.
• Moderator duties include:
• Distributing materials for, and scheduling, the inspection session.
• Leading the session.
• Recording all errors found.
• Ensuring that the errors are subsequently corrected.
• The second team member is the programmer.
• The remaining team members usually are the program’s designer and a test specialist.
• The specialist should be well versed in software testing and familiar with the most common
programming errors
Inspection Agenda:-
• Several days in advance of the inspection session, the moderator distributes the program’s listing
and design specification to the other participants.
• The participants are expected to familiarize themselves with the material prior to the session.
• During the session, two activities occur:
1. The programmer narrates, statement by statement, the logic of the program.
During the discourse, other participants should raise questions, which should be
pursued to determine whether errors exist.
In other words, the simple act of reading aloud a program to an audience seems
to be a remarkably effective error-detection technique.
2. The program is analyzed with respect to checklists of historically common
programming errors.
• The moderator is responsible for ensuring that the discussions proceed along productive lines and
that the participants focus their attention on finding errors, not correcting them.
• The programmer corrects errors after the inspection session.
• Upon the conclusion of the inspection session, the programmer is given a list of the errors
uncovered.
• List of errors is also analyzed, categorized, and used to refine the error checklist to improve the
effectiveness of future inspections
• The time and location of the inspection should be planned to prevent all outside interruptions.
• The optimal amount of time for the inspection session appears to be from 90 to 120 minutes.
• The session is a mentally taxing experience, thus longer sessions tend to be less productive.
• Most inspections proceed at a rate of approximately 150 program statements per hour.
• For that reason, large programs should be examined over multiple inspections.
Human Agenda
• For the inspection process to be effective, the testing group must adopt an appropriate attitude.
• The programmer must a leave his or her ego at the door and place the process in a positive and
constructive light, keeping in mind that the objective of the inspection is to find errors in the
program and, thus, improve the quality of the work.
• For this reason, most people recommend that the results of an inspection be a confidential
matter, shared only among the participants.
• The inspection process has several beneficial side effects.
1. The programmer usually receives valuable feedback concerning programming style, choice of
algorithms, and programming techniques.
2. The inspection process is a way of identifying early the most error prone sections of the program,
helping to focus attention more directly on these sections during the computer-based testing processes
Error Checklist for Inspections
• An important part of the inspection process is the use of a checklist to examine the program for common
errors.
• The checklist is divided into various categories:- Data Reference Errors, Data Declaration Errors,
Computation Errors, Comparison Errors, Control-Flow Errors, Interface Errors and Input/Output Errors.
Data Reference Errors
• Does a referenced variable have a value that is unset or uninitialized?
• This probably is the most frequent programming error, occurring in a wide variety of circumstances.
• For each reference to a data item (variable, array element, field in a structure), attempt to ‘‘prove’’
informally that the item has a value at that point.
• For all references through pointer or reference variables, is the referenced memory currently allocated?
This is known as the ‘‘dangling reference’’ problem.
Data Declaration Errors
• Have all variables been explicitly declared? A failure to do so is not necessarily an error, but is, a
common source of trouble.
• Where a variable is initialized in a declarative statement, is it properly initialized?
• Are there any variables with similar names (e.g., VOLT and VOLTS)?
• Is each variable assigned the correct length and data type?
Computation Errors
• Is it possible for the divisor in a division operation to be zero?
• Are there any mixed-mode computations? (An example is when working with floating-point and
integer variables.)
• Are there any computations using variables having inconsistent data types?
• Are there any computations using variables having the same data type but of different lengths?
• Is an overflow or underflow expression possible during the computation of an expression? (That is,
the end result may appear to have valid value, but an intermediate result might be too big or too small
for the programming language’s data types.)
Comparison Errors
• Are there any mixed-mode comparisons or comparisons between variables of different lengths? If so,
ensure that the conversion rules are well understood.
• Are the comparison operators correct? Programmers frequently confuse relations such as, at most, at
least, greater than, not less than, and less than or equal ).
• Are the operands of a Boolean operator Boolean? Have comparison and Boolean operators been
erroneously mixed together? (example:- If you want to determine whether i is greater than x or y,
i>xIIy is incorrect. Instead, it should be (i>x)II(i>y).
Control-Flow Errors
• Will every loop eventually terminate? Devise an informal proof or argument showing that each loop
will terminate.
• Will the program, module, or subroutine eventually terminate?
• Is it possible that, because of the conditions upon entry, a loop will never execute
Interface Errors
• Does the number of arguments passed by this module to another module equal the number of
parameters expected by that module?
• Does the units system of each argument passed to another module match the units system of the
corresponding parameter in that module?
• If built-in functions are invoked, are the number, attributes, and order of the arguments correct?
Input / Output Errors
• Does the program properly handle ‘‘File not Found’’ errors?
• Are I/O error conditions handled correctly?
• Are there spelling or grammatical errors in any text that is printed or
• displayed by the program?
• Have all files been opened before use?
• Have all files been closed after use?
• Is sufficient memory available to hold the file your program will read?
Walkthroughs
• The code walkthrough, like the inspection, is a set of procedures and errordetection techniques for
group code reading.
• It shares much in common with the inspection process, but the procedures are slightly different, and
a different error-detection technique is employed.
• Like the inspection, the walkthrough is an uninterrupted meeting of one to two hours in duration. •
The walkthrough team consists of three to five people.
• One of these people plays a role similar to that of the moderator in the inspection process; another
person plays the role of a secretary (a person who records all errors found); and a third person plays
the role of a tester. The programmer is one of those people
• Suggestions for the other participants include: A highly experienced programmer, A programming-
language expert, A new programmer (to give a fresh, unbiased outlook), The person who will
eventually maintain the program, Someone from a different project, Someone from the same
programming team as the programmer.
• The initial procedure is identical to that of the inspection process.
• The participants are given the materials several days in advance, to allow them time to bone up on
the program.
• During the meeting, each test case is mentally executed; that is, the test data are ‘‘walked
through’’ the logic of the program.
• The state of the program (i.e., the values of the variables) is monitored on paper or a
whiteboard.
• The test cases must be simple in nature and few in number, because people execute programs at
a rate that is many orders of magnitude slower than a machine.
• In most walkthroughs, more errors are found during the process of questioning the programmer
than are found directly by the test cases themselves.
• As in the inspection, the attitude of the participants is critical.
• Comments should be directed toward the program rather than the programmer
• The walkthrough should have a follow-up process similar to that described for the inspection
process.
• Also, the side effects observed from inspections (identification of error-prone sections and
education in errors, style, and techniques) also apply to the walkthrough process.
Desk Checking
• Desk checking is a manual technique for verifying the logic and programming of an algorithm
before a program is launched. It's a traditional method for analyzing problems.
• In desk checking, the person performing the check acts as the computer. They use pen and paper to
record results, carefully following the algorithm and adhering to the specified logic.
• Desk checking can help programmers find bugs and errors that could prevent the application from
functioning properly. It can also be used to:
• Review code against design specifications
• Review other programming code
• Make quick changes without the code leaving the developer's local machine
• Desk checks can be performed at any point while working on a task.
• For example, when the person or people working on the item think they're done, or when the
expertise of someone else could help the implementation
• For most people, desk checking is relatively unproductive.
• One reason is that it is a completely undisciplined process.
• A second, and more important reason, is that it runs counter to testing principle 2 (A programmer
should avoid attempting to test his or her own program).
• For this reason, desk checking is best performed by a person other than the author of the program.
Peer Ratings (Peer Reviews or Program Reviews)
• Peer rating is a technique of evaluating anonymous programs in terms of their overall quality,
maintainability, extensibility, usability, and clarity.
• The purpose of the technique is to provide programmer self evaluation.
• A programmer is selected to serve as an administrator of the process.
• The administrator, in turn, selects approximately 6 to 20 participants (6 is the minimum to preserve
anonymity).
• The participants are expected to have similar backgrounds.
• Each participant is asked to select two of his or her own programs to be reviewed.
• One program should be representative of what the participant considers to be his or her finest work;
the other should be a program that the programmer considers to be poorer in quality
• Once the programs have been collected, they are randomly distributed to the participants.
• Each participant is given four programs to review.
• Two of the programs are the ‘‘finest’’ programs and two are ‘‘poorer’’ programs, but the reviewer is
not told which is which.
• Each participant spends 30 minutes reviewing each program and then completes an evaluation form.
• After reviewing all four programs, each participant rates the relative quality of the four programs.
• The evaluation form asks the reviewer to answer, on a scale from 1 to 10 (1 meaning definitely yes
and 10 meaning definitely no), such questions as:
• Was the program easy to understand?
• Was the high-level design visible and reasonable?
• Was the low-level design visible and reasonable?
• Would it be easy for you to modify this program?
• Would you be proud to have written this program?
• The reviewer also is asked for general comments and suggested improvements.
• After the review, the participants are given the anonymous evaluation forms for their two contributed
programs.
• They also are given a statistical summary showing the overall and detailed ranking of their original
programs across the entire set of programs, as well as an analysis of how their ratings of other programs
compared with those ratings of other reviewers of the same program.
• The purpose of the process is to allow programmers to self-assess their programming skills.
Concepts of Agile Development methodology
• The Agile methodology is a project management approach that involves breaking the
project into phases and emphasizes continuous collaboration and improvement.
• Teams follow a cycle of planning, executing, and evaluating.
• The approach of an agile team is to deliver work in small, but consumable, increments,
rather than wagering everything on a "big bang" launch.
• As a result of continuously evaluating requirements, plans, and results, teams are able to
respond to change in a timely manner.
• Agile methods break tasks into smaller iterations, or parts do not directly involve long term
planning.
• The project scope and requirements are laid down at the beginning of the development
process.
• Plans regarding the number of iterations, the duration and the scope of each iteration are
clearly defined in advance.
• Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks.
• The division of the entire project into smaller parts helps to minimize the project risk and to
reduce the overall project delivery time requirements.
• Each iteration involves a team working through a full software development life cycle
including planning, requirements analysis, design, coding, and testing before a working
product is demonstrated to the client.
Phases of Agile Model
1. Requirements gathering 2. Design the requirements 3. Construction/ iteration
2. 4. Testing/ Quality assurance 5. Deployment 6. Feedback
1. Requirements gathering:
In this phase, you must define the requirements.
Explain business opportunities and plan the time and effort needed to build the project.
Based on this information, you can evaluate technical and economic feasibility.
2. Design the requirements:
When you have identified the project, work with stakeholders to define requirements.
The user flow diagram or the high-level UML diagram to show the work of new features and show
how it will apply to your existing system.
3. Construction/ iteration:
When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working product.
The product will undergo various stages of improvement, so it includes simple, minimal
functionality.
4. Testing:
In this phase, the Quality Assurance team examines the product's performance and looks
for the bug.
5. Deployment:
In this phase, the team issues a product for the user's work environment.
6. Feedback:
After releasing the product, the last step is feedback.
In this, the team receives feedback about the product and works through the feedback
Scrum (software development)
• Scrum is the type of Agile framework.
• It is a framework within which people can address complex adaptive problem while
productivity and creativity of delivering product is at highest possible values.
• Scrum uses Iterative process.
Silent features of Scrum are:
• Scrum is light-weighted framework
• Scrum emphasizes self-organization
• Scrum is simple to understand
• Scrum framework help the team to work together
Sprint: A Sprint is a time box of one month or less. A new Sprint starts immediately after
the completion of the previous Sprint.

Release: When the product is completed, it goes to the Release stage.

Sprint Review: If the product still has some non-achievable features, it will be checked in
this stage and then passed to the Sprint Retrospective stage.
• Sprint Retrospective: In this stage quality or status of the product is checked.

• Product Backlog: According to the prioritize features the product is organized.

• Sprint Backlog: Sprint Backlog is divided into two parts Product assigned features to sprint
and Sprint planning meeting.

SCRUM LIFECYCLE
Advantage of using Scrum framework:
• Scrum framework is fast moving and money efficient.
• Scrum framework works by dividing the large product into small sub-products. It’s like a
divide and conquer strategy
• In Scrum customer satisfaction is very important.
• Scrum is adaptive in nature because it have short sprint.
• As Scrum framework rely on constant feedback therefore the quality of product increases
in less amount of time

Disadvantage of using Scrum framework:

• Scrum framework does not allow changes into their sprint.
• It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear
definition
• The daily Scrum meetings and frequent reviews require substantial resources.
Scrum Process Framework
• Scrum Process Framework can be viewed by means of a sequence of events and the
corresponding artifacts.
• The Scrum events are time-boxed events . That means, in a project, every scrum event has a
predefined maximum duration.
• These events enable transparency on the project progress to all who are involved in the
project.
• The vital events of scrum are-
•The Sprint
•Sprint Planning
•Daily Scrum Meetings
•The Sprint Review
•The Sprint Retrospective
The Sprint

• During a Sprint, a working product Increment is developed.

• It is usually of duration two weeks or one month, and this duration remains constant for all
the sprints in the project.
• We cannot have varying durations for the different sprints in a project.
• A new Sprint starts immediately after the conclusion of the previous Sprint.
• It provides guidance to the Team on why it is building the Increment.
• It is created during the Sprint Planning meeting.
• A Sprint should be cancelled if the Sprint Goal becomes obsolete
• This might occur if the organization changes direction or if market or technology
conditions change
• Due to the short duration nature of Sprints, cancellation during a sprint rarely makes sense.
• As the sprint cancellations consume resources, for getting re-organized into another Sprint,
they are very uncommon.
• All the incomplete Sprint Backlog Items are put back into the Product Backlog.
Sprint Planning
• Sprint Planning Meeting is of duration of maximum of four hours for two weeks sprints and eight
hours for one month Sprints.
• It is the responsibility of the Scrum Master to ensure that the meeting takes place and that all the
required attendees are present and understand the purpose of the scheduled meeting.
• The Scrum Master moderates the meeting to monitor the sustenance of discussion and closure on
time.
• Sprint Planning focuses on the following two questions –
• What needs to be and can be delivered in the Sprint Increment?
• How will the work needed for the execution of Sprint be achieved?
•The inputs to this meeting are -

•The Product Backlog

•The latest product Increment
•Project capacity of the Team during the Sprint
•Past performance of the Team
• The Scrum Team discusses the functionality that can be developed during the Sprint.
• Product Owner provides clarifications on the Product Backlog items.
• The Scrum Team then comes up with Sprint Goal. The Sprint Goal is an objective that provides
guidance to the Team on why it is building the Product Increment
• The Team then decides how it will build the selected functionality into a working product Increment
during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them
is called the Sprint
• By the end of the Sprint Planning meeting, the work is divided into tasks of duration of one day or
less.
• This is to enable the ease of work allocation, and tracking the completion. If the Team realizes that it
has too much or too little work.
• The Team may also invite others (not part of Scrum Team) to attend the Sprint Planning meeting to
obtain technical or domain advice or help in estimation.
Daily Scrum Meetings
• The Daily Scrum Meeting is a 15-minute meeting for the Team, conducted daily to quickly
understand the work since the last Daily Scrum Meeting and create a plan for the next 24 hours.
• This meeting is also referred to as Daily Stand up Meeting
• The Daily Scrum Meeting is held at the same time and same place every day to reduce complexity.
• During the meeting, each Team member explains –
• What did he do yesterday that helped the Team meet the Sprint Goal?
• What will he do today to help the Team meet the Sprint Goal?
• Does he see any impediments that prevent him or the Team from meeting the Sprint Goal?
• The input to the meeting should be how the team is doing toward meeting the Sprint Goal, and the
output should be a new or revised plan that optimizes the team’s efforts in meeting the Sprint goal.
• The Scrum Master coordinates the Daily Scrum Meeting and ensures that the objectives of the
meeting are met, the Meeting is the responsibility of the Team.
• If necessary, the Team may meet immediately after the Daily Scrum Meeting, for any detailed
discussions, or to re-plan the rest of the Sprint’s work.
• Following are the benefits of Daily Scrum Meetings –
• Improve communication within the Team.
• Identify impediments, if any, in order to facilitate an early removal of the same, so as to minimize
impact on the Sprint.
• Highlight and promote quick decision-making.
• Improve the Team’s level of knowledge.
Sprint Review
• A Sprint Review is held at the end of every Sprint.
• During the Sprint Review, a presentation of the increment that is getting released is reviewed.
• In this meeting, the Scrum Team and the stakeholders collaborate to understand what was done in
the Sprint.
• Based on that, and any changes to the Product Backlog during the Sprint, the attendees arrive at
the next steps required that could optimize value.
• Thus, the objective of Sprint Review is to obtain feedback and progress unitedly.
• If the product still have some non-achievable features then it will be checked in this stage and
then the product is passed to the Sprint Retrospective stage.
• The Sprint Review is normally held for two hours for two week sprints and for four hours for one
month sprints.
• The Scrum Master ensures that –
• The meeting takes place.
• The participants understand the purpose.
• The meeting is focused on the required agenda and is completed within the required duration.
• The Sprint Review includes the following aspects –
• Attendees include the Scrum Team and key stakeholders, as invited by the Product Owner.
• The Product Owner explains what Product Backlog items have been completed during the sprint
and what has not been completed.
• The Team discusses what went well during the Sprint, what problems it ran into, and how those
problems were solved.
• The Team demonstrates the work that it has completed and answers questions, if any, about the
Increment.
• The entire group then discusses on what to do next.
• Thus, the Sprint Review provides valuable input to Sprint Planning of the subsequent Sprint.
 • The Scrum Team then reviews the timeline, budget, potential capabilities, and marketplace for the
next anticipated release of the product increment.
• The outcome of the Sprint Review is an updated Product Backlog, which defines the probable
Product Backlog items for the next Sprint
Sprint Retrospective
• The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
• This is usually a one hour meeting for two-week duration sprints and a three hour meeting for one
month duration Sprints.
• The purpose of the Sprint Retrospective is to –
• Combine the learnings from the last Sprint, with regards to people, relationships, process, and
tools.
• Identify the major items that went well and potential improvements.
• Creation of a plan for implementing improvements to increase product quality.
• The Sprint Retrospective is an opportunity for the Scrum Team to introspect and improve within
the Scrum process framework so as to make the next Sprint outcome more effective.