Difference between revisions of "IS480 Team wiki: 2015T1 Internal Testing"
Yyhoo.2013 (talk | contribs) |
Yyhoo.2013 (talk | contribs) |
(No difference)
|
Revision as of 13:11, 7 October 2015
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.
Identify the features and functions to test
Due to the sensitive nature of our application, the list of test cases will be uploaded on the team’s private repository available here . Generally, this is the scope of all our internal testing throughout the iterations and it will be updated accordingly along with the iterations.
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.