Page History
| Table of Contents |
|---|
Manifesto for Agile Software Development
Back in 2001, a group of people wrote a manifesto to make better software development. Agile software development is backed up by 4 values and 12 principlesdepicted in the Manifesto for Agile Software Development, quoted next.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
...
Customer collaboration over contract negotiation
BDD is an approach where technical and non-technical users collaborate together to have clear understanding of requirements and their acceptance criteria, by writing concrete usage examples/scenarios in natural language that can be later on executed by an automation engine. These examples describe the intended behavior of the system, in a way that can be easily understood by all "stakeholders".
Xray has native support for Cucumber and other Gherkin based frameworks (e.g. Behave, Calabash, SpecFlow), allowing customers to collaborate with the product/development team by writing and reviewing Scenarios.
But besides supporting BDD, Xray also promotes collaboration on any work item, including user stories, bugs, and all testing related entities (e.g. Tests, Test Executions, Test Plans). Since Xray uses issue types as a way to abstract testing related artifacts, you can leverage the built-in collaboration features, among others, that Jira provides for any issue in general.
...
Responding to change over following a plan
Agility means being able to quickly adapt as changes arise because customers can continuously provide feedback in order to have a more tailored product/system that addresses their needs.
Instead of having a well-defined plan built at the start, taking into account a list of highly detailed requirements defined in advance, Agile teams iterate and deliver value frequently based on customer feedback that constantly is used as feedback loop to build a better, more suitable product.
If working in a Scrum context, teams iterate on sprints and can use Test Plans and/or Test Executions on a per sprint level or even use Sub-Test Executions to manage their work, in a visible way, in the scope of the sprint.
But being able to respond to change, means that Tests can be written at any moment and added to respective Test Plan(s).
In fact, if you're implementing more and more automated tests as a means to add additional coverage, they can be dynamically added to Test Plans along with their results, as soon as you start running them in your CI/CD pipeline. Thus, you don't have to plan ahead what exact list of test cases you'll need. You may assess the risks (at the start and during development), enumerate them in your Test Plan and use them to create Tests and execute them at any moment.
Scrum values
Focus
Everyone focuses on the work of the Sprint and the goals of the Scrum Team.
Team members must know what they have to do, focus on getting it done right and not loose time with other non-essential tasks.
- From specification, to organization, execution and planning, all testing related entities including Test, Test Set, Test Execution, Test Plan, Test Runs can be assigned; users get notified and can track their work (what they have to do and what they have already done). All Xray issue type based entities can also be watched if you want to follow more closely what is happening.
- If you want, you may configure email notifications to get notified upon relevant events, such as knowing that you're assigned some Test Run(s)
Testing related reports, should be automatable, shareable or easily deliverable, so that team members can focus on tasks where they can bring more value.
- Use Jira dashboards with real-time information that can be shared with all your team members
- Create, if really needed, reports as document assets, that can be downloaded, sent and stored (for regulatory/conformance reasons)
- After having an Xporter report template, you can manually generate a report from the issue screen (e.g. from a Test Plan) but you can also automate the creation of the report to make it happen upon the transition of a workflow or even on a periodic basis.
- After having an Xporter report template, you can manually generate a report from the issue screen (e.g. from a Test Plan) but you can also automate the creation of the report to make it happen upon the transition of a workflow or even on a periodic basis.
If your testers/SDETs/developers are implementing automated tests then should be focused on doing the right tests and implementing them; they should not loose time on side activities for having visibility of those results being reflected in Jira/Xray. Therefore, with Xray they can easily submit the automated test results using either one of the free CI plugins or by using the REST API directly. Upon submission, Xray will automatically, if necessary and possible, create Test entities mapping to each automated test. It is also possible to link automated tests to stories (or any "requirement" like issue) right from the automated test code. All this lets your team focus on what matters most.
Openness
The Scrum Team and its stakeholders agree to be open about all the work and the challenges that come with performing the work.
Being open means that everyone should be able to provide feedback, no matter if you're authoring new Test cases or if you're building your Test Plan.
Xray provides the ability for any team member to collaborate on any testing activity, including, and not limited to, Test Runs and Test Plans.
Respect
Scrum Team members respect each other to be capable, independent people.
Team members work on their assigned tasks and the team trusts them to deliver their work. However, each team member does not work in isolation; the team collaborates in order to successfully complete each task. How? No matter the role, team members can contribute at any moment.
Developers:
- can interact and leave comments on user stories, on Test cases, on Test Plans
- review PRs
Testers:
- can interact and leave comments on user stories and ask for clarifications, define and review Test cases
- can define the goals of Test Plans, based on risk assessment, discussed together with the team
PO:
- review comments on user stories
- clarify acceptance criteria on user stories
- work with team to identify the risks, so a proper Test Plan can be built accordingly
Courage
Scrum Team members have the courage to do the right thing and work on tough problems.
Courage is, first of all, about transparency of the work and its progress, including failures that may happen.
Thus, testing progress can be promptly and automatically evaluated at the Test Execution, at Test Plan or even at user story level.
Courage to be receptive to feedback from other team members is also a value of Scrum; Xray promotes this by enabling users to leave comments on any testing entity.
Courage also means "to be willing to change, if needed." Therefore, users can:
- explicitly abort a Test Run with a specific custom status, to make it more visible
- signal some Test Execution using a specific workflow status while leaving comments on it
- make any testing artifact read-only or writable, using the Jira way of managing permissions
To make sure you're working on the right thing and that it is properly tested, so you can deploy confidently, you may use the Overall Coverage Report to give you real-time insights of real status of the user stories or other items being worked out/tested. You can group your covered items (e.g. stories, epics, bugs, etc) by Priority, by component of the system or by any other field; this gives you
Commitment
People personally commit to achieving the goals of the Scrum Team.
Test Plans, Test Executions can be assigned to a sprint, so you can track in your active sprint Board. As they're issues, they can be assigned to a certain user, who will be responsible for managing the life cycle of each one of them.
Individual Test Runs, which are part of Test Executions, can also be assigned to specific users. Thus, these two levels of assignment (at Test Execution and at Test Run level) provide finer control over the work that needs to be performed.
While working in the context of a Test Plan or of a Test Execution, users can track their progress and thus are able to evaluate the "progress of their commitment".
