example software engineering paperwork

Software Engineering : TDB 2163 2015

LABORATORY AUTOMATION SYSTEM Page 0

TDB 2163 SOFTWARE ENGINEERING

PROJECT DOCUMENTATION

LABORATORY AUTOMATION SYSTEM

Date: 14th August 2015

Members:

1. AFIQ AIMAN BIN ZAMRI 19071

2. MUHAMMAD NAZMI BIN MAT ASRI 19103

3. AMELIA ASYIQIN BINTI MOHAMAD 18856

4. KHALIDA ADEEBA BINTI MOHD ZAILAN 19271

5. WAN NOR SUHAILI BINTI WAN ZAHARI 19141



OVERVIEW

This idea came up when we notice that there are quite some time it happened that the

laboratory door is not open and the students have to wait until the lecturer came because only

the lecturer or security department (control room) have the access to the door. This project is

to create a system for laboratory door as well light which can control the behaviour of those

particular appliances. The system can be controlled from a distance and the controller will be

included in the system as well. The controller is a web that will be associated with the

system and use Wi-Fi as connection medium. The concept that we are going to implement is

Internet of Things (IOT), which allow the specific user to have control over the appliances

from far, as long as the connection to the internet is accessible. We will be providing a small

scale project in order to show how it is work in a real time (working prototype).

Name given for the system is Laboratory Automation System. This system created

because of few observations were made especially during the day at 8.00am lab where the

labs were locked and students and lecturers or tutors have to wait for the security to open it.

Instead of coming over to open the lab, we create this system which can be controlled by the

one in charged in the control room. This is less time consuming rather than coming over to

lab and to open the lab for the students and lecturers.

The group consist of 5 members, named as Muhammad Nazmi bin Mat Asri as the

group leader, Afiq Aiman bin Zamri, Amelia Asyiqin Binti Mohamad, Khalida Adeeba binti

Mohd Zailan and Wan Nor Suhaili binti Wan Zahari. Tasks were given accordingly to each

members in order to complete this project and documentations.



CONTENT

I OVERVIEW 1

II SOFTWARE PROJECT MANAGEMENT PLAN (SPMP) 5

1.0 INTRODUCTION 7

1.1 Project Overview 7

1.2 Project Deliverables 7

2.0 PROJECT ORGANISATION

2.1 Software Process Model 8

2.2 Roles and responsibilities 9

2.3 Tools and Techniques 10

3.0 PROJECT MANAGEMENT PLAN 11

3.1 Tasks

3.1.1 Task 11

3.1.1.1 Description 11

3.1.1.2 Deliverables and Milestones 11

3.1.1.3 Resources Needed 12

3.1.1.4 Dependencies and Constraints 12

3.1.1.5 Risks and Contingencies 13



III SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

1.0 INDTRODUCTION 19

1.1. Product overview 19

1.2 Scope 19

2.0 SPECIFIC REQUIREMENT 20

2.1. External Interface Requirement 20

2.2. Software System Attributes 21

ADDITIONAL MATERIAL 24

IV SOFTWARE DESIGN DESCRIPTION (SDD) 30

1.0 INTRODUCTION 32

2.0 SYSTEM ARCHITECTURAL DESIGN 33

2.1 Chosen System Architecture 33

3.0 DETAILED DESCIPTION OF COMPONENTS 43

3.1 Physical arrangement of devices and Communication and installed software

components on devices 37

4.0 USER INTERFACE DESIGN 44

4.1. Screen Images 45

4.2 Objects and Action 47



V SOFTWARE TESTING DOCUMENTATION (STD)

1.0 INTRODUCTION 50

1.1. System Overview 50

1.2. Testing Approach 51

2.0 TEST PLAN

2.1 Features to be tested 52

2.2 Features not to be tested 52

2.3 Testing Tools and Environment 53

3.0 TEST CASES 65

4.0 ADDITIONAL MATERIAL (TEST LOGS) 67

VI REFERENCES 69



Software Project Management Plan


Final version

13th

August 2015

Universiti Teknologi PETRONAS



Software Project Management Plan (SPMP)

Table of Contents

1 INTRODUCTION

1.1 Project Overview 7

1.2 Project Deliverables 7

2 PROJECT ORGANISATIONS

2.1 Software Process Model 8

2.2 Roles and Responsibilities 9

2.3 Tools and Techniques 10

3 PROJECT MANAGEMENT PLAN

3.1 Tasks

3.1.1 Task

3.1.1.1 Description 11

3.1.1.2 Deliverables and Milestones 11

3.1.1.3 Resources Needed 12

3.1.1.4 Dependencies and Constraints 12

3.1.1.5 Risks and Contingencies 13

3.2 Assignments 14

3.3 Timetable 15



1 INTRODUCTION

1.1 Project Overview

This idea came up when we notice that there are quite some time it happened that the

laboratory door is not open and the students have to wait until the lecturer came because only

the lecturer or security department (control room) have the access to the door. This project is

to create a system for laboratory door as well light which can control the behavior of those

particular appliances. The system can be controlled from a distance and the controller will be

included in the system as well. The controller is a web that will be associated with the

system and use Wi-Fi as connection medium. The concept that we are going to implement is

Internet of Things (IOT), which allow the specific user to have control over the appliances

from far, as long as the connection to the internet is accessible. When you access the

webserver from your browser of choice, you will have a big button that triggers the

laboratory door via a relay. We will wire a very basic circuit to the Pi's GPIO pins and upload

a website that triggers the circuit. When the relay is triggered, it closes the circuit hooked up

to the laboratory door motor and opens the door.

1.2 Project Deliverables

This project will be used for our targeted group that is our security department, for them to

easily open the door and lighting from far. We must buy the breadboard, relay, raspberry pi,

wire and laboratory motor. Then, we will combine the apparatus and we will use HTML, CSS

and JavaScript for the. While for the raspberry pi will use Webiopi application in the

Raspberry pi to control the GPIO pin inside the pi. Lastly, to connect the pi and the web using

HTML and REST API. The cost for this project is less than RM 50.00 for small scale project.

This project will be tested using prototype. The due for this project is the end of this August



2015, that‟s mean our timeline for our projects is about 3 months that starting from June 2015

until August 2015.

2 PROJECT ORGANISATIONS

2.1 Software process model

Our project will follow an incremental and an iterative development model for its

deliverables. The development will be done in several phases and each phase will represent a

complete development cycle, with certain functionality of the system delivered at the end of

each phase. Additionally, the project phases with start, finish dated and goals for each phase

are outlined in table below.

Phase Start and finish date Phase goals

Project startup 26 / 05/ 2015 – 30 / 05/ 2015 - Strategy planning

- Learning about the existing

technologies regarding

automation system

Requirement 01/ 06/ 2015 – 15/ 06/ 2015 - Become familiar with the

requirement

- Design the prototype

- Start searching tools for the

prototype

Phase 1 16/ 06/ 2015 – 17/ 07/ 2015 - Start doing the prototype

- Component characterization

format

Phase 2 18/ 07/ 2015 – 31/ 07/ 2015 - Constraint checker



Phase 3 01/ 08/ 2015 – 10/ 08/ 2015 - Final touch up

Each of the team members will create a list of tasks to be completed for the upcoming phase

of the project. Then the time for each task will be allocated, followed by the workload

balancing of the tasks. At the completion of each phase a postmortem analysis will be done to

analyze the previous phase. All tasks that we not completed during a phase will be recorded

and scheduled for completion in the upcoming phase.

2.2 Roles and responsibilities

The team structure is hierarchical. There is a team leader, and the rest of the roles are

assigned to the other tasks. All team members have their own area of responsibility and

everyone is expected to contribute equally to the project. The team will engage in regular

monthly meetings. Additionally team members will communicate by Facebook for the

compilation of documents and WhatsApp as our main communication medium. Personal

communication between team members is strongly encouraged.

Roles List of responsibilities

Team leader - Motivate the team members to perform their task

- Help the team in allocating the tasks and resolving

issues

Development manager - Producing the development strategy

- Producing the design specification

- Implement the product

- Developing the build, integration and system test plan

- Developing the test materials and running the tests

Planning manager - Lead in producing the task plan for next phase



- Lead in producing the schedule for the next phase

- Track the team progress against the plan

Process manager - Lead in producing and tracking the quality plan

- -alerts the team to quality problem

- Lead in defining and documenting its processes and in

maintaining the process improvement process

- Establish and maintain the team‟s development

standards

Support manager - Lead in determining its support needs and in obtaining

the needed tools and facilities

- Maintain the team‟s issue and risk tracking system

- Manage the configuration management system

2.3 tools and technique

Additional tools that will be used are: breadboard, relay, raspberry pi , wire and laboratory

motor. Then, we will combine the apparatus and we will used HTML , CSS and JavaScript

for the. While for the raspberry pi will use Webiopi application in the Raspberry pi to control

the GPIO pin inside the pi. Lastly, to connect the pi and the web using HTML and REST

API.



3 PROJECT MANAGEMENT PLAN

3.1 Task

3.1.1 Task -1

3.1.1.1 Description

The aim of this project is to help the Security department to create a system for

laboratory which can control the behavior of those particular appliances. The system can be

controlled from a distance and the controller will be included in the system as well. There are

a lot of risks and constraints that need to overview about the production so that it is inclined

with what we want to achieve.

3.1.1.2 Deliverables milestones

Milestone Date Description

Complete gathering

requirements

15/ 06/ 2015 All requirement for the security to

detect which want to be opened

Complete design the

prototype

17/ 07/ 2015 Design the system prototype and

its functionality

Complete coding the

prototype

31/ 07/ 2015 All coding completed resulting in

software prototype

Complete testing and

debugging the

prototype

10/ 08/ 2015 All functionality had been tested

and identified errors corrected

Complete production Complete the prototype and



of the prototype documentation transitioned to

operations group to begin

production

3.1.1.3 Resources needed

Hardware: breadboard, relay, raspberry pi ,wire and laboratory motor

Software: HTML, CSS, JavaScript, Webiopi and REST API

3.1.1.4 Dependencies and constraints

There are constraints that may arise along the way of our project because of resources needed

for the project that cannot be obtained and maintained.

Firstly, time constraints. The time given from end of May until early August 2015.

Actually we only given 2 months to complete this project with our 18 credit hour this sem.

We also rarely manage to meet the client because of time constraints and unavailability of

both parties. So this will make there possibilities for us to not meet client‟s requirement or

misunderstanding from the client‟s requirement.

Next, the limitation of UI or design on the web itself. It is because the CSS code

hardly or cannot overwrite and need to built it in CSS application of Webiopi that was the

software for the pi. Webiopi is a component that will interact the pi with the HTML code

from the web. So we need to have Webiopi application.



3.1.1.5 Risk and contingencies

There are a lot of risks need to be taken note when seeing the clients or any stakeholder.

Firstly, when we use an electrical apparatus, we have to take note the voltage used. If

the voltage used or output voltage is higher from input voltage, the raspberry pi will crash or

broken and not working. So to prevent our hardware easily crash, we must take care all about

that. This also one way how we want to make our project more productive and prevent for

wastage in term of buying extra things because of the experiment was not going well.

Then, project management process. We have to well plan our project so that

everything within the time frame given and will not delay. This is the important of team

leader to make sure everything is in the right places to prevent from delay of the project. We

also can make a Gantt chart to make our schedule more visible and revisable for everyone.

We also must make a correct budget and allocate correctly within our budget as a student.



3.2 Assignments

Nazmi Asri is assigned as the Project Manager who will do the technical part of

preparing materials for the prototype. The rest of the team acts as System Analysts, as

required at the current level of development of the system. Under Nazmi‟s

supervision, Khalida Adeeba leads the estimation of project size, effort and schedule

in the project management area. Amelia designed the work plan and developed the

Gantt chart which is approved by the project manager and the team members. Afiq

gathers the requirements mostly via the observations of the current system. From the

substances gathered, Suhaili leads the process of preparing the requirement definition

document. The review of the system is finally prepared by Afiq based on the

planning, analysis and design of the system that has been made and approved by

Nazmi Asri.



3.3 Project Timetable

In order to finish this project on time, we had prepared a timetable allocating each member

with their particular job. Allocation of jobs is important as we know what to do first before

one another. This help to ease the flow of our project. We managed to clear out our project in

time of 2 Months and 18 days.

Name Job scopes Time

Nazmi Gather material for prototype 1 Week

Afiq Gather requirements for the project 4 Days

Adeeba System Project Management Plan 1 Week

Suhaili System Requirement Specification 1 Week

Amelia System Design Description 1 Week

Nazmi

Afiq

System Testing Development 2 Weeks

Nazmi Monitor the workflow All the time

ALL Implementing the system and Working Prototype 1 Month



Software Requirements Specification


Final version

13th

August 2015


Table of Contents



1. INTRODUCTION 19

1.1 Overview 19

1.2 Scope 19

2. SPECIFIC REQUIREMENTS 20

2.1 External Interface Requirements 20

2.1.1 User Interfaces 20

2.1.2 Hardware Interfaces 20

2.1.3 Software Interfaces 21

2.1.4 Communications Protocols 21

2.2 Software Product Features 21

2.3 Software System Attributes 21

2.3.1 Reliability 22

2.3.2 Availability 22

2.3.3 Security 22

2.3.4 Maintainability 22

2.3.5 Portability 23

2.3.6 Performance 23

3. ADDITIONAL MATERIAL 24



Appendix A: Use Case 24

Appendix B: Sequence Diagram 25



1. INTRODUCTION

1.1 Purpose

The purpose of this SRS is to provide details about the workings of the Laboratory

Automation System. The details are to be sufficient enough that the system (including the

components) to be built. It is intended to be readable by the developer team involved. This

document provides the description of the system, laying out the functional and non-functional

requirements and use cases that describe the interactions the users will have with the

software.

1.2 Scope

The product to be produced is a Laboratory Automation System. This system will basically

allow the behavior of particular appliances to be controlled from a distance. Basic properties

and features will be described, which include the concept, medium of connection and

controller as well as the components, the actions it is suggested to, and shall perform. The

system is aimed to help security department to easily control the particular appliances‟

behavior and reduce time consumption in order to move from one to another laboratory in

comparison to a conventional manual door.



2. SPECIFIC REQUIREMENTS

2.1 External Interface Requirements

This section shall describe the interface requirement for the laboratory automation

system. They specify the way the user shall interact with the system as well as define

the necessary hardware interfaces and communication interfaces required by the

software to support the main function.

2.1.1 User Interfaces

The user interface shall follow basic Window style and functionality

conventions. The interface has two buttons on the screen with necessary

description to be provided on how to use the system. User need to login using

the given username and password before making any command. One button

will represent light and another one for door. The color of the button means;

green for on and red for off. Each click of the button will trigger the behavior

of the appliances thus perform the desired action. For example, when the user

click on the button light (in color of red), the button will trigger the light in the

laboratory room to be turned on. Thus the color of the button will change to

green, means the light is on.

2.1.2 Hardware Interfaces

The system will be using a controller which can control the appliances from a

distance. This controller will be connected through Wi-Fi connection and

perform action received by webserver using basic networking protocols.



2.1.3 Software Interfaces

The system is using the concept of Internet of Thing (IoT) which control the

behavior of things using the medium of Internet connection. The webserver

shall be able to be accessed from any type of operating system as long as there

is web browser. The web should be able to be accessed from anywhere and

anytime. The webserver can be open using mobile android or web.

2.1.4 Communications Protocols

The button feature in the webserver shall perform it function based on the

desired outcome. The green button shall only be able to be activated when the

door is locked and vice versa. The security system must be ensured by

providing the security department with a proper login username and password

to prohibit ant unauthorized access.

2.2 Software Product Features

The main features of the system will be:

Button for light and door

Different button color code control

Contact detail

Description on usage



Wi-Fi connector and receiver

Login access for authentication

Lock or unlock door

Turn on or off light

2.3 Software System Attributes

2.3.1 Reliability

The system is expected to be reliable to use over time and not sensitive that

prone to cause failure. 2.3.2 Availability

The system can be accessed anytime depending on the availability of

Wi-Fi connection

2.3.3 Security

Only authorized people especially from security department can access

the webserver and gain the login information

Fail authentication login more than 3 times should be blocked and alert

notification will be sent to main control room

2.3.4 Maintainability

The system uses a single page webpage which is not complex and

eases the maintenance.



2.3.5 Portability

The webpage can be opened in any operating system available along as

there is web browser.

Both web and mobile android can be used as a platform

2.3.6 Performance

The system should respond to action made by user with no delay more

than 20 seconds



3. ADDITIONAL MATERIAL

Appendix A: Use Case Diagram



Appendix B: Sequence Diagram



SOFTWARE DESIGN DESCRIPTION


Final Version

13th

August 2015




Table of Content

1. INTRODUCTION 32

1.1 Design Overview 32

2. SYSTEM ARCHITECTURAL DESIGN 33

2.1 Chosen System Architecture 33

3. DETAILED DESCRIPTION OF COMPONENTS 43

3.1 Component 43

4. USER INTERFACE DESIGN 44

4.1 Description of the User Interface 44

4.1.1 Screen Images 45

4.1.2 Objects and Action 47



INTRODUCTION

1.1 Design Overview

The software system being produced called “Laboratory Automation System”. It is

being produced to ease the student to get access to any laboratory door via the Internet. They

do not have to wait for the lecturer or security to come and open the door using their card.

This system is designed to “provide automation support” for the process of operating the door

and light in the particular laboratory. This system is largely cross-platform and is available to

any student who has a stable Internet connection. The system will be run on a central server

with each user will instruct them by a click on a particular instruction interface through a web

browser. The Laboratory Automation System will allow every verified student to have access

with web server. This project mainly focus on the problem faced by most of the student by

initiating the automating and standardizing automation system, providing the most effective

way to overcome the problem. Our project is design to ease everyone that may want to use

the room. This project will enable user to have control at any time as long as they are verified

use to use our website. Our project enable people to log in and choose which ever option

either door or light that they want to turn it on or off.



2. SYSTEM ARCHITECTURAL DESIGN

2.1 Chosen System Architecture

• This system works anywhere as long as there is internet access, it is a web based so it

is applicable for mobile phones as well as personal computer. This idea came up when we

notice that there are quite some time it happened that the laboratory door is not open and the

students have to wait until the lecturer came because only the lecturer have the access to the

door. This project is to create a system for laboratory door which can control the behaviour

of those particular appliances. The system can be controlled from a distance and the

controller will be included in the system as well. The controller is a web or a mobile

application that will be associated with the system and use Wi-Fi as connection medium. The

concept that we are going to implement is Internet of Things (IOT), which allow the specific

user to have control over the appliances from far, as long as the connection to the internet is

accessible. The platform that we are using is web, the code is written in html and JavaScript

and using mobile using Android for the security easily access everywhere and anytime. We

also used Raspberry Pi as the controller which is easy for us access that is connect through

Wi-Fi. When you access the webserver from your browser of choice, you will have a big

button that triggers the laboratory door via a relay. We will wire a very basic circuit to the

Pi's GPIO pins and upload a website that triggers the circuit. When the relay is triggered, it

closes the circuit hooked up to the laboratory door motor and opens the door.



Use Case Diagram



Activity Diagram

Figure 2.1.2: Login



Figure 2.1.3: Verify user



Figure 2.1.4: Browse page



Figure 2.1.5: logout



Sequence Diagram



3. DETAILED DESCRIPTIONS OF COMPONENTS

3.1 Component

Raspberry Pi

- The Raspberry Pi is a low cost, credit-card sized computer that plugs into a

computer monitor or TV, and uses a standard keyboard and mouse. It is a capable

little device that enables people of all ages to explore computing, and to learn how

to program in languages like Scratch and Python.

- We use application webiopi in raspberry pi to control GPIO pin in raspberry pi for

general purpose input and output.

We also use HTML, CSS, and JavaScript for the website.

To connect website and raspberry pi we did apply HTML and REST API.



4 USER INTERFACE DESIGN

4.1 Description of the User Interface

The user interface shall follow basic Window style and functionality

conventions. The interface has two buttons on the screen with necessary

description to be provided on how to use the system. User need to login using

the given username and password before making any command. One button

will represent light and another one for door. The colour of the button means;

green for on and red for off. Each click of the button will trigger the behaviour

of the appliances thus perform the desired action. For example, when the user

click on the button light (in color of red), the button will trigger the light in the

laboratory room to be turned on. Thus the color of the button will change to

green, means the light is on. The button feature in the webserver shall perform

it function based on the desired outcome. The green button shall only be able

to be activated when the door is locked and vice versa. The security system

must be ensured by providing the security department with a proper login

username and password to prohibit ant unauthorized access.



4.1.1 Screen Images

Figure 1 & 2: Login interface



Figure 3: Main Page interface



4.1.2 Object and Action

There are some object on screen which are :

* Button for light and door

* Different button color code control

* Contact detail

* Description on usage

* Wi-Fi connector and receiver

* Login access for authentication

* Lock or unlock door

* Turn on or off light

The action needed to access this server is that login and then choose option either

door or light and then set it to or off.



Software Test Documentation


Final version

13th

August 2015




1 INTRODUCTION

1.1 System Overview 50

1.2 Test Approach 51

2 TEST PLAN

2.1 Features to be Tested 52

2.2 Features not to be Tested 52

2.3 Testing Tools and Environment 53

2.3.1 Testing tools (Development Testing) 54

2.3.2 Testing Tools (Interface Testing) 54

2.3.3 Testing Tools (Functionality Testing) 55

2.3.4 Testing Tools (HTML and CSS) 56

2.3.5 Testing Tools (Compatibility Testing) 57

2.3.6 Testing Tools (Performance Testing ) 58

2.3.7 Testing Tools (Usability Testing) 59

2.3.8 Testing Tools (Security Testing) 60

2.3.9 Testing Tools (White Box Testing) 62

3 TEST CASES

3.1 Case 1 65

3.1.1 Purpose

3.1.2 Inputs

3.1.3 Expected Outputs & Pass/Fail criteria

3.1.4 Test Procedure



3.2 Case 2 66

3.2.1 Purpose

3.2.2 Inputs

3.2.3 Expected Outputs & Pass/Fail Criteria

3.2.4 Test Procedue

4 ADDITIONAL MATERIAL (including appendix A)

APPENDIX A. TEST LOGS

4.1 Log for test case 1 67

4.2 Log for test case 2 68



1. INTRODUCTION

1.1 SYSTEM OVERVIEW

This project is to create a system for laboratory door as well light which can control

the behaviour of those particular appliances. The system can be controlled from a distance

and the controller will be included in the system as well. The controller is a web that will

be associated with the system and use Wi-Fi as connection medium. The concept that we

are going to implement is Internet of Things (IOT), which allow the specific user to have

control over the appliances from far, as long as the connection to the internet is

accessible. When you access the webserver from your browser of choice, you will have a

big button that triggers the laboratory door via a relay. We will wire a very basic circuit to

the Pi's GPIO pins and upload a website that triggers the circuit. When the relay is

triggered, it closes the circuit hooked up to the laboratory door motor and opens the door.

Testing the Lab Auto System is intended to show that this system is working and

functioning well. We are referring the Authorities here is Security Department members

who are working in the Control Room to monitor the campus including controlling the

doors and lights. Furthermore, testing will enable us to detect the errors from the system.

When we test the software, we execute a program using artificial data. We check the

results of the test run for errors, anomalies or information about the systems‟ non-

functional attributes. The goal of this testing stage is;

• To demonstrate on how to use the system to the authorities like in this case is the

security department.

• To discover situations in which the behaviour of the software is incorrect, undesirable

or does not conform to its specification.



1.2 TEST APPROACH

We are calling all the guards for demonstrating the usage of the Lab Auto System.

After being explained the steps, we took their photographs as we are using face

recognition for them to unlock the door and lights for labs. A few references have been

listed below for testing purposes:

# Document Identifier Document Title

[Ref1] ID Authorities‟ ID

[Ref2] Password Authorities‟ Password

[Ref3] Light Button to switch on the Lights

[Ref4] Door Button to open the door

Standard and Regulatory Reference

# Document Identifier Document Title

[STD1] Password This password for guards are important for them to unlock

the door and switch on the lights



2 TEST PLAN

2.1 Features to be tested

For Lab Auto System, the guards will need their ID number and password in

order for them to have the accessibility to the system. Only one computer can operates

the system at one time. This is to avoid from misuse from any party that trying to play

around with the system and to maintain the level of security at the lab. Whenever the

guards are login, they will proceed to a webpage that consist a simple buttons of lights

and doors. That buttons have 2 different colors; red and green. Red color indicates the

switch is OFF while green in color indicate the switch is ON.

2.2 Features not to be tested

As our concern, due to time constraint and limited funding, the face

recognition is unable to be tested as we can‟t get the right time to meet the guards for

a proper photograph session as it will be used for the face recognizing. Moreover, due

to limited time we also unable to find a cheap IP camera and suitable for our project.



2.3.1 Testing tools (Development Testing)

2.3.1.1 Hardware preparation

2.3.1.1 This system can run in some devices only such desktop and

laptop. We cannot use the system in mobile phone or smartphone since

it is not a mobile friendly system.

2.3.1.2 Software preparation

2.3.2.1 The system is compatible with any kind of browser for desktop

such as Internet Explorer, Google Chrome, Mozilla Firefox,

Safari and Opera

2.3.1.3 Safety, security and privacy precautions

2.3.3.1 For safety, security and privacy precautions, we use login

system before anyone can use the system.

2.3.2 Testing Tools (Interface Testing)

2.3.2.1 Objectives are to detect faults due to interface errors or invalid

assumptions about interfaces. This testing is applicable during the

login. The interfaces of the system are same before the login but

different because it will show another screen that display the buttons of

Door and Light.



2.3.3 Testing Tools (Functionality Testing)

2.3.3.1 The objective of this test is to check if the system is as per the

specifications the customer intended for it as well as the functional

requirements that have been showed in the development

documentation.

2.3.3.3.1 Testing activities are included:

2.3.3.3.1.1 Outgoing links

2.3.3.3.1.2 Internal links

2.3.3.3.1.3 Anchor links

2.3.3.3.2 Test cookies are working as expected.

2.3.3.3.2.1 Cookies are used by websites to remember

active user sessions so the user does not need to

re-login every time the user use the website

2.3.3.3.2.2 Testing cookies are deleted when expired

2.3.3.3.2.3 Testing cookies received when user login

2.3.3.3.2.4 Tools that can be used: IBM Rational, Selenium



2.3.4 Testing Tools (HTML and CSS)

2.3.4.1 To ensure that search engines can crawl your site easily. This will

include

2.3.4.1.1 Checking for syntax errors

2.3.4.1.2 Readable colour schemas

2.3.4.1.3 Standard compliance. Ensure standards such W3C,

OASIS, IETF, ISO, ECMA, or WS-I are followed.

2.3.4.2 Functional Test Scenarios:

2.3.4.2.1 Test the system should not display the error message for

optional fields.

2.3.4.2.2 Test the functionality of the buttons available

2.3.4.2.3 Test the java script is properly working in different

browsers (IE, Firefox, Chrome, safari and Opera).

2.3.4.2.4 Test to see what happens if a user deletes cookies while

in the site.

2.3.4.2.5 Test to see what happens if a user deletes cookies after

visiting a site.



2.3.5 Testing Tools (Compatibility Testing)

2.3.5.1 Ensures that your web application displays correctly across different

devices.

2.3.5.1.1 Browser Compatibility Test: Same website in different

browsers will display differently. You need to test if

your web application is being displayed correctly across

browsers, JavaScript, AJAX and authentication is

working fine.

2.3.5.1.2 To determine if the software is compatible with other

elements of a system with which it should operate, e.g.

Browsers, Operating Systems, or hardware.

2.3.5.1.3Compatibility Test Scenarios:

2.3.5.1.1 Test the website in different browsers (IE,

Firefox, and Chrome) and ensure the website is

displaying properly.

2.3.5.1.3.2 Test the HTML version being used is

compatible with appropriate browser versions.

2.3.5.1.3 Test the images display correctly in different

browsers.

2.3.5.1.4 Test the fonts are usable in different browsers.

Test the java script code is usable in different

browsers.



2.3.6 Testing Tools (Performance Testing)

2.3.6.1 Ensure site works under all loads. Testing activities will include

but not limited to;

2.3.6.1.1 Website application response times at different

connection speeds

2.3.6.1.2 Load test your web application to determine its

behavior under normal and peak loads

2.3.6.1.3 Stress tests your web site to determine its break

point when pushed to beyond normal loads at

peak time.

2.3.6.1.4 Test if a crash occurs due to peak load, how

does the site recover from such an event

2.3.6.2 Performance testing is conducted to evaluate the compliance of

a system or component with specified performance

requirements.

2.3.6.2.1 To determine the performance, stability and

scalability of an application under different load

conditions.

2.3.6.2.2 To evaluate product and/or hardware to

determine if it can handle projected load

volumes.



2.3.6.2.3 To determine if the current architecture can

support the application at peak user levels.

2.3.7 Testing Tools (Usability Testing)

2.3.7.1 Usability testing has now become a vital part of any web based

project. It can be carried out by testers by our team or a small

focus group of authorities of the web application.

2.3.7.1.1 Test the site Navigation:

2.3.7.1.1.1 Buttons or Links to different pages on your site

should be easily visible and consistent on all

webpages

2.3.7.1.2 Test the Content:

2.3.7.1.2.1 Content should be legible with no spelling or

grammatical errors.

2.3.7.1.2.2 Images if present should contain an "alt" text

2.3.7.2 Usability Test Scenarios:

2.3.7.2.1 Web page content should be correct without any

spelling or grammatical errors

2.3.7.2.2 All the text should be properly aligned.

2.3.7.2.3 All the buttons should be in a standard format and size.

2.3.7.2.4 Check the end user can run the system without

frustration.



2.3.7.2.5 Check the site on different resolutions (640 x 480,

600x800)

2.3.7.2.6 Check for broken links and images.

2.3.8 Testing Tools (Security Testing)

2.3.8.1 Security testing is vital for control room usage website that controls the

safety of the labs (doors and lights).

2.3.8.2 Test unauthorized access to secure pages should not be permitted

Figure 1: Username and password are needed to login into the page



Figure 2: The user will enter the username and password



2.3.9 Testing Tools (White Box Testing)

2.3.9.1 Codes for functioning buttons (door & light)

2.3.9.2 White box testing are involves the testing of the software/system code

for the following:

2.3.9.2.1 Internal security holes

2.3.9.2.2 Broken or poorly structured paths in the coding process

2.3.9.2.3 The flow of specific inputs through the code

2.3.9.2.4 Expected output

2.3.9.2.5The functionality of conditional loops



2.3.9.2.6 Testing of each statement, object and function on an individual

basis

2.3.9.3 The way that we do the white box testing are:

2.3.9.3.1 Understand the source code

2.3.9.3.1.1 The first thing a tester will often do is learn and

understand the source code of the application

2.8.3.1.1.2 Since the 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, in our case is HTML,

CSS, Javascript, JQuery, AJAX and WebioPi coding.

2.3.9.3.2 Create test cases and execute

2.3.9.3.2.1 The second basis step to white box testing involves

testing the application‟s source code for the proper flow

and structure.

2.3.9.3.2.2 One way is writing more code to test the application‟s

source code.

2.3.9.3.2.3 The tester will develop little tests for each process or

series of processes in the application.



2.3.9.3.4 This requires that the tester must have intimate

knowledge of the code and is often done by the

developer.

2.3.9.3.5 Other methods of testing are manual testing, try and

error listing.



3.0 TEST CASES

3.1 Test Case 1 – Login Page (user=Security)

3.1.1 Purpose

To test the login page usability

3.1.2 Inputs

Security‟s username

Security‟s password.

3.1.3 Expected Outputs and Pass/Fail Criteria

Security should be able to login successfully and the system will display the

home screen back.

The process failed if the security are not able login (not because of wrong

username or password)


Navigate to the login page

Provide valid username and password

Press „enter‟



3.2 Test Case 2 – Login Page (user=Security Venue: Office (Outside the control room))

3.2.1 Purpose

To test the login page usability

3.2.2 Inputs

Security‟s Username

Security‟s password.

3.2.3 Expected Outputs and Pass/Fail Criteria

Security should be able to login successfully and the system will display the

home page back.

The process failed if the Security are not able to login (not because of wrong

username or password)


Navigate to the login page

Provide valid username and password

Press „enter‟



4.0 ADDITIONAL MATERIAL (TEST LOGS)

4.1 Logs for Test Case 1 – Login Page

4.1.1 Test Results

The purpose is to test the login page usability by having security as the user. Several

Security members‟ sample input data was inserted. Below are the test results:

Input Data Expected Result Actual

Result

Comment

Username= webiopi

Password=rahimi432

Successfully

logged in into the

system

Passed -

Username= webiopi

Password=tingtang143

Unsuccessfully

logged in into the

system

FAILED Only one user can

have the access at a

time to prevent the

misuse of the buttons

and ruin the system.



4.0 ADDITIONAL MATERIAL (TEST LOGS)

4.2 Logs for Test Case 2 – Login Page (different place)

4.2.1 Test Results

The purpose is to test the login page usability by having Security as the user. Security‟s

sample input data was used. Below are the test results:

Input Data Expected Result Actual

Result

Comment

Username=webiopi

Password=rahimi432

Unsuccessfully

logged in into the

system

FAILED Couldn‟t log in

because it only

functions at control

room. One of the ways

to prevent misuse of

the system.



VI REFERENCES

1) http://www.guru99.com/web-application-testing.html

2) http://www.guru99.com/white-box-testing.html

3) http://www.guru99.com/complete-web-application-testing-chec…

4) http://www.softwaretestinghelp.com/web-application-testing/

5) http://www.tutorialspoint.com/s…/web_application_testing.htm

6) https://code.google.com/p/webiopi/wiki/INSTALL?tm=6

7) https://code.google.com/p/webiopi/wiki/CONFIGURATION

http://www.guru99.com/web-application-testing.html

http://www.guru99.com/white-box-testing.html

http://www.guru99.com/complete-web-application-testing-checklist.html

http://www.softwaretestinghelp.com/web-application-testing/

http://www.tutorialspoint.com/software_testing_dictionary/web_application_testing.htm

https://code.google.com/p/webiopi/wiki/INSTALL?tm=6

https://code.google.com/p/webiopi/wiki/CONFIGURATION

example software engineering paperwork

Documents