Finalprojectdraft

Georgia Southern University
Brown and
Donaldson tested
with Selenium
Software Testing and Quality Assurance
Dr. Vladan Jovanovic
Stephen Daniel
ONeal Jones
Robert McLaughlin
Scott Morris
Alex Welk
4/15/2015
Group 6 Page 1
Table of Contents
Team Organization
Page 2
SQA Plan
Page 3
Tools
Page 5
Standards
Page 6
Assumptions
Page 7
Website Organization
Page 8
SRS Overview
Page 9
Test Plans
Page 10
Conclusions
Page 15
Post Mortem
Page 16
References
Page 18
Appendix
Page 19
Group 6 Page 2
Team Organization
Team Member:
Roles:
Responsibilities:
Stephen Daniel
System analyst
Analyzes software.
Software Tester
Tests software.
Manager
Leads Project.
Software Tester
Tests software.
Scribe
Helps write paper.
Test Planner
System Analyst
Lead Scribe
Prepares Test Plan.
Software Tester
Tests software.
Scribe
Helps write paper.
Software Tester
Tests Software.
Scribe
Helps write paper.
ONeal Jones
Robert McLaughlin
Scott Morris
Alex Welk
Analyzes software.
Writes paper.
Group 6 Page 3
Part A: SQA Plan

SECTION 1. ACTIVITIES
1.1 Activity: Review System
The group shall review the SUT for the purposes of understanding it and its
intended functionality. Each group member should conduct their own review by
using the site, and share what theyve learned with the rest of the group. the SUT
is described in Part C of the report.
1.2 Activity: Install, Review and Learn Testing Tools

The group shall learn the use and functionality of Selenium, the tool to be used for
this SQA. Each member who is to conduct tests needs to obtain a copy of the
testing tools and familiarize themselves with how to use it in the context of
verifying the SUT. If any group member has difficulty, they should seek help from
the rest of the group.
1.3 Activity: Evaluate System Features

The group shall further investigate the system after an initial review to determine
which features of the SUT may be most likely to reveal defects under testing, and
brainstorm possible tests to verify the features robustness.
This activity is to prepare the group to for devising and executing the various test
cases which will be used to evaluate the SUT, as well as engendering a greater
understanding of it.
1.4 Devise Testing/Report Management
Group 6 Page 4
This activity is to ensure there is a clear avenue of communication and peer-review
of the deliverables and their components as theyre made. This is the managers
responsibility to create and moderate as the project progresses.
Communication of results and ease of access to the planning documents is
essential to the success of the project, as planning documents may as well not
exist if they are unavailable to those meant to execute them. In addition, if the vital
information pertaining to the report is distributed and unavailable, compiling it
becomes an exercise in inefficiency.
1.5 Activity: Create and Evaluate Test Plan

This activity ensures that there is concrete plan for verifying the SUT. The test plan
shall comply with IEEE 829 standards, and must be evaluated and verified by the
group before ultimately being approved by the manager.
The test plan should be as comprehensive as possible, as to facilitate the
verification of the SUT, ensure the whole group is of one mind going into testing,
and otherwise keep progress moving forward.
1.6 Activity: Standardize Use Case Reporting

This activity is to ensure that the group members have a standard to use when
reporting the results of their tests. There should be a format and labelling for the
test and use cases, as well as a means for the tester to communicate additional
notes, if necessary, while keeping the the reports consistent.
1.7 Activity: Schedule and Check in

The group shall check in with the manager at least once every two weeks to share
progress made, if any, and receive new advisement if necessary on future course
of action. If theres an urgent matter or adjustment to the standing plan, the
manager will inform the rest of the group.
Group 6 Page 5
SECTION 2. TOOLS
2.1 Selenium
The major tool in use will be Selenium, as it allows automation of test cases on web
browsers.
2.2 Eclipse and Java

The automated test cases for Selenium will be written and run in Java, using the
Eclipse IDE, as everyone in the group is familiar with the language and
environment, allowing for minimal time to be wasting when learning the ins and
outs of Selenium.
Group 6 Page 6
SECTION 3. STANDARDS
3.1 IEEE 829
The test plan will be written and executed complying with IEEE 829 standards.
Group 6 Page 7
SECTION 4. ASSUMPTIONS
4.1 Intended For Deployment
The group shall keep the attitude while testing that the SUT is intended to be
deployed and used by clients as a serious product. This is important to clarify
because the SUT was in fact made for the academic purpose of being tested.
Despite this, the group has decided to treat as a serious piece of software to
maintain the perspective of a tester verifying a system.
4.2 No Perfect System

The group shall hold the assumption that the system is not perfect, and will not be
perfect. It is the goal of the testers to find as many defects as possible to ensure
the system would hold up to common use in the case that the defects found were
corrected.
4.3 The Group Contributes Equally

For the testing and QA to be successful, there must be the assumption that all
parts contribute equally to the whole and successfully carry out their role.
4.4 The Group Follows the Plan

The plan assumes, of course, that it must be followed to be successful.
4.5 No Major Failures

The group assumes there will be no insurmountable problems or system failures
that wholly halt the process, and that any issues that arise can be dealt with in a
timely manner.
Group 6 Page 8
Group Collaboration (Web

Organization)
Each group member will submit their contributions to the project as a whole on a
shared Google Drive folder, owned by the manager. From there, everyone in the
group has access to see whats been so far and what has yet to be done. Google
Drives flexibility and link to gmail makes it ideal for collaboration and
communication as the group tests the system and compiles the results.
Communication will be chiefly through gmail, with meetings held in person as
necessary to the completion of the software testing and report.
Group 6 Page 9
SRS Overview
An official SRS for the system is unavailable, but after an analysis, the SUT is
meant to allow for the buying and selling of fake virtual stocks, as well as provide
means to search through a database of company symbols, view the stocks you
have and get quotes on stock prices. An important detail of the SUT is that while it
has functional features as described, it was created for the purpose of being tested
by students. This will not change the groups attitude that the SUT should be
resistant to defects, and the process will be treated as though they were verifying
real software meant to be used. Any other attitude would defeat the purpose of the
exercise. See the appendix for an overview of the site and its features.
Group 6 Page 10
Test Plan
This Test Plan shall be identified by G6TP-1, being Group 6s Test Plan: version 1.
References
Documents that support the methodologies and strategies used in this Test Plan
are the various documents available in the modules provided to V Jovanovics
Software Testing and QA class at Georgia Southern University in the Spring of 2015.
Introduction
This Plans purpose is for the testing and verification of the features made available
by the B&D stock trade site. The tests are academic in nature, meant for the
testers to learn the process of testing software and ensuring its quality. The tests
will be made using the Selenium web-testing software through Eclipse.
Test Items
The scope of this test includes all features of the B&D site that allow for user input.
The version of the site is 1.0, circa 2000.
Software Risk Issues

As this is an academic venture to test the software, with no requirement or
intention to fix discovered defects or client to deliver to, there are no risks related
to the software itself.
Features To Be Tested
The features to be tested include:
The creation of a new account: low risk
Group 6 Page 11
Logging into an existing account: high risk
Trading assets: medium risk
changing password: high risk
searching tags: low risk
canceling orders: medium risk
Getting a quote: low risk
Features Not To Be Tested

The following features are considered trivial and will not be tested:
Approach
The strategy to be employed is to devise a comprehensive set of tests for the
features of the site. The main points of vulnerability to be considered and tested
are text entry, as it is the main way for the user to interact with the site, and there
are many possibilities for defects to appear. After tests are devised, they will be
distributed them across the group to be carried out using Selenium. The members
will then document the results, including any notes they have about the test itself
or the results of the test. The metric of each test will simply be a pass or a fail per
case, with what constitutes passing or failing decided on a per test basis. Results of
the tests will be collected in a shared google drive for review before finally being
incorporated into the final report. Meetings will be held as deemed necessary, and
an open channel of communication will kept through email.
Item Pass/Fail Criteria

The plan will be considered complete when all test cases have been run to
completion. If it appears that more test cases would, with the confidence of the
group, produce additional meaningful or undiscovered defects, more test cases
may be devised and the plan may continue until the testing group is satisfied or
the due date is reached.
Group 6 Page 12
Suspension Criteria and Resumption

Requirements
Suspension criteria for tests is ultimately at the discretion of the individual tester to
suggest and the group to approve on a per case basis. As the point is not only to
test the software, but to learn about the process itself, suspension of a test should
be discussed by the group. As a rule of thumb, a test should be suspended if
further testing would be trivial or repetitive. For instance, if including an
apostrophe( ) at the end of a username does not produce a defect, it would be
unnecessary and a waste of resources to test 100 different usernames with an
apostrophe at the end. Resumption may occur when all tests have been completed
and the group agrees returning to one or more may be worthwhile.
Test Deliverables
Test Plan Document
Test Cases and Notes
Tools and Outputs
Possible solutions to discovered defects
Final Report
Training Needs
As Computer Science students, training is unnecessary; the testing team is more
than capable of learning new tools and aiding one another when the need arises.
Responsibilities
Stephen Daniel completed test cases for open orders and cancel orders.
ONeal Jones completed the test cases for the change password and login.
Group 6 Page 13
Robert McLaughlin completed the test plan document.
Scott Morris completed the test cases for create account and trading.
Alex Welk completed the test cases for orders and look up quote.
Schedule
Design Test Plan and Learn Tools
Brainstorm tests to verify features
Carry out tests
Compile results
Compile report
Planning Risks and Contingencies

1) Issues may arise from unexpected complexity of tools, in which case different
tools may need to be chosen or someone with deeper knowledge of them may
need to be contacted.
2) Other academic projects and responsibilities may distract group members from
the project, in which case the group will need to come together and create a
clearer plan and division of work. In addition, group members may not be
contributing to the load evenly, and if a compromise cannot be reached, the
instructor may need to intervene.
3) Group members may produce malformed test cases if they misunderstand the
requirements. If this is the case, the group may need to convene to make sure
everyone shares an understanding of the requirements and definitions.
4) It may be difficult or impossible to determine what the expected output for a
given test should be, in which case it would be necessary to either find a test case
that produces a very clear defect, or document that particular test as necessary to
abandon, with included reasoning.
Approval Process
Group 6 Page 14
The group as a majority has final say on when a process is complete and the next
step forward should be made, as the scope is small enough for everyone to
understand the whole of the process. If there is no clear consensus, the manager
has final say.
Glossary
The Group: the individuals working to test B&D; Group 6 of the Software Testing
and QA class.
Selenium: automated browser testing tool.
Selenium WebDriver: browser-based regression automation suites and tester
Selenium IDE: Standalone automation-aided for creating scripts to test
JUnit: Framework to write repeatable tests in Java.
Eclipse (Java): IDE for Java based coding.
Firefox: customizable non-profit web browser.
SQL Injection: code injection technique, used to attack data-driven applications, in
which malicious SQL statements are inserted into an entry field for execution.
Glossary for Website:
B&D: the site under test, available at bdonline.sqe.com.
Good Till Canceled: GTC: An order that remains in effect until it is either executed
or canceled. If the order is not renewed within thirty calendar days, it will be
systematically canceled at the end of the trading day indicated on the order. All
orders with Saturday or Sunday expiration dates expire at the end of the previous
trading day.
Holdings: The amount held in each asset class.
Limit Price: Price instruction on a buy or sell order. With a sell limit order, the
customer is instructing that the sale be made at or above the specified price. With
a buy limit order, the customer is instructing the purchase be made at or below the
specified price.
Open Orders: Any unexecuted order to buy or sell securities that has not been
canceled.
Group 6 Page 15
Stock: An instrument that signifies an ownership position, or equity, in a
corporation, and represents a claim on its proportionate share in the corporation's
assets and profits.
Symbol: A system of letters used to uniquely identify a stock or mutual fund.
Symbol Look-up: Use to find a symbol by entering a company name and selecting
"Symbol Look-up".
Conclusion
Testing revealed several defects in the system, and the group has determined it
would not be ready for commercial deployment.
Group 6 Page 16
Post Mortem
Stephen Daniel:
Web application software testing through Seleniums automation techniques,
user friendly GUI, extensive support, and instant feedback makes it must have tool
for testing. The tools learning curve spans from learning the basics in the matter of
minutes (great for an entrepreneur who isnt tech suave) to weeks by designing
complex (but not complicated) techniques of testing software. Selenium allows
users to export the automation testing and test cases to various well known
programming language, allowing for the potential of the testing tool to exceed
many other tools.
Seleniums IDE is easy to install and set up and use. The process only took a
matter of minutes before it was up and running. Designing the test cases were
trivial with extensive guide and support offered online. The built in options allows
anyone to design test cases on a large scale thanks to the abundant amount of
given options. The greatest gift Selenium offers is the automation process, which
speeds up the testing significantly, allowing the user to run even more test within a
given time.
Group 6 Page 17
Seleniums ability to export test cases to various programming languages
(such as Java using JUnits) gives the user a limitless potential to create almost any
test case they desire. Test cases can provide instant feedback and easily catch
unexpected errors. Adding new test cases were just a matter of adding one extra
line to the code, allowing the user to test any case he/she desires exhaustedly.
Setting up JUnits with Java is a more complicated than using the IDE itself because
of the very nature of programming in a computer language, but thanks to online
documentation and the built in libraries of Selenium, testing with Java is not nearly
as complicated as one would think.
Eugene Jones:
Selenium was a very user-friendly tool for testing a web application. Being
able to export the material to JUnit made this a familiar testing tool but new
enough to have to sit down and read documentation on how to use it. The
automation of this tool also helped for making test cases that seemed repetitive.
As a group we had a chance not only to learn about a new testing tool but we also
got some hands on experience using Selenium to test a web application. Not only
did group 6 get the chance to learn a new testing tool we also got a taste of IEEE
829 formatting. This formatting experience could prove to be useful depending on
the route we as individuals take in the workforce.
Robert McLaughlin:
Over the course of this project, I had to look up and read a lot about quality
assurance, and went through many SQA and test plans written for other systems.
Over the course of this, it became clear that standards and guidelines are just that.
You cant just follow them to the exact letter to achieve the goal; you have to read
and assess the spirit of the standard, and understand why its recommending what
it does, if you want to devise a successful and meaningful plan. Something I would
take away from this experience for the future is to take more time at the start and
again near the middle to go over the plan, and make sure everyone has a similar
understanding of whats trying to be accomplished.
In addition, its made it very apparent how important knowledge and
experience of the domain is for making effective tests on the system. You can
approach something as systematically as you want, at some point you need
intuition to know what needs to be done.
Scott Morris:
Quality assurance is a concept that many have heard of, but few are actually
familiar with. Throughout the QA and testing course I have gained a much more
concrete understanding of that concept. After devising, implementing, and
Group 6 Page 18
analyzing test plans for a system I had not seen before, my knowledge of QA is
something that I will carry with me into my career, regardless of whether I am
creating new systems or maintaining old ones. Any programmer can solve a
problem and create something that is useful, but QA gives that solution a
usefulness that goes beyond just problem solving by giving that solution greater
real-world applications.
Even though this course gave everyone an in-depth analysis of QA and
testing, I have realized that QA goes even further beyond what was covered in the
classroom. QA does not happen after a product is finished, instead it is devised
before typing any code and takes place during the entire software engineering
process. This project and this course have helped to remind me that I cannot
approach software development from a single frame of mind, and it is a lesson that
I will carry into every project I am a part of throughout my career.
Alex Welk:
For this project, we wanted to design and implement a test plan to test a
web application. We went through many different ideas on how to format our test
plan and what web application to test. We communicated entirely through email,
which while easy, was not the most efficient. I think a in person meeting at the
beginning of the process would have been more effective at ironing out some
problems. I think one efficient thing we did was to make standard templates that
way each team member could simply fill it out thus ensuring they had provided all
pertinent information.
One of the most discussed points we had in our email was about choosing
the web app to test. We originally decided Reddit because we assumed the
functionality would be simple enough, but it proved a bit too complex. We finally
decided on our final choice because the functionality is straightforward enough and
because of its flaws so that we could design tests to fail.
I found that Selenium was a very user-friendly and effective tool to use. The
ability to record your actions may be simple and rudimentary, but being able to
export the recorded actions to JUnit is very handy. With JUnit code, we could modify
it to take different parameters and run a whole set of test cases.
References
[3] Brown and Donaldson, 'Brown and Donaldson', 2015. [Online]. Available:
https://bdonline.sqe.com/. [Accessed: 25- Apr- 2015].
Group 6 Page 19
[2] Seleniumhq.org, 'Selenium - Web Browser Automation', 2015. [Online].

Available: http://www.seleniumhq.org/. [Accessed: 25- Apr- 2015].
[1] Uccs.edu, 2015. [Online]. Available:
http://www.uccs.edu/Documents/tboult/SQA_Plan_Template.doc.
[Accessed: 25- Apr- 2015].
Appendix
Homepage:
Group 6 Page 20
Group 6 Page 21
UCSD-0 Holdings:
Group 6 Page 22
Group 6 Page 23
Group 6 Page 24
UCSD-0:
View holding area is the area where successful transactions are reflected and
updated. This occurs when the transaction is valid and the user buys or sells stock
at market price. If the user selects to buy or sell option at limit price, the open
orders section should be update rather than the view holdings area. Orders
purchased with the limit option where deferred to the open orders and not view
holdings, however when selling stocks using the limit option the view holdings area
was updated to include that transaction. This should not be the case. All cases
reflected the market purchases seemed to work along with limit buying option, with
only limit sell option not working.
The last screenshot shows the test cases predicted outcomes used for this
test case. By plugging in values for the the test cases that the user expected to be
the output, we can receive feedback if the test failed or pass. As shown the test
cases in which the sell limit option failed.
-SD
Group 6 Page 25
UCSD-1
Group 6 Page 26
Group 6 Page 27
UCSD-1:
Open order was tested with view holding section in mind. Open orders
reflected stocks being sold with the limit purchase or selling option. Similar to the
view holding section, when the user tried to sell stocks using selling limit option it
was not reflective in the open order. Buying stock options however was. These test
cases did not test to sell if the user could cancel an order as other test cases were
used to do so. Test cases seeing if the open orders with the day timing expiring at
the end of the next available business day was tested in another test case set.
-SD
UCSD-2
Group 6 Page 28
UCSD-2:
After the user made their selections two day previous we examine the
results of our new open orders page. The stock option that were selected with the
day time limit did indeed expire at the end of the next business day. The one(s)
that had GTC did. It appears that this feature of the website works as intended. GTC
will expire after thirty business days, however this project did not permit the
allowed time to test such feature.
Group 6 Page 29
UCAW-0:
Group 6 Page 30
UCAW-0:
The cancel open order feature is very stable given that the user has
successfully logged in. Every test passed as the system handles every
alternate flow effectively. Namely, handling if there are no open orders and
when the user removes orders without selecting one.
-
A. Welk
Group 6 Page 31
UCSM-0:
Group 6 Page 32
UCSM-0(above): Similar to other test cases, this one resulted in uncovering another
database query flaw. When the site queries the database for a list of symbols,
entering a single quote in the textbox and clicking the trade button will result in a
database error, even showing the section of the query that went wrong. Thankfully,
this issue does not pose much of a security threat, as the character limit in the
textbox is very small. SQL injection is not a possibility here, but the issue of having
the site break and show code still remains. Outside of security considerations, this
screen was tested mostly with boundaries in mind. The site handles these issues
Group 6 Page 33
relatively well and manages to give clear feedback on what went wrong so that the
user can make amends and trade stocks successfully.
-S Morris
UCSM-1:
Group 6 Page 34
Group 6 Page 35
UCSM-1(above): Test cases here were generated to make sure that the site gives
proper feedback to the user if account creation should fail. There was also a
field that allows the user to enter a sum of money for the account (no more
than $1,000,000 and no less than $1,000), so that had to be boundary
tested. The site provides proper feedback for things such as existing
usernames and invalid passwords, but an interesting event occurs when
single quotes are placed in front of the username or email. Instead of
throwing database query errors as before, the site simply tells the user that
the account already exists, which is not true. These tests were recorded as
failures on the basis that the wrong error was thrown. The site also does not
mention the minimum or maximum balance amounts before account
creation, which could be an for inconvenience for the user.
-S Morris
Group 6 Page 36
UCEJ-0:
UCEJ-0: The login system for any website is extremely important and should
be flawless 99.99999% of the time. Especially when it is dealing with the
issue of money like a stock exchange website. This login system is very
prone to SQL injection or anything dealing with single quotes. It is also not
case sensitive as long as single quotes are around password. This is a very
poor way to handle any login system for anything. It makes an easy target
for an amutuer hacker. If single quotes are not added into the password text
field then the password has to be typed correctly. When the password is
typed incorrectly the system displays a message saying invalid username
Group 6 Page 37
and password combinations. Please try again. When the password is entered
correctly the user is taken to the Brown and Donaldson homepage.
-
E. Jones
Group 6 Page 38
Group 6 Page 39
UCEJ-1:
The change password system was a little tougher to break than the
regular login system. Out of fifteen tries the system only broke once. The
point in testing the change password system is to see if the users account
was taken how easy it would be for the hacker to manipulate the users
password. To change the password would be easy as long as the new
password matches the confirm password. However, if the user is changing
his or her password then the user should not be allowed to change the
password back to the old password. This would make the users account an
easy target especially if it has already been attacked once.
-
E. Jones
Group 6 Page 40
UCAW-1:
Group 6 Page 41
Group 6 Page 42
UCAW-1:
The quote lookup option fell victim to many of the same errors as
other use cases. This function is very forgiving and will search any input as a
substring of the available stock tickers. As such, it will accept symbols and
number as input, even though they are never found in stock tickers. It would
be best it it automatically stripped input of symbols or would not even
accept them. This would also fix its susceptibility to SQL injection as the
character makes the system throw an error.
-
UCAW-2:
A. Welk
Group 6 Page 43
Group 6 Page 44
UCAW-2:
The symbol lookup option fell victim to many of the same errors as the
quote lookup case. This function is very forgiving and will search any input
as a substring of the available stock tickers. As such, it will accept symbols
and number as input, even though they are never found in stock tickers. It
would be best it it automatically stripped input of symbols or would not even
accept them. This would also fix its susceptibility to SQL injection as the
character makes the system throw an error.
-
A. Welk
JUnit Code: For some repeatable test cases, parameterized JUnit was used to run
tests repeatedly. Other cases are not repeatable. This is because they are based on
the prices of stocks, which fluctuate, and as such may be valid or invalid from day
to day. Other cases cases are dependent on the success or failure of the previous
case. Thus after running a full test suite, it can not be repeated without the initial
condition being recreated. Because of these conditions, JUnit was used on tests
that are independent and remain their validity regardless of price or time.
Every test suite was configured to run each test with an expected result parameter
and would compare the actual result at the end. The pass/fail condition of every
test is thus dependent on whether the expected result matched the actual result,
just as in the test case. It should be noted that the pattern of passes and fails will
match exactly with the test cases above.
Group 6 Page 45
UCEJ-0:
package com.example.tests;
import
import
import
import
import
import
import
import
java.util.Arrays;
java.util.Collection;
java.util.concurrent.TimeUnit;
org.junit.*;
org.junit.runner.RunWith;
org.junit.runners.Parameterized;
static org.junit.Assert.*;
org.openqa.selenium.*;
Group 6 Page 46
import org.openqa.selenium.firefox.FirefoxDriver;
import org.junit.runners.Parameterized.*;
@RunWith(Parameterized.class)
public class Login {
private WebDriver driver;
private String baseUrl;
private StringBuffer verificationErrors = new StringBuffer();
private String user, passwd;
private boolean assertPage;
private boolean pass;
//Scenario true = Successful login
//Scenario false = Failed login
public Login(boolean pass, String user, String passwd){
this.pass=pass;
this.user=user;
this.passwd=passwd;
}
@Before
public void setUp() throws Exception {
driver = new FirefoxDriver();
baseUrl = "https://bdonline.sqe.com/";
driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
}
@Parameters
public static Collection<Object[]> data(){
return Arrays.asList(new Object[][] {
{true, "TestCase", "blah"},
{false, "TestCase", "blah1"},
{false, "TestCase", "1blah"},
{false, "TestCase", ""},
{false, "TestCase", "'blah"},
{false, "TestCase", "\"blah"},
{false, "TestCase", "'blah'"},
{false, "TestCase", "'b'l'a'h'"},
{false, "TestCase", "b1lah"},
{false, "TestCase", "blah"},
{false, "TestCase", "halb"},
{false, "TestCase", "'halb"},
{false, "TestCase", "'"},
{false, "TestCase", "'1'"},
{false, "TestCase", "\"\'hi\'\""},
{false, "TestCase1", "blah"},
{false, "TestCase'1'", "blah"},
{false, "\"", "blah"},
{false, "'TestCase'", "1'"},
{false, "'NO'", "blah"},
});
}
@Test
public void testLogin() throws Exception {
driver.get(baseUrl + "/login.asp");
assertEquals("B&D - Login Page", driver.getTitle());
Group 6 Page 47
driver.findElement(By.name("login")).clear();
driver.findElement(By.name("login")).sendKeys(user);
driver.findElement(By.name("password")).clear();
driver.findElement(By.name("password")).sendKeys(passwd);
driver.findElement(By.cssSelector("input[type=\"image\"]")).click();
if(driver.getTitle().equals("B&D - Market News")){
assertPage = true;
} else assertPage = false;
assertEquals(assertPage, pass);
}
@After
public void tearDown() throws Exception {
driver.quit();
String verificationErrorString = verificationErrors.toString();
if (!"".equals(verificationErrorString)) {
fail(verificationErrorString);
}
}
}
UCEJ-1
Group 6 Page 48
import
import
import
import
import
import
import
import
import
import
java.util.Arrays;
org.junit.*;
org.junit.runners.Parameterized.Parameters;
org.openqa.selenium.firefox.FirefoxDriver;
public class Changepasswd {
int scenario, assertPage;
Group 6 Page 49
String email, oldP, newP, verifyP, corr;
//Scenario 0 = Password changed
//Scenario 1 = Password not changed
public Changepasswd(int scenario, String corr, String oldP, String newP, String verifyP){
this.scenario=scenario;
this.corr=corr;
this.oldP=oldP;
this.newP=newP;
this.verifyP=verifyP;
}
@Parameters
{1, "blah", "blah", "''", "''"},
{1, "blah", "blah", "blah", "blah"},
{1, "blah", "blah", "", ""},
{0, "blah", "blah", "abcd", "abcd"},
{1, "abcd", "blah", "runn", "runn"},
{0, "abcd", "abcd", "1234", "1234"},
{0, "1234", "1234", "runner", "runner"},
{1, "runner", "'runner'", "runn", "runn"},
{1, "runner", "'1234'", "happy", "happy"},
{1, "runner", "'runner!'", "abcd", "abcd"},
{1, "runner", "'1'runner", "abcd", "abcd"},
{1, "runner", "runner", "abcd", "zyxw"},
{1, "runner", "runner", "abcd", "'1abcd"},
{1, "runner", "runner", "abcd", "'1'abcd"},
{0, "runner", "runner", "blah", "blah"}
});
}
@Before
}
@Test
public void testChangepasswd() throws Exception {
driver.findElement(By.name("login")).sendKeys("TestCase");
driver.findElement(By.name("password")).sendKeys(corr);
driver.get(baseUrl + "/change_password.asp");
assertEquals("B&D - Change Password", driver.getTitle());
driver.findElement(By.name("email")).clear();
driver.findElement(By.name("email")).sendKeys("blah@blah.com");
driver.findElement(By.cssSelector("input[name=\"password\"]")).clear();
driver.findElement(By.cssSelector("input[name=\"password\"]")).sendKeys(oldP);
driver.findElement(By.name("newpassword")).clear();
Group 6 Page 50
driver.findElement(By.name("newpassword")).sendKeys(newP);
driver.findElement(By.name("newpassword2")).clear();
driver.findElement(By.name("newpassword2")).sendKeys(verifyP);
driver.findElement(By.name("login_button")).click();
if(driver.findElement(By.cssSelector("BODY")).getText().matches("^[\\s\\S]*Your information has
been updated successfully\\.[\\s\\S]*$")){
assertPage=0;
}else assertPage=1;
assertEquals(assertPage, scenario);
}
@After
driver.quit();
}
}
}
UCAW-1:
import
import
import
import
import
import
import
java.util.Arrays;
org.junit.*;
Group 6 Page 51
import static org.junit.Assert.*;
import org.openqa.selenium.*;
import org.openqa.selenium.firefox.FirefoxDriver;
public class Quote {
String ticker;
//Scenario 0 = Valid input, display result
//Scenario 1 = Ticker not in database, display error message
//Scenario 2 = Invalid string, display error message
public Quote(int scenario, String ticker){
this.ticker=ticker;
}
@Before
driver.findElement(By.name("login")).sendKeys("narfbarf");
driver.findElement(By.name("password")).sendKeys("greenapple");
}
@Parameters
{0, "AAPL"},
{1, "ZZZZ"},
{2, "'"},
{2, ""},
{1, "44g4 4$"}
});
}
@Test
public void testQuote() throws Exception {
driver.get(baseUrl + "/quote.asp");
assertEquals("B&D - Quote", driver.getTitle());
driver.findElement(By.id("text1")).clear();
driver.findElement(By.id("text1")).sendKeys(ticker);
if(driver.findElement(By.cssSelector("BODY")).getText().matches("^[\\s\\S]*This is market data for
"
+ "informational purposes only\\. The accuracy of this data is not warranted\\.
Group 6 Page 52
[\\s\\S]*$")){
assertPage=0;
}else if(driver.findElement(By.cssSelector("BODY")).getText().matches("^[\\s\\S]*The ticker
symbol you entered is not valid\\. Please try again\\.[\\s\\S]*$")){
assertPage=1;
} else if(driver.findElement(By.cssSelector("BODY")).getText().matches("^[\\s\\S]*Please enter a
valid ticker[\\s\\S]*$*$")){
assertPage=2;
}else assertPage=3;
}
@After
driver.quit();
}
}
}
UCAW-2:
import
import
import
import
import
java.util.Arrays;
org.junit.*;
Group 6 Page 53
import
import
import
import
import
org.openqa.selenium.firefox.FirefoxDriver;
public class Symbol {
String input;
//Scenario 0 = Successful search, results displayed
//Scenario 1 = No input provided
//Scenario 2 = Successful search, no results found
public Symbol(int scenario, String input){
this.input=input;
}
@Parameters
{0, "Apple"},
{0, "Microsoft"},
{1, ""},
{2, "1234"},
{2, "'"},
{2, "!@#$"}
});
}
@Before
driver.findElement(By.name("login")).sendKeys("narfbarf");
driver.findElement(By.name("password")).sendKeys("greenapple");
}
@Test
public void testSymbol() throws Exception {
driver.get(baseUrl + "/symbol_lookup.asp");
assertEquals("Brown & Donaldson - Symbol Lookup", driver.getTitle());
driver.findElement(By.name("company")).clear();
driver.findElement(By.name("company")).sendKeys(input);
Group 6 Page 54
if(driver.findElement(By.cssSelector("BODY")).getText().matches("^[\\s\\S]*Company[\\s\\S]*$")){
assertPage=0;
}else if(driver.findElement(By.cssSelector("BODY")).getText().matches("^[\\s\\S]*Please specify a
company before attempting a search\\.[\\s\\S]*$")){
assertPage=1;
}else if(!
driver.findElement(By.cssSelector("BODY")).getText().matches("^[\\s\\S]*Exchange[\\s\\S]*$") &&
isElementPresent(By.cssSelector("img[alt=\"Symbol Lookup\"]"))){
assertPage=2;
}else assertPage=3;
}
@After
driver.quit();
}
}
private boolean isElementPresent(By by) {
try {
driver.findElement(by);
return true;
} catch (NoSuchElementException e) {
return false;
}
}
}

Finalprojectdraft

Uploaded by

Copyright:

Available Formats

You might also like

Finalprojectdraft

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Finalprojectdraft

Uploaded by

Copyright:

Available Formats

Georgia Southern University

Dr. Vladan Jovanovic

Helps write paper.

Prepares Test Plan.

Helps write paper.

Helps write paper.

Part A: SQA Plan

1.2 Activity: Install, Review and Learn Testing Tools

1.3 Activity: Evaluate System Features

1.4 Devise Testing/Report Management

1.5 Activity: Create and Evaluate Test Plan

1.6 Activity: Standardize Use Case Reporting

1.7 Activity: Schedule and Check in

2.2 Eclipse and Java

4.2 No Perfect System

4.3 The Group Contributes Equally

4.4 The Group Follows the Plan

4.5 No Major Failures

Group Collaboration (Web

Software Risk Issues

Features Not To Be Tested

Item Pass/Fail Criteria

Suspension Criteria and Resumption

Planning Risks and Contingencies

[2] Seleniumhq.org, 'Selenium - Web Browser Automation', 2015. [Online].

You might also like