N/A status is going all the way to Runs, Tests, and even Requirements
For better transparency of your testing efforts
It’s the N/A step status we added last year as we saw the need for Not Applicable status.
We took this further and from now on, in case you mark all the tests in a test set/run as N/A, the Run status will change to N/A accordingly
(the same applies also to the Test Status, or even the requirement status)
This small GUI change gives an even more accurate and clearer view into your testing status, enabling you to communicate “neutral” testing efforts as they are, and not appear as “no run” like previously.
From today (Nov 29, 2017) at 7:00 AM UTC, N/A statuses will be calculated and updated all the way from the steps to the requirements. Previous runs with N/A steps, are not touched (and considered as NO RUN), mainly since we didn’t want to touch the history of your runs.
Moving to markdown
In the last couple of weeks, we’ve been working hard to shift our previous description fields which were HTML based to markdown. The reasons to shift are many – it’s easy, fast, clean and more.
It also enabled us to upgrade the editor we had to a simpler markdown editor, with better UI capabilities and fewer bugs. We were also able to enable rich editing in the steps’ descriptions and expected results, that was not part of the application before.
And in addition to all that, if you now export and import tests from and to PractiTest, the style remains, which makes it even easier to migrate data.
Anyways, to cut the story short, we’re markdown! Enjoy the rich editing in steps attributes, and the (almost) bugs free editor.
Take into account that old description fields (of tests, issues, requirements) were all migrated to markdown (from html). Let us know if you find any issues.
Session Based Testing (Exploratory Testing)
PractiTest now includes a new type of test that supports Exploratory and Session Based Testing practices.
- Quick and intuitive – Create Exploratory tests as test instances “on the go”
- Run Exploratory Testing Sessions and create annotations for easy tracking and collaboration
- Report Issues from run – works with all your existing project’s integrations
Exploratory tests in PT allow you to define Charters for your ET Sessions, document annotations as you are running your tests, report bugs directly from your runs, and finally to review your ET sessions with colleagues in order to gather feedback.
Unlike other tests, which are created first in the Test Library and then added to any Test Set (new or existing) before running, the Exploratory Test is created as an instance in the TestSet and Runs module “on the go”, which is more intuitive and supportive for exploratory testing methodology.
Now your Test Sets can contain all types of tests at once: automated, manual and exploratory. This ability to combine various tests improve QA coverage and trace-ability.
Updated application navigation bar for increased usability (and Step Parameters)
PractiTest’s latest navigation bar update separates Project related setting and actions, such as: search, requirements, tests, reports, project settings; from other General application actions such as: user settings, help, tutorials.
This modification makes navigation more intuitive –
You will also notice that all menu options are presented and are actionable based on permissions, un-permitted menu items are disabled and colored grey (used to be hidden) –
One last time saving GUI change is we have moved all project settings to an quick access drop-down menu –
New Step Parameters [Enterprise only]
This week we also relased Steps Parameters: a cool way to increase Test reusability – Learn more
New Step status: N/A
A small addition to your steps run that will make a big difference:
- Now you can choose to set test step status as N/A (Non Applicable) and reflect an accurate testing status.
- Test status will be based on all other steps in the Test run and can be marked as completed.
This small GUI and functionality change is helpful, because it means you can now define certain steps “neutral” so they don’t affect the final run status, and you can still pass tests with N/A steps, rather than the previous “no run” option.
This is meant to give your team and project members a more accurate view of project status.
End to end Integration with JIRA
Yesterday (Saturday 23rd) we upgraded our integration with JIRA Server, JIRA Cloud
End to end traceability of your Jira Requirements and Issues in PractiTest for Seamless Jira test management
See JIRA issues directly in PractiTest
JIRA users can now see their JIRA Issues directly in PractiTest including all the relevant testing information.
Linked issues are synced to PractiTest in real time.
Integrate Requirements into PractiTest
Your requirements/User stories are now a part of your testing.
Users can now link requirements directly from JIRA to PractiTest and have testing traceability from end to end, including:
Requirements, tests, issues and the relevant reports.
Requirements are synced from JIRA to have information at PractiTest updated at all times.
Users can choose to link/unlink the Requirement from PT to JIRA.
New projects are now easier to set up than ever before.
Project, issue and PT IDs are automatically populated from your JIRA projects.
Start working with this integration today
JIRA Cloud users : Update was done automatically!
JIRA Server users: Please update your PractiTest-JIRA add-on and contact us.
For more information, please review our JIRA integration page.
PractiTest Maintenance Notification – Saturday, August 9th, 2014
As part of on-going operations to improve the functionality and the performance of PractiTest we will be carrying out maintenance operations to our servers during the weekend of August 9th, 2014. Even though most of our maintenance does not usually cause any downtime, this specific operation will require us to have some downtime in our service.
In order to minimize the impact of this operation we have scheduled our maintenance to happen on Saturday, August 9th, 2014 at the following time:
- GMT – 5:00 to 9:00
- CEST – 7:00 to 11:00
- Eastern US – 1:00 to 5:00
- Pacific US – 22:00 (Friday Aug 8) to 2:00 AM
- Eastern Australia – 15:00 to 19:00
You can follow our live updates for this operation via PractiTest’s Twitter account.
As always, we will be more than happy to provide additional information and answer any questions you may have. Feel free to send your questions to our support.
The PractiTest Team
All 2013 archive posts
5 Agile Principles You Can Apply to Every Type of Development Process
There is something professional consultants may not want you to know:
You don’t need to make major changes to your development processes in order to gain many of the benefits from Agile principles.
If you take the time to truly understand Agile (and not only repeat the Pros & Cons circling around the web), you’ll appreciate the fact that Agile is not a methodology but an approach to software development that can be applied to every methodology. Sure, methodologies such as SCRUM and XP were designed to make specific use of Agile principles, but this doesn’t mean you need to work this way in order to gain all or most of the benefits of Agile.
Some work Agile without even noticing it
A couple of months ago we talked to a customer who told us they wanted to work using Agile principles but had not had the time yet to implement SCRUM in their organization. The team’s manager mentioned that a SCRUM consultant had come to talk to them about implementing Agile, but after further review he decided it would be better to wait until their current release was out the door, within the next 6 to 9 months, to make all the necessary process changes.
This manager, being so impressed with what he heard, asked the team to make small changes and start implementing some of the ideas the consultant had suggested. And so, the team started having short 15 to 20 minute update meetings each morning over coffee and bagels.
Instead of having each programmer work on long tasks that could take between 6 to 8 weeks to complete, they started organizing tasks for shorter periods and worked in task teams of 2 or 3 programmers.
Another thing they did was to get the testers to work earlier and more closely with the developers, beginning during the coding phase itself, Testers would perform preliminary tests on the unfinished product and also give programmers ideas on how they could improve their Unit and Integration tests. As part of this process, programmers also “learned” how to run part of the manual test cases themselves before committing their changes as part of their “internal sanity.”
Finally, the manager asked the whole team to schedule a formal meeting with Product Marketing at the end of each month where they would demo the progress of the features. During these meetings Marketing would also provide feedback that could still be implemented for the current version’s development without delaying the release.
The manager told us that since they started working this way the productivity and the general working environment in the team improved greatly, and that he was really looking forward to implementing SCRUM in the team.
What he had not understood was that, without making any revolutionary changes to the way they work, they were already implementing an important number of Agile practices and experiencing their benefits.
The Road of Small Changes and Improvements
The story of this manager is a great example of how Agile can be implemented using small changes to your overall process. There is no real need to carry out a revolution in order to achieve many of the results you are looking to gain.
Following are a number of ideas that can be taken from the story above and that we believe can be implemented quickly regardless of which development methodology your team is currently using.
(1) Work in small/er chunks
Instead of working with a small number of very large requirements or tasks, break them down into smaller, more easily managed chunks that can be completed in shorter time intervals (days or weeks). This way you are making sure tasks don’t start taking up more resources than you originally allocated (because if your planning assumptions start slipping you will notice it within 2 weeks instead 2-3 months into the work) and most importantly, you will be able to deliver features faster to Testing and to Product Marketing and get feedback in time to make the necessary fixes and adjustments without affecting your release date.
(2) Increase the collaboration and communication between programmers and testers
If the idea is to get feedback about the features to the developers as quickly as possible then the best way to do so is to test sooner, many times, even in parallel to development.
You can achieve this in multiple ways, for example by inviting testers to run their test directly on the development environment as soon as parts of the features are ready (instead of waiting until everything is completed).
Another way is by having testers work with developers to plan and write their Unit and Integration tests in ways that will help them catch more bugs more quickly. And finally, how about we start teaching programmers how to run at least part of the manual and automatic tests written by the testers as part of their Sanity Sessions before committing their code? We see many teams where developers have their own Test Sets in PractiTest that they need to run before committing their code to the main branches.
(3) Have more automated tests and run them more often
This is one of the first principles applied by Agile teams but in fact, it is logical for every type of project. Make a commitment and a conscious investment in automation.
Start by instructing your developers to create Unit and Integration tests for each new feature or major bug fix.
You can also have your testing team create automatic tests to cover as much of your product as possible, and instruct your developers to code in ways that will make this functional automation simpler and more robust (for example, by using correct instrumentation of the GUI elements).
But creating your tests is not nearly enough. You need to have a framework that runs these tests as often as possible and provides immediate feedback to programmers whenever they’ve introduced a bug.
Today there are a number of very good Continuous Integration Frameworks (such as Jenkins, Bamboo or TeamCity), all of them can be integrated into PractiTest using our Robust API. Finally, you will also make sure your programmers comply with the golden of rule of “you broke it, you fix it. RIGHT AWAY!”
(4) Seek quick feedback and continuous improvement
The greatest enemy of improvement is human behavior: no one likes being criticized, and we mean that. No one!
That is why whenever we work on something, we don’t like showing it to others unless we feel it is complete and our audience will be able to understand “exactly” what we did.
But as you may already understand, this is counter-productive in programming because if we wait too much to get feedback then we won’t be able to implement any changes without missing our delivery targets.
So what can you do?
Basically, overcome the trauma of being criticized by making it a policy to have everyone present their progress to the rest of the team and product marketing – as they are working.
Work on creating a culture where people know how to give and receive feedback. You can achieve this by making sure feedback is always directed to the work and not to the person, and also by having people give feedback on both the good and bad things in the product (and not only focus on stuff that needs to be fixed).
It may not be easy at first, but it will be easier with time and the value gained by this is simply incredible.
(5) Embrace change and work accordingly
This may be the cornerstone of Agile – the realization that regardless of how hard you work on planning your project and how good you are at it, in the end, stuff will change and you will need to adjust your plans.
But, slogans aside, how do you embrace change?
First of all plan less, not less deep but yes, less for the long-term since you cannot foresee exactly what your reality will be a few months down the line.
Seek feedback sooner rather than later, make sure that if you do need to change features and plans, you know this 2 to 4 weeks into the project and not 6 to 9 months into it.
Plan for change and make sure your team is aware that change will indeed come and it will be accepted; this makes it easier for them when they are faced with that reality and need to cope with it.
Making small changes should be part of your work culture.
One of the best principles you can adopt from Agile is the understanding that just as the product and the requirements are constantly changing, so should your work processes be dynamic and adaptive.
Be open to asking questions about whether you are working in the best and most effective way or if you can make small (or large) improvements to the process?
Be open to feedback, seek it and even reward the people who give it. Once you are able to introduce the acceptance of feedback into your company culture, you will see how things really start improving, almost on their own.read more
All 2012 archive posts
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