A quick guide to Agile testing in PractiTest
More and more teams are switching to Agile development, in order to increase their efficiency and meet the competitive requirements of the field and their users.
Agile software development is very different from more traditional forms of development. As such, it – only logical that adapting an Agile development methodology will require a change in the testing process.
Managing your Agile testing process using PractiTest
Agile testing is a team effort, and therefore requires high-quality communication between team members. Since the testing process may seem less “organized”, it – very important that the relevant information is available to all parties involved. You should always know what should be tested, who – testing what and where everything stands.
Here at PractiTest we are ardent believers of agile development and testing, and we try to design our test management software accordingly. Many of our features can contribute significantly to your agile testing process (as well as make your life a lot easier regardless of your testing methodology). Using Traceabiliy between entities, dynamic views instead of rigid folders, the flexibility of our customization settings, and the graphical information displayed in the Dashboard – your testing process can be more effective than ever before.
In more traditional testing methods, you would use the Requirements module to define how your system under test (SUT) should work, and what should be tested. In an Agile testing process, you can replace the traditional requirements with user stories – short and precise descriptions of your end users’ needs. You can then organize your User Stories using Custom Views.
Sharing tests in the test library
In PractiTest you can write and manage your Acceptance Tests (i.e. – tests designed to ensure that your requirements are met) within the Test Library, linking them back to the User Story where they originated.
You can then use the history, comments and notifications features to allow everyone to add their inputs into these tests, and to be informed about any changes made by other users.
You can simply create a test for each User Story, where developers can provide their inputs to testers as they come up with ideas during the design or coding process.
Creating tests sets for each user story
We recommend creating Test Sets for each User Story Independently. These test sets can contain the acceptance tests, functional tests, and any other testing operations needed for a specific User Story. This way you can get a better sense of coverage and completion for each User Story. It is also recommended to use the Tractability function to link between tests and their user stories.
Grouping issues based on their target sprint and user story
When you report issues, use custom fields to assign them the sprint in which they should be solved.
Also, in order to have tractability between issues, tests and requirements, you should link your tests to their relevant user stories. You can report issues directly from your test runs (using “fail and issue”), or link the issues back to the tests they originated from, for full tractability.
Using views to organize your issues based on Sprints, Users Stories, Modules, etc.
A good practice is to use the Issues Module not only to report bugs, but also to manage all the tasks of your User Stories and Sprint. Create tasks to keep track of the activities of your project and their individual statuses.
Provide visibility using a Summary Dashboard and additional Dashboards per User Story
You can use the Dashboard to keep your team up to date with the status of the Sprint in general, and of each User Stories in particular.
With the help of the views you have in each of your modules, create one dashboard centralizing all the information for your Sprint, and then create additional dashboard tabs with information for each User Story independently.read more
Automation Tests Support Beta is now Publicly available
This weekend we released a new version of PractiTest with one feature in particular that has been requested by a number of customers – the public release of our Automation XBot Plugin.
Using the XBot, you can run automated tests and scripts created with virtually any tool (Selenium, Watir, QTP, etc) or any homegrown testing framework. You can learn more about the XBot from our Automated Tests documentation, and if you want to take part in this Public Beta just send us an email and we will activate this feature in your projects.
This version comes with a number of small additions in the Report Center, such as the ability to export your reports to PDF format as well as to work with Views on Requirement Reports.
The current release also fixes a number of smaller issues that were reported by some of you in the last couple of weeks.
We’ll be happy to get your feedback on these or any of the rest of PractiTest, you mail us directly or use our User Feedback Forum.read more
Multiple-select lists, Issue status resolution, and more added features
With this new year we are releasing a new version that brings some of the functional features requested by many of you lately:
- Multi-select lists, with the ability to choose more than one value for the same field.
- Issue status resolution field, in cases where you want to add not only a status but a resolution. For example to specify the kind of fix performed, or the reason an issue is being rejected.
- Bulk deletion of tests, when doing mass operation on tests that require you to delete large numbers at once.
- And other smaller features and fixes throughout the system.
As always, we invite you to share any comments or feedback with us, both via our support hot-line or our user feedback site.
Last but not least we wanted to wish you a Joyful, Successful and most importantly Happy New Year!read more
PractiTest at the IGT Cloud Summit
Last week we participated in the IGT Cloud Summit that took place in Exodia, Tel Aviv. It was pretty fun and we’ve got some pictures to share. We also met some interesting companies who presented their ideas and product.
Our logo (part of the 20 ‘cloud’ companies that were presenting that day):
Joel also gave a short presentation, explaining about the real need for PractiTest that came from, yes, our users: