StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
4683415
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-01-13T17:58:29.313
FavoriteCount
0
LastActivityDate
2013-03-06T22:06:43.830
LastEditDate
2013-03-06T22:06:43.830
LastEditorUserId
363592
OwnerUserId
363592
ParentId
4621036
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
It might help to think of BDD in its lightest form; as discussions around particular scenarios. You've got your use cases. You've got your requirements. Now you want to verify that you've got a really good understanding of those. So someone - maybe a developer, maybe a tester - says, "Okay. Just to verify that I understand... given that we start with <this>, when a user does <this> then <this> should happen. Is that right?" And the tester will say, "Yes, that's right." Then the UX or analyst says, "Well, it's right unless <this other context exists>". By having discussions around the scenarios, the time taken to ensure that everyone has a common understanding is cut down drastically. We normally gloss over the obvious scenarios and focus on the edge-cases; on new domain terms, concepts which differ between departments, difficult interactions with legacy systems. The developers don't really work off of the test-cases. They work from requirements and acceptance criteria in exactly the same way that they always do. The test-cases just become an example of the kind of thing they might expect; scenarios in which users get to benefit from, or pass on, the value of the system. Automating those test-cases can be useful because the effort of testing increases roughly proportionally to the size of the code-base. BDD works best in projects where there's high uncertainty around the requirements or the domain, and people's understanding differs greatly. If your project works already then stick with it. Maybe you could have a look at where the biggest gap between coming up with ideas and implementing them is, and if BDD helps you in that space, use it; otherwise pick something else. What you're doing sounds very similar to BDD processes anyway.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POBDD/TDD vs JAD?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USLunivore
UserOwnerUserId
1. USLunivore
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.