Initial commit

[VineetReynolds]

Initial set of acceptance test criteria.

This PR is meant for review to decide:

• Whether the acceptance criteria aids in understandability of various features
• Gherkin is suitable for writing down "executable" acceptance test criteria from the POV of the entire team
• Split acceptance criteria for user stories/features based on walking skeleton and project backlog
• Split feature files based on feature areas
• Map out how to write the test implementation:
  • Choice of language (Golang vs any other)
  • Choice of framework (Godog vs goconvey vs any other)

[VineetReynolds]

Please don't merge this. I'm opening this for review cc @aslakknutsen @ldimaggi

[aslakknutsen]

I started a little GoDog experiment during the weekend. Essentially testing the /api/status endpoint via the client lib defined as a feature spec; aslakknutsen/fabric8-wit@9c46604

[ldimaggi]

Initial comments follow below (I will attach finer-grained comments to the individual files):

• Whether the acceptance criteria aids in understandability of various features
  ------> Agreed, this looks good.
• Gherkin is suitable for writing down "executable" acceptance test criteria from the POV of the entire team
  ------> +1, better to use this than to define an entirely new syntax
• Split acceptance criteria for user stories/features based on walking skeleton and project backlog
  ------> +1, within the context of the progress made in each sprint
• Split feature files based on feature areas
  ------> +1, this is a good approach to organizing this
• Map out how to write the test implementation:
• Choice of language (Golang vs any other)
• Choice of framework (Godog vs goconvey vs any other)

------> Not sure on this - I have not yet used Go....yet.

[VineetReynolds]

@aslakknutsen That's useful!

There are a few tests that may require browser-based tests to be implemented. I'm currently working on the criteria for iteration planning and backlog management, and a few scenarios involving moving WIs across iterations may require browser based tests. Will point those out as soon as I have finished committing and pushing them.

[ldimaggi]

1) Global comments:

• It's not yet a defined story, but when we go on-premises, we will have to define the means by which users can administer an entire RHD server.
• Will you add the issue numbers to all the features/scenarios?
• I saw your comment regarding the need to use a browser for some tests. In order to be a full test for the API and the UI, wouldn't we want to verify each scenario both through the API, and through the UI? The UI accesses the core services through the API, but it must be able to process, present, manipulate core services data in the UI.
• In terms of implementing the acceptance tests, yes - I volunteer to help. ;-)

2) Comments on specific files:

a) agile/backlog-mgmt/backlog-mgmt.feature

Line 3 - Scenario: Add work items to backlog - The newly created work item will have its create date/time set to the current date/time. What about the status value of the new workitem? Will it be set to "new" or will it have no value?

Line 11 - Scenario: Rank work items in sprint - Just to confirm - A workitem can be assigned a ranking in a sprint or any other iteration, or only in a sprint?

b) build/project-build.feature

Line 26 - What does it mean for a build pipeline to be "linked" to a project? Does the build pipeline appear in the project's list of assets, and/or what else?

Line 39 - Is the manual build started from within the ALM UI?

Line 48 - Will a specific string in the comment trigger the pull request?

Line 102-111 - Will the user be able to re-run/re-start the failed build after the build error is resolved, or must he/she start a new build?

c) collaboration/work-item-collab.feature

Line 7 - How does a user become a team member? Is this always self-service, or is the user assigned to a project?

d) program-mgmt/project-mgmt/project-mgmt.feature

Line 14 - Must the title be unique? Or must a combination of title+description be unique?

Line 63 - Can Deactivated users be re-activated?

e) user-team-mgmt/github-login.feature
f) user-team-mgmt/redhat-login.feature

What happens if a user's account in github/Red Hat is closed?