CSC/ECE 517 Spring 2016 E1676 Role-based reviewing - Revision history

Pjain12: /* Test Cases */

2016-11-09T06:09:34Z

Test Cases

← Older revision		Revision as of 06:09, 9 November 2016
Line 55:		Line 55:
	then you should not be able to pick a duty if it was already selected by some other member.		then you should not be able to pick a duty if it was already selected by some other member.

	4. Login in as a ~~Review~~		4. Login in as a Reviewer

	When you login in as a reviewer you should get the questionnaire based on your duty. For example, if you are a software engineer you should get the review		When you login in as a reviewer you should get the questionnaire based on your duty. For example, if you are a software engineer you should get the review
	questionnaire assigned to software engineer.		questionnaire assigned to software engineer.

	Different roles will be assigned different questionnaires for review.		Different roles will be assigned different questionnaires for review.

Pjain12: /* Testing Details */

2016-11-09T06:06:01Z

Testing Details

← Older revision		Revision as of 06:06, 9 November 2016
Line 23:		Line 23:

	== Testing Details ==		== Testing Details ==
			In our project, we are providing an option of adding duty for different team members in an assignment and giving review options based on their duty. We will add following functionalities:
			1. How instructor create assignment with duties/roles
			2. How students take duties from a given list of duties
			3. How teammate evaluation rubric assign different review questionnaire based on duty.

	=== UI Testing ===		=== UI Testing ===
			UI will be tested manually. First, we will test creating an assignment as an instructor with different duties and assign different review questionnaires to each duty. Then we will login in as a student and take a duty from given list of duties. We will try covering all edge case scenarios in test cases section.

	=== Test Cases ===		=== Test Cases ===
			Following will be the test cases:

			1. Login in as an Instructor:

			1.a] While creating an assignment, in the Review Strategy tab provide the list of roles/duties possible for teammates. There will be one text box to add
			duty. To add more duties click on "add more".
			1.b] Mark the check box that says multiple team members can have the same duty.
			1.c] Go to the Rubrics tab and select different questionnaires for different duty.
			After creating this assignment students should be able to see different duties in "Your Team" page and should be able to select any duty. Multiple students
			should be able to select same duty.

			2. Login in as an Instructor:

	~~=== RSpec ===~~		2.a] Repeat steps 1.a and 1.b
			2.b] This time do not mark the check box that says "multiple team members can have the same duty".
			After creating this assignment students should be able to see different duties in "Your Team" page. This time student should not be able to select a duty if
			it was already selected.

			3. Login in as a Student

			When you login in as a student you should be able to pick different duties assigned by the instructor. If multiple members are not allowed to have same duty
			then you should not be able to pick a duty if it was already selected by some other member.

			4. Login in as a Review

	~~===Factory Girl===~~		When you login in as a reviewer you should get the questionnaire based on your duty. For example, if you are a software engineer you should get the review
			questionnaire assigned to software engineer.

			Different roles will be assigned different questionnaires for review.

			=== RSpec ===

	~~===Running~~ RSpec~~===~~		For functional testing, we will use RSpec. It uses Behavior Driven Development (BDD) for testing functionality of the system. It provides way to describe specific functionality of the system being tested and helps in better visualization of test cases.

			=== Capybara ===
			We will use Capybara for automating the manual test cases. It is a web-based automation framework and coupled with RSpec. It allow developers to write the test cases which simulate the whole scenario of manual testing.

	===~~Test Cases~~===		===Factory Girl===
			We will use Factory Girl for creating data factory. Factory Girl is a Ruby Gem that allow users to create templates for valid and re-usable objects. It allows more customization when user instantiate the objects and it aims to ensure that user have a valid object to work with.

	== References ==		== References ==

Pjain12: /* Updates */

2016-11-08T19:28:42Z

Updates

← Older revision		Revision as of 19:28, 8 November 2016
Line 14:		Line 14:
	==Updates==		==Updates==

	Below are the key files modified:		Below are the key files to be modified:
	===Controllers===		===Controllers===

Pjain12: /* Design */

2016-11-08T19:28:10Z

Design

← Older revision		Revision as of 19:28, 8 November 2016
Line 8:		Line 8:
	== Design ==		== Design ==

			=== UML Diagram ===
			=== Design Pattern ===
	=== Database Design ===		=== Database Design ===

Pjain12: /* Testing Details */

2016-11-08T19:25:15Z

Testing Details

← Older revision		Revision as of 19:25, 8 November 2016
Line 21:		Line 21:

	== Testing Details ==		== Testing Details ==
	=== UI Testing ====		=== UI Testing ===

	=== Test Cases ====		=== Test Cases ===


Line 40:		Line 40:

	===Test Cases===		===Test Cases===

			== References ==

Pjain12: /* Testing Details */

2016-11-08T19:24:29Z

Testing Details

← Older revision		Revision as of 19:24, 8 November 2016
Line 21:		Line 21:

	== Testing Details ==		== Testing Details ==
			=== UI Testing ====

			=== Test Cases ====




	=== RSpec ===		=== RSpec ===

Ychen75: /* Purpose */

2016-11-05T04:20:06Z

Purpose

← Older revision		Revision as of 04:20, 5 November 2016
Line 4:		Line 4:
	== Purpose ==		== Purpose ==

	===Rationale of using Scrum ===		===Rationale of using Scrum & Role based reviewing ===

	== Design ==		== Design ==

Ychen75: /* Design */

2016-11-05T04:19:34Z

Design

← Older revision		Revision as of 04:19, 5 November 2016
Line 9:		Line 9:

	=== Database Design ===		=== Database Design ===

	~~=== Design Pattern ===~~

	~~=== Use Case Design ===~~

	==Updates==		==Updates==

Ychen75: /* Implementation */

2016-11-05T04:19:20Z

Implementation

← Older revision		Revision as of 04:19, 5 November 2016
Line 14:		Line 14:
	=== Use Case Design ===		=== Use Case Design ===

	==~~Implementation~~==		==Updates==

	Below are the key files modified:		Below are the key files modified:

Ychen75: /* Design */

2016-11-05T04:17:42Z

Design

← Older revision		Revision as of 04:17, 5 November 2016
Line 7:		Line 7:

	== Design ==		== Design ==

			=== Database Design ===

	=== Design Pattern ===		=== Design Pattern ===


	=== Use Case Design ===		=== Use Case Design ===



	~~=== Database Design ===~~

	==Implementation==		==Implementation==