NetApp Update Center Interim Report

1
NetApp Update Center
Interim Project Report
Sponsor Netapp
NetApp Sponsor Liaisons:
Mr. Chuck Fouts & Dr. Clinton Knight
CSC492 Team #14:
Jason Brown
Santosh Beyagudem
Zack Litzsinger
Dylan Ventra
North Carolina State University
Department of Computer Science
October 21st, 2013

2
Outline
1. Executive Summary
2. Problem Description
a. Sponsor Background
b. Problem Statement
c. Project Goals & Benefits
d. Development Methodology
e. Challenges
3. Resources Needed
4. Requirements
5. Design
6. Implementation
7. Test Plan & Results
8. Suggestions for Future Teams
9. Task Plan (Written Interim Project Report only)
Required Separate Documents
Installation Guide
User Guide
Developer’s Guide

3
Executive Summary
The NetApp Snap Creator Framework is a tool that is utilized by a large
number of high profile companies in order to do data storage and backup,
thereby providing a safeguard from losing valuable data. The NetApp team
has tasked our team with the development of an Update Center, which is
intended to help validate compatibilities between various plugins and the
primary Snap Creator components, the server and agent. Our solution will
connect to the main Snap Creator framework and provide our functionality to
the Snap Creator production system.
Over the last couple of weeks we were able to get access to the NetApp Snap
Creator Community and source code for the Snap Creator Framework
through Git. We have been able to build and run the server and agent by
using an installation document one of our NetApp contacts gave us. Recent
development has primarily been focused on creating the Update Center in
Ruby on Rails, specifically the database, the web API, and the graphical user
interface. This development mirrors our designs that we created during the
initial part of the project. We are using an agile development process utilizing
Rally to track our iterations. Overall we are progressing at a steady rate and
moving toward completion of the Update Center, as well as beginning to look
at integration and setting up a build server.
Our goal for the coming weeks is primarily to finalize the Update Center and
put it onto a server that we can access by using a build server provided by
NetApp. Integration is a must in the near future, as is better task planning
since our current task planning has been weak at times.

4
Problem Description
Sponsor Background
Our sponsor, Net App, has a local campus in Research Triangle Park in North
Carolina, but their headquarters is located in Sunnyvale, California. The
company focuses on network and cloud storage for large scale data, including
virtualization and cloud computing. They are responsible for a significant
portion of data storage and backup within major companies, including 85%
of the Fortune 500. The project presented to us is to create a Snap Creator
Version Update Center to help monitor server versions, agent versions, and
plugin versions and help decide if upgrading the current version is
compatible. This capability will allow customers to be able to update their
systems based on their current plugins without having to worry about issues.
Their primary motivation in giving us this project is to develop a solution for
compatibility within their internal componentsto ensure that items properly
communicate with each other and that the user knows which version of
software to download. When we integrate our solution into their framework,
they will have a smoother user experience in the maintenance and
installation of their product.
Sponsor Contacts:
Mr. Chuck Fouts
Chuck.Fouts@netapp.com
Dr. Clinton Knight
Sr. Manager, Snap Creator Engineering
Clinton.Knight@netapp.com
Problem Statement
NetApp’s Snap Creator product utilizes community developed plug-ins to
interface with Snap Creator Agents which then communicate with the Snap
Creator Servers. This 3-tier style of collaboration among software requires
consistent compatibility and version monitoring. Plug-ins need to know which
agents will support them as well as which other plug-ins are compatible while
running on the same agents. When a server update is made, administrators
need to know which agents need to be updated as well. Furthermore, if an
Agent is upgraded, it will need to reference plug-in version information to
check if it is still compatible with the new system.
Project Goals & Benefits
In order to solve the problems addressed above, a Snap Creator Update
Center must be developed. The Update Center will be a stand-alone server
that will service requests from Snap Creator Plug-ins, Agents, and Servers.

5
Our goal is for the Update Center to maintain complete compatibility between
all 3-tiers of the Snap Creator product. In order for the Update Center to
accomplish this, we will also develop a versioning system for each of the
applications. Databases need to be developed to store compatibility
information for reference upon various Update Center server requests. Lastly,
a web application will need to be developed for administrators to update the
compatibility and versioning information on the Update Center.
Since the Snap Creator product focuses on community driven development
by allowing custom plug-ins to me made to interface with Snap Creator
Agents, it is critical that compatibility be maintained. Otherwise it would be
difficult for plug-in developer to know which agents they can access and for
customers to know which plug-ins they can access for their particular agent
and their currently installed plug-ins. Also, as new versions of both servers
and agents are released by NetApp, developers need to know which version
of the open source framework that they need to be building their plug-ins
for.
Development Methodology
We will be using an agile development process with iteration cycles of two
weeks. Each iteration will be planned out on its initial date and completed
with testing complete and a demo on Wednesday during our regularly
scheduled meeting time. The thrust of our iterations will be primarily on
identifying the problem and attempting to solve it a few days before the
iteration is done so that testing can be completed for it. Coding will be done
in pairs, with one person testing the component that the other builds. At the
suggestion of our NetApp contacts, we will be using Rally to plan and manage
our sprints with input from our sponsor contacts.
Challenges
Technical Challenges
● Github: Repositories have been a big issue for us. It is important that
we maintain repository for us to all add our individual contributions to
this collaborative project. However, we have had issues keeping our
own local copies in sync. To address this issue we started using
branches for our own local directories and we merge them with the
main branch.
● Ruby: Our Update Center server is running on Ruby on Rails. Our
databases are also running the same platform. However, all of our
team had no experience programming in this environment before. In
order to learn Ruby on Rails we each followed online guides and
tutorials. Then when we finished a few tasks we discussed with each
other how we solved each task and explained how we did it with Ruby
on Rails.
● Rally: We used Rally to document and plan our iterations. However
during our first iteration we were very confused and ignorant to all
that Rally had to offer. As a team we met with our NetApp sponsors
and they walked us through how they use Rally. This gave us insight

6
into actual, production level, commercial iterative software
development.
● Deploying Update Center Server: Our server will be deployed,
maintained, and hosted by NetApp on their local VPN. Therefore we
have limited control over setting our server up until NetApp provides it
for us.
Legal Challenges
● NetApp’s Snap Creator product is open source and community driven
so we don’t have many legal challenges. However, since our server is
being hosted on NetApp’s VPN, we will have a legal liability for what
we do on their network.
Resources Needed
● We will need GitHub to host our repository as well as to collaborate
with the current Snap Creator source code, as it is hosted on GitHub.
● During our development process, Rally will help us to plan, document,
and track our process iteratively.
● Our Update Center will be created on a Ruby on Rails platform. As
such, we will need Ruby and Ruby on Rails installed on our machines.
● Google documents is needed as a document repository and as a way
to collaborate between team members.
● We also need NetApp to host our server using Jenkins to deploy the
application.
Requirements
Overall View
● The system should have a release name to help identify it
● Provide a version management system for the Snap Creator Server,
Agent, and Plugins
● Create Snap Creator Update Center to determine which versions are
compatible with which components
● Ensure that the Snap Creator team can integrate our solution into a
production environment and expand on it
Detailed Requirements
Update Center Requirements
1. Functional
1.1 Update Center shall determine if a plugin is compatible with a given SC
agent
1.2 Update Center shall determine if an agent is compatible with a given SC
server

7
1.3 Update Center shall store versioning metadata for plugins that describes
if it is compatible with a certain version of agent
1.4 Update Center shall store versioning metadata for agents that describes
if it is compatible with a certain version of a server
1.5 Update Center shall allow admins to upload updated versions of files
1.6 Update Center shall a simple user interface that allows versioning
metadata associated with plugins, servers, and agents to be managed
1.7 Update Center shall provide a way to set the initial admin password
2. Non-functional
2.1 Update Center must be available to the server through the local network
and must accept web request calls that follow the specifications of the
Update Center web API
2.2 Update Center must connect to the versioning framework created within
the Snap Creator framework
2.4 Update Center shall ensure that all most recent versions of agents,
servers, and plugins work together; if this is not the case, it will use the most
recent versions that work together
2.5 In the result of an invalid database configuration or other unknown error,
the Update Center shall not fail in a manner that prevents it from receiving
other web requests
2.6 Update Center shall utilize a database with a schema to keep track of
versioning and compatibility
2.7 Update Center shall require a login to manage the database
2.8 Get requests on the Update Center shall not require a login and shall not
cause any modifications on the database
3. Constraints
3.1 Update Center must maintain 70% test coverage or greater.
3.2 Update Center must be created using a web framework that can be
extensible and easily maintained by Snap Creator team after our
development cycle.

8
3.3 Update Center shall utilize the existing SnapCreator method of
downloading updated files rather than reimplementing a new system
Snap Creator Server Requirements
4. Functional
4.1 SC Server shall have the ability to poll a known URL for update meta-
data related to the installed product.
4.2 SC Server shall provide the customer the ability be able to turn
compatibility checking with the Update Center off from a configuration file.
4.3 The SC server GUI will be able to poll the Update Center for new versions
of SC agent and or plugins.
5. Non-functional
5.1 Failure to connect to the Update Center after three retries will fail but
continue to run the server and show an error message.
5.2 SC Server must use a background thread to perform tasks on a
scheduled basis.
5.3 The SC server GUI shall have a new column to the Agent Monitor to
identify Agents that have plugins that need to be updated.
6. Constraints
6.1 Additional code added to the SC server must maintain 70% test coverage
or greater.
Snap Creator Agent Requirements
7. Functional
7.1 Every Plugin shall add a versioning method or API call to the Describe
operation.
7.2 An API call shall be added to the Agent to collect installed plugins
7.3 An API call shall be added to the Agent to plugin versions

9
7.4 An API call shall be added to the Agent to agent system information.
8. Non-functional
9. Constraints
9.1 Additional non-GUI code added to the SC agent must maintain 70% test
coverage or greater.
External Dependencies or Interfaces
● The Snap Creator framework is an Eclipse package and thus requires Eclipse
to build the project.
● Java Development Kit 1.6 or 1.7
● All of the Snap Creator source code is located online using Github.com in a
Git repository and requires a Github account AND approval from the
development team in order to clone the repository.
● Apache Ant is used for parts of the framework’s build process for the SC
Server.
● Ruby or Perl may be installed for various Snap Creator Plug-ins.
● The OS that the server VM runs on will need to be determined.
Design
High Level Design
At a high level, the Update Center is a new piece of software that is being created
and hooked into the existing Snap Creator framework. Below is a diagram of the
system.

10
FIGURE 1
The Snap Creator framework is shown above (figure 1) in blue and green, with blue
being parts that will not be modified and green being parts that will be modified.
Orange parts are new components that are being added by our team into the
system. At a high level, the Snap Creator server is responsible for controlling
several agents, which in turn are responsible for controlling several plugins. Each
agent and server can be of different versions. The server is controlled by the user
using the agent monitor GUI. Our components must hook into the Snap Creator
server and allow it to manage its own versioning as well as ensure that the
subsystems are all compatible.
Update Center API
Based on our requirements, the Update Center API must be a RESTful web service
that allows the existing Snap Creator server to connect to it. The server makes get
requests to the server and receives back formatted data. Essentially, the server can
fetch data about what the latest version of a plugin is, or what plugin versions are
compatible with a given agent. These servers will be run locally at NetApp and will
communicate with a single Update Center, meaning that one Update Center needs
to support several servers. Scalability is not a problem we have to solve as the
Update Center will only be handling a small number of servers.
Database
The Update Center has to store versioning data in order to be able determine what
to return to the Snap Creator server when it queries. It must do this using a
database. The database must be populate from somewhere, so the Update Center
also requires a web interface that enables a user to manually add, update, and
delete versioning information.

11
Users
This table keeps track of the users in the system. It uses names and emails to help identify
users and has encrypted password and remember tokens to support password-secure
sessions.
ID Int
Name String
Email String
Password string (encrypted)
Remember token string (encrypted)
Timestamp Datetime
Plugins/Agents/Servers
Plugins/Agents/Servers need to be conscious of their name and enough information to know
which version they are. They also need to know what operating system they are to
disambiguate between the same version for different OSes.
ID Int
Name String
Major Int
Minor Int
Revision Int
Build Int
OS String
Timestamp Datetime
Agent-Server Compatibility
The compatibility matrices will simply show which agents are compatibility with which servers,
given as IDs into their respective tables. These tables are implemented as a white list to show
what is compatible with what. Similar tables are constructed for Plugin-Agent and Plugin-Server.
Agent ID Int
Server ID Int
The database has three main tables - plugins, agents, and servers - as well as
cross-compatibility tables and a user table to track login information. Each plugin,
agent, and server will have an id, a name, a version broken up into integer values,

12
and a timestamp. Plugins do not need a unique identifier as they can be identified
by their name and version number. Cross compatibility tables will use id numbers
into other tables to determine what items are compatible with what. This means
that compatibility can be determined simply by looking into a table for an item with
id values equal to the id of the individual components. The users table has login
credentials as well as an encrypted password and session id. This is a simple
system that allows for a user to login to the system and remain logged in until they
log out, thus creating additional security measures to control who has access within
NetApp. It has also been stated that at some point the Update Center might be
accessible by plugin creators themselves, so authentication would be a must.
Admin GUI
There will be a small number of users that are required to interface with the Update
Center in NetApp, but it is important that they have a simple way to manage its
versioning data. For this reason, the Update Center web server has a simple
interface that allows a logged in user to view versioning data, create new data, and
modify or delete existing data through a user interface. Creating, modifying, or
deleting an entry brings up a dialog that allows the user to set the name and
versioning values, which are then checked to ensure the name and version
numbers are valid. This system is simple and straightforward and allows users to
easily modify the internal database that effectively controls the versioning for all
Snap Creator servers.
Snap Creator Server
Each Snap Creator server, for the purposes of the Update Center’s development, is
responsible for managing versioning for itself and all its subsystems (i.e., each
agent and plugin). It communicates with the Update Center directly by utilizing web
requests due to the fact that the Update Center and Snap Creator servers are
located on the same network. An existing GUI helps manage individual agents, to
which user interface elements will allow users to check and update to latest
compatible versions.
Low Level
At a low level, most of the design to be done was on the Update Center, as the
Snap Creator has already been designed and implemented by the NetApp Snap
Creator team. Ruby on Rails dictates using a model-view-controller pattern which
shaped a significant amount of our design process. The Update Center also is
required to control versioning for servers, agents, and plugins, meaning that each
of these need to be defined in code in a parallel manner.
Model
The model portion of the Update Center is the database. Entries are created, read,
updated, and deleted by the controller. The database is only ever modified by the
controller and not directly by the user. It manifests itself as an SQL database that is

13
created and modified in Ruby on Rails code. It is also vital that data is validated as
it enters the model to ensure that elements are correctly formatted.
View
Users have to be able to control the information that is available in the database,
but they cannot do so directly due to the manner that model-view-controller works.
The view consists of the user interface that is shown to the user through the web
and allows the user to manipulate the database through it. The view is outlined
below in UI design and manifests as formatted web pages utilizing Twitter
Bootstrap in order to be readable and straightforward. The Snap Creator server will
never utilize the view when getting version and compatibility data from the Update
Center.
Controller
The controller is the glue between the model and view and represents the way in
which elements of the view affect the model and vice versa. When the Snap Creator
server makes a web request, it will go directly through the controller, check the
model for information it needs to determine the return values, and then return
JSON back as text.
User Interface Design
The user interface is primarily focused on being simple and straightforward for
technical users. The Update Center will only be utilized directly by the NetApp Snap
Creator team and approximately only every six months when they do a major
release. As a result, we wanted the user interface to be easy for them to use but
did not want to put in a large amount of work into creating a perfect, layman-
friendly interface. Our interface is intended to model a database that we hope will
be easy for the technical users to understand. We also wanted to ensure that the
color scheme of the site matched NetApp for the sake of consistency.
Below are some mockups that were created by Santosh.

14
FIGURE 2
The above mockup (figure 2) shows a sample list of items as they would be
displayed on the web server.

15
FIGURE 3
Here is a similar page (figure 3) using the actual implemented user interface.
Plugins are displayed in a tabular format with options to create a new plugin as well
as show or edit an existing plugin.
Implementation
More info to be added.
Test Plan & Results
See the separate document named Testing Guide.docx for many more details
including steps to setup the local environment for testing. We are using Rspec for
Ruby to conduct unit testing. We currently have 39 unit tests covering the user and
plugin classes using Rsepc. All unit tests are currently passing.
Rpec output
The output from Rspec will list the time taken to run the test, the number of "examples" or test
run, and the number of failures. When all test are passing you will see a similar output as below,
each dot on the top line is a test that was ran. Below we took 0.27518 seconds to run the test
and ran 39 tests and had 0 failures.

16
.......................................
Finished in 0.27518 seconds
39 examples, 0 failures
Randomized with seed 37381
If a test case fails its dot will become a 'F' to reflect the failure (see example below) and also
Rspec will also give additional information to help you locate the failure.
For each failing test Rspec will list
1. the test name,
2. the assert that failed
3. the expected outcome
4. location of the file containing the failing test
An example output with a failing test is below
.........F.............................
Failures:
1) User when password confirmation != password
Failure/Error: it { should_not be_valid }
expected #<User id: nil, name: "Example User", email: "user@example.com", created_at:
nil> not to be valid
# ./spec/models/user_spec.rb:88:in `block (3 levels) in <top (required)>'
Finished in 0.23503 seconds
39 examples, 1 failure
Failed examples:
rspec ./spec/models/user_spec.rb:88 # User when password confirmation != password
Randomized with seed 13879
In the above output
● the test name is shown in the line
1) User when password confirmation != password
● the assert that failed in the line
Failure/Error: it { should_not be_valid }
● the expected outcome in the line

17
expected #<User id: nil, name: "Example User", email: "user@example.com", created_at: nil>
not to be valid
● the location of the file containing the failing test, the line number of the failing test
and the failing test name with the output
rspec ./spec/models/user_spec.rb:88 # User when password confirmation != password
Note if you are getting failing test that really should be passing, try restarting the server.
At this time the standard testing suite for Ruby does NOT have a code coverage tool. Through
some digging we have found one called Rconv. However at this time we have not been able to
get this tool working. The final report should include full code coverage reports from Rconv
Selenium
For integration and acceptance testing we are using Selenium IDE. Selenium can be
used in many ways. We are using the Selenium IDE through the Selenium Firefox
plugin. This testing suite is currently using Firefox version 24 with the Selenium Plugin.
The selenium folder contains a subfolder for each suite of tests, for example the
signin_page_test subfolder contains the test suite for the signin page. The test suites
and individual test are stored as .html file and the full test suite for each folder will have
a filename ending in test_suite.
For example the test suite for the user sign in page is named
signin_page_test_suite.html and its relative path is
seleniumsignin_page_testsignin_page_test_suite.html
To open a test suite, in the Selenium window you want to click File -> Open Test Suite...
Then browse to the Update Center root folder, then into the selenium folder where all
Selenium test are contained. To open the signin page test suite navigate to the folder
seleniumsignin_page_test Then open the file named signin_page_test_suite.html
Selenium now has the test suite loaded and it is ready to run. The example below has
the signin_page_test_suite.html loaded

18
The individual test cases for the test suite are listed in the left column. The actual test
code is located in the right hand pane in the shot above. To run the entire test suite click
the green arrow button with the three green rectangles
To run just the single test highlighted in the left pane click the green arrow with only one
green rectangle.
After running the entire test suite you will see an output screen similar the one below.

20
Black Box Test Plan - Selenium
Test Suite for Sign Up page
Correct Content Test for Sign Up Page
content_correct
Open /signup
assertTitle Update Center
assertText css=h1 Sign up
verifyElementPresent id=user_name
verifyText css=label Name
verifyElementPresent id=user_email
verifyText //form[@id='new_us
er']/label[2]
Email
verifyElementPresent id=user_password
er']/label[3]
Password
verifyElementPresent id=user_password_
confirmation

21
er']/label[4]
Confirmatio
n
verifyElementPresent name=commit
verifyValue name=commit Create my
account
verifyElementNotPresent link=Home
verifyElementPresent link=Sign in
verifyText link=Sign in Sign in
Check Signin Link is Valid on Sign Up Page
signin_link_valid
Open /signup
assertTitle Update
Center
assertText css=h1 Sign
up
verifyElementNotPresent link=Home

22
clickAndWait link=Sign in
assertTitle Update
Center
verifyText css=h1 Sign in
Check Username field is validating correctly on sign up page
username_checks
Open /signup
Type id=user_name
Type id=user_email test@test.com
Type id=user_passwo
rd
Password
Type id=user_passwo
rd_confirmation
Password

23
clickAndWait name=commit
verifyElementPresent css=div.alert.ale
rt-error
assertText css=div.alert.ale
rt-error
The form contains
2 errors.
verifyElementPresent id=error_explan
ation
verifyText css=#error_expl
anation > ul > li
exact:* Name can't
be blank
verifyText //div[@id='error_
explanation']/ul/li
[2]
exact:* Name is
too short
(minimum is 4
characters)
Open /signup
Type id=user_name this_name_is_reall
y_really_really_too
_long
Type id=user_email test@test.com
Type id=user_passwo
rd
Password

24
Type id=user_passwo
rd_confirmation
Password
verifyElementPresent css=div.alert.ale
rt-error
verifyText css=div.alert.ale
rt-error
The form contains
1 error.
verifyElementPresent css=#error_expl
anation > ul > li
verifyText css=#error_expl
anation > ul > li
exact:* Name is
too long
(maximum is 40
characters)
Check Email Field is validating correctly on sign up page
email_checks
Open /signup
Type id=user_name Blank Email User

25
Type id=user_email
Type id=user_pass
word
Password
Type id=user_pass
word_confirm
ation
Password
verifyElementPresent css=div.alert.
alert-error
verifyText css=div.alert.
alert-error
The form contains 2
errors.
verifyElementPresent css=#error_ex
planation > ul
> li
verifyText css=#error_ex
planation > ul
> li
exact:* Email can't be
blank
verifyText //div[@id='err
or_explanatio
n']/ul/li[2]
exact:* Email is
invalid
Open /signup

26
Type id=user_name Invalid Eamil Format
User
Type id=user_email test@test
Type id=user_pass
word
Password
Type id=user_pass
word_confirm
ation
Password
alert-error
alert-error
The form contains 1
error.
planation > ul
> li
planation > ul
> li
exact:* Email is
invalid
Open /signup

27
Type id=user_name Invalid Eamil Format
User
Type id=user_email i@valid.does not
work
Type id=user_pass
word
Password
Type id=user_pass
word_confirm
ation
Password
alert-error
alert-error
The form contains 1
error.
planation > ul
> li
planation > ul
> li
exact:* Email is
invalid
Open /signup

28
Type id=user_name Email Too Long
Type id=user_email this_email_address_i
s_longer_than_40_ch
ars@aol.com
Type id=user_pass
word
Password
Type id=user_pass
word_confirm
ation
Password
alert-error
alert-error
The form contains 1
error.
planation > ul
> li
planation > ul
> li
exact:* Email is too
long (maximum is 40
characters)

29
verify Password field is validating correctly on sign page
password_checks
Open /signup
Type id=user_name Password is
Blank
Type id=user_email INvalid12@aol.c
om
Type id=user_passwor
d
d_confirmation
verifyElementPresent css=div.alert.alert
-error
verifyText css=div.alert.alert
-error
The form
contains 2 errors.
verifyElementPresent css=#error_expla
nation > ul > li
verifyText css=#error_expla exact:* Password

30
nation > ul > li can't be blank
verifyText //div[@id='error_
explanation']/ul/li[
2]
exact:* Password
is too short
(minimum is 6
characters)
Open /signup
Type id=user_name Password is Too
Short
Type id=user_email not_valid@aol.co
m
d
12345
d_confirmation
12345
-error
-error
The form
contains 1 error.
nation > ul > li

31
verifyText css=#error_expla
nation > ul > li
exact:* Password
is too short
(minimum is 6
characters)
Open /signup
Type id=user_name Password_Confir
m Error
Type id=user_email total_INvalid@ao
l.com
d
123456
d_confirmation
123455
-error
-error
The form
contains 1 error.
nation > ul > li

32
verifyText css=#error_expla
nation > ul > li
exact:* Password
confirmation
doesn't match
Password
Test for a Valid Sign Up on sign up page
valid_signup
Open /signup
verifyElementPresent css=h1
verifyText css=h1 Sign up
Type id=user_name New User
Type id=user_email legit@email.co
m
Type id=user_password Password
Type id=user_password
_confirmation
Password

33
verifyElementPresent css=div.alert.alert-
success
verifyText css=div.alert.alert-
success
Signed in!
verifyText css=h1 New User
legit@email.co
m
Check home link is valid on signup page
home_link_valid
Open /signup
assertTitle Update
Center
assertText css=h1 Sign up
verifyElementPresent link=Home
verifyText link=Home Home
verifyElementNotPresent link=Sign in

34
clickAndWait link=Home
assertTitle Update
Center
verifyText css=h1 Test
Page
TestSuite for User Sign In Page
Check for correct content on signin page
content_correct
open /signin
assertTitle Update
Center
verifyElementPresent id=session_e
mail

35
verifyText css=label Email
verifyElementPresent id=session_p
assword
verifyText //label[2] Password
verifyElementPresent name=commi
t
verifyValue name=commi
t
Sign in
verifyText css=p exact:New user?
Sign up now!
verifyElementPresent link=Sign up
now!
verifyText link=Sign up
now!
Sign up now!
Check that the Signin link is valid on the sign in page
signin_link_valid
open /signup

36
assertTitle Update
Center
assertText css=h1 Sign
up
clickAndWait link=Sign in
assertTitle Update
Center
Check that Signup link is valid on sign in page
new_user_signup_link_valid
open /signin
assertTitle Update
Center

37
verifyText css=p exact:New user?
Sign up now!
verifyElementPresent link=Sign up
now!
verifyText link=Sign up
now!
Sign up now!
clickAndWait link=Sign up
now!
assertTitle Update
Center
verifyText css=h1 Sign up
Test for Unregistered User Sign In Page
user_not_registered
open /signin

38
type id=session_email testing@email.
com
type id=session_pass
word
Password
-error
-error
Incorrect
credentials
Test Valid user sign in on Sign in page
valid_user_signin
open /signin
verifyElementPresent link=Sign up now!

39
verifyText link=Sign up now! Sign up
now!
clickAndWait link=Sign up now!
type id=user_name Valid User
type id=user_email valid3@aol
.com
type id=user_password Password
type id=user_password_co
nfirmation
Password
verifyElementPresent css=div.alert.alert-
success
verifyText css=div.alert.alert-
success
Signed in!
Additional Black Box Acceptance test and additional Unit test will be added here as
they are completed.
Please see the separate document titled Testing Guide
for more details and setup information.

40
Suggestions for Future Teams
One of the largest issues our team had to deal with are sync and commit issues in
GitHub. We decided to use the GUI manager to do commits and pulls from the
server because it seemed easy to use. There have been multiple issues with us
using the “sync” action to push our commit that would make the branch unstable.
In the future I would suggest that there should be a couple meetings within the
team to learn about GitHub and how to use it to prevent any large issues to the
branch.
Iteration planning was also another problem we had near the beginning of the
project. It is beneficial to the team if there are well defined requirements and
stories for each iteration before the iteration starts. This will allow you to work
more on your tasks than trying to figure out what you need to be doing.
Ruby on Rails was a new framework and language for us to learn and develop.
Because of this most of our first iteration went to researching and learning. If you
are not familiar with this framework do plan for a couple of weeks of learning before
developing.

41
Task Plan
Team 14 Task Plan
Item Owner(s) Due Date Status
Iteration 1 ALL 9-24-2013 Complete
● OPR 1 ALL 9-13-2013 Complete
● Setup and research ALL 9-24-2013 Complete
● Setup Development
Environment
ALL 9-24-2013 Complete
● First draft of Interim
Progress Report (IPR)
● Set up basic Ruby on Rails
web server
Zack 9-24-2013 Complete
● Create database structure
for plugins
Dylan 9-24-2013 Complete
● Create mockups for UI
interface for Update Center
Santosh 9-24-2013 Complete
● Ensure that plugins in the
database can be managed via a
controller
● Add sample testing data
into the model
Dylan 9-24-2013 Complete
● Add a web request to find
latest version for a plugin
● Do Tech exploration and
Design testing framework for our
project
Jason 9-24-2013 Complete
Iteration 2 ALL 10-08-2013 Complete
● Create Acceptance Test for
Sign up webpages
● Create migrations for server Dylan 10-08-2013 Complete

42
and agent tables
● Create Acceptance Test for
Sign up webpages
● Create Installation Guide Jason 10-08-2013 Complete
● Admin can create, update,
or delete items from the UI
● OPR 2 Zack 10-07-2013 Complete
● Plugin data validation
before saving
● Start API Documentation Dylan 10-08-2013 Complete
● Finalize database schema Zack 10-08-2013 Complete
● Add unit test for User class Jason 10-08-2013 Complete
● Form for put/posting data Santosh 10-08-2013 Complete
Iteration 3 ALL 10-22-2013 In
progress
● Investigate SC Framework
Code Base for Version API addition
Jason 10-22-2013 In
progress
● Resolve remaining SC-
Framework build issues
● Update Draft Interim
Project Report to Final Interim
Project Report
● Create Acceptance test for
Plugins page
Jason 10-22-2013 Not
started
● Convert Acceptance test for
Sign In page to Selenium
● Convert Acceptance test for
Sign Up page to Selenium
● Web requests for
determining what
Plugins/Agents/Servers are
compatible with a given
component

43
● Convert Installation and
Testing Documents to Github
Markdown Language
Jason 10-22-2013 Not
started
● Update Document with
Chuck's suggestions
Zack 10-22-2013 In
progress
● Seed database with more
data
Dylan 10-22-2013 In
progress
● Create remaining database
table migrations
Dylan 10-22-2013 In
progress
● Work on IPR ALL 10-21-2013 In
progress
Posters & Pies ALL 12-6-2013 Not
started
Installation Documentation Jason 12-13-2013 In
progress
Final Presentation ALL 12-13-2013 Not
started
Developer's Guide
See separate document titled Developer Guide
User's Guide
See separate document titled User Guide
Installation Guide
See separate document titled Install Guide

NetApp Update Center Interim Report

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to NetApp Update Center Interim Report

Similar to NetApp Update Center Interim Report (20)

NetApp Update Center Interim Report