As you may have noticed, earlier today we modified our Website.
Basically we wanted our users and potential customers to understand why our Intelligent testing platform improves the QA planning, design and execution processes; ensuring product status transparency and reducing time to market uncertainty.
As part this update we also introduced our new logo, that includes a drawing of our mascot, the testing fox.
Why did we add a fox to our logo?
For many of us (testers) this is a trivial question, but still to make sure we don’t leave any doubts out there, the answer lies in the similarities between the “personal characteristics” of a fox and those of a good tester.
Think about a fox for a second, how he behaves in nature and what traits help him survive and even exceed in his surroundings.
You can say that in order to survive in the wild a fox he needs to be:
And the list goes on and on…
Now let’s look at the Tester in his natural habitat:
SMART – OK, who’d ever say that his job allows even “dumb” people to succeed… But in the case of testing we know that due to the level of complexity required of us, as well as the multitasking and context-switching that define our day-to-day tasks testers need to be smart enough to quickly grasp the challenges ahead of them and successfully approach them in the most intelligent way – without wasting time over-analyzing the situation.
CRAFTY-ness in testers refers to the way we are required to make use of the tools we have at hand, and at times even to come up with new tools to complete our jobs.
CREATIVE-ness allows us to look at an issue and come up with interesting and new approaches to understand and solve them. Sometimes it is how to test a component, other times it can be how to find the complete scenario of a difficult bug, regardless of how you see it, a tester needs to be able to find the solutions by reframing or zooming out from their tasks.
SNEAKY – as the saying goes, it takes a thief to catch a thief! And so, a tester needs to have a sense of sneakiness when he sets out to hunt for bugs. One of the tips I give beginning testers is to go and check the bug database for defects that were detected and fixed in past versions. Understanding the way bugs sneak into the system is always a good way of catching new bugs that used “old ways” to sneak in.
ADAPTABILITY is also something that allows a good tester to juggle between the testing tasks, bug verification tasks, “trouble-shooting with support” tasks, feedback to developer tasks, and all the other tasks that fill out our daily task list.
Finally INGENUITY or cleverness is what allows us to keep coming up with answers and different approaches to the challenges faced everyday.
So, why did we choose a fox? Because a tester needs to be like the fox that works in small groups and even though he’s not the strongest, or the fastest in the forest, he is still able to catch his prey successfully and elegantly.
“We were looking for a solution to organize our testing process and keep control of our quality. PractiTest supplied what we needed, with its organized and structured test case management solution.”
Gilad Breslawer, QA Team Leader, Plimus
“PractiTest enables us to organize our tests and report bugs into one database, in a unified and pre-defined mode, providing us with much-needed order and enabling us to streamline our testing process.
As a service provider working in complete transparency with our customers, we found the PractiTest dashboard and reporting mechanism a superior tool for providing our customers with a clear and precise view of development status. In this way PractiTest helps us reach our goal of maximal customer satisfaction.”
Hila Vax, QA Team leader, Symcotech
“With PractiTest we manage testing of three separate applications (ERP, point-of-sale, and payment processing). This means that separate QA teams in different sites use PractiTest to manage tests and bugs.
No doubt, this is the best product in its price category: PractiTest is solid enough to support multiple testing environments and complex scenarios, yet it’s very intuitive for everyday use (such as filling in bug information and opening new projects). Their support is second to none; a mail is normally replied within the hour; sometimes directly by phone.”
Ophir Amitai, QA Manager, Delek Corp.
“With PractiTest we finally connected Marketing, R&D and QA in one system, streamlining our whole product – development process – from requirements to testing. The results: shorter development and testing cycles, and a product that is closer to market demands.”
Uriel Perlman, Head of QA, Wavion
We open this month with the latest version of PractiTest, released on april 1st. This version includes new features and updates, most of them were requested by our customers.
Here are the main changes made in the latest version:
- Our new and improved Test Instances grid: You can now select to see any field taken from the original test (in the Test Library) as part of your test instances grid (within the Test Set). So you can now filter the instances in the grid based on the Test fields (just click on the Columns button)!
- Multi-level linked-lists: in previous versions, you were able to create linked-list field, whose values depend upon a previously created list field, so that your linked lists were limited to 2 levels only (parent-child). Now you no longer have to settle for a 2-level linked list, and you can create linked lists with as many levels as you need.
For example, you can create a regular list field to denote the OS you are working on, then a linked list of Browsers showing you only the browsers available for each OS, and then a second linked list of Browser Versions showing you only versions relevant for the selected browser.
- New notification list: users defined as Administrators can now add other users to an entity – notification list, to make sure their users receive messages when changes are made the entity
- Improved dashboard pie-charts, with easy to read labels located outside the different sections.
We hope you enjoy and benefit from these new additions, and as always, we are waiting for your feature request if you have further suggestions or comments, don’t hesitate to let us know!
We are happy to announce that PractiTest has been selected to participate in Red Hat Innovate.
Red Hat Innovate is a new initiative launched by Red Hat, the world’s leading Open Source Software Company. The initiative aims to assist innovative software development start-ups to build on the power of the open source community.
Red Hat – vote of confidence means a lot to us, and we are very excited to be offered this partnership. This opportunity will help us keep doing what we do best – developing and innovating in the field of software testing.
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.
A couple of weeks ago we had a short service outing for PractiTest.
The service was down for about 22 minutes. This was the first time in over 18 months that our service was unavailable for more than a couple of minutes (and even this happened only twice) or as part of a scheduled maintenance.
Even though short outings like this one are common in our Industry (after all there is no system, not even Gmail, that doesn’t have glitches once in a while) we have gone through a serious retrospective analysis of what happened in order to avoid similar issues in the future, and maybe more importantly to respond even faster in the event something like this happens once again.
What went right
Part of our analysis showed that there were many things that worked correctly.
– We got both SMS messages as well as notification phone calls from our automatic monitoring systems telling us something was wrong with our servers.
– All back-up systems were working correctly (even though we did not really need them because no data was corrupted at any time).
– Our team was aware of the issue even before the first of our users contacted us.
Things to improve
We also detected a couple of things that need to be improved:
1. Because of system security procedures there were only 2 PractiTest employees who could respond and act when issues like this happened. Unfortunately this number seems to be not enough because at the exact time the issue happened one of them was commuting and the other one was also out of the office with a dead smart-phone battery.
To avoid issues like this we provided another employee with access to these servers. We are also creating an internal notification process to make sure that at least one of them is available 24/7 – with more than one way to communicate 🙂
2. Up to last week our internal monitoring system didn’t cover secondary services and one of such services turned to be the culprit. Now we’ll monitor all services, primary and secondary. This means that the monitoring process will give a head’s up before the services reach a dangerous level, so that we have more time to act.
3. One of the things we had already planned to do but may take a couple of sprints to have in place, is the ability to use the Autoscale system provided by Amazon. This will allow our system to automatically scale up in cases when the CPU of any of our services goes over a set threshold.
We already started working on this, but now we increased the development’s priority of it.
4. Last but not least, we want to provide even better visibility and transparency to what is happening in our service. We know that we have the best support and provide almost immediate answers via any of our current communication channels (e.g. Support Site, Skype, email, etc)
But we need to improve the way we broadcast information by being quicker with our twitter updates or by publishing blog posts such as this one faster and closer to the date of the incident.
(*) Just a short note to say that some of our technological plans may change as we have been accepted to be part of the Redhat Innovate program.
As always, we are here to answer any questions you may have about this or any other aspect of our service.
Please don’t hesitate to contact us via firstname.lastname@example.org.
The PractiTest team.