Category Archives for "Testing Tips"

5 impactful questions a test management tool will answer in your team

Imagine you’ve joined a new organization as a QA manager and you see a great product. The product you think which can be next big thing.

Sure your new company isn’t where it can be right now, but it has huge potential.

 

So as a QA manager or anyone in charge of quality for that matter, where will you begin your job?

In most cases, companies hire staff for testing and leave them on their own. So when you are all alone against big responsibility, what to do?

Continue reading

Step-by-step guide to integrate Ranorex Test Automation with Test Collab

Ranorex is easy-to-use test automation software (yet available for Windows OS only). A step-by-step wizard helps to set up the test environment and quickly get started.

For Windows application development and testing, it makes perfect sense.

Non-programmers can use the script-free drag & drop functionality, whereas professional programmers can use an API for C# and VB.NET to enhance their test suites and recordings.

It has a powerful GUI recognition covers all requirements in terms of accuracy and unique identification. It will recognize and find the element anyway even if the button’s shape or color changes. Facility to reuse code and action modules across multiple test cases with click & go functionality. This will save a lot of time when changing multiple test cases. Recording tests is very simple. Just press the record button, start your manual testing and It remembers all of the steps. Delete redundant steps with an easy-to-use editor.
Continue reading

Manually testing Feature Branches the right way

For many teams it is essential to work with different branches at same time so the main repository stays stable while development can still progress at a fast rate. Developers can create their own branches from the trunk/baseline and work independently on it. (Read more about that on Martin Fowler’s blog)

This creates a few problems when it comes to testing:

  1. With the changes that occur in branch, some test cases are affected too and needs to be changed.
  2. Multiple branches means maintaining multiple copies of a test case.
  3. Testing individual branches requires a tester to refer to the updated list of test cases only.
  4. Some branches will be merged to trunk/master sooner than later, that means at some point you will be merging these updated test cases to the trunk/master.

Continue reading

1 8 free new testing tools which are making development teams more productive

WOW, we’re seeing so much innovation in software testing this year.

A part of me can’t help but feel overwhelmed every time I see all these brand new awesome tools available which promises so much. More tools bring me more pressure, but they also bring insane improvements in how things get done in a team. That’s why – we never stop looking out for these new tools.

Every year new tools are doing exponentially more than their respective predecessor.

Imagine this:

About 8 years back, it took me over 100 hours to setup a simple CruiseControl build system from scratch for our very first product. Continue reading

Test Case Versioning with Test Collab

During your application life cycle a lot of new changes are made to existing features, and when these features change, so does your test cases. Do you know Test Collab stores all revisions of your test case? So every time you make a change in your test case, the old revision is automatically stored. This means you can keep track of such changes over time. Continue reading

3

Test Automation for Windows and Linux

Imagine being able to track your manual and automated test results from a same place. Sounds cool right? With Test Collab not only you can do exactly that but also assign tests to human or machine with just a few clicks without messing up with a dozen APIs or doing custom code. The bottom line is:

  1. You create test and store them in your test case manager so other team members can run it.
  2. Few of these tests are automated too.
  3. But there is no easy way to keep track of automated results for each test. Okay, maybe your build server does that but then again you have to check test results at two different places: Test Case manager for manual test and Build server for automated test.
  4. And to run manual test, you will assign an execution to your team. Similarly you will trigger a new build on your build server for running automated tests.

     

    We know this is unproductive so we bring you our new improved remote executor.

For people who never read about remote executors yet, here’s a quick summary: Test Collab Remote Executor turns your machine into a test slave which is used to run automated tests. It posts all necessary info produced while testing to Test Collab server for analysis. Check the how-to screen cast here (little outdated) – it isn’t best explanation but will help you in a basic way. For further help, you can always reach our support team.

While we launched this quite a while back, but now we revamped the whole thing and added support for linux platform too. This is first stable release of our remote executor. Download here

Dear Software Teams: Using Spreadsheets for testing is a crime against productivity

I remember few weeks after our launch (in mid 2011), a potential customer emailed us saying that he needs to convince his team that using Test Collab would be better than using Excel for their software projects. Then we received a few more emails like this, and found out many corporates and big companies were stuck with Excel as a testing tool, it appeared they never even looked for a specialized tool.

Here’s a thought: Why not use a specialized tool instead, like Test Collab? You’ll spend hundred of hours maintaining a large sheet with thousands of records which becomes obsolete after a few months. Choosing such a cumbersome solution has only two possible outcomes: (a) No one in QA team will want to use the solution – because its ineffective and it wastes their time. (b) These spreadsheet will become so ugly and annoying as project grows that no one will be able to use it, even if they want.

So, want a reason to ditch spreadsheets (or Excel) right now? I’ll give you eight:

  • It was not made for test management. Although some might argue that it can be repurposed to do whatever, but good luck first figuring that out, then writing rules for team and getting team on same page.
  • No user management or roles: You cannot define permissions granularly without being an Excel nerd. Even if you do, it’s simply not worth considering hours you’ll spend on development and maintenance.
  • Categorization / Tagging / Reusing data across projects will never be possible. Even an Excel nerd can’t help you here.
  • Real Test Execution / Tracking time elapsed is not possible. A tester can never feel the execution running in an spreadsheet, because that is what he’s working on – a sheet. With a software like ours, testers get real sense of activity while tests are executing, while a sheet on the other hand is just a place for end result to go.
  • Integrating with your defect manager: Testers can push defect from test failures to your issue manager in real time. Can your spreadsheet do that? No, I’m guessing.
  • No data organization
  • No out-of-the-box metrics: We provide every metric we gather from data about your testing. Sure spreadsheets can do that, but not without several hours of formulas writing.
  • No API for custom rules and logic

The point is: Using a test management solution is a crucial factor for software development, without one in place you might be losing without even knowing it.

And what’s worse than spreadsheets? Not managing your tests at all.

1

Repurposing test cases with Tags / DRY in software testing

I’ve discussed about DRY in software testing earlier also which involved reusing test cases across projects, today I’m going to discuss a similar topic: reusability/repurposing of test cases within project itself.

During your software development life cycle, there are several phases where your team tests the application. Let’s see how a typical development cycle works before checking out the problem (it’s somewhat similar to what we do for Test Collab):

  1. During development, developer executes set of few tests in order to make sure their changes don’t break the build before committing the code. (Smoke tests)
  2. A continuous build verifies that all the code is fine by executing some specific tests. (Some functional tests)
  3. Tester executes a few tests manually at the end of the day to make sure application is running as it should. (All functional tests)
  4. Then there’s a staging / testing server, where all the automated testing is carried out. (All functional tests)
  5. Before every release, manual load testing is done so it can be made sure that this version is going to be okay after released. (Load tests)
  6. After every release, specific tests are executed every 7 days to make sure your application is running online. (Production monitoring tests)

Now, this may or may not resemble to your software development lifecycle, it’s just there to show you how testing or software QA has multiple contexts.

Do you notice something wrong with above image? It’s most common issue among QA teams. Each testing context is treated as a container/category for these test cases, and when some test case, say, Test Case #1 also needs to act as a ‘Load test’, it is copied in ‘Load test’ container as it is. This is absolutely wrong. So what happens is you end up with hundreds/thousands of test cases which are often duplicates of each other. A test case should not be hard coded for a single context if it is required in other contexts too.

For example a test case which verifies “User registration” in my app might be treated as ‘smoke’ test and at the same time a ‘production monitoring’ test. Similarly, I might add more information in this same test case, so it can also act as ‘Load test’.

So what is the correct way?

Treat each testing context as a “Tag”. Tags are not new to the blogging world, but they also make sense in testing and here’s how:

So by applying tags we’ve avoided creating 3 new duplicates. Now one single test can belong to multiple testing scenarios or contexts:

Few days back, we’ve released tagging feature which was long awaited by some of our customers. I hope this article helps you getting best out of it.