I am analyzing Milk teas management website, that is a web online to help user buys via online and seller can manage their products, orders
I have to do Non-functional requirements and functional requirements for this website like this
FUNCTIONAL REQUIREMENTS
Register
Login
Add products to card
Submit order
Cancel order
NON - FUNCTIONAL REQUIREMENTS
Number of milk tea can be added to the cart
I am right for that? Can you give me some idea for this to let me improve better, I am new for this section, thank you so much
Functional Requirements
Good functional requirements should clearly describe the behavior of the system. Here are some examples:
"If the user enters the wrong password 3 times when signing in, the account shall be locked for 24h."
"When an electronics product is added to the cart, the user shall be presented with an option to purchase a warranty."
"If a user attempts to cancel an order after it has been processed, the user must specify the reason for the cancellation, which must be approved before a refund is issued"
If you want to add more functionality, create more requirements, don't pile them all into one. For example, the last requirement in the above list can be split into 2: (1) require cancellation reason, (2) approval before refund. It also helps to organize requirements by feature in spreadsheets (one row per requirement) or JIRA Stories, for example.
Make sure you read many examples of well-written requirements, and practice. Follow a checklist, and have a co-worker review your work. Always ask yourselves how you would test each requirement. If you can't figure out how to write a test for the requirement, how can you ever prove the product works as intended?
Non-Functional Requirements
Non-functional requirements are also known as "quality attributes" or "constraints" of the system. The range of possible items that can be added to a cart (0..max) seems like a constraint on that field, so I can see how some would consider this a NFR. But how would you test it?
Instead, you can express this like a functional requirement: "When the user enters a value that is greater than the maximum, display an error message". A NFR might describe the color, size and location of the error message. NFRs can also specify which UI kit to use and style guidelines to follow. For example, "Must follow Google Material Design" (https://material.io).
You should also be familiar with NFR categories (also known as the "ilities"):
Performance
Stability
Reliability
Scalability
Flexibility
Usability
Testability
Traceability/Auditability
Security
Compliance/Certification
Much More: https://en.wikipedia.org/wiki/Non-functional_requirement#Examples
Here are some examples of NFRs for a website:
Performance: "A new user account shall be created in less than 2000 ms"
Reliability: "The system shall have at least 99.9% availability"
Capacity: "The system shall service up to 1000 simultaneous users"
Scalability: "The system shall be horizontally scalable to increase the number of simultaneous users"
Usability: "Users should be able to navigate to any page in the site within 3 clicks"
References
Read these guidelines by the System Engineering Body of Knowledge (SEBoK). Follow them closely, share with your team:
https://www.sebokwiki.org/wiki/System_Requirements#Presentation_and_Quality_of_Requirements
This is an excellent book on large-scale agile requirements if you want to go deeper:
https://www.oreilly.com/library/view/agile-software-requirements/9780321685438/
Related
I've been using Gherkin (with Cucumber) for many years now. I noticed early on that Cucumber.io homepage examples refer to 'I' in the given and when statements, but not in the then statements.
I always assumed this was because given and when statements are subjective actions by a user, where as then statements should be objective measures about the state of the application under test.
However, I noticed in the official Cucumber book, their examples refer to 'I' all the way through the steps (including when using then statements).
Anyone know which method is correct?
In my experience regarding the BDD and Gherkinri, we've always considered that the User story has two actors: User and System. Not all actors are end users. For example, a role could be another system or someone who wants certain functionality in order to buy your product but will never actually use the product. It may be useful to create aggregate roles (such as consumer) and specialized roles (such as browser or frequent shopper). So having I in the Then steps is actually expected result from end-user's perspective. Example:
Then I should see that cash amount 'storedTotalAmount' and cash amount 'currentAmount' are equal 'true'
There is not a definitive rule as to whether "Then" statements should include "I". As #ekostadinov it depends on the Actors which are taking part in the test scenario.
For instance in a messaging scenario:
Given Alice is on a messaging page
When Alice posts a message to Bob
Then Bob should receive the message
In such a scenario it would make no sense to use "I" in the "Then". However if you had a slightly different scenario:
Given I am on the messaging page
When I post a message to Bob
Then I should receive confirmation that Bob received the message
Then using "I" does make sense.
Hence it depends on how you write your tests. To conclude, I prefer to use personas (i.e. particular types of users in your system) throughout my tests e.g. Alice, Bob etc. This generally removes any possible ambiguity with the use of "I".
I have set up SpecFlow to execute a number of Selenium tests to test a website. This all works fine!
I am just considering if there might be room for some optimization on the structuring of the SpecFlow features.
All the scenarios in a specific feature should use the same login. This is something I have hardcoded in the StepDefinition using the [BeforeScenario()] hook at the moment, since I don't really wan't pollute the scenarios with login info. It isn't relevant for the test.
But at the same time, I would like to remove the hardcoded part, and move this into my feature.
My question is two part.
Can I specify login credentials in my feature description. Sort of like a Given:
Feature: As a user I want to be able to see my ongoing orders, and interact with them.
Given I am logged in with username abc and password xyz
Scenario: See list of ongoing order
Given I place an order
When I navigate to MyOrders page
Then I can see at least one order in the list
Is this good practice?
Does it make sense to do it like this, on the feature level I mean. The scenarios are not dependent on a specific order, and they would execute faster if I didn't need to log in for each scenario.
Thanks for your input.
For steps that are common to all scenarios in a feature you can use Backgrounds:
Feature: As a user I want to be able to see my ongoing orders, and interact with them.
Background:
Given I am logged in with username abc and password xyz
Scenario: See list of ongoing order
Given I place an order
When I navigate to MyOrders page
Then I can see at least one order in the list
Too much abuse of background steps can be a bad practice because it introduces coupling between your scenarios.
Another solution is to put the login part directly into your "I Place an order" step.
This will remove all the noise about login stuff since it's implicit that you need to log in to place an order.
I'd also suggest to call it "I've placed an order" instead of "I place an order".
Given steps are usually pre-condition that describes what happened prior using the functionnality (when steps)
When I first read your post, I thought of Dan North: Who's domain is it anyway? and that influences me to think that we should be trying to write our tests so that they stick to a single knowledge domain. As you talk about specific users and navigation and orders in a list, well its very like the example he gives in that your specification is crossing domains. This kind of leads me towards almost making your specification less specific, i.e. its not about navigating and checking a list, do you have an order or not!
Scenario: See list of ongoing order
Given I am logged in with username abc and password xyz
And I place an order
Then should have at least one order
I wanted to give you another example link, to a post I cant find, which talks about the benefits that a team has got by actually defining some example users and what value that gives their testing. So in your business domain you might have a user called Jack who will have placed a large order in the system, and another prospective client Jill with no orders. In this way tests such as
Given I am Jack
When I search for my orders
Then I will find 1
Given I am Jill
When I search for my orders
Then I will find 0
can guarantee that you are only testing your Search functionality, and less about getting the setup in place.
I'd also suggest that you have a look at Liz Keogh: Acceptance Criteria vs Scenarios who asserts that more general broad definitions are less valuable than very specific examples. (It is Specification By Example after all :-) )
So to answer your question, I think having the specified user is a good thing, but doing it how you are doing it is heading a very complicated route.
The scenario examples that are given are completely not in line with the Feature.
Feature: As a user I want to be able to see my ongoing orders, and interact with them.
Background:
Given I am logged in as John Doe
Scenario: This is taking to long
And I have placed an order more than 29 days ago
When I navigate to MyOrders page
Then I can see my order in the list
and I am able to cancel it
Scenario: Track package
And I have been notified my order has been send
When I navigate to MyOrders page
Then I can see my order in the list
and I am able to navigate to the postman's site and see its status
Scenario: Review item
And I have received my package
When I navigate to MyOrders page
Then I can see my order in the list
and I am able to review the item
Scenario: Contact Seller
And I have placed an order two weeks ago
When I navigate to MyOrders page
Then I can see my order in the list
and I am able to ask the seller what is going on
As you can see the When and the Then is starting to duplicate itself and you might want to consider tucking those away.
Is it acceptable to write a "Given When Then When Then" test in Gherkin?
A real-life example is as follows all AllPlayers.com
Scenario: Successfully register a user
Given I am on homepage
And I am not logged into an account
When I follow "create a new account"
And I fill in "First Name" with "Bobby"
And I fill in "Last Name" with "Bricks"
And I fill in "E-mail" with "bbricks#example.com"
And I select "Jun" from "Birthday Month"
And I select "22" from "Birthday Day"
And I select "1985" form "Birthday Year"
And I select "Male" from "Gender"
And I fill in "Password" with "123testing"
And I fill in "Confirm Password" with "123testing"
And I solve the captcha math problem
And I click "Create new account"
Then I should see "the user dashboard"
And I should see the Registration Wizard
When I push "Proceed to next step"
Then the "First Name" field should contain "Bobby"
And the "Last Name" field should contain "Bricks".
I know it works using behat, so parsing it isn't a problem. I'm just trying to write better tests. I could write in the first then And the Registration Wizard should be filled out with data but that doesn't seem specific enough...
Suggestions?
It depends on the target audience of the feature as written. It seems highly likely that the gherkin you've got there was not written with a stakeholder (i.e. somebody not-techie but has a vested interest in the business and the website). BDD is really about the conversation about requirements and expectations - and Gherkin is a tool which gives a standard/recognised way that everyone should be able to read that you can write the requirements and expectations; in a way that serves as automated tests for a developer and perhaps test scripts for a tester.
Trying to take my developer hat off now - I would say that a business stakeholder would rather read, and understand easily...
Scenario: Should be able to successfully register on website
Given I am new to the website
And I want to register for a user account
When I go to the registration form
And I complete all the required registration details correctly
Then I will be registered on the website
And I will be automatically logged in
You can still build the same test behind the scenes of this specification - but this specification has larger readership, it is a more easily understood requirement that anyone should understand. I'm not saying what you have got has no value - far from it. It will be a very valid test. But it is quite developer specific, and highly coupled to the UI implementation (if you refactor/redesign the UI, you now need to refactor your Requirements...).
I started off having plenty of gherkin specifications much like yours - and I still use them on occasion. Once your testing framework has built up a little gherkin is a really great way of kind of writing data-driven/configurable unit tests; and they still have great value to my development process. But I do try to separate the more "pure" specifications from my "developer" ones - but folder and tags/categories.
Edit: I guess in summary what I'm getting at is... what you have is a great "test", but a fairly bad "requirement". Stick with it though!
Yes, more than one When/Then cycle is appropriate in a Gherkin scenario when the real-world scenario calls for it.
SaxonMatt's answer makes the excellent point that scenarios are best written in stakeholder language rather than in the language of UI manipulation, and that doing so often reduces the length of a scenario, but that misses the exact point of the question. Let's take the bull by the horns.
Gherkin was designed for acceptance tests: tests which test that stakeholder-level requirements have been completely implemented, i.e. that the software actually provides value to stakeholders. Sometimes providing value takes more than one action-response cycle. Consider the following scenario:
Scenario: Guest buys a product
# This scenario starts with the user not logged in, which doesn't require a step
Given there is a product named "Elliptical Juicer"
When I go to the product page for "Elliptical Juicer"
And I add the product to my shopping cart
Then I should see 1 product in my shopping cart
When I request to check out
Then I should see the account creation form
When I create an account
Then I should see the checkout form with 1 product, "Elliptical Juicer"
When I check out
Then I should see the checkout success page with 1 product, "Elliptical Juicer"
And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"
(Note that when I have more than one When/Then cycle in a scenario I like to separate them with blank lines so they stand out.)
There are several reasons why this scenario is best written with multiple When/Then cycles:
Before the user checks out, they should see one product in their shopping cart (only as a digit in the site header, so the step doesn't mention the product name). There is no way to test this requirement at the end of the scenario. (Well, the test could collect the information immediately after the user adds the product to their cart and assert the expected count at the end of the scenario, but that would be pointlessly sneaky and confusing.) Instead, assert the correct count at the natural place in the scenario, as soon as it is visible to the user.
Similarly, Then I should see the account creation form and Then I should see the checkout form with 1 product, "Elliptical Juicer" can test important requirements at the points in the scenario at which it is natural to test them.
Suppose we didn't care about what the user sees during the process, only whether they get to the end of the scenario with their product on the way. We might then omit the intermediate Then steps:
Given there is a product named "Elliptical Juicer"
When I go to the product page for "Elliptical Juicer"
And I add the product to my shopping cart
And I request to check out
And I create an account
And I check out
Then I should see the checkout success page with 1 product, "Elliptical Juicer"
And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"
And I create an account comes as a surprise, doesn't it? It requires the reader to infer that a guest user is asked to create an account during checkout. It's clearer to say so explicitly, as in the first version of the scenario that I gave.
Suppose none of the above concerns convinced us and we wrote a separate Gherkin scenario for each point in the overall scenario where we needed to assert that requirements have been met:
Scenario: Guest adds a product to their shopping cart
Given there is a product named "Elliptical Juicer"
When I go to the product page for "Elliptical Juicer"
And I add the product to my shopping cart
Then I should see 1 product in my shopping cart
Scenario: Guest with a product in their shopping cart attempts to check out
Given I have a product in my shopping cart
When I request to check out
Then I should see the account creation form
Scenario: Guest creates an account
Given I have a product named "Elliptical Juicer" in my shopping cart
And I am on the account creation form
When I create an account
Then I should see the checkout form with 1 product, "Elliptical Juicer"
Scenario: Newly registered user checks out
Given I am a user
And I have a product named "Elliptical Juicer" in my shopping cart
And I am on the checkout form
When I check out
Then I should see the checkout success page with 1 product, "Elliptical Juicer"
And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"
That's awful! First, none of the scenarios is what a stakeholder would think of as a scenario. Second, when one of the intermediate states changes, two steps will have to change: the step which asserts the intermediate state and the Given step which sets up the intermediate state for the next scenario. Each of those Given steps is an opportunity to set up the wrong state, i.e. make an integration error. This set of scenarios has much less value as an integration test suite than did the single scenario. You might almost have written a series of unit tests.
It's true that writing every scenario end-to-end is likely to lead to some duplication. Just as you tolerate duplication more in unit tests than you would in regular code, tolerate duplication even more in Gherkin scenarios than you would in unit tests. Don't compromise on understandability. Break up scenarios and use Givens only at crucial points (such as creation of a product in the example above), and do so knowing that you're diluting your scenarios' integration-testing power.
Also, keep in mind that acceptance tests should be only part of your automated test suite. Write only enough acceptance tests to cover critical scenarios, and cover the details with unit tests. Often enough, the solution to duplication among acceptance tests is to replace one with a unit test.
I would also say No.
In a separate post of mine Daniel F found this fantastic article. Here is the relevant section:
Given-When-Then steps must appear in order and cannot repeat. A Given may not follow a When or Then, and a When may not follow a Then. The reason is simple: any single When-Then pair denotes an individual behavior. This makes it easy to see how, in the test above, there are actually two behaviors covered: (1) searching from the search bar, and (2) performing an image search. In Gherkin, one scenario covers one behavior. Thus, there should be two scenarios instead of one. Any time you want to write more than one When-Then pair, write separate scenarios instead. (Note: Some BDD frameworks may allow disordered steps, but it would nevertheless be anti-behavioral.)
https://automationpanda.com/2017/01/30/bdd-101-writing-good-gherkin/
I would say no.
When a test fails it should tell you where in your system the failure has occurred.
Long tests like in your example tend to be brittle and require a higher level of maintenance.
You need to define what your test is testing (which should be one thing) reading your test
it could be a form validation test.
it could be a registration test.
it could be a user dashboard test.
It would require an amount of time to investigate where the failure is and where that relates to in the code.
I would also say No.
The Given is a precondition for setup.
The When is an action (which can be a do nothing)
The Then form asserts.
If you need more actions then break the test down.
This will become far more useful once the first Then's fail for localising the problems.
can you please provide examples on requirements of the type ( functional , non-functional and user requirements ) of a website social network ( lets say the facebook ) ?
thanx in advance
Here are some examples for what requirements should be like for Facebook. However it's worth a warning: there isn't a single, agreed definition for what each type of requirement is, so I've given a definition for you I've chosen for each case.
I'm sure all of these can be improved in one way or another, but I feel these are decent requirements.
User Requirements
High level requirements that describe what a user can achieve. These are the needs that the system fulfil, similar to business requirements
U1. Users can post a textual update of their current mood or status.
U2. Users can choose whether the post described in U1 is shared with Friends, Everyone, or Nobody other than themselves.
U3. Users are presented with a list of posts made by people they are friends with or posts that are made to Everyone (see U2).
U4. The posts that appear in the lists U3 are filtered to only contain those that the user will find relevant or interesting
U5. The posts that appear in the lists U3 are ordered so that those the user will find highly relevant, and have not been seen previously by the user are towards the top of the list.
Function Requirements
Functional requirements provide highly specific details that allow designers, developers and testers to create a system to meets precise specifications. I've mapped them to user requirements from above
F1. Posts can be 63,206 characters long. [ref U1]
F2. Posts can be contain unicode characters. [ref U1]
F3. Posts may not contain any any of the following formatting, other than what can be provided by unicode characters - bold, strikethrough, underline [ref U1]
F4. 80% or more of posts in a users' post list (U3) should be from their friends. The remaining posts can be public posts or sponsored posts.
Non Functional Requirements
qualities and characteristics of the system that are not features. Again can be mapped to user or functional requirements
N1. After submitting a post through the web interface (see U1), it will be available to appear to in other users' lists of posts (see U3) within 30 seconds for 90% of posts.
N2. An update to a users list of posts (either the initial view of a list, or an extension to the list when scrolling to the bottom) appears in 3 seconds for 90% of users.
N3. 50% of users can post a status update within 1 minute of starting to try and post without having used the application before or receiving help.
I'm considering asking for credit card details BEFORE an address for a physical product with average purchase price between $10-$50
What might be the technical (or non technical) issues surrounding doing this?
What comes to mind is :
This seems a little non-standard from the users perspective
We cant do address verification if we find we're having issues with fraud (not an issue so far)
Users may be more likely to complete the sale since they've committed to their most important piece of information first
By asking for zipcode we can populate city/state when we do ask for the address
Are there any dealbreakers i'm missing or things I'm not considering?
I'm trying to make the system as flexible as possible, but would prefer to getit right first time without barking up the wrong tree.
My advice to you is don't do it.
I often cancelled buy attempts and abandoned the sites when I got asked for my credit card number right in the face.
Often, the site is so poorly designed with no answers to obvious questions that you have to go through the complete form hoping to find answer in the process. Do they offer this particular shipment option? How much does this cost? Do they send to a package station or only to my home address? Do they provide an extra line for an address for me to use the "c/o" technique? I often could not find answers to these question anywhere on the site. So I either found them in the form before entering my payment details, in very few cases I did call them, in most others I just chose other places to buy from.
One more use case. In many places I've seen they only show you if they have an item on stock on the very last page of the order form. Not many people would want to "commit" to the payment right away without getting all the required information. You enter your credit card number, then on the second page you see they don't offer the shipment option you need, on the last page it says "the item is currently out of stock - delivery awaited in 3-4 weeks". And the order is already placed. Then it is a commitment from the user but not from the company, many will react emotionally to this approach as to scam and request their money back immediately.
The important thing is to behave friendly to your customers, don't scare them away, don't raise suspicions in them, don't make them regret they committed to their buying. Make them feel relaxed and happy and never with their arms bound.
This may seem non-standard from a consumer perspective, but this is perfectly normal in B2B systems. You can collect personal/company & payment details, then shipping & payment addresses, and then present the user with a final confirmation screen showing tax & delivery charges before processing the order. Only then do you process the credit card payment.
However, the issue that "New in town" mentions is a very valid one, where the customer is left thinking:
Hang on, why are you asking for my credit card details when I haven't seen the final amount yet?
I think this is perhaps down to a site not having a clearly defined order creation process (or at least one that is not clearly communicated to the customer), so that the customer is under the impression that by entering their CC details at that point, the payment will be processed there and then.
It may be best to do things the way other popular online stores do, Principle of Least Astonishment and all that, but if you really want to do it in this order then perhaps a simple progress bar to indicate order creation flow would help allay customer fears. Don't bet on it though, online consumers are rightly paranoid when it comes to their credit card details these days. ;)
As someone who has done quite a bit of online purchases, I can say that I would be extremely worried if a site first asks for my creditcard information before it asks for anything else. It tends to trigger my "Fraud Detector". Am not sure why this is, but I just get worried that the site is going to forget about asking for my address.
As mentioned, in B2B environments, this is a bit more common, though. Then again, in many B2B environments, the visitor first creates a business account before he even starts ordering. Part of setting up this business account is providing the creditcard information. To be honest, many B2B also provide services and digital downloads which don't even need a shipping address.
Many people use the ship to address page to determine if the site will ship to their region/country. They are not likely to bother giving CC info before they even know you'll ship to them.
I live in outside the US and MOST sites fail to recognize that there are customers outside of the US. Often the only way to determine if they will ship to me is to go through the order process to find out they have a finite list of "states" they will ship to and no "country" drop down.