Task 1: Study and usage of OpenProj or similar software to draft a project

plan.

Introduction: Project managers can use OpenProj, a free task tracking application, when
creating effective plans. OpenProj delivers functionality that rivals the capabilities of
commercial software. This can save thousands of dollars in start-up costs. Of course, saving a
lot of money can be foolish if the required tasks can't be done. This is not the case with
OpenProj. Luckily the OpenProj application gives managers a full set of tools that are typically
used to track projects. Useful aids such as critical path analysis, resource tracking and task
comments are all present in OpenProj. The tool is ideal for simple project management but is
capable of larger efforts as well.

For the purposes of the example project plan, the following assumptions are made: -

 The OpenProj software has already been installed and correctly configured on a
workstation with an attached printer.

 The goal is to launch a new marketing effort in 6 months, called "Anganwadi".

 There are three full-time staff resources, including the manager.

 Budget is not a consideration - Schedule is the primary consideration.

 The target implementation date is 6 months away but is not an absolute fixed date.
Opensource.org interface Create account on
Opensource.org website

Allow Agreement and create

account

Choose the Language

1|Page
Account is Created and Software is ready to use

Task-2

Aim: - Study and usage of Openproj to track the progress

of a project,
2|Page
 Finding the right project management solution for your team can be very hard. Finding
an open source project management solution may be even harder. That’s the mission of
solution that allows teams to collaborate throughout the project life cycle. Additionally,
the project aims to replace proprietary software like Microsoft Project Server or Jira.

The OpcnPI ojcct objectives:

l.
Establish and promote an active and open community of developers, users, and
companies for continuous development of the open source project.
2. Define and develop the project vision, the code of conduct, and
principles of the application.
3. Create development policies and ensure their compliance.
4. Define and evolve the development and quality assurance processes.
5. Provide the source code to the public.
6. Provide and operate the OpenProject platform.

MissioIt of OpcliProject
The mission of OpenProject can be quickly summarized: we want to build excellent
open source project collaboration software. And when I say open source, I meant it. We
strive to make OpenProject a place to participate, collaborate, and get involved—with an
active, open- minded, transparent, and innovative community.
Companies have finally become aware of the importance of project management
software and also the big advantages of open source. But why is it that project teams
still tend to switch to old-fashioned ways of creating project plans, task lists, or status
reports with Excel, PowerPoint, or Word—cr having other expensive proprietary project
management software in use? We want to offer a real open source alternative for
companies: free, secure, and easy to use.

Pi’oject Det elopiiieiit Schedule

: 4/4/18
8:00 AM

TASK-3
AIM:-Preparation of Software Requirement Specification Document, Design
Documents and Testing Phase
SRS FOR QUEST GROUP OF INSTITUTIONS
3|Page
 Functional Requirements
R.1. Registrations
`R.1.1. Admissions
R.1.1.1. Courses
R.1.1.2. International Students
R.1.1.3. Enquiry

R.2. Annoucements

R.2.1. Admission Open

R.2.2. Exam forms
R.2.3. Placements
R.3. Payments
R.3.1.Online
R.3.1.1. UPI
R.3.1.2. Bank Transfer
R.3.1.3. PayUmoney
R.4. Facilities
R.4.1. Hostel Facilities
R.4.2. Computer Centre
R.4.3. Labs And Workshops
R.5. Courses
R.5.1. BTECH
R.5.1.1. Computer Science
R.5.1.2. Civil
R.5.1.3. Mechanical
R.5.2. BBA/MBA
R.5.3 BCA
R.6. Support
 Non-functional Requirements
R.1. Scalability

R.2. Reliability

R.3. Regulatory

R.4. Maintainability

R.5. Serviceability

R.6. Utility

R.7. Security

R.8. Manageability

R.9. Data integrity

R.10. Capacity
4|Page
 R.11. Availability

R.12. Usability

R.13. Interoperability

DESIGN DFD AND ER DIAGRAM

The DFD diagram has three main levels:

 Level 0 (Context Diagram)

 Level 1
 Level 2
A. 0 Level DFD – College Management System.

The DFD level 0 (context diagram) portrays the systems’ abstract view or the single
process with its external parties. It depicts the overall structure as a single bubble that
comes with incoming and outgoing indicators showing input and output data.

This diagram serves as the main idea that reveals the main process, users, and data that roam the
system. The college system’s external entities are as follows:

 College Administrator
 Teachers
B. 1 Level DFD – College Management System

The context diagram is used to derive the DFD Level 1 content, which is then split down into
sub-processes. This is to inform the programmer about the system’s included operations and
data inputs.

5|Page
The 1st level of the college management system DFD is composed of the following sub-
processes:

 Manage Student Information

 Assign Courses
Assign class Rooms
 Manage Teachers
C. 2 Level DFD – College Management System

DFD level 2 describes where data inputs are routed and where they originate inside the project.
Once you know how to use a data flow diagram, you can figure out how important it is to break
down operations in more detail.

Figure 1

Level 2 is the most abstract level of the data flow diagram for the college administration system.
Also emphasized is data management, including data storage (database). Databases were
responsible for storing the data that entered the system and serving as the source of data outputs.

 ENTITY RELATIONSHIP DIAGRAM(E-R)

The college management system ER diagram shows the connections between the system’s
entities, which make up the
database design. This shows how the
database or data storage works from a
logical point of .
view College
administration involves identifying
entities, their properties, and how
they interact.

6|Page
 Figure 2

Task: - 5

Aim: - Preparation of the Software Configuration management and Risk

management related documents.
7|Page
 Software Configuration management
SCM or Software Configuration management is a Project Function (as defined in the
SPMP) with the goal to make technical and managerial activities more effective. Software
configuration management (SCM) is a software engineering discipline consisting of
standard processes and techniques often used by organizations to manage the changes
introduced to its software products. SCM helps in identifying individual elements and
configurations, tracking changes, and version selection, control, and baselining.
SCM is also known as software control management. SCM aims to control changes
introduced to large complex software systems through reliable version selection and
version control.
The SCM system has the following advantages:
 Reduced redundant work.
 Effective management of simultaneous updates.
 Avoids configuration-related problems.
 Facilitates team coordination.
 Helps in building management; managing tools used in builds.
 Defect tracking: It ensures that every defect has traceability back to its source.
Benefits of Software Configuration Management
SCM provides significant benefits to all projects regardless of size, scope, and complexity.
Some of the most common benefits experienced by project teams applying the SCM
disciplines described in this guide are possible because the SCM system:
 Organization
Being that Configuration Management is like the framework for greater information
management programs, it should go without saying that it is critical for greater management
and organization of information as a whole. With a well-ordered system in place, a good IT
worker should be able to see all of the past system implementations of the business, and can
better address future needs and changes to keep the system up to date and running smoothly.
 Reliability
Nothing is worse than an unreliable system that is constantly down and needing repairs
because a company’s configuration management team is lacking in organization and pro-
activeness. If the system is used correctly, it should run like the well-oiled machine that it is,
ensuring that every department in the company can get their jobs done properly. Increased
stability and efficiency of the system will trickle down into every division of a company,
including customer relations, as the ease and speed in which their problems can be solved
and information can be accessed will surely make a positive impact.
 Cost Reduction and Risks
Like anything else in business, a lack of maintenance and attention to details can have
greater risks and cost down the line, as opposed to proactive action before a problem
arises. Configuration Management saves money with the constant system
maintenance, record keeping, and checks and balances to prevent repetition and
mistakes. The organized record keeping of the system itself saves time for the IT
department and reduces wasted money for the company with less money being spent
on fixing recurring or nonsensical issues.

SCM Process
The software configuration management process defines a series of tasks that have four
primary objectives:
8|Page
 1. To identify all the items that collectively defines the software configuration.
2. To manage changes to one or more of these items.
3. To facilitate the construction of different versions of an application.
4. To ensure that software quality is maintained as the configuration evolves over time.

Risk Management
1. A risk is any anticipated unfavourable event or circumstance that can occur while project
is being developed
2. The project manager needs to identify different type of risk in advance so that the
project deadlines don’t get extended
3. There are three main activities of risk management
Risk identification
1. The project manager needs to anticipate the risk in project as early as possible so
that the impact of risk can be minimised by using defective risk management plans
2. Following are the main types of risk that need to be identified
3. Project risk:- these include
 Resource related issues
 Schedule problems
 Budgetary issues
 Staffing problem
 Customer related issues
4. Technical risk := includes
 Potential design problems
 Implementation and interfacing issues
 Incomplete specification.
 Changing specification and technical uncertainty
 Ambiguos specification
 Testing and maintenance problem
5. Business risk :-
 Market trend changes
 Developing a product similar to the existing applications

9|Page
 
 Personal commitments
4. In order to be able to successfully identify and foresee the different type of
risk that might affect a project it is good idea to have a company disaster list
5. The company disaster list contains al the possible risk or events that can occur in
similar projects
Risk assessment: -
1. The main objective of risk assessment is to rank the risk in terms of their damage
causing potential
2. The priority of each list can be computed using the equation p=r*s, where p is
priority with whichthe risk must be handled , r is probability of the risk becoming
true and s is severity of damage caused due to the risk becoming true
3. If all the identified risk are prioritised than most likely and damaging risk can be
handled first and others later on
Risk containment: -
1. Risk containment include planning the strategies to handle and face the
most likely and damagingrisk first
2. Following are the strategies that can be used in general
a. Avoid the risk :- eg:- in case of having issues in designing phase with
reference to specifiedrequirements , one can discuss withe customer to
change the specifications and avoid the risk
b. Transfer the risk :-
i. This includes purchasing and insurance coverage
ii. Getting the risky component developed by Third party
Risk reduction: - leverage factor:

a) The project manger must consider the cost of handling the risk and the
corresponding reduction of the risk
b) Risk leverage = ( risk exposure before reduction - risk exposure after
reduction) / cost of reduction

Task: - 6

Aim: - Study and usage of any Design phase CASE tool.

CASE Tools: -
10 | P a g e
 CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools. CASE tools
are set of software application programs, which are used to automate the SDLC activities.
CASE tools are used by software project managers, analysts and engineers to develop
software system.
Reasons for using case tools:
• The primary reasons for using a CASE tool are:
– To increase productivity
– To help produce better quality software at lower cost
– To decrease the development time and cost.
• Various tools are incorporated in CASE and are called CASE tools, which are used to
support different stages and milestones in a software development lifecycle.
Architecture Of CASE tools: -

Figure: - 5.1

• Layer 1 is the user interface whose function is to help the user to interact with core of
the system. It provides a graphical user interface to users using which interaction with the
system become easy.
• Layer 2 depicts tool management system (TMS) which constitutes multiple tools of
different category using which automation of the development process can be done. TMS
may include some tools to draw diagrams or to generate test cases.
• Layer 3 represents object management system (OMS) which represents the set of objects
generated by the users. Group of design notations, set of test cases (test suite) are treated
as the objects.
• Layer 4 represents a repository which stores the objects developed by the user. Layer 4 is
nothing but a database which stores automation files.
Components of CASE Tools: - CASE tools can be broadly divided into the following
parts based on their use at a particular SDLC stage:

Central Repository - CASE tools require a central repository, which can serve as a source of
common, integrated and consistent information. Central repository is a central place of storage
where product specifications, requirement documents, related reports and diagrams, other

11 | P a g e
useful information regarding management are stored. Central repository also serves as data
dictionary.
 Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages
of SDLC.
 Lower Case Tools - Lower CASE tools are used in the implementation, testing
and maintenance stages.
 Integrated Case Tools - Integrated CASE tools are helpful in all the stages of
SDLC, from Requirement gathering to Testing and documentation.

Figure: - 5.2

Why CASE Tools are developed?

• Main purpose of the CASE tools is to decrease the development time and cost and
increase the quality of software.
• CASE tools are developed for the following reasons:
– Firstly Quick Installation
– Time saving by reducing coding and testing time.
– Enrich graphical techniques and data flow.
– Enhanced analysis and design development.
– Create and manipulate documentation
– The speed during the system development increased.
Types of CASE tools: - Major categories of CASE tools are:
– Diagram tools
– Project Management tools
– Documentation tools
– Web Development tools
– Quality Assurance tools
– Maintenance tools

Benefits of CASE tools

Project Management and control is improved: CASE tools can aid the project
management and control aspects of a development environment. Some CASE tools
allow for integration with industry-standard project management methods (such as
PRINCE). Others incorporate project management tools such as PERT charts and
critical path analysis. By its very nature, a CASE tool provides the vehicle for managing
more effectively the development activities of a project.
12 | P a g e
 1. System Quality is improved: CASE tools promote standards within a development
environment. The use of graphical tools to specify the requirements of a system
can also help remove the ambiguities that often lead to poorly defined systems.
Therefore, if used correctly, a CASE tool can help improve the quality of the
specification, the subsequent design and the eventual working system.
2. Consistency checking is automated: Large amounts of information about a business
area and its requirement are gathered during the analysis phase of an information
systems development project. Using a manual system to record and cross reference
this information is both time-consuming and inefficient. One of the advantages of
using CASE tool is that all data definitions and other relevant information can be
stored in a central repository that can then be used to cross check the consistency
of the different views being modelled.
3. Productivity is increased: One of the most obvious benefits of a CASE tool is that it
may increase the productivity of the analysis team. If used properly, the CASE tool
will provide a support environment enabling analysts to share information and
resources, manage the project effectively and produce supporting documentation
quickly.
4. The maintenance effort is better supported: It has been argued that CASE tools
help reduce the maintenance effort required to support the system once it is
operational. CASE tools can be used to provide comprehensive and up-to-date
documentation – this is obviously a critical requirement for any maintenance effort.
CASE tools should result in better systems being developed in the first place.

Problems associated with CASE tools

1. Need for organization - wide commitment: To be used effectively, CASE tools require
the commitment of the organisation. Every member of the development team must
adhere to the standards, rules and procedures laid down by the CASE tool
environment.
2. Unrealistic expectations: CSE tools cannot replace experienced business/systems
analysts and designers. They cannot automatically design a system nor can they
ensure that the business requirements are met. Analysts and designers still need to
understand the business environment and identify the system requirements. CASE
tools can only support the analytical skills of the developers, not replace them.
3. Long learning curve: CASE is technical software. It will take time for the development
team to get use to flow and use it effectively for development work.
5. Costs of CASE tools: CASE tools are complicated software packages and are, therefore,
expensive to buy. In addition to the initial costs, there are many ‘soft’ costs that have to be
considered. These ‘soft costs’ include integration of the new tool, customising the new tool,
initial and on-going training of staff, hardware costs and consultancy provided by the CASE
tool vendor.

13 | P a g e
 Task:-7

Aim: -To perform unit testing and integration testing.

Unit Testing:- Unit testing, a testing technique using which individual modules are tested to determine
if there are any issues by the developer himself. It is concerned with functional correctness of the
standalone modules. The main aim is to isolate each unit of the system to identify, analyze and fix the
defects.

Unit Testing Life cycle:-

Advantages of unit testing:-

 Defects are found at an early stage. Since it is done by the dev team by testing individual pieces of
code before integration, it helps in fixing the issues early on in source code without affecting other
source codes.
 It helps maintain the code. Since it is done by individual developers, stress is being put on making the
code less inter dependent, which in turn reduces the chances of impacting other sets of source code.
 It helps in reducing the cost of defect fixes since bugs are found early on in the development cycle.
 It helps in simplifying the debugging process. Only latest changes made in the code need to be
debugged if a test case fails while doing unit testing.
Disadvantages:
 It’s difficult to write good unit tests and the whole process may take a lot of time
 A developer can make a mistake that will affect the whole system
 Not all errors can be detected, since every module it tested separately and later different
integration bugs may appear.
 Testing will not catch every error in the program, because it cannot evaluate every execution
path in any but the most trivial programs. This problem is a superset of the halting problem,
which is un decidable.
 The same is true for unit testing. Additionally, unit testing by definition only tests the
functionality of the units themselves. Therefore, it will not catch integration errors or broader
system-level errors (such as functions performed across multiple units, or non-functional test

14 | P a g e
 areas such as performance).
 Unit testing should be done in conjunction with other software testing activities, as they can
only show the presence or absence of particular errors; they cannot prove a complete absence of
errors.
 To guarantee correct behaviour for every execution path and every possible input, and ensure
the absence of errors, other techniques are required, namely the application of formal methods
to proving that a software component has no unexpected behaviour.

Unit Testing Techniques:

1. Black Box Testing - Using which the user interface, input and output are tested.
2. White Box Testing - used to test each one of those functions behavior is tested.
3. Gray Box Testing - Used to execute tests, risks and assessment methods.
Integration Testing:- It tests integration or interfaces between components, interactions to different
parts of the system such as an operating system, file system and hardware or interfaces between systems.
 Also after integrating two different components together we do the integration testing. As
displayed in the image below when two different modules ‘Module A’ and ‘Module B’ are
integrated then the integration testing is done.

Fig 6.2 Figure: - 6.3

 Integration testing is done by a specific integration tester or test team.

 Integration testing follows two approach known as ‘Top Down’ approach and ‘Bottom
Up’ approach as shown in the image below:

Below are the integration testing techniques:

1. Big Bang integration testing: - In Big Bang integration testing all components or modules are
integrated simultaneously, after which everything is tested as a whole. As per the below image all the
modules from ‘Module 1’ to ‘Module 6’ are integrated simultaneously then the Testing is carried out.

Advantage: Big Bang testing has the advantage that everything is finished before integration
testing starts.

15 | P a g e
Disadvantage: The major disadvantage is that in general it is time consuming and difficult to trace the
cause of failures because of this late integration.

2. Top-down integration testing: Testing takes place from top to bottom, following the control
flow or architectural structure (e.g. starting from the GUI or main menu). Components or systems
are substituted by stubs. Below is the diagram of ‘Top down Approach”

Advantages of Top-Down approach:

 The tested product is very consistent because the integration testing is basically performed
in an environment that almost similar to that of reality
 Stubs can be written with lesser time because when compared to the drivers then Stubs are simpler
to author.

Disadvantages of Top-Down approach:

 Basic functionality is tested at the end of cycle
3.Bottom-up integration testing: Testing takes place from the bottom of the control flow upwards.
Components or systems are substituted by drivers. Below is the image of ‘Bottom up approach’

Advantage of Bottom-Up approach:

 In this approach development and testing can be done together so that the product
orapplication will be efficient and as per the customer specifications.

Disadvantages of Bottom-Up approach:

 We can catch the Key interface defects at the end of cycle
 It is required to create the test drivers for modules at all levels except the top control

System Testing: - System Testing (ST) is a black box

testing technique performed to evaluate the complete
system the system's compliance against specified
16 | P a g e
 requirements. In System testing, the functionalities of the system are tested from an end-to-end
perspective. System Testing is usually carried out by a team that is independent of the development
teamin order to measure the quality of the system unbiased. It includes both functional and Non-
Functional testing.

Task:-8

Aim: - To perform various white box and black box testing techniques.

17 | P a g e
 White Box Testing: -
White Box Testing is the testing of a software solution's internal coding and infrastructure. It focuses
primarily on strengthening security, the flow of inputs and outputs through the application, and improving
design and usability. White box testing is also known as Clear Box testing, Open Box testing, Structural
testing, Transparent Box testing, Code-Based testing, and Glass Box testing.
It is one of two parts of the "box testing" approach of software testing. Its counter-part, black box
testing, involves testing from an external or end-user type perspective. On the other hand, White box
testing is based on the inner workings of an application and revolves around internal testing.
The term "white box" was used because of the see-through box concept. The clear box or white box name
symbolizes the ability to see through the software's outer shell (or "box") into its inner workings.
Likewise, the "black box" in "Black Box Testing" symbolizes not being able to see the inner workings of
the software so that only the end-user experience can be tested.

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
The testing can be done at system, integration and unit levels of software development. One of the basic
goals of white box testing is to verify a working flow for an application. It involves testing a series of
predefined inputs against expected or desired outputs so that when a specific input does not result in the
expected output, you have encountered a bug.

How do you perform White Box Testing

To give you a simplified explanation of white box testing, we have divided it into two basic Steps. This is

18 | P a g e
what testers do when testing an application using the white box testing technique:
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, the tester must be very
knowledgeable in the programming languages used in the applications they are testing. Also, the testing
person must be highly aware of secure coding practices. Security is often one of the primary objectives of
testing software. The tester should be able to find security issues and prevent attacks from hackers and
naive users who might inject malicious code into the application either knowingly or unknowingly.
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. This method requires that the
tester must have intimate knowledge of the code and is often done by the developer. Other methods
include Manual Testing, trial and error testing and the use of testing tools as we will explain further on in
this article.

White Box Testing Techniques

The 3 main White Box Testing Techniques are:
 Statement Coverage
 Branch Coverage
 Path Coverage
Let’s understand these techniques one by one with a simple example.
 Statement coverage:
In a programming language, a statement is nothing but the line of code or instruction for the computer to
understand and act accordingly. A statement becomes an executable statement when it gets compiled and
converted into the object code and performs the action when the program is in a running mode.
Hence “Statement Coverage”, as the name itself suggests, it is the method of validating whether each and
every line of the code is executed at least once.
 Branch Coverage:
“Branch” in a programming language is like the “IF statements”. An IF statement has two branches: True
and False. So in Branch coverage (also called Decision coverage), we validate whether each branch is
executed at least once.
In case of an “IF statement”, there will be two test conditions:
 One to validate the true branch and,
 Other to validate the false branch.
Hence, in theory, Branch Coverage is a testing method which is when executed ensures that each and
every branch from each decision point is executed.
 Path Coverage:
Path coverage tests all the paths of the program. This is a comprehensive technique which ensures that all
the paths of the program are traversed at least once. Path Coverage is even more powerful than Branch
coverage. This technique is useful for testing the complex programs.
Types of White Box Testing
White box testing encompasses several testing types used to evaluate the usability of an application,
block of code or specific software package.
Unit Testing: It is often the first type of testing done on an application. Unit testing is performed on
each unit or block of code as it is developed. Unit Testing is essentially done by the programmer. As a
software developer, you develop a few lines of code, a single function or an object and test it to make sure
it works before continuing. Unit testing helps identify majority of bugs, early in the software development
lifecycle. Bugs identified in this stage are cheaper and easy to fix.
19 | P a g e
Testing for Memory Leaks: - Memory leaks are the most important causes of slower running
applications. A QA specialist who is experienced at detecting memory leaks is essential in cases where you
have a slow running software application. There are many tools available to assist developers/testers with
memory leak testing, example, Rational Purify for windows application. Apart from above a few testing
types are part of both black box and white box testing. They are listed as below:
White Box Penetration Testing: In this testing, the tester/developer has full information of the
application's source code, detailed network information, IP addresses involved and all server information
the application runs on. The aim is to attack the code from several angles to expose security threats
White Box Mutation Testing: Mutation testing is often used to discover the best coding techniques
to use for expanding a software solution.

Integration Testing: - Integration testing is a level of software testing where individual units are combined
and tested as a group. The purpose of this level of testing is to expose faults in the interaction between
integrated units. Test drivers and test stubs are used to assist in Integration Testing.
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 White Box 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 can lead to production errors.
 White box testing requires professional resources, with a detailed understanding of programming and
implementation.
 White-box testing is time-consuming, bigger programming applications take the time to test fully.
Black Box Testing
Black box testing is a software testing techniques in which functionality of the software under test
(SUT) is tested without looking at the internal code structure, implementation details and knowledge of
internal paths of the software. This type of testing is based entirely on the software requirements and
specifications. In Black Box Testing we just focus on inputs and output of the software system
without bothering about internal knowledge of the software program.

Black Box Testing – Steps: -

Here are the generic steps followed to carry out any type of Black Box Testing.
 Initially requirements and specifications of the system are examined.
 Tester chooses valid inputs (positive test scenario) to check whether SUT processes them correctly.
Also some invalid inputs (negative test scenario) are chosen to verify that the SUT is able to detect
them.
 Tester determines expected outputs for all those inputs.
 Software tester constructs test cases with the selected inputs.
 The test cases are executed.
 Software tester compares the actual outputs with the expected outputs.
 Defects if any are fixed and re-tested.
Types of Black Box Testing
There are many types of Black Box Testing but following are the prominent ones -
 Functional testing - This black box testing type is related to functional requirements of a system; it is
done by software testers.
 Non-functional testing - This type of black box testing is not related to testing of a specific
20 | P a g e
 functionality, but non-functional requirements such as performance, scalability, usability.
 Regression testing - Regression Testing is done after code fixes, upgrades or any other system
maintenance to check the new code has not affected the existing code.

Black box testing strategy:

Following are the prominent Test Strategy amongst the many used in Black box Testing
 Equivalence Class Testing: It is used to minimize the number of possible test cases to an optimum
level while maintains reasonable test coverage.
Boundary Value Testing: Boundary value testing is focused on the values at boundaries. This
technique determines whether a certain range of values are acceptable by the system or not. It is very
useful in reducing the number of test cases. It is mostly suitable for the systems where input is within
certain ranges.
 Decision Table Testing: A decision table puts causes and their effects in a matrix. There is
unique combination in each column.

Advantages of Black Box Testing

Tester can be non-technical.
 Used to verify contradictions in actual system and the specifications.
 Test cases can be designed as soon as the functional specifications are complete

Disadvantages of Black Box Testing

 The test inputs needs to be from large sample space.
 It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and
difficult
 Chances of having unidentified paths during this testing

TASK – 9

AIM: Testing of a web site.

21 | P a g e
Web Testing, or website testing is checking your web application or website for potential bugs before its
made live and is accessible to general public. Web Testing checks for functionality, usability, security,
compatibility, performance of the web application or website.
During this stage issues such as that of web application security, the functioning of the site, its access to
handicapped as well as regular users and its ability to handle traffic is checked.
Now, we will test a website and check its performance.
We are going to conduct a test on Questgoi.org using an online website testing tool which is GTmetrix.

Step1.Put an URL.

Step2. Wait until it tests and give report.

Performance Summary
Opportunities & Experiments
22 | P a g e
Is it Quick?Needs Improvement.

This site was very slow to connect and deliver initial code. It began rendering content with considerable
delay. The largest contentful paint time was slower than ideal.

Is it Usable?Needs Improvement.

This site had minor layout shifts.It took a long time to become interactive. It had 2 accessibility issues, none
serious. 0.27% of HTML was generated client-side, delaying usability.

Is it Resilient?Not bad...

This site had many render-blocking 3rd party requests. It had no security issues detected. Dependence on
client-generated HTML risks fragility.

23 | P a g e