CODING AND TESTING

QUE 1 :CODING

 The coding is the process of transforming the design of a system into a computer
language format.
 This coding phase of software development is concerned with software translating
design specification into the source code.
 It is necessary to write source code & internal documentation so that the code to its
specification can be easily verified.
 Coding is done by the coder or programmers who are independent people than the
designer.
 The goal is not to reduce the effort and cost of the coding phase, but to cut to the cost
of a later stage.
 The cost of testing and maintenance can be significantly reduced with efficient coding.
Goals of Coding
1. To translate the design of system into a computer language format: The coding is the
process of transforming the design of a system into a computer language format, which can
be executed by a computer and that perform tasks.
2. To reduce the cost of later phases: The cost of testing and maintenance can be significantly
reduced with efficient coding.
3. Making the program more readable: Program should be easy to read and understand. It
increases code understanding having readability and understandability as a clear objective of
the coding.
Characteristics of Programming Language

Readability: A good high-level language will allow programs to be written in

some methods that resemble a quite-English description of the underlying
functions.
Portability: High-level languages, being virtually machine-independent, should
be easy to develop portable software.
Generality: Most high-level languages allow the writing of a vast collection of
programs.
Brevity: Language should have the ability to implement the algorithm with less
amount of code. Programs mean in high-level languages are often significantly
shorter than their low-level equivalents.
Error checking: A programmer is likely to make many errors in the development
of a computer program. Many high-level languages invoke a lot of bugs checking
both at compile-time and run-time.
Cost: The ultimate cost of a programming language is a task of many of its
characteristics.

Quick translation: It should permit quick translation.

Efficiency: It should authorize the creation of an efficient object code.
Modularity: It is desirable that programs can be developed in the language as
several separately compiled modules, with the appropriate structure for ensuring
self-consistency among these modules.
 Widely available: Language should be widely available, and it should be feasible
to provide translators for all the major machines and all the primary operating
systems.
Coding Standards
1. Indentation: Proper and consistent indentation is essential in producing easy to
read and maintainable programs.
Indentation should be used to:
o Emphasize the body of a control structure such as a loop or a select
statement.
o Emphasize the body of a conditional statement
o Emphasize a new scope block
2. Inline comments: Inline comments analyze the functioning of the subroutine, or
key aspects of the algorithm shall be frequently used.
3. Rules for limiting the use of global: These rules file what types of data can be
declared global and what cannot.
4. Structured Programming: Structured (or Modular) Programming methods shall be
used. "GOTO" statements shall not be used as they lead to "spaghetti" code, which
is hard to read and maintain, except as outlined line in the FORTRAN Standards and
Guidelines.
5. Naming conventions for global variables, local variables, and constant
identifiers: A possible naming convention can be that global variable names
always begin with a capital letter, local variable names are made of small letters,
and constant names are always capital letters.
6. Error return conventions and exception handling system: Different functions
in a program report the way error conditions are handled should be standard within
an organization. For example, different tasks while encountering an error condition
should either return a 0 or 1 consistently.
Coding Guidelines
General coding guidelines provide the programmer with a set of the best methods
which can be used to make programs more comfortable to read and maintain.
Most of the examples use the C language syntax.
The following are some representative coding guidelines recommended by many
software development organizations.
1. Line Length: It is considered a good practice to keep the length of source
code lines at or below 80 characters. Lines longer than this may not be visible
properly on some terminals and tools. Some printers will truncate lines longer
than 80 columns.
2. Spacing: The appropriate use of spaces within a line of code can improve
readability.
Example:
Bad: cost=price+(price*sales_tax)
fprintf(stdout ,"The total cost is %5.2f\n",cost);
Better: cost = price + ( price * sales_tax )
fprintf (stdout,"The total cost is %5.2f\n",cost);
3. The code should be well-documented: As a rule of thumb, there must be at
least one comment line on the average for every three-source line.
4. The length of any function should not exceed 10 source lines: A very
lengthy function is generally very difficult to understand as it possibly carries out
many various functions. For the same reason, lengthy functions are possible to
have a number of bugs.
5. Do not use goto statements: Use of goto statements makes a program
unstructured and very tough to understand.
6. Inline Comments: Inline comments promote readability.

QUE 2:CODE REVIEW

 Code review is a systematic examination of source code.

 It's an essential part of the software development process that helps
guarantee the quality, correctness, and maintainability of code.
 Code reviews involve developers reviewing each other's work before
merging code into a shared repository.
 This practice helps identify bugs, improve code quality, and facilitate
knowledge sharing among team members.
 How does code review work?
The code review process typically follows these steps:
1. Code submission: A developer writes code and submits it for review, usually via
a pull request (PR) in platforms like GitHub.
2. Review assignment: The developer assigns one or more code reviewers—often
peers or senior developers—who are responsible for examining the submitted
code.
3. Code review: Reviewers analyze the code, looking for potential issues,
improvements, and adherence to coding standards. They might check for:
 Logical errors
 Style inconsistencies
 Performance optimizations
 Security vulnerabilities
4. Feedback: Reviewers then provide feedback, which may include comments,
suggested changes, and finally approval of the code.
5. Revisions: The initial developer revises the code based on feedback and
resubmits it for further review if necessary.
6. Approval: Once the code meets the required standards, the reviewers approve it,
and it gets merged into the main codebase.

What is the code review process?

The code review process can vary based on team practices and project
requirements:
 Code review methodology: There are various methodologies to conduct code
reviews, including:
 Formal inspections: A structured process where specific roles and
documentation are involved.

 Over-the-shoulder reviews: A quick informal review where a reviewer

looks over the author's shoulder as they present their code or during pair
programming.
 Tool-assisted reviews: Utilizing code review tools (like Graphite) to
automate and streamline the review process.
 Code review format: The format of a code review can differ based on the tool or
method used. Common formats include inline comments directly on the code,
summary reports, or dedicated review tools that aggregate feedback.
Code review effectiveness definition
Code review effectiveness refers to how well the review process identifies and
resolves issues in the code. Metrics for measuring effectiveness may include:
 Defect density: The number of defects found per unit of code.
 Review turnaround time: The time taken from code submission to approval.
 Post-release defects: Tracking bugs found after code deployment to evaluate
the quality of the review process.
To enhance effectiveness, teams can implement best practices, such as limiting
the size of code changes and providing specific feedback.
Code review roles and responsibilities
In a typical code review process, several roles contribute to its success:
 Code reviewers: The individuals responsible for analyzing the submitted code.
They provide feedback, suggest improvements, and ensure adherence to coding
standards.
 Code author: The developer who writes and submits the code for review. They
are responsible for addressing feedback and making necessary changes.
 Lead reviewer: In some teams, a lead reviewer may oversee the review process,
ensuring that reviews are conducted efficiently and effectively.
Code review vs pair programming
 While both code review and pair programming aim to improve code quality, they
differ in approach:
 Code review: Involves one developer submitting code for another developer (or
multiple developers) to review after the code is written. It focuses on catching
defects and ensuring quality before the code is integrated into the main branch.
 Pair programming: A collaborative approach where two developers work
together at the same workstation. One writes code while the other reviews it in
real-time, allowing for immediate feedback and correction. This technique can
enhance communication and lead to higher quality code.

QUE 3:SOFTWARE DOCUMENTATION

 Software documentation is a written piece of text that is often

accompanied by a software program.
 This makes the life of all the members associated with the project easier.
 It is a very critical process in software development. It’s primarily an
integral part of any computer code development method.
 computer code practitioners are a unit typically concerned with the worth,
degree of usage, and quality of the actual documentation throughout the
development and its maintenance.
 For example, before the development of any software product
requirements are documented which is called Software Requirement
Specification (SRS). Requirement gathering is considered a stage
of Software Development Life Cycle (SDLC).

Types Of Software Documentation:

1.Requirement Documentation: It is the description of how the software shall

perform and which environment setup would be appropriate to have the best out of it.

2. Architectural Documentation: Architecture documentation is a special type of

documentation that concerns the design. It contains very little code and is more
focused on the components of the system.
3. Technical Documentation: These contain the technical aspects of the software
like API, algorithms, etc. It is prepared mostly for software devs.
4. End-user Documentation: As the name suggests these are made for the end
user. It contains support resources for the end user.

Purpose of Documentation:

 Due to the growing importance of computer code necessities, the method of

crucial them needs to be effective to notice desired results.
 As to such determination of necessities is often sure regulation and pointers that
area unit core in getting a given goal.
 These all imply that computer code necessities area unit expected to alter thanks
to the ever ever-changing technology within the world.
 For a software engineer reliable documentation is typically a should the presence
of documentation helps keep track of all aspects of associate applications.

Principles of Software Documentation:

1.Write from reader’s point of view:
 It’s important to keep in mind the targeted audience that will be learning, and
working through the software’s documentation to understand and implement the
fully functional robust software application.
  while writing a documentation it becomes very crucial to use the simplest
language & domain related specific languages and terminologies.

 If there’s a lot of content, you can organize it in the glossary part at the end of
the document.
 List down synonyms, antonyms and difficult terminologies used.
2. Avoid unnecessary repetition: The back-end database stores
every piece of information as an individual unit and displays it in various different variety
of context so redundancy at any point will not be maintainable and is considered a bad
practice.
3. Avoid ambiguity:

Documentation contains a lot of information regarding the versatile functionalities of the software
system, every part of it must be written with clear and precise knowledge while avoiding any
conflicting information that might cause confusion to the reader.

4. Follow a certain standard organization:

In order to maintain the professionalism, accuracy, and precision of the document a certain set of
principles must be followed taking reference from other software documentations.

5. Record a Rationale

Rationale contains a comprehensive understanding of why a certain design or development decision

was made. This part of our documentation is written & maintained by the developer or the designer
itself for justification and verification for later needs.

6. Keep the documentation updated but to an extent

This principle applies to the maintainers of the documentation of the software, because updates are
made to the software on frequent intervals.

7. Review documentation

The documentation consists of too many web-pages collectively holding a large chunk of information
that’s serving a sole purpose – educate and spread knowledge to anyone who is trying to understand
or implement the software.

Advantages of software documentation

 The presence of documentation helps in keeping the track of all aspects of an application
and also improves the quality of the software product.

 The main focus is based on the development, maintenance, and knowledge transfer to other
developers.

 Helps development teams during development.

 Helps end-users in using the product.

Disadvantages of software documentation

 The documenting code is time-consuming.

 The software development process often takes place under time pressure, due to which
many times the documentation updates don’t match the updated code.
  The documentation has no influence on the performance of an application.

 Documenting is not so fun, it’s sometimes boring to a certain extent.

QUE:4 TESTING

 Software testing is an important process in the software development lifecycle .

 It involves verifying and validating that a software application is free of bugs, meets
the technical requirements set by its design and development , and satisfies user
requirements efficiently and effectively.
 This process ensures that the application can handle all exceptional and boundary
cases, providing a robust and reliable user experience.
 software testing helps deliver high-quality software that performs as expected in
various scenarios.
Software testing can be divided into two steps
1. Verification: It refers to the set of tasks that ensure that the software correctly implements a
specific function. It means “Are we building the product right?”.
2. Validation: It refers to a different set of tasks that ensure that the software that has been
built is traceable to customer requirements. It means “Are we building the right product?”.

Importance of Software Testing

 Defects can be identified early: Software testing is important because if there are any bugs
they can be identified early and can be fixed before the delivery of the software.
 Improves quality of software: Software Testing uncovers the defects in the software, and
fixing them improves the quality of the software.
 Increased customer satisfaction: Software testing ensures reliability, security, and high
performance which results in saving time, costs, and customer satisfaction.
 Helps with scalability: Software testing type non-functional testing helps to identify the
scalability issues and the point where an application might stop working.
 Saves time and money: After the application is launched it will be very difficult to trace and
resolve the issues, as performing this activity will incur more costs and time. Thus, it is better
to conduct software testing at regular intervals during software development.

Need for Software Testing

 Software bugs can cause potential monetary and human loss.
 There are many examples in history that clearly depicts that without the testing
phase in software development lot of damage was incurred. Below are some
examples:
 1985: Canada’s Therac-25 radiation therapy malfunctioned due to a software bug and
resulted in lethal radiation doses to patients leaving 3 injured and 3 people dead.
 1994: China Airlines Airbus A300 crashed due to a software bug killing 264 people.
 1996: A software bug caused U.S. bank accounts of 823 customers to be credited with 920
million US dollars.
 1999: A software bug caused the failure of a $1.2 billion military satellite launch.
 2015: A software bug in fighter plan F-35 resulted in making it unable to detect targets
correctly.
 2015: Bloomberg terminal in London crashed due to a software bug affecting 300,000 traders
on the financial market and forcing the government to postpone the 3bn pound debt sale.
 Different Types Of Software Testing
Explore diverse software testing methods including manual and automated testing for
improved quality assurance . Enhance software reliability and performance through
functional and non-functional testing, ensuring user satisfaction. Learn about the significance
of various testing approaches for robust software development.

Types Of Software Testing

Software Testing can be broadly classified into 3 types:
1. Functional testing : It is a type of software testing that validates the software systems against
the functional requirements. It is performed to check whether the application is working as
per the software’s functional requirements or not. Various types of functional testing are
Unit testing, Integration testing, System testing, Smoke testing, and so on.
2. Non-functional testing : It is a type of software testing that checks the application for non-
functional requirements like performance, scalability, portability, stress, etc. Various types of
non-functional testing are Performance testing, Stress testing, Usability Testing, and so on.
3. Maintenance testing : It is the process of changing, modifying, and updating the software to
keep up with the customer’s needs. It involves regression testing that verifies that recent
changes to the code have not adversely affected other previously working parts of the
software.
Apart from the above classification software testing can be further divided into 2 more ways
of testing:
1. Manual testing : It includes testing software manually, i.e., without using any automation
tool or script. In this type, the tester takes over the role of an end-user and tests the
software to identify any unexpected behavior or bug. There are different stages for manual
testing such as unit testing, integration testing, system testing, and user acceptance
testing. Testers use test plans, test cases, or test scenarios to test software to ensure the
completeness of testing.
2. Automation testing : It is also known as Test Automation, is when the tester writes scripts
and uses another software to test the product. Apart from Regression testing , Automation
testing is also used to test the application from a load, performance, and stress point of view.
It increases the test coverage, improves accuracy, and saves time and money when
compared to manual testing.
Different Types of Software Testing Techniques
Software testing techniques can be majorly classified into two categories:
1. Black box Testing : Testing in which the tester doesn’t have access to the source code of the
software and is conducted at the software interface without any concern with the internal
logical structure of the software known as black-box testing.
2. White box Testing : Testing in which the tester is aware of the internal workings of the
product, has access to its source code, and is conducted by making sure that all internal
operations are performed according to the specifications is known as white box testing.
3. Grey Box Testing : Testing in which the testers should have knowledge of implementation,
however, they need not be experts.

QUE 5:BLACK BOX TESTING

Black-box testing is a type of software testing in which the tester is not concerned
with the software’s internal knowledge or implementation details but rather
focuses on validating the functionality based on the
provided specifications or requirements.

Black Box Testing

Types Of Black Box Testing
The following are the various categories of black box testing:
1. Functional Testing
2. Regression Testing
3. Nonfunctional Testing (NFT)

Functional Testing
 Functional testing is defined as a type of testing that verifies that each function of the
software application works in conformance with the requirement and specification.
 This testing is not concerned with the source code of the application. Each functionality of
the software application is tested by providing appropriate test input, expecting the output,
and comparing the actual output with the expected output.
Regression Testing
 Regression Testing is the process of testing the modified parts of the code and the parts that
might get affected due to the modifications to ensure that no new errors have been
introduced in the software after the modifications have been made.
 Regression means the return of something and in the software field, it refers to the return of
a bug. It ensures that the newly added code is compatible with the existing code.
Nonfunctional Testing
 Non-functional testing is a software testing technique that checks the non-functional
attributes of the system.
 It is defined as a type of software testing to check non-functional aspects of a software
application.
 It is designed to test the readiness of a system as per nonfunctional parameters which are
never addressed by functional testing.
Advantages of Black Box Testing
 The tester does not need to have more functional knowledge or programming skills to
implement the Black Box Testing.
 It is efficient for implementing the tests in the larger system.
 Tests are executed from the user’s or client’s point of view.
Disadvantages of Black Box Testing
 There is a possibility of repeating the same tests while implementing the testing process.
 Without clear functional specifications, test cases are difficult to implement.
 It is difficult to execute the test cases because of complex inputs at different stages of testing.
 Sometimes, the reason for the test failure cannot be detected.
QUE 6:WHITE BOX TESTING

White Box Testing

 White Box Testing is a testing technique in which software’s internal structure,
design, and coding are tested to verify input-output flow and improve design,
usability, and security. In white box testing, code is visible to testers, so it is also
called Clear box testing, Open box testing, Transparent box testing, Code-based
testing, and Glass box testing.
 It is one of two parts of the Box Testing approach to software testing.
 The term “WhiteBox” was used because of the see-through box concept. The clear
box or WhiteBox name symbolizes the ability to see through the software’s outer
shell (or “box”) into its inner workings.

What do you verify in White Box Testing?

White box testing involves the testing of the software code for the following:
 Internal security holes
 Broken or poorly structured paths in the coding processes
 The flow of specific inputs through the code
 Expected output
 The functionality of conditional loops
 Testing of each statement, object, and function on an individual basis

How do you perform White Box Testing?

STEP 1) UNDERSTAND THE SOURCE CODE
The first thing a tester will often do is learn and understand the source code of the
application. Since white box testing involves the testing of the inner workings of an
application.
STEP 2) CREATE TEST CASES AND EXECUTE
The second basic step to white box testing involves testing the application’s source
code for proper flow and structure. One way is by writing more code to test the
 application’s source code. The tester will develop little tests for each process or
series of processes in the application.

WhiteBox Testing Example

Consider the following piece of code
Printme (int a, int b) { ------------ Printme is a function
int result = a+ b;
If (result> 0)
Print ("Positive", result)
Else
Print ("Negative", result)
} ----------- End of the source code

To exercise the statements in the above white box testing example, WhiteBox test
cases would be
 A = 1, B = 1
 A = -1, B = -3

Advantages of White Box Testing

 Code optimization by finding hidden errors.
 White box tests cases can be easily automated.
 Testing is more thorough as all code paths are usually covered.
 Testing can start early in SDLC even if GUI is not available.
Disadvantages of WhiteBox Testing
 White box testing can be quite complex and expensive.
 Developers who usually execute white box test cases detest it. The white box testing by
developers is not detailed and can lead to production errors.

QUE 7:DEBUGGING

 Debugging in Software Engineering is the process of identifying and

resolving errors or bugs in a software system.
 It’s a critical aspect of software development, ensuring quality, performance,
and user satisfaction.
 In the context of software engineering, debugging is the process of fixing a bug in the
software.
 When there’s a problem with software, programmers analyze the code to figure out
why things aren’t working correctly.
 Debugging
Process of Debugging
Debugging is a crucial skill in programming. Here’s a simple, step-by-step
explanation to help you understand and execute the debugging process effectively:
Process of Debugging
Debugging is a crucial skill in programming. Here’s a simple, step-by-step
explanation to help you understand and execute the debugging process effectively:

Process of Debugging
Step 1: Reproduce the Bug
 To start, you need to recreate the conditions that caused the bug. This means making the
error happen again so you can see it firsthand.
 Seeing the bug in action helps you understand the problem better and gather important
details for fixing it.
Step 2: Locate the Bug
 Next, find where the bug is in your code. This involves looking closely at your code and
checking any error messages or logs.
 Developers often use debugging tools to help with this step.
Step 3: Identify the Root Cause
 Now, figure out why the bug happened. Examine the logic and flow of your code and see
how different parts interact under the conditions that caused the bug.
 This helps you understand what went wrong.
Step 4: Fix the Bug
 Once you know the cause, fix the code. This involves making changes and then testing the
program to ensure the bug is gone.
 Sometimes, you might need to try several times, as initial fixes might not work or could
create new issues.
 Using a version control system helps track changes and undo any that don’t solve the
problem.
Step 5: Test the Fix
After fixing the bug, run tests to ensure everything works correctly. These tests
include:
 Unit Tests: Check the specific part of the code that was changed.
 Integration Tests: Verify the entire module where the bug was found.
 System Tests: Test the whole system to ensure overall functionality.
 Regression Tests: Make sure the fix didn’t cause any new problems elsewhere in the
application.
Step 6: Document the Process
 Finally, record what you did. Write down what caused the bug, how you fixed it, and any
other important details.
 This documentation is helpful if similar issues occur in the future.

Debugging Approaches/Strategies
1. Brute Force: Study the system for a longer duration to understand the system.
2. Backtracking: Backward analysis of the problem which involves tracing the program
backward from the location.
3. Forward analysis of the program involves tracing the program forwards using breakpoints or
print statements.
 4. Using A debugging experience with the software debug the software with similar problems
in nature.
5. Cause elimination: it introduces the concept of binary partitioning.

Examples of error during debugging

Some common example of error during debugging are:
 Syntax error
 Logical error
 Runtime error
 Stack overflow
 Index Out of Bound Errors
 Infinite loops
 Concurrency Issues

QUE 8:Program Analysis Tools in Software

Engineering
 The goal of developing software that is reliable, safe and effective is crucial in the dynamic
and always changing field of software development.
 Programme Analysis Tools are a developer’s greatest support on this trip, giving them
invaluable knowledge about the inner workings of their code.

What is Program Analysis Tool?

 Program Analysis Tool is an automated tool whose input is the source code or the
executable code of a program and the output is the observation of characteristics of the
program. It gives various characteristics of the program such as its size, complexity,
adequacy of commenting, adherence to programming standards and many other
characteristics.
Importance of Program Analysis Tools

1.Finding faults and Security Vulnerabilities in the Code: Automatic programme analysis tools
can find and highlight possible faults, security flaws and bugs in the code. Memory Leak
2.Detection: Certain tools are designed specifically to find memory leaks and inefficiencies. By
doing so, developers may make sure that their software doesn’t gradually use up too much
memory.

3.Vulnerability Detection: Potential vulnerabilities like buffer overflows, injection attacks or

other security flaws can be found using programme analysis tools.

4.Dependency analysis: By examining the dependencies among various system components,

tools can assist developers in comprehending and controlling the connections between modules.
5.Automated Testing Support: To automate testing procedures, CI/CD pipelines frequently
combine programme analysis tools. Only well-tested, high-quality code is released into
production thanks to this integration, helping in identifying problems early in the development
cycle.
 Classification of Program Analysis Tools

1. Static Program Analysis Tools

Static Program Analysis Tool is such a program analysis tool that evaluates and computes various
characteristics of a software product without executing it. Normally, static program analysis tools
analyze some structural representation of a program to reach a certain analytical conclusion.
Whether the coding standards have been fulfilled or not.

2. Some programming errors such as uninitialized variables.

3. Mismatch between actual and formal parameters.

4. Variables that are declared but never used.

2. Dynamic Program Analysis Tools

 Dynamic Program Analysis Tool is such type of program analysis tool that
require the program to be executed and its actual behavior to be observed.
 A dynamic program analyzer basically implements the code.
 It adds additional statements in the source code to collect the traces of
program execution. When the code is executed, it allows us to observe the
behavior of the software for different test cases.
 Once the software is tested and its behavior is observed, the dynamic program
analysis tool performs a post execution analysis and produces reports which
describe the structural coverage that has been achieved by the complete
testing process for the program.
 For example, the post execution dynamic analysis report may provide data on
extent statement, branch and path coverage achieved. The results of dynamic
program analysis tools are in the form of a histogram or a pie chart. It
describes the structural coverage obtained for different modules of the
program.
QUE 9:INTEGRATION TESTING

 Integration testing is the process of testing the interface

between two software units or modules. It focuses on determining
the correctness of the interface.
 The purpose of integration testing is to expose faults in the
interaction between integrated units. Once all the modules have
been unit-tested, integration testing is performed.
 Integration testing is a software testing technique that focuses on
verifying the interactions and data exchange between different
components or modules of a software application.
 The goal of integration testing is to identify any problems or bugs
that arise when different components are combined and interact
with each other.
 Integration testing is typically performed after unit testing and
before system testing.
 It helps to identify and resolve integration issues early in the
development cycle, reducing the risk of more severe and costly
problems later on.
 Integration testing can be done by picking module by module.
This can be done so that there should be a proper sequence to be
followed.
 And also if you don’t want to miss out on any integration
scenarios then you have to follow the proper sequence.
 Exposing the defects is the major focus of the integration testing
and the time of interaction between the integrated units.
Integration test approaches
1. Big-Bang Integration Testing

 It is the simplest integration testing approach, where all the modules are
combined and the functionality is verified after the completion of individual
module testing.

 In simple words, all the modules of the system are simply put together and
tested.

 This approach is practicable only for very small systems. If an error is found
during the integration testing, it is very difficult to localize the error as the error
may potentially belong to any of the modules being integrated.

 So, debugging errors reported during Big Bang integration testing is very
expensive to fix.

 Big-bang integration testing is a software testing approach in which all

components or modules of a software application are combined and tested at
once.

Advantages of Big-Bang Integration Testing

 It is convenient for small systems.

 Simple and straightforward approach.

 Can be completed quickly.

 Does not require a lot of planning or coordination.

Disadvantages of Big-Bang Integration Testing

 There will be quite a lot of delay because you would have to wait for all the
modules to be integrated.

 High-risk critical modules are not isolated and tested on priority since all
modules are tested at once.

 Not Good for long projects.

 High risk of integration problems that are difficult to identify and diagnose.

2. Bottom-Up Integration Testing

In bottom-up testing, each module at lower levels are tested with
higher modules until all modules are tested. The primary purpose
of this integration testing is that each subsystem tests the
interfaces among various modules making up the subsystem.
 In bottom-up testing, no stubs are required.
  A principal advantage of this integration testing is that several disjoint
subsystems can be tested simultaneously.

 It is easy to create the test conditions.

Disadvantages of Bottom-Up Integration Testing

 Driver modules must be produced.

 In this testing, the complexity that occurs when the system is made up of a
large number of small subsystems.

3. Top-Down Integration Testing

Top-down integration testing technique is used in order to
simulate the behaviour of the lower-level modules that are not
yet integrated. In this integration testing, testing takes place
from top to bottom. First, high-level modules are tested and then
low-level modules and finally integrating the low-level modules
to a high level to ensure the system is working as intended.
Advantages of Top-Down Integration Testing

 Separately debugged module.

 Few or no drivers needed.

 It is more stable and accurate at the aggregate level.

Disadvantages of Top-Down Integration Testing

 Needs many Stubs.

 Modules at lower level are tested inadequately.

 It is difficult to observe the test output.

4. Mixed Integration Testing

A mixed integration testing is also called sandwiched integration
testing. A mixed integration testing follows a combination of top
down and bottom-up testing approaches. In top-down approach,
testing can start only after the top-level module have been
coded and unit tested. In bottom-up approach, testing can start
only after the bottom level modules are ready.
Advantages of Mixed Integration Testing

 Mixed approach is useful for very large projects having several sub projects.

 This Sandwich approach overcomes this shortcoming of the top-down and

bottom-up approaches.
 Disadvantages of Mixed Integration Testing

 For mixed integration testing, it requires very high cost because one part has a
Top-down approach while another part has a bottom-up approach.

Applications of Integration Testing

1. Identify the components: Identify the individual components of your

application that need to be integrated.

2.Create a test plan: Develop a test plan that outlines the scenarios and test
cases that need to be executed to validate the integration points between the
different components. Set up test 3.environment: Set up a test environment that
mirrors the production environment as closely as possible.

4. Execute the tests: Execute the tests outlined in your test plan, starting with
the most critical and complex scenarios.

6. Analyze the results: Analyze the results of your integration tests to identify
any defects or issues that need to be addressed.
7. Repeat testing: Once defects have been fixed, repeat the integration testing
process to ensure that the changes have been successful and that the
application still works as expected.

QUE 9: Object Oriented Testing in Software Testing

 Software typically undergoes many levels of testing, from unit testing

to system or acceptance testing. Typically, in-unit testing, small
“units”, or modules of the software, are tested separately with a focus
on testing the code of that module.
 As information systems are becoming more complex, the object-
oriented paradigm is gaining popularity because of its benefits in
analysis, design, and coding.
 Testing classes is a fundamentally different issue than testing
functions. A function (or a procedure) has a clearly defined input-
output behavior, while a class does not have an input-output behavior
specification.

 Data dependencies between variables

 Calling dependencies between modules

 Functional dependencies between a module and the variable it

computes

 Definitional dependencies between a variable and its types.

But in Object-Oriented systems, there are the following additional

dependencies:

 Class-to-class dependencies

 Class to method dependencies

 Class to message dependencies

 Class to variable dependencies

 Method to variable dependencies

 Method to message dependencies

 Method to method dependencies

Issues in Testing Classes:

 Additional testing techniques are, therefore, required to test

these dependencies.
 Another issue of interest is that it is not possible to test the class
dynamically, only its instances i.e, objects can be tested.
Similarly, the concept of inheritance opens various issues .
 in a larger system of a class it will be difficult to test subclasses
individually and isolate the error to one class.
 In object-oriented programs, control flow is characterized by
message passing among objects, and the control flow switches
from one object to another by inter-object communication.

1.Fault Based Testing: This type of checking permits for coming

up with test cases supported the consumer specification or the
code or both. It tries to identify possible faults (areas of design
or code that may lead to errors.). For all of these faults, a test
case is developed to “flush” the errors out. These tests also
force each time of code to be executed. This method of testing
does not find all types of errors. However, incorrect specification
and interface errors can be missed.

2. Class Testing Based on Method Testing: This approach is the simplest

approach to test classes. Each method of the class performs a well
defined cohesive function and can, therefore, be related to unit testing
of the traditional testing techniques. Therefore all the methods of a
class can be involved at least once to test the class.

3. Random Testing: It is supported by developing a random test sequence

that tries the minimum variety of operations typical to the behavior of
the categories

4. Partition Testing: This methodology categorizes the inputs and outputs

of a category so as to check them severely. This minimizes the number
of cases that have to be designed.

5. Scenario-based Testing: It primarily involves capturing the user actions

then stimulating them to similar actions throughout the test. These
tests tend to search out interaction form of error.

Purpose of Object Oriented Testing

2. Object Interaction Validation: Check to make sure objects interact with

one another appropriately in various situations.
 3. Determining Design Errors: Find the object-oriented design’s
limitations and design faults.

4. Finding Integration Problems: Evaluate an object’s ability to integrate

and communicate with other objects when it is part of a bigger
component or subsystem.
5. Assessment of Reusable Code: Evaluate object-oriented code’s
reusability. Code reuse is promoted by object-oriented programming
via features like inheritance and composition.

6. Verification of Handling Exceptions: Confirm that objects respond

correctly to error circumstances and exceptions.
7. Verification of Uniformity: Maintain uniformity inside and between
objects and the object-oriented system as a whole.

Smoke Testing – Software Testing

 Smoke testing, also known as “Build Verification Testing” or “Build Acceptance Testing,” is
a type of software testing that is typically performed at the beginning of the development
process to ensure that the most critical functions of a software application are working
correctly.
 It is used to quickly identify and fix any major issues with the software before more detailed
testing is performed.
 Smoke tests are a minimum set of tests run on each build. Smoke testing is a process where
the software build is deployed to a quality assurance environment and verified to ensure the
application’s stability.

Characteristics of Smoke Testing

The following are the characteristics of the smoke testing:
1. Level of Testing: Without delving into specific functionality, the testing procedure is
superficial and broad-based, covering only the most important features.
2. Automation: Automated smoke tests are a common way to quickly and effectively confirm
fundamental system functionality.
4. Frequency of execution: Usually, smoke testing is done following the release of a new build
or following significant code modifications.
5. Time Management: The process of determining the build’s stability is usually swift, requiring
little time.
5. Environment: Usually, smoke tests are carried out in a controlled setting that is quite similar
to the production setting.

Goal of Smoke Testing

The aim of Smoke Testing is:
1. Stop Wasting Resources: Refrain from wasting resources on extensive testing if the core
functions aren’t working properly.
2. Time Management: Save time by recognizing show-stopping concerns early on, so that
development teams may rapidly handle important issues.
3. Making Objective Decisions: Establish a transparent and impartial framework for
determining whether a software build is ready for more, in-depth testing or if it has to be
fixed right away.
 Types of Smoke Testing
There are three types of Smoke Testing:
1. Manual Testing: In this, the tester has to write, develop, modify, or update the test cases for
each built product.
2. Automated Testing: In this, the tool will handle the testing process by itself providing the
relevant tests.
3. Hybrid Testing: As the name implies, it is the combination of both manual and automated
testing. Here, the tester has to write test cases by himself and he can also automate the tests
using the tool. It increases the performance of the testing as it combines both manual
checking and tools.
Tools used for Smoke Testing:
 Selenium
 Cypress
 JUnit/TestNG
 PyTest
 Postman
 Jest
 SoapUI
 Robot Framework
These tools are used while implementing the automated test cases.
Advantages of Smoke Testing
1. Smoke testing is easy to perform.
2. It helps in identifying defects in the early stages.
3. It improves the quality of the system.
4. Smoke testing reduces the risk of failure.
Disadvantages of Smoke Testing
1. Smoke Testing does not cover all the functionality in the application. Only a certain part of
the testing is done.
2. Errors may occur even after implementing all the smoke tests.
3. In the case of manual smoke testing, it takes a lot of time to execute the testing process for
larger projects.

Que 10:Software Quality – Software Engineering

What is Software Quality?

 Software Quality shows how good and reliable a product is. To convey an associate
degree example, think about functionally correct software.
 It performs all functions as laid out in the SRS document. But, it has an associate
degree virtually unusable program.
 even though it should be functionally correct, we tend not to think about it to be a
high-quality product.

Factors of Software Quality

1. Portability: A software is claimed to be transportable, if it may be simply created to figure
in several package environments, in several machines, with alternative code merchandise,
etc.
2. Usability: A software has smart usability if completely different classes of users (i.e.
knowledgeable and novice users) will simply invoke the functions of the merchandise.
3. Reusability: A software has smart reusability if completely different modules of the
merchandise will simply be reused to develop new merchandise.
4. Correctness: Software is correct if completely different needs as laid out in the SRS
document are properly enforced.
5. Maintainability: A software is reparable, if errors may be simply corrected as and once they
show up, new functions may be simply added to the merchandise, and therefore the
functionalities of the merchandise may be simply changed, etc
6. Reliability: Software is more reliable if it has fewer failures. Since software engineers do
not deliberately plan for their software to fail, reliability depends on the number and type
of mistakes they make. Designers can improve reliability by ensuring the software is easy
to implement and change, by testing it thoroughly, and also by ensuring that if failures
occur, the system can handle them or can recover easily.
7. Efficiency. The more efficient software is, the less it uses of CPU-time, memory, disk
space, network bandwidth, and other resources. This is important to customers in order to
reduce their costs of running the software, although with today’s powerful computers, CPU
time, memory and disk usage are less of a concern than in years gone by.
Software Quality Management System
Software Quality Management System contains the methods that are used by the
authorities to develop products having the desired quality.
Some of the methods are:
 Managerial Structure: Quality System is responsible for managing the structure as a whole.
Every Organization has a managerial structure.
 Individual Responsibilities: Each individual present in the organization must have some
responsibilities that should be reviewed by the top management and each individual
present in the system must take this seriously.
 Quality System Activities: The activities which each quality system must have been
o Project Auditing.
o Review of the quality system.
o It helps in the development of methods and guidelines.

Evolution of Quality Management System

Quality Systems are basically evolved over the past some years. The evolution of a Quality
Management System is a four-step process.
1. Inception: Product inspection task provided an instrument for quality control (QC).
2. Quality Control: The main task of quality control is to detect defective devices, and it also
helps in finding the cause that leads to the defect. It also helps in the correction of bugs.
3. Quality Assurance: Quality Assurance helps an organization in making good quality products.

Que 11:Statistical Testing – Software Engineering

 Statistical Testing is a testing method whose objective is to work out the

undependable software package products instead of discovering errors.
 check cases are designed for applied mathematics testing with a wholly different
objective than those of typical testing.
 Steps in Statistical Testing:
Statistical testing permits one to focus on testing those elements of the system
that are presumably to be used. the primary step of applied mathematics testing is
to work out the operation profile of the software package. a successive step is to
get a group of check knowledge reminiscent of the determined operation profile.
The third step is to use the check cases in the software package and record the
time between every failure. Once a statistically important range of failures is
ascertained, the undependable may be computed.

Advantages and Disadvantages of Statistical Testing:

 Statistical testing permits one to focus on testing elements of the system that are
presumably to be used.
 Therefore, it leads to a system that the users to be a lot of reliable (than truly it is.
 However, it’s dangerous to perform applied mathematics testing properly. there’s
no easy and repeatable manner of process operation profiles.
 additionally, it’s a great deal cumbersome to get check cases for applied
mathematics cause the number of test cases with which the system is to be tested
ought to be statistically important.

QUE 12:Software quality management

 Software quality management involves keeping a close eye on software

development and maintenance to ensure that it meets customer expectations and
is bug-free.
 It includes activities like quality assurance, testing, and continuous improvement.
 With quality management, you can deliver software that is reliable, efficient, and
easy to use.
 To build an app, developers should work on many factors, such as choosing
their front end framework and the limitations of app size.
 Testers have to ensure that they do their job with a near-perfect notion to ensure
there are no bugs or defects.

How does Software Quality Management work?

Generally, software quality management is of three types: Quality Assurance, Quality Planning,
and Quality Control.

 Quality Assurance (QA):

 This is a systematic quality management process where you determine if a service or

product would meet the needs and requirements of a customer.
 In quality assurance, you establish and maintain the needed requirements to manufacture
products you can rely upon.
 With a proper quality assurance system, you can skyrocket customer confidence to the
next level while you improve how you handle your work efficiently.

 Quality Planning:
o How accessible is your product to different users?
 o How about the modularity aspects- can your developers reuse the code to
perform the same action at various locations?
o How robust is your website when multiple customers log in?
o Answering such questions is where quality management and planning come into
the picture.
o You address different aspects such as the market you intend your product to
outperform, the release date of new updates, addressing potential risks,
possessing quality goals, and developing the needed risk management policy.

 Quality Control:

 A quality control team's job is to test and review if the

software adheres to quality assurance standards and

processes, be it as an organization or a project. Every

software development firm has to prefer agile quality

management since it creates a ruckus if you don’t adapt

control procedures. One example includes following up on

software review to ensure you address any changes in the

previous test. Another one would be releasing software

testing with the proper documentation support for the testing

process.

Benefits of Software Quality Management

Software quality = Software success. There is no other say in this claim.
How does it help your business? Here you go
 Increase in development team productivity.
 Improvement in product quality.
 Get more favorable, up-to-date, and precise defect tracking and test statistics for your
website or mobile app test strategy.
 Bring down rework costs as soon as you detect your defects in the software development
lifecycle and software testing life cycle (STLC).

What are Software Quality Management metrics?

 Metrics are nothing but numbers or pointers helping us realize the
three P’s- product, process, and project attributes.
 The product attributes include size, quality, and complexity. The
process attributes talk about quality improvement and
development speed.
 The project attributes would bring the productivity, number of
resources, and costs into the picture.
 How important are Software Quality
Management metrics?
They indicate the product, process, and project health. When you
possess good metrics with data accuracy, it can help you to:
 Develop a project, process, and product strategy, directing you the right way.
 Recognize the area you need to focus on.
 Make strategic decisions.
 Drive key performance.

QUE 13: ISO 9000 Certification in Software Engineering

 The International organization for Standardization is a world

wide federation of national standard bodies. The International
standards organization (ISO) is a standard which serves as a for
contract between independent parties. It specifies guidelines for
development of quality system.
 Quality system of an organization means the various activities
related to its products or services. Standard of ISO addresses to
both aspects i.e. operational and organizational aspects which
includes responsibilities, reporting etc.
Why ISO Certification required by Software Industry?
There are several reasons why software industry must get an ISO
certification. Some of reasons are as follows :
 This certification has become a standards for international bidding.
 It helps in designing high-quality repeatable software products.
 It emphasis need for proper documentation.
 It facilitates development of optimal processes and totally quality
measurements.
Features of ISO 9001 Requirements :
 Document control –
All documents concerned with the development of a software product
should be properly managed and controlled.
 Planning –
Proper plans should be prepared and monitored.
 Review –
For effectiveness and correctness all important documents across all
phases should be independently checked and reviewed .
 Testing –
The product should be tested against specification.
 Organizational Aspects –
Various organizational aspects should be addressed e.g., management
reporting of the quality team.
Advantages of ISO 9000 Certification :
Some of the advantages of the ISO 9000 certification process are
following :
 Business ISO-9000 certification forces a corporation to specialize in
“how they are doing business”. Each procedure and work instruction
must be documented and thus becomes a springboard for continuous
improvement.
 Employees morale is increased as they’re asked to require control of
their processes and document their work processes
 Better products and services result from continuous improvement
process.
 Increased employee participation, involvement, awareness and
systematic employee training are reduced problems.
Shortcomings of ISO 9000 Certification :
Some of the shortcoming of the ISO 9000 certification process
are following :
 ISO 9000 does not give any guideline for defining an appropriate
process and does not give guarantee for high quality process.
 ISO 9000 certification process have no international accreditation
agency exists.

Capability Maturity Model (CMM) – Software Engineering

 The Capability Maturity Model (CMM) is a tool used to improve and refine
software development processes.
 It provides a structured way for organizations to assess their current practices
and identify areas for improvement.
 CMM consists of five maturity levels: initial, repeatable, defined, managed, and
optimizing.
 By following the CMM, organizations can systematically improve their software
development processes, leading to higher-quality products and more efficient
project management.
 Capability Maturity Model (CMM) was developed by the Software Engineering
Institute (SEI) at Carnegie Mellon University in 1987.
  It is not a software process model. It is a framework that is used to analyze the
approach and techniques followed by any organization to develop software
products.
 It also provides guidelines to enhance further the maturity of the process used
to develop those software products.

Importance of Capability Maturity Model

 Optimization of Resources: CMM helps businesses make the best use of all of their
resources, including money, labor, and time
 Comparing and Evaluating: A formal framework for benchmarking and self-
evaluation is offered by CMM. Businesses can assess their maturity levels, pinpoint
their advantages and disadvantages, and compare their performance to industry
best practices.
 Management of Quality: CMM emphasizes quality management heavily. The
framework helps businesses apply best practices for quality assurance and control,
which raises the quality of their goods and services.
 Enhancement of Process: CMM gives businesses a methodical approach to evaluate
and enhance their operations. It provides a road map for gradually improving
processes, which raises productivity and usefulness.
 Increased Output: CMM seeks to boost productivity by simplifying and optimizing
processes. Organizations can increase output and efficiency without compromising
quality as they go through the CMM levels.

Principles of Capability Maturity Model (CMM)

 People’s capability is a competitive issue. Competition arises when different
organizations are performing the same task (such as software development).
 In such a case, the people of an organization are sources of strategy and skills,
which in turn results in better performance of the organization.
 The people’s capability should be defined by the business objectives of the
organization.
 An organization should invest in improving the capabilities and skills of the people
as they are important for its success.

Shortcomings of the Capability Maturity Model (CMM)

 It encourages the achievement of a higher maturity level in some cases by
displacing the true mission, which is improving the process and overall software
quality.
 It only helps if it is put into place early in the software development process.
 It has no formal theoretical basis and in fact, is based on the experience of very
knowledgeable people.
 It does not have good empirical support and this same empirical support could also
be constructed to support other models.
Levels of Capability Maturity Model (CMM)
There are 5 levels of Capability Maturity Models. We will discuss each one of them
in detail.
 CMM
Level-1: Initial
 No KPIs defined.
 Processes followed are Adhoc and immature and are not well defined.
 Unstable environment for software development.
 No basis for predicting product quality, time for completion, etc.
 Limited project management capabilities, such as no systematic tracking of
schedules, budgets, or progress.
 We have limited communication and coordination among team members and
stakeholders.
 No formal training or orientation for new team members.
 Little or no use of software development tools or automation.
 Highly dependent on individual skills and knowledge rather than standardized
processes.
 High risk of project failure or delays due to a lack of process control and stability.
Level-2: Repeatable
 Focuses on establishing basic project management policies.
 Experience with earlier projects is used for managing new similar-natured projects.
 Project Planning- It includes defining resources required, goals, constraints, etc. for
the project. It presents a detailed plan to be followed systematically for the
successful completion of good-quality software.
 Configuration Management- The focus is on maintaining the performance of
the software product, including all its components, for the entire lifecycle.
 Requirements Management- It includes the management of customer reviews and
feedback which result in some changes in the requirement set. It also consists of
accommodation of those modified requirements.
 Subcontract Management- It focuses on the effective management of qualified
software contractors i.e. it manages the parts of the software developed by third
parties.
 Software Quality Assurance- It guarantees a good quality software product by
following certain rules and quality standard guidelines while developing.
Level-3: Defined
 At this level, documentation of the standard guidelines and procedures takes place.
 It is a well-defined integrated set of project-specific software engineering and
management processes.
 Peer Reviews: In this method, defects are removed by using several review
methods like walkthroughs, inspections, buddy checks, etc.
 Intergroup Coordination: It consists of planned interactions between different
development teams to ensure efficient and proper fulfillment of customer needs.
 Organization Process Definition: Its key focus is on the development and
maintenance of standard development processes.
 Organization Process Focus: It includes activities and practices that should be
followed to improve the process capabilities of an organization.
 Training Programs: It focuses on the enhancement of knowledge and skills of the
team members including the developers and ensuring an increase in work
efficiency.
Level-4: Managed
 At this stage, quantitative quality goals are set for the organization for software
products as well as software processes.
 The measurements made help the organization to predict the product and process
quality within some limits defined quantitatively.
 Software Quality Management: It includes the establishment of plans and
strategies to develop quantitative analysis and understanding of the product’s
quality.
 Quantitative Management: It focuses on controlling the project performance
quantitatively.
Level-5: Optimizing
 This is the highest level of process maturity in CMM and focuses on continuous
process improvement in the organization using quantitative feedback.
 The use of new tools, techniques, and evaluation of software processes is done to
prevent the recurrence of known defects.
 Process Change Management: Its focus is on the continuous improvement of the
organization’s software processes to improve productivity, quality, and cycle time
for the software product.
 Technology Change Management: It consists of the identification and use of new
technologies to improve product quality and decrease product development time.
 Defect Prevention It focuses on the identification of causes of defects and prevents
them from recurring in future projects by improving project-defined processes.

QUE 14: Six Sigma in Software Engineering

 Six Sigma is a methodology that helps organizations in making their process

better and more efficient by identifying and removing errors and variations.
 Variations in processes can lead to errors, these errors can lead to product
defects and product defects can lead to poor customer satisfaction.
 By reducing variation and errors Six Sigma can reduce process costs and
increase customer satisfaction.
 What is Six Sigma?
 Six Sigma is a methodology used by most organizations for process
improvement, and It is a statistical concept that aims to define the variation
found in any process.
 Six Sigma is a process of producing high and improved quality output. This
can be done in two phases – identification and elimination.
 The cause of defects is identified and appropriate elimination is done, which
reduces variation in whole processes.
 Six Sigma processes have a failure rate of only 3.4 per million opportunities
i.e. 99.99966 percent of Six Sigma products are free from defect, while Five
Sigma processes have a failure rate of only 233 errors per million
opportunities.

Characteristics of Six Sigma

The Characteristics of Six Sigma are as follows:
1. Statistical Quality Control: Six Sigma is derived from the Greek Letter ? which
denote Standard Deviation in statistics. Standard Deviation is used for measuring
the quality of output.
2. Methodical Approach: The Six Sigma is a systematic approach of application in
DMAIC and DMADV which can be used to improve the quality of production.
DMAIC means for Design-Measure- Analyze-Improve-Control. While DMADV stands
for Design-Measure-Analyze-Design-Verify.
3. Fact and Data-Based Approach: The statistical and methodical method shows the
scientific basis of the technique.
4. Project and Objective-Based Focus: The Six Sigma process is implemented to focus
on the requirements and conditions.
5. Customer Focus: The customer focus is fundamental to the Six Sigma approach. The
quality improvement and control standards are based on specific customer
requirements.
6. Teamwork Approach to Quality Management: The Six Sigma process requires
organizations to get organized for improving quality.
The 6 Key Principals of Six Sigma
Organizations can enhance their sigma level by integrating Six Sigma principles into
leadership, process management, and improvement efforts. Some Common Six Sigma
Principals are:

Principals of Six Sigma

1. Customer Centric Improvement
The primary principal of six sigma methodology is to focus on customer. Voice of the
Customer (VoC) and methods for determining what the customer truly want from a
product or process
2. Continuous Process Improvement
The Six Sigma approach requires constant process improvement. An organization that fully
implements the Six Sigma technique never stops improving. It continuously discovers and
priorities opportunities. Once one area has been improved, the organization will move on
to another.
3. Reduce Variation
A method to continuously improve a process is to reduce its variation. Every process has
an inherit variation. Variation in processes can lead to errors, these errors can lead to
product defect and product defect can leads to poor customer satisfaction. By reducing
variation and errors six sigma can reduce process cost and increase customer satisfaction.
Suppose there are some developers developing web application, variation will exist as
every developer have different coding styles, expertise levels, environment factors and
project requirement. By adopting strategies like coding standards and guideline, code
reviews, automated testing and documentation variation can be reduce to some extent.
4. Eliminating Waste
Waste is a major problem in the six sigma methodology. Eliminating waste means
removing items, procedures or people that are not required.
5. Empowering Employees
Until organizations provide employees with the tools they need to monitor and sustain
improvements, implementing improved processes is only a temporary solution. Process
improvement usually involves two approaches in most organizations.
6. Controlling the Process
Six Sigma improvements are frequently used to handle uncontrolled processes. Out-of-
control processes meet certain statistical conditions. The purpose of improvement is
to bring a process back under statistical control. Then, after the improvements are
implemented