First One:
Scenario: Manager can log in into the login page (that is my one scenario next I move to the test cases)
For the above scenarios, I wrote the four test cases
First Test Case: Verify manager with valid user id and valid password
Second Test Case: Verify manager with in-valid user id and valid password
Third Test Case: Verify manager with valid user id and in-valid password
Fourth Test Case: Verify manager with in-valid user id and in-valid password
My question is if I wrote four test cases of one scenario so the scenario is the same of all test cases or it will be changed to every test cases like;
Second One:
Scenario: Manager can log in into the login page
Test case: Verify manager with valid user id and valid password
Scenario: Manager cannot log in into the login page
Test case: Verify manager with invalid user id and valid password
Which one is correct?
First approach is correct, we can create multiple test cases for single scenario.
Every software testing company follows the approach of creating test cases for the scenarios.
In the above statement, the scenario is the same for all the test cases, and writing all possible test cases for a single scenario is the best approach i.e the first one in your statement.
What is a test scenario? As a tester, you put yourself in the end user's shoes and figure out the real-world scenarios i.e a high-level understanding of the feature that needs to be tested. In your first statement, you have written one scenario and all the possible real-time test cases under it.
Test Scenario is a general thing. many test cases can be derived from test cases.
In your example test scenario can be : Checking the login functionality.
While test cases can be:
1) Manager can log in into the login page with valid credentials
2) Manager cannot log in into the login page with invalid userid and valid password.
3)Manager cannot log in into the login page with valid userid and invalid password.
4)Manager cannot log in into the login page with invalid userid and invalid password.
Your first approach would help you out in case you want to manage a single suite to run a Regression test and Smoke test
Reason: It contains negative and positive test cases in a single scenario
Your second approach would help you when you want to keep your Smoke Test and Regression Test separately
Reason: It has different test scenarios of negative test cases and positive test cases. Hence you can execute a selective set of positive
scenarios when you want to run the smoke test cycle and all scenarios
when you want to execute regression test cycle
Select wisely..!
Happy Testing :)
Related
My App has a user, kind of like an admin user, and the app absolutely does not allow more than 1 of that user to be online at a time. The actions this user performs have heavy implications on the system, so I want every test run with more than a few users to have one of these users present, but my system will crash if more than 1 of these users are booted up.
Is there a way for me to tell Locust to start up exactly 1 and only 1 of a specific user? My other users are getting booted up fine and they're working as intended.
Probably the easiest solution is to run a separate instance of Locust for just that one user. Then you can do whatever you need to do for all the rest of your users. If you didn't want to split your code, you could use an environment variable or add a custom command line argument that you can key off of to determine which tasks to run.
Another option could be to use the test_start EventHook to kick off a greenlet or thread that runs your admin flow separately and use request_success and request_failure to report request status like a normal task.
I'm trying to test the Stripe API and want to use one of the test tokens like tok_visa.
(I can't really use the test cards like 4242424242424242 because my software is a middleware layer, and in normal operation it just passes a token through from client to server, and I'd prefer not to add logic for creating tokens just for the sake of testing.)
When I use tok_visa and retrieve the token data from Stripe, the cvc_check and address_zip_check are set to null.
The problem is on the test server I'm talking to, it requires that these be set to true. I also am unable to modify the test server to skip these checks.
The docs say that if you set the CVC or ZIP to any valid value then these checks should pass, but I don't see how to set the CVC number or address for tok_visa because it's already been tokenized.
The test server is looking for a value (true) that is never going to come from a Stripe token.
The possible values for a token's card.cvc_check and card.address_zip_check are:
pass
fail
unavailable
unchecked
The test tokens will usually have a null value (but never true -- it's not a valid value). Some test tokens that Stripe provides will instead have unchecked if they are configured to fail when checked.
If you create a token in test mode, its value will be unchecked until you attach it to a customer or try to charge to it. At that point, it will become one of the other three values.
I am drawing a use case diagram for an Online Bill Payment and I am confused about the authentification step. Is it better to create separate use cases for a new user and for a registered user like I've tried below
or should I create just a login use case and then extend the register, for example like this:
or should I create an authentification use case and extend login, logout and register?
A use case shows added value brought to its actor. There is no added value for Login. So Login is no use case at all. It is a constraint you apply to other use cases. It can be attached to (real) use cases like { actor must be logged in}.
I can recommend Bittner/Spence as an excellent source on how to deal with use cases.
There are several approaches depending on expected system behavior and your writing style.
Use two different actors, authorised and non-authorised user. Write subfunction level login use case for non-authorised user. Let authorised user only to be an actor in user goal use cases like Check balance.
In all user goal level use cases write precondition that user is authorised. Write subfunction level login use case.
In all user goal level use cases write precondition that user session is valid. Write subfunction level use case where system checks session and enforces login use case when needed.
Login, logout and registration (also session expiration) scenarios are not connected in the way you asking. You can, for example, tag them as AAA or put in AAA chapter/folder. There is no need to mix them in one scenario.
I am doing sequence diagrams, but I have some issues in the design of these diagrams. So I was doing the diagram for Account Creation as follows:
So, first the user goes to the registration page and then enters his information. I also wanted to show what would happen if the information entered by the user in the registration page are incorrect: I added the verify input arrow from the registration page to the database.
I am not sure who should verify that the input is correct, is it correct to say it's the database that checks if the entered data are valid?
Moreover, is it correct to add the dashed arrow from the database to the registration page or should I go directly to the if condition?
What would you advice me to change?
1) ..who should verify..input...database..?
You can delegate the responsibility for data validation to whichever actor with whatever name. Database is good candidate, and many SQL databases have some kind of integrity constraint checking mechanism built-in
If configured, such database will validate data and reject them at the moment of insert/update attempt. So in your case if a SQL database would handle it the way they usually do, the VerificationResult would be returned from AddNewUser() message, not sooner
However, for real-life application the good candidates according to Open Web Application Security Project (OWASP) → Data Validation would be:
..Integrity checks must be included wherever data passes from a trusted to a less trusted boundary, such as from the application to the user's browser in a hidden field, or to a third party payment gateway, such as a transaction ID used internally upon return..
..Validation must be performed on every tier..
2) ..dashed arrow from the database to the registration page..directly to the if..?
I would extend the execution (activation) down as shown below, but it does not mean that your way is not correct
See also: uml-diagrams.org: UML Sequence Diagrams Examples
3) ..advice..to change?
I would review the use of synchronous/asynchronous messages. It seems that you use one type of arrow for everything
I'm trying to create a PHP based game where you have to do all sorts of simple but un-obvious tasks in order to progress to the next level (eg. refresh browser, press keyboard combination, ...) Kinda like the game "this is the only level" (if anyone has ever heard of it)
Now I was thinking: Would it be possible to create a level where they'd have to sign up at a different page in order to progress to the next level?
So say for example they need to sign up to goal.com and if they're signed up they proceed to the next level. The page would need to constantly check if the signup process on the other site is completed. Is this even possbible? And if so, any thoughts on how?
Thanks!
With most sites, given a username and password, you can check if an account exists.
All you have to do is post some data to a url and parse the output for a successful login.
You may have problems with the bigger sites since they have other checks in place to deter scripted logins.