Of-course, understanding the goal of an user-story before coding review gives a lot of context. In an Scrum team I would expect all team-members to already understand the acceptance criteria as everyone was part of the Sprint planning session.
Still actively verifying the (user/customer level) acceptance criteria of an user-story does not seem something I ...
"The value of any practice depends on its context"
N-wise testing is a technique, not a silver bullet to solve any problem.
It's your responsibility as a professional to analyze how to best approach a specific problem.
Take the example of a pairwise analysis:
valid name, valid password
valid name, invalid password
invalid name, valid password
To answer the main question, your test is a functional test which uses an expected invalid input condition.
Some of my classifications of functional test types are:
Functional test - any test of the application's functionality. This can include valid input, invalid input, navigation through the application, and pretty much anything else that involves the ...
A user story describes desired behaviour of the system focussing on results and written in plain understandable language. More formally:
A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective.
A bug is something wrong in the system. Either a violation of ...
There are a few clarifications needed here, before I can help you out in the right direction, as per your query.
1- Are you working in an Agile/Scrum model?
2- Why are the 'Requirements' unclear?
3- Why do the user stories change so often?
4- Why are the user stories so vast?
I think you may find that your testing is hampered, and you are being set up ...
Can you please give me basic functional and invalid input cases for
the above scenario?
Functional testing for your scenario would cover cases including but not limited to:
Test whether the UI of the screen containing a checkbox and a button are displayed properly (as in color matches the requirement document, the positioning of those form controls ...
It really depends on how you write your test plans.
In that specific case, you can at least do preparatory work, with structure, without details, like
"create a customer, enter an invalid age, checke there is an error message, enter a valid age, check the creation works". If you happen to need more detail in your test plan(really depends on the shop), ...
the answer to your first question is YES. You can definitely use Excel for creating acceptance tests. There are different types of acceptance testing:
User Acceptance test
Operational Acceptance test
Contract Acceptance testing
Compliance acceptance testing
So, I am assuming that you are planning to create acceptance tests for User Acceptance testing.
What I believe: In future, if someone looks at some block of code and feels WTF, then Code Reviewer is responsible more than implementer.
This belief is not SCRUM.
In SCRUM, the team is responsible, not the individual. If the code isn't delivered at the end of the sprint, or if it doesn't meet the acceptance criteria, or if it is of low quality, it is not ...
This greatly depends on your release cycle, true Agile teams should try to release as often as possible. An Agile release cycle could be from a couple of times per day to at-least once a month. Having a lot of manual testing effort before you can release will slow you down. Thus you will want enough automated testing coverage to be confident to release often ...
As mentioned in comments, SCRUM is a process/methodology for executing functional work and not in the weeds on what "proper" work is/isn't. That being said there are certain checkpoints that need to be adhered to and I think you are touching on some of those, so this answer is scoped more to the touch points of reviews during SCRUM and not detailed ...
Not really.. You could always:
Write your own history tab.
Amend your email templates for better
formatting (I have to agree with you on that one - the default emails
are useful to get as a note that something has changed, but I don't
know anyone who really reads them because the formatting is not
Your suggestion addresses how to add writing an automated test as a work item in your Agile process, but does not recognize that some tests should never be automated.
You need to understand and address your team's objections to automating everything. Some of those objections may be legitimate. For example, some automated tests may require so much ...
The other thing that many companies neglect in Agile, Extreme and even Waterfall working is that you need to have a test section on board as well and while the developers are working to fulfill a given story point, feature or requirement the test team should be developing the tests, (in extreme these need to be developed before the developers start), and ...
I have been involved in a BDD framework creation where in we created BDD framework using Calabash , Jbehave and Thucydides and another one we used ,in that we created reports using BDD and rest all part was written in Selenium - Java - TestNG . So Frame work used was Selenium and coding language was Java , with unit test framework TestNG.
I have seen your ...
To be honest this sounds like the very issue that seems to have split the BDD tools. You either have tools that produce specifications during the test runs, ao that you know exactly what your system is capable of doing. Or you have tools that consume specifications so that you know how compliant your application is with the specifications.
In the first case ...