Testing

1. Unit testing

Since our project involves changing a website's appearance and efficiency, we want to make sure that each of the button options works and brings up the data it is supposed to. For this, we will test the following actions by directly using mouse interaction on the active webpage. The webpage shall remain a bare bones design with a white background due to time constraints.

  • Start Page
    • Ensure that when navigating to the site uksp2017.optionapps.com that the site opens with no browser errors on Safari, Chrome, and Firefox.
    • Ensure that the ODDS OptionApps logo and the ticker search bar pop-up on the main screen.
  • Ticker Search Bar
    • When the user types in a ticker name, the autocomplete suggestions should pop up and be clickable.
    • When a ticker is selected and the "GO" button is pressed, the page redirects to the ticker's main page.
  • Ticker Main Page
    • After a ticker is searched, the menu bars should appear.
    • After a ticker is searched, a basic chart, similar to that shown on Google, should appear. This chart should have up-to-date and accurate information regarding only the selected ticker.
  • Charts Menu Functionality
    • Should have the following options when Charts is selected:
      • Probability
        • After the Probability option is selected another menu should appear with the options: Distribution, Density, Surface, and Back.
          • If Distribution, Density, or Surface is selected, the page should then make a call to the database and load the corresponding chart which the user can then interact with.
          • If the Back option is selected, the menu should then return to the main Charts menu.
      • Time Series
        • After the Time Series option is selected another menu should appear with the options: Historical Volatility, Implied Volatility, Term, Skew, Volume, Open Interest, Borrow Rate, Correlation, Probability Cones, and Back.
          • If Historical Volatility, Implied Volatility, Term, Skew, Volume, Open Interest, Borrow Rate, Correlation, or Probability Cones is selected, the page should then make a call to the database and load the corresponding chart which the user can then interact with.
          • If the Back option is selected, the menu should then return to the main Charts menu.
      • Volatility
        • After the Volatility option is selected another menu should appear with the options: Volatility Cone, Volatility Percentile, Volatility Surface, Garch Forecast, and Back.
          • If Volatility Cone, Volatility Percentile, Volatility Surface, Garch Forecast is selected, the page should then make a call to the database and load the corresponding chart which the user can then interact with.
          • If the Back option is selected, the menu should then return to the main Charts menu.
      • Dummy
        • This menu is a placeholder and does not need to have charts associated with it. However, it does need to have the options: Term Structure, Skew, Open Interest, Pane, and Back.
  • Ideas Menu Functionality
    • Should have options: Academic Summary, Academic Scans, Volatility Comparison, Volatility Change, Volatility Rank, Borrow Rank, Preconfigured Scans
      • None of these options need to have functionality implemented per customer direction. They just need to be placeholder buttons and need to be clickable.
  • Strategies Menu Functionality
    • Should have options: Buy Call, Put Credit Spread, Call Debit Spread, Collar, Covered Call, Short Put, Buy Straddle, Iron Condor, Buy Put, Call Credit Spread, Put Debit Spread, Forecast
  • Fundamentals/News Menu Functionality
    • When this option is clicked, it brings up a pop-up modal that shows what was previously on the fundamentals page for the ticker on the old website. This modal includes things like the current price, implied borrow, implied dividend, next earnings period, etc. This modal can be closed by the X button in the top right corner.
  • Me Menu Functionality
    • The customer has not yet planned out what they want to do with this menu yet and therefore did not give us any menu options. This just needs to be a clickable button as a placeholder.

2. Integration/function testing

Since our project is a website based on user interaction with a mouse and there is only one case of user input, we must make sure each click is doing what it is supposed to. To test this, we will ensure the following tasks are being completed and the integration between the front-end and back-end are working properly.

  • Search Feature
    • Make sure when the user clicks a predicted text ticker, the correct ticker page is loaded and it makes a correct database call to bring up the data corresponding to that ticker.
    • If the user types in a ticker that does not exist, or any characters that do not exist in a ticker, do not show any predictive text. If they click go, just clear and refresh the same page.
  • Menu Option Selection
    • All menu buttons should properly redirect to either a new menu or a chart. This can be tested by interacting with the webpage.
    • All selections within menus need to be verified that the button is properly calling not only the webpage associated with that chart, but also the database call is returning the correct chart. This can be done by looking at the user interface to make sure the correct chart is returned.

3. System testing

Our system, including our own copy of the OptionApps website and our own modified database, were set up by James Hughbanks. Because of this, we are limited in how we can go about testing the system. The only project requirement we had in regards to the system was making sure the database was running more efficiently, by reducing the amount of database calls and load time based on user interaction. We will test this by comparing the load time from the old website after changing options and selecting new charts, to the new load time when only loading one chart at a time. Since the old website was so obviously slow, this will be very easy to tell just by us clicking through the site. Additionally, as with all the tests listed above, we will make sure every interaction continues to produce accurate results as we can always log on to our copy of the OptionApps website to make sure our result on the new design matches the result from the old design.

The customer wants to continue to have the website support the most used web browsers among their customers. Additionally, these browsers are also used on tablet devices in desktop mode, and therefore will not require different coding to support these. These browsers, in priority order, are:

  • Google Chrome: Version 57.0.2987.133 (64-bit)(used on desktops, laptops, and Android tablets)
  • Apple Safari: Version 10.0 (12602.1.50.0.10) (used on desktops, laptops, and iPad tablets)
  • Mozilla Firefox: Version 52.0.2 (64-bit)

It was discussed that the website is mobile friendly, but that a mobile design is not a priority as it is not widely used by their users; but it does need to be tablet friendly by using these browsers on tablets.

4. Customer/user testing

Our customer, Don Fishback and James Hughbanks of ODDS OptionApps, gave us specifications as to the modifications they wanted to see to their website by the conclusion of this project. These are lined out in the "Project Specifications" page of this website. At every meeting we have had with our customer, occurring roughly every 2 weeks, we allowed them to look at a deliverable of the progress we had at the time. When they did this, they offered suggestions on things we could improve and gave feedback on if we were on the right track with their requests. At the end of the project, the customer tested on Google Chrome, the latest version mentioned above, their desktop Mac computer. They tested to be sure the user interface was easy to navigate, that database calls were performing fast enough, and that the site was fully functional on mobile.

At the end of this project, we intend to show them our final website modifications and allow them to click through it as if they were themselves and their users, following the typical steps a user would take as laid out in "Unit Testing" section above. We expect the customer to test on their desktop, using Chrome as their browser of choice, as they have done in the past. We will then take any feedback or modifications they may have and fix those before the semester end.

Our customer will test:

  • User Interface: Not only will they make sure all interactions with the webpage work and produce accurate responses, but they will also make sure the design is user-friendly which includes being easy to use and easy on the eyes.
  • Database Calls and Optimization: The user will make sure that when a chart option is selected there is only one correct database call at a time so that the site is running quickly and efficiently.
  • Mobile Friendly Design: The customer will test the website on a tablet, either Android or iPad, to make sure the website works on their requested mobile operating systems.