HeaderSIS.jpg

IS480 Team wiki: 2015T1 Internal Testing

From IS480
Jump to navigation Jump to search
Chipmunks-logo-small.png


Team Chipmunks Icon Home.png   HOME

 

Team Chipmunks Icon AboutUs.png   ABOUT US

 

Team Chipmunks Icon Overview.png   PROJECT OVERVIEW

 

Team Chipmunks Icon ProjectManagement.png   PROJECT MANAGEMENT

 

Team Chipmunks Icon Documentation.png   DOCUMENTATION

 


Chipmunks InT Icon Selected.png Chipmunks UT1 Icon.png Chipmunks UT2 Icon.png Chipmunks LT1 Icon.png Chipmunks ut3 icon.png

General Test Plan

Objectives

  • Define testing scope and objectives
  • Define testing methodology
  • Identify the features and functions to test


Define testing scope and objectives

The scope of the testing conducted by the team includes all functionalities completed up till that point in time. The aim of the testing is to identify the presence of bugs and irregularities in the application not previously discovered by the developers in the earlier development phase. Also, the testing conducted for the application is tested on several different browsers and Operating Systems to ensure performance consistency and maximum coverage on corporate machines.

  • Operating Systems
    • Mac OS X Yosemite (10.10.4)
  • Browsers
    • Google Chrome (Version 45.0.2454.85 (64-bit))
    • Safari (Version 8.07 (10600.7.12))
    • Internet Explorer (Version 10.0.9200.16384 (64-bit))


Testing Approach

The team takes testing and quality assurance very seriously and thus, integrated the use of automated testers (jUnit) and comprehensive manual testing every iteration. The developers will conduct individual unit testing before commiting their codes into our shared repository on GitHub.

These codes will then be integrated together with the other functionalities and be regressively tested locally, for fear of other functionalities impacted by the integration of the codes, by the lead quality assurance against the set of test cases for the application. Upon identification of the bugs, the lead quality assurance will update the bug-tracking document and notify the necessary developers on the issues at hand and the corresponding priority level.

Lastly, the fixed set of codes will be deployed online and a last check will be conducted against the set of test cases to be thorough in making sure that the application that is deployed works with no major problems.


Testing Process
Internal Testing Process.pngInternal Testing.png

Due to the sensitive nature of our application, the list of test cases will be uploaded on the team’s private repository available here.

Software Risks Issues

Currently, there are several risks that pose a considerable level of threat to the completion of our project such as the mobile view of the web application. Due to our software not being built as a mobile application, the difficulty comes in when standardization of the display of charts and various relevant information comes into consideration. To handle this issue, the group has employed the use of charting libraries that come with mobile responsiveness functionalities built in to reduce the number of areas that require tinkering of codes.

Manipulation of financial data poses a certain risk due to its heavy reliance on financial knowledge and the specific formulas required to process the raw data. Although the team has employed the use of a jUnit automated tester to aid us in verifying the correctness of our output, any added functionalities or change in formulas (which happens occasionally) used might impact us negatively.

Schedule

Following the Scrum project management methodology, which advocates the Agile approach, time of approximately 2-3 days will be allocated for the testers for comprehensive testing to be done. The integration and testing phases coincides to allow for a more efficient and time-effective manner of conducting testing i.e., functional and integration testing to be done together.

Resources

The Lead Quality Assurance is in charge of all related testing documentations namely, the test cases, bug metrics, bug tracking document and the general test plan. During the testing and integration phase of the iteration, the Deputy Quality Assurance will assist the Lead Quality Assurance in helping test out the application against the test cases and if need be, modify and improve the documents to allow for a more relevant and thorough checking of the application.

Research and references

The Lead Quality Assurance is in charge of all related testing documentations namely, the test cases, bug metrics, bug tracking document and the general test plan. During the testing and integration phase of the iteration, the Deputy Quality Assurance will assist the Lead Quality Assurance in helping test out the application against the test cases and if need be, modify and improve the documents to allow for a more relevant and thorough checking of the application.