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’s 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’s very important that the relevant information is available to all parties involved. You should always know what should be tested, who’s 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.

User stories

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.

For example:

- 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 support@practitest.com.

Happy Holidays!

The PractiTest team.

We’ve been making changes over the last several weeks to better support our customers at PractiTest. As our client-base grow, so do the support requests, and our need for more automation and integration to our workflows.

That’s why we have migrated to new PractiTest help platform (via Assistly). This will make support more efficient. What you can expect is the same level of support, with the following visible changes:

• All support will be answered right in your inbox.
• A new knowledge-base, with the same articles you’re used to.
• Later on, an easier ticket submission right from the app instead of opening your email or creating a ticket in the help site.

We are confident this new system will make our excellent support even better.

Do you know a company that may benefit from PractiTest? Now you can earn money by recommending  users to work with PractiTest.

PractiTest will pay a referral fee of twenty percent (20%) of net revenues for the life-time of your referral, subject to the minimum requirements stated in the cooperation agreement.

affiliates program

PractiTest Affiliate Program is simple:

• In order to receive a referral fee you need to refer at least one new paying customer every twelve months, generating a minimum US $400 revenues per month.
• As long as this minimum milestone is kept, you will receive the referral fee of 20% for all the accumulative accounts you referred!

As you can see, this is an awesome affiliate program so go ahead and check-out the details. This is your chance to benefit both yourself and your colleagues, by recommending PractiTest.

Does your team have automated tests?

• Do you run automation as part of your tests?
• How do schedule and execute your automated scripts?
• Do you generate reports out of your automation?  Do you do this together with your manual tests?

It’s great to see how test automation is becoming more common in today’s testing organizations.  Something that used to be mainly a buzzword in the industry, is becoming a helpful tool to many teams around the world.

Regardless if you use Selenium, QTP, or even home-brewed scripts, automation is more and more a part of everyday QA life.  Even though it is still far from being a Silver Bullet, as many tool vendors want us to believe, it allows to streamline our processes and to develop more stable products, helping us release high quality products faster than before.

The problem is that, in order to make proper use of automation you need to manage it and integrate it into your overall testing process. For example, you need to understand what part of your tests are automatic vs. manual; or sometimes you are asked to generate reports that will show your stakeholders the overall testing status of your product (regardless if the test is automated or not!).

What were we looking to solve?

After getting a number of requests from users to expand PractiTest’s functionality to manage (also) automated tests we started searching for the best possible solution.

Basically we wanted to come up with an approach that would allow users to:

1. Manage their tests and runs, whether manual or automated, in one place.
2. Increase the visibility of the automation efforts and teams, eliminating any communication or coordination issues.
3. To see the results of all my tests in one place, creating comprehensive reports.
4. Providing a solution that is simple to deploy and flexible enough to manage as many tools as possible.

Our solution – the xBot automation agent

So, after talking to our users and reviewing many possible approaches we chose to develop what we call the xBot automation agent, a small java utility that runs on every OS (Windows, Mac, Linux) and is able to execute scripts written on any tool or any language.

Users who want to run automated test simply map their automation scripts to tests in the Test Library, they then create a Test Set with their scripts, and schedule the time when they want their tests to start running.  When this time arrives the xBot gets from PractiTest the order to execute the scripts locally.  Finally after each test is run, the agent uploads the results to PractiTest as part of the test execution log.

Public release of the xBot agent

In the beginning of the year we started a private beta with a limited number of customers who had asked for this functionality.  Later on, in February, we released the public beta in order to get more feedback on the solution.

In May and June published a number of posts in our QAblog, linked-in and other forums, asking testers what are their biggest challenges when coordinating automated and manual tests.

Now, after taking the feedback from the Beta and the inputs from the web, we are proud to release this new solution to support automated testing via PractiTest.

We hope you’ll like our solution and invite you to keep providing us your feedback.  Here’s more information about the xBot and PractiTest’s support for Automated Tests.