Version 2.9 – Better Team Building, Cloning Test Cycles, New Test Cases
Time flies here at uTest, and not long after we rolled out version 2.8 of our testing platform, our engineering team comes along and delivers version 2.9. And with this being the holidays, they’ve included some great new features sure to brighten the eyes of software companies and testers everywhere. So grab some milk and cookies and let’s unwrap these great new version 2.9 features:
Better Test Team Building
As customers come back to test again and again, they have been asking us for greater control in building their recurring test teams. Starting with version 2.9, customers can more easily find the right testers for their projects, including inviting back the testers they liked best from past test cycles.
That means a customer can get the team they want faster and more easily than ever before. And that means it’s faster and easier to run new test cycles.
Cloning a Test Cycle
We’re also introducing the ability to clone a test cycle. Cloning a test cycle lets customers take all the settings from a previous project – including their testing requirements across locations, environments and testers – and reuse them on a new test cycle with just a few clicks. That means our customers can focus on only the things they want to do differently – such as adjusting the testing scope or special instructions.
To get started, open the test cycle you want to clone and look for the “Clone Release” button. Click it, and then change the name, end date, and any other details you wish to adjust in your new test cycle.
Incorporating Test Cases
More and more often, customers are asking us for help, not just in finding new bugs, but also to help make sure the old ones stay gone. Many customers are now asking our testers to provide testing coverage (across functionality, across locations, across OS and browsers) to validate their applications. The best way to achieve this testing coverage is by using test cases that ensure that all the important details are covered. Until now, we’ve asked for testers to submit their completed test cases as “technical bugs”, but from this point forward, testers can submit a completed test case as its own kind bug type.
When submitting a completed test case, report it as a bug and choose “Test Case” as the bug type:
Have a great idea for our future releases? uTesters can join our testing forums and check out our Platform Feedback section.
uTest leadership,
Good update. I’m impressed with your firm’s growth and continuous improvement efforts. I think you’re missing one additional way to significantly improve your efficiency and effectiveness. The improvement opportunity is hinted at in your update.
You mention: “Many customers are now asking our testers to provide testing coverage (across functionality, across locations, across OS and browsers) to validate their applications. The best way to achieve this testing coverage is by using test cases that ensure that all the important details are covered.”
Studies, including this one: https://www.hexawise.com/casestudies show that this is not technically correct – at least if the implication that testing each “important detail” individually is sufficient. You don’t only want to ensure each of the details (or features) are covered; you want to ensure that you’re testing for each feature IN COMBINATION with every other feature (and data range and OS and browser type). The only way to do that efficiently and effectively is with a pairwise and/or combinatorial testing tool. Yes, using “only” is a bit like using “always” or “never”; I don’t use it lightly.
To put my money where my mouth is on this assertion, here’s a tongue tongue in cheek offer that I hope doesn’t come off as sounding too brash. If you’d like to do a pilot of a pairwise / combinatorial testing tool that will dramatically improve the number of defects your testers find per hour, please let me know. My expectation (which I’m willing to back up with a friendly wager) is that you’ll double your tester productivity.
I’ll bet you a bottle of wine your testers will find twice as many defects per hour using this approach (as opposed to, e.g., running the same set of tests for IE8 and again for FireFox). Two buck Chuck or first growth Bordeaux. Your choice. 100% improvement or I lose. What say you?
Thanks. You know how to reach me.
Happy holidays.
- Justin
______________
Justin Hunter
Founder and CEO of Hexawise
“More coverage. Fewer tests.”