• Customize the code inspection document/checklist Design a code inspection document/checklist and appropriate improvement plan. Codes types: express, ejs, html, css etc.
• Use the checklist to check another team member’s code (you cannot check you own code)
Copy and paste from Milestone 7
Quality Assurance Plan
Introduction
Our team is developing a website for a flight reservation system; therefore we will be combining the conventional testing strategies of software and the innovated Web Application Testing.
Scope
Reference of FURPS+
-
FURPS:
- Functionality
- Usability
- Reliability
- Performance
- Supportability
-
The Plus +:
- Design constraints
- Implementation requirements
- Interface requirements
- Physical requirements
-
Functional:
All eight ranked user stories with eligible acceptance tests (from Milestone 5 [Storyboard]). -
Non-Functional:
The font size of text, webpage loading speed, etc.
Quality Objective
An easy-to-use web application for not just markers but everyone who has basic technology of computer.
Roles and Responsibilities
-
Ali and Jordan:
All Back-End relevant testings of the codes they implemented: the database, Nodejs, Javascripts, etc.
-
Wes and Nick:
All Front-End relevant testing of the systems they implemented: the HTML pages with CSS stylings, shared responsibilities of testing of Nodejs, Javascripts, etc.
-
Wes:
Overall testing and Web Application Testing of the entire project.
Test methodology
- Deliverables:
- A fully-functioning system without bugs
- Testing approach:
- White-box testing
- Black-box testing
- Testing levels:
- Unit testing
- Integration testing
- System testing
- Operational acceptance testing
- Testing types:
- Installation testing
- Compatibility testing
- Regression testing
- Acceptance testing
- Alpha testing
- Beta testing
- Functional vs non-functional testing
- Test tools with bug repoarting:
- Brackets without debugger
- Visual Stduio with debuger
- Browsers: Chrom, Firefox, Edge, etc.
Inspection methodology
- Deliverables:
- A well-developed website ready to be used
- Inspection approach:
- Planning
- Overview meeting
- Preparation
- Inspection meeting
- Rework
- Follow-up
Software Quality Inspection Checklist for Java Classes This checklist is intended to be used with a Findings Report for inspecting and reporting on Java class definitions. The examples provided in the checklist are meant to be suggestive, not prescriptive. Inspection Instructions
- Familiarize yourself with the code you are to inspect. Make sure you understand generally how it is designed to work, and that there are no passages of Java code which you do not recognize or understand at all. If necessary, consult a Java manual.
- Inspect the code for each checklist item in each category.
- For a checklist item which requires code elements to have a certain property (e.g. layout used consistently, algorithms to be space efficient), make an entry in the Report of Findings if you discover an element which doesn't have the property. Indicate where in the project (by line number and class name) you found the element.
- For a checklist item which prohibits a code element (e.g. calls to System.exit), make an entry in the Findings Report if you discover the element. Indicate where in the project you found it.
- For a checklist item which requires a code element to be present (e.g. a method with a particular name), make an entry in the Findings Report if you discover that the element is absent. Indicate the class or method header (by line number) in which the element ought to have appeared. Quality Criteria and Inspection Items
- Completeness (of reflection by code of requirements) a. Each required function is provided as a public method 2. Each such method has appropriate parameters
- Consistency (of layout, name choice, and code organization) a. Placement of braces ({ and }) done consistently throughout. b. Indentation is used, consistently, to indicate block structure within braces. c. Block comments precede the code they describe. d. The same names or abbreviations are used consistently for the same concept (e.g. not next, nextNode, and nxtn in three places in the same class). e. Naming conventions for classes, class members (methods and variables), constants, and local variables, are distinct and consistent (e.g.ClassName, classMethod, CLASS_CONSTANT, and local_variable).
- Anomaly Management (of inputs and contexts which the requirements didn't anticipate) a. Input parameters to public methods, and inputs read from files, are checked explicitly for all unacceptable values. b. Unacceptable public input produces error output (System. err) and/or throws exceptions. c. Unacceptable public input produces a documented result (e.g. zero, null, the empty String ...) when there is no exception thrown. d. Input parameters to private methods are assumed acceptable and are not checked. e. Input to protected methods is consistently assumed either private or public as above.
- Efficient Processing (using as little processing time as is reasonable) a. Loops contain complex code, or other loops, only when necessary. b. Array processing (especially search) contains loop exit code to execute when the condition is found.
- Efficient Storage a. All local and instance variables are actually used somewhere.
- Simplicity a. No method is longer than one page (about 60 lines including comments). b. Math expressions, control expressions (in ifs, whiles, fors, and switches) are as simple as possible. c. Standard coding idioms (e.g. for (int i=0; i<array.length; ++i)) are used where appropriate. Short private methods are preferred to repeating the same code over and over in different places.
- Self-Description a. Comments are provided whenever the purpose or reason for doing something in the code is obscure. b. Comments are provided to describe every method, however briefly. c. Comments are provided to describe the purpose, restrictions, and relationships between all instance variables in a class. d. All names are chosen well and consistently to reflect their usage and purpose. e. Constants (static final) are used instead of magic numbers. (e.g. Don't write 42, write static final ULT_ANS = 42; and then use ULT_ANS instead.) f. Booleans are not compared to boolean constants. (e.g. if (!found) is preferred to if (found == false)).
- Reusability a. Public methods are as general-purpose as is consistent with the design. b. Public method headers do not reveal the known usage of the class by code outside the class.
- Modularity a. Instance variables are not public. b. Variables are declared as locally as possible. c. Public method headers don't reveal the internal design of the class. d. System.exit is not called directly.
- Instrumentation a. Every class has a parameterless toString method which returns a String containing a dump or summary of an instance of the class.
Findings Report
Inspector’s Name:
Date Started:
Date Completed:
Project Name:
Time Report:
Time spent on Familiarization with the Code:
Time spent on Filling in Findings Report:
Time spent on Actual Inspection:
Findings:
Description Line # Class Name Associated Checklist Item #
1
2
3
4
5
Further Comments from the Inspection of this Class:
Action Plan
Fantastic 4:
All team members had participated in two scheduled weekly meetings as usual.
Alpha related issues had been discussed and resolved;
These two meetings were used as mostly workshop hours for this milestone.
Time spent as a team: 3 hours (1.5 hours of Tuesday meeting, 1.5 hour of Thursday meeting, 3 hours in total)
Ali (Back-End):
Worked closely with Jordan, completing about 50% of the database plus basic information of pages.
Will continue to address issues regarding the Beta focuses 1, 2, & 4 as indicated above.
Individual time spent on Milestone 9: 10 hours
Individual time will be spent on Milestone 10: 10 hours
- Searching for flights: 50% (Ali claimed he would complete by this today. : )) Origin Time Indication: 5% (Corrected to 80%, remaining will be CSS by Nick) About page of the company: 90% (Will be completed by Nick and checked by Wes, by Thursday)
- Security of payment page: 70% (Prompting "No payment information will be saved" VS "Reservation info saved" by Ali, by Thursday)
Jordan (Back-End):
Scheduled and booked a team meeting room as a regular weekly task.
Worked closely with Ali, completing about 50% of the database plus basic information of pages.
Revised ReadMe file of the master branch and minor changes of the database.
Will continue on resolving the Beta focuses 1, 2, & 4 as indicated above together with Ali.
Individual time spent on Milestone 9: 10 hours
Individual time will be spent on Milestone 10: 10 hours
2. Retrieval of reservation: 10% (Will be completed by Jordan by Thursday, login-email-retrieval)
Nick (Front-End):
Completed testing of the database of the project created by Jordan and Ali.
Revised ReadMe file of the master branch together with Jordan after minor changes.
Worked on the styling of ejs pages: Homepage(index), Flights, Payment with required contents.
Will continue to resolve issues regarding the Beta focus 3 and reaming Alpha focus 5, 6, 7 and 8 as indicated above.
Individual time spent on Milestone 9: 10 hours
Individual time will be spent on Milestone 10: 10 hours
- Usability of web pages: 25% (Will be completed by Nick and checked by Wes, by Thursday)
Wes (Testing/Front-End):
Created and summarized Milestone 8 at Wiki.
Finished the final formatting of this milestone.
Worked on the styling of ejs pages: Summary and About Page with required contents.
Completed testing of Product Alpha with desired coverages, user stories 5 to 8.
Will work closely with Nick tackling the Beta focus 3 and remaining Alpha focus 5, 6, 7 and 8 as indicated above.
Individual time spent on Milestone 9: 10 hours
Individual time will be spent on Milestone 10: 10 hours
- Language options of pages: 60% (%Showing confidence level, %not completion, will be completed by Wes in next milestone) Milestone 9 Inspection Documentation (Mostly completed by Wes by Wednesday, and checked by Nick by Thursday.) Document check list