All 2013 archive posts

5 Agile Principles You Can Apply to Every Type of Development Process

Date: 2013-01-01

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.

Rich Text Formatting, Improved filter definition, Import & Export settings, and more

Date: 2013-01-01

During the last month we’ve been gradually rolling out a number of features and changes aimed at improving the system and to answer the requests received by a number of users.

• Rich Text Formatting. Allowing users to add text effects such as bold, italics, underline, as well as colors, bullets and numbering. With the rich formatting we are also providing support for Right to Left text orientation* (as required by our Hebrew and Arabic speaking customers).
  
• Improved filter definitions and view exporting. As part of our new features we redefined the way users create and edit filters, improving the usability of this control. We also added the option to export each view as part of the view control itself (see image bellow).
  
• Import and Export Settings. We decided to group the importing and exporting functions and place them in their own tab as part of the settings, making it faster for users who want to perform regular exports of all their projects in one place.
• Plus additional bug fixes and smaller features.

We invite all of you to continue providing us with feedback and ideas on the features you’d like to see added to PractiTest as well as any other improvements you can think about. Just add your feature requests to our Product Feedback forum.

See you all in our new update!

* To enable RTL (Right to Left), goto Settings -> Project, check the enable RTL checkbox & Save

Import tests and steps, improved graphs settings and more

Date: 2013-04-01

In the last couple of weeks we released a number of improvements to PractiTest to help you work better and faster:

• Additional advanced settings in Dashboard Graphs.
  These settings let you create wider graphs to handle more information, and they also allow you determine the colors of your graphs easier and with a higher level of control for each of the categories in the graphs themselves.
  

• Ability to import Tests and Steps from one file in one operation.
  This is one of the biggest requests we got around this feature. PractiTest now allows you to import all your test information (including the steps) in one go.
  To learn more about this feature and how to work with it you can read this suport article on how to import tests and steps.

• Work directly with MS-Excel files such as XLS and XLSX. This will allow users to work faster, without the need to convert their files to CSV.

Make sure to contact us and to keep telling us what you want to see improved or added into PractiTest. We’re always happy to get your feedback.

See you all in our next update!

Introducing PT Labs, cloning issues between projects, TestSets & Reports API

Date: 2013-06-01

We’ve kept busy during the last couple of weeks working on the new product GUI, but in the meantime we’ve also released some features and improvements that a number of our users eagerly requested:

• PT Labs.
  With the increasing number of ideas we keep wanting to develop and include into PractiTest, we choose create the PT Labs project as a testing ground for experimental features that aren’t quite ready for primetime. But that we think provide great value to many of our users.To check out the PT Labs section simply go to Settings and then to the Project tab.
• Cloning issues between projects.
  One of the first features to enter the PT Labs project is the ability to clone bugs between projects. Once you activate this feature in the settings you will be able to copy your bugs between the different projects based on your development process.
• Test Sets and Reports API.
  As many of our customers keep making extensive use of our API we got multiple requests to add API coverage to the Test Sets and to the Reports areas of PractiTest. To learn more about this extended API just go to our support site: TestSets API, Reports API.

As always, we invite all of you to continue providing us with feedback and ideas on the features you’d like to see added to PractiTest as well as any other improvements you can think about. Just add your feature requests to our Product Feedback forum.

See you all in our new update!

New GUI Design is on the way!

Date: 2013-08-01

PractiTest was initially released in 2008. Back then we designed the GUI almost on our own, and we were anxious to get the product out for beta usage.

Since then, the application has continued growing based on our product road-map and the comments & ideas from our ever expanding user base.

Over the years many things have changed, we modified our logo, we moved to a new office location, and all the time we got requests from of our users to refresh and improve parts of our GUI, to streamline some of our processes and to organize the information a little better.

Until we reached the point where we realized that it was the correct time to shift to a new and more professional 2013-style GUI; one that supports both current and future features, and that will be based on the benefits HTML5 technologies and more.

So about half a year ago, we started this “new GUI” project. The project itself included thousands of code changes, an upgrade of the libraries we use, and major changes to our css and app layout; all this resulting in a faster, cleaner and better application.

We showed some of the changes to a limited number of customers, and their positive reviews literally blowed us away!

Here’s a glimpse of what’s about to come:

1. Neutral colors and smart design

One of the first changes you’ll notice is the new palette, with neutral colors to help you concentrate on your work.

The new toolbars and the overall design of the system has been focused on displaying more information, doing so with a more structured and intelligent approach.

2. New and Edit screens

The screens to create Requirements, Tests, Tests Sets and Issues will also have now a more structured design.

With a more flowing design to better use all your screen, grouping fields based on type (e.g. user, dates, etc), and decreasing the number of tabs by grouping more information areas together, such as Attachments and Comments on the General Tab.

3. Step Edit and Execution windows

Steps were also upgraded based on a number of comments and requests we got from our users.

Steps are now displayed in a grid like view. Run and Step status is more evident based on the color of the step’s name, and a new-integrated view will provide all the advantages of the compact view with all the functionality (e.g. report bug ids, add attachments, etc) of the extended view.

And much, much more…

These is only a small sample of the improvements that will be provided with the new GUI design of PractiTest.

We expect to release this “new GUI” project within the next month or so (by October). PractiTest Account Managers – you can expect to get access to see these changes in the next 2 to 3 weeks.

If you have any questions or comments please don’t hesitate to contact us.

PT GUI change – what and how

Date: 2013-09-01

Heads up for PractiTest clients
If you think you’d like to use our staging environment with the new GUI to get a feeling of the new system before the deployment, please don’t hesitate to contact us (email to support).

As many of you already know, we’re are going to be upgrading our GUI in the next couple of weeks.

We’ve been wanting to do this project for a while now, but we started the concrete process only around April 2013. The idea was to improve a number of aspects in the User Interface, and also perform some technical changes and optimizations to our existing platform.

Here are some of interface issues we wanted to solve as part the GUI project:

• Make better use of the available screen – most of our users use desktops, with large HD screens, when testing their software. We thought it was about time to make better use of the width of these wide screens and avoid the scroll if we can.
• Flexible Text Areas – we have text areas in numerous of places (entities’ description, steps’ descriptions and more). Having them with a fixed height forced customers to use the scroll many times (either when scrolling the whole page, or scroll inside the text area itself). Now, these text areas expand and collapse dynamically as needed!
• Replace the issue right pane with a preview pane. The “old” GUI used to have a right pane in the issues module that we didn’t like. It made the whole grid look awkward and usually it was used only to view the fields (and not to edit them). So we took it away, and added a popover when hovering those items, to see the fields. The popover was added to many other grids as well.
• Better support for tablets. As much as we said that our users work with their desktops, we found that a number of users are starting to work with tablets during part of their testing operations. The new GUI is smart enough to resize itself all the way to “tablet size” and help you work seamlessly with these devices.
• Reduce the amount of tabs we have in each entity. It came to our attention that we had too many tabs and that we could reduce this number by grouping part of the information into existing tabs. So now, for example, you will be able to add comments and attachments from the general tab.
• And many other changes and improvements.

In addition to the externally perceived changes in the GUI, we also did some important improvements to the GUI infrastructure “behind the scenes”. One of them was the adoption of Twitter Bootstrap.

There were many reasons for selecting this framework, and the main ones are the following:

• We like its clean and simple design, and we feel it helps us to set design boundaries.
• It encourages us (as designers and developers) to use their standard, and we love coding standards 🙂
• It is quite easy to implement, even in a large application such as PractiTest.

• It has almost all the components we need, and we can probably get rid of some collected javascripts code.

• It supports responsive design.

Here’s how the Tests’ grid looks now:

And so, after completing the design of the Graphical Interface, we started the development phase of the “new GUI project” on April. We did in parallel to all the rest of the on-going projects on a separate git branch.

We’re happy that up to now we’ve achieved the following accomplishments:

• Changed ~ 27k lines of code (w/o white-space changes)
• Made 752 commits
• CSS lines of code dropped from ~8000 lines down to ~1000 lines in separate files- making it much more maintainable
• We started to use only css.scss (instead of css), once again for easier code maintenance
• We revised a lot of the javascript code, using namespaces, and refactoring old stuff
• We dropped most of the images we used, using instead fortawesome (which will make everything load faster via sprites)

Completing this GUI project (which is now in advanced testing stages) was very intensive. We had to scope out many items we wanted todo (revise reports GUI, change to a standard grid, and more), that will be postpone for further releases in the coming weeks/months. But overall we are very happy and excited with the results!

Finally I’d like to thank the people who worked hard to make this project happen: Einav, Ortal, Boris, Joel, Nir & Stas

Work better now with PractiTest new & improved GUI

Date: 2013-09-01

Ever since PractiTest was launched, we have always made sure to be in tune to our users’ adaptive needs. Taking into account your requests and feedback we have implemented some changes, refreshed and improved our GUI.

Now we can proudly announce our GUI update – “PractiTest Style 2013”. The new style improves and streamline your daily processes, so now you can work in a more organized and intuitive manner.

Here’s a glimpse of the improvements:

Neutral colors and smart design

One of the first changes you’ll notice is the new color palette. Neutral colors that will help avoid distractions so you and your team can concentrate on your work.

“New” and “Edit” screens

You will notice the new “Edit” and “New” screens have a new design, with easy input fields and better use of the space on your screen.

Tabular step run window

A new and more useful design for steps in Test Sets & Runs, This new design integrates all the functionality of the extended view with the advantages of the compact view.

Rollover Preview

The “old” GUI used to have a right pane in the various modules, which made the whole grid look awkward. So we took it away, and added a popover when hovering those items, to see the fields. The popover was added to most of the entities in the program.

Better support for tablets!

As it is now common use to work on tablets while testing operations, we made sure the new GUI was able to re-size itself and adopt to the various platforms you might use.

And there is so much more!

___________________________________________________________

We know that sometimes changes can prompt questions and so we will be more than happy to assist you any way we can via our support team. We will also be delighted if you want to write to us to share your thoughts and comments on this new GUI.

We hope that you like what you see. And thanks for using PractiTest.

– The PractiTest team

Core-Apps

Date: 2013-10-01

“Thanks for a great product!”

Michele Williams, Core Apps

Freeman

Date: 2013-10-01

“The PractiTest team has always been great to work with. If I have found an issue they respond back quickly and very professionally. Without spending hundreds of thousands of dollars a year, we are getting a great product with great support that fits the needs of our department.”

Stephen Musal, Freeman’s Lead QA Tester

Improved Preview popovers – only by a button click

Date: 2013-10-01

Since we released the new GUI last month, we got some amazing feedback from our users.

We did an online survey, to explore more about the things you liked and those you though we could still improve and we found that although most of you really loved the changes we did, you still thought we had some things that could be improved.

Many users found it annoying that when they moved their mouse over the id in the grid, the popovers would open automatically; and we also had couple of bugs in this feature (which we fixed in one of those patches we’re doing all the time…) We even added a place in the personal settings to disable those popover from popping automatically.

But we really think this is a great feature and so we decided to solve the issues that were “annoying” some users. We started by changing the functionality so that when the mouse is over the id (hover), we now show the “info” button, enabling the users to click to see the preview but only with a mouse click; and another mouse click to close it.

In addition, we added some useful information to those previews. Tests -> now you can see the first 5 steps, TestSets -> now you can see the first 5 instances, Requirements – > the traceability.

We are sure this feature is now a lot better and it provides even more value than before.

Note: the disable popover flag in the personal settings settings works (turns off the popover) in the places where the feature would have been opened in the “old way” without pressing on the popover button (not in the grids). But we foresee that in the next couple of releases this flag will become irrelevant as we migrate all the popover functionality to work as it is doing in the grids today.

An interesting take on current events: What Can IT Project Leaders Learn from the Healthcare.gov Fiasco?

Date: 2013-10-01

The latest news headlines regarding the healthcare.gov debacle are an excellent example of how not to launch a new website, application or any other IT product. The common development pitfalls — lack of visibility and communication were imminent throughout the whole development process.

As many of you will agree, lack of visibility and communication are illnesses suffered by many software development and IT projects. The problematic signs are usually there, but they are not communicated to higher management.

Without the proper visibility into the process and without the ability to understand the status of the project at all times, management cannot make the correct decisions to ensure the success of the project. Healthcare.gov is an unfortunate example of the catastrophic consequences of noise interfering with the message communicated to higher management.

How can such problems be avoided? … More on the subject in our latest PR release

Ministry of Foreign Affairs

Date: 2013-10-01

“With the help of PractiTest’s customization we were able to define new issue types and better cluster the information, allowing us to filter out data and generate more accurate and detailed reports. We recommended PractiTest within our Organization to be used in further projects.”

Hein Eltink, test coordinator for the PACTA project

Radwin

Date: 2013-10-01

“When you post an issue they get back to you promptly and their turnaround is second to none. They’ve even included some features we requested in their releases. You can’t get better than that.”

Kfir Hemed, Head of the Verification Unit at Radwin

Can PractiTest support Agile Test Management?

Date: 2013-10-10

Agile Development and Agile Testing

Today, more and more teams are shifting over to AGILE. One of the interesting facts about agile development is that it comes in many variations, from Scrum to Extreme Programming and more; but regardless of the approach you follow there a number of principles in agile development that everyone agrees to:

• Customer satisfaction is achieved by frequent delivery of useful software
• Changes in requirements are part of the software development process
• Regular adaptation is needed to comply with the changing circumstances

When you work based on frequent deliveries, constant changes and regular adaptations; how can you still manage an efficient testing process?

Part of the philosophy behind agile development & agile testing talks about shifting towards automated testing as the means for covering regression testing & test driven development to achieve more stable code from the beginning. This “advise” is helpful but it still falls short from providing the solution and the guidance needed by a QA team to cope with the challenges of shifting to AGILE.

There are books that talk about this, and Joel wrote about similar topics in his blog. But in the end there is nothing like the experience from working with many organizations that shifted to AGILE with the help of PractiTest, and from the knowledge we’ve gain from our own experience developing PractiTest as an agile team. The tools you use will help you achieve your testing and development goals in the same way that a hammer and the nails help the carpenter to make his furniture, and flexibility & adaptability is a must when you are looking for a tool to help you manage your agile process.

PractiTest Test Management Solution for Agile Development

A quick search on the Internet will show there are many solutions specifically designed to handle agile development, and some of them even claim to support agile testing, but we still see many customers who check them out and find they are missing important functionality needed to cover the testing process.

As a methodological test-management solution, from time to time we are asked to show how we support agile development and testing, and an interesting fact is that we support Agile Testing without having any specific feature developed solely for this purpose!

How do we do it? The answer is simple, we believe in flexibility. PractiTest enables YOU, the user, to customize the system based on your process, your product and your needs.

If you working based on sprints, for example, you can customize the system by creating a custom field called SPRINT and adding it to your requirements (or user stories), to your tests and to the issues in your project. Once you have this field in place you can organize all your data and work based on the sprints you defined. You can then create views and reports that will make it easy for everyone to gain visibility into their tasks and those of the team and allow the whole team to manager their work fast and easily.

What’s even best is that you can modify the values in the fields and even the fields themselves with a small number of “clicks” and in a matter of seconds (without the need to of complicated customizations or processes).

Another aspect common to Agile Testing is the popularity of Exploratory Testing among testers. This approach works mainly by defining testing charters up front and documenting your testing steps at the same time you execute the tests. In PractiTest this is easily achieved with the functionality available that lets you edit your tests steps even when you are running them within the Test Sets & Runs module.

There are many aspects that define Agile Development & Agile Testing, and the truth is that each organization and even each team will approach Agile in their own individual and different way (based on their needs and their constraints). In this same way, we believe that it is not correct or even possible to try to define for you how you should manage your agile testing process. The best approach, the one we believe in, is to give you the freedom to let you decide how to work and to support you process your way!

More information about custom views and custom fields.

Better Test Sets & Runs Navigation

Date: 2013-10-01

Hello to all PractiTesters!

Recently we performed another update of PractiTest with important additions to make your work better and more effective. Let’s start with some additions to make your work clearer, specially when you are only getting started with the system. We believe that each tester (or non-tester) working with PT should understand our methodology (and read the page at least once).

As part of our Testing Methodology you can see that:

• A Test Set is a collection of Test Instances
• An Instance is linked to a Test (in the Test Library), so that each Test can be linked to multiple Instances
• Each Instance can have multiple Test Runs (where the status of the Instance is the status of its last Test Run).

The Test Legend

To avoid confusion (“where am I right now?”), we added a Test Legend in all testing related entities, indicating the location in the application. We believe that especially for new PractiTesters, this legend will help understand our methodology and the links between the different entities.

The standard Testing Scenario

• Each Test (in the Test Library) is defined only once, with all its relevant steps
• Test Set creation, and their respective Instances, are defined once in a while when there’s a reason to start running these tests ( e.g. a new version /release, new functionality, etc).
• Whenever a user goes to the Instance, and presses the Run button, a new Test Run is created, copying all the steps to the test run (so if the Test in the Library is changed later, the steps in the run will not change)
• If for any reason, an Instance needs to be re-run in a specific Test Set, the tester will create an additional Run and not overwrite the previous run. Ensuring all run history is saved.

Better Test Sets and Runs navigation

In addition to the above we decided to streamline the testing process, making the run button much more powerful, and skipping some screens when they’re not required:

• If the user starts a Run from the instance grid, and the Instance has no required fields or older runs, then it goes straight to the run window (with the steps). Enabling to start and testing right a way.
• In cases when there are required fields in the instance that are not filled, it will go to the instance window.
• And in the case there are older runs (that you want to review before starting your new Run!), it will go to the instance window, showing previous runs, enabling to go and check or update one of those test runs.

We are sure these changes will make your testing experience more productive. And we invite you to share with us additional ideas to make your work even more effective in the future.