One of the most common questions people ask me during consulting sessions is “what do you recommend for testing?”. It’s a very interesting question that I find important, and it should be a primary concern for people beginning a new project. In fact, application tests are the only thing that can guarantee the end user a pleasant user experience.

To answer this question, I refer to cases analyzed in our technical support work, because the quantity and diversity of the applications we’ve studied is a good sample for understanding the nature of the most frequent errors.

I suggest these three rules:

The developer can’t run the test
Obviously I don’t mean that developers should do their jobs without testing what they’ve made, but rather that the developer’s test should only be preliminary: a test that must be passed before handing over the functionality to someone else who has not worked on developing that part of the application. This is a very significant consideration, because the person who implemented a form will use it according to their own way of thinking, which is the same way of thinking that led to the current implementation. It’s truly difficult to step off your own rails. It’s no accident that application testing is a career in itself.

Whoever does the internal test mustn’t receive instructions
This means that the colleague who tests the functionality should not get an explanation of how the app works, because they need to test it following their own intuition. In fact, often a problem that seems impossible to replicate locally can be replicated with help from a support tech. This is because when you already know how the application should be used, you don’t veer outside your pre-established patterns, and in practice you always click in the right place at the right time. But as soon as the application is used by end users, who have no pre-set mental pathways, the problem crops up.

Implement the beta test
When you put the application into production, even if you’re careful to follow the previous steps, problems that are less evident and not as easy to replicate always occur. In most of the cases we’ve seen in support, it took at least 2-3 causes at the same time. One possible solution is to install two versions of the application: the latest stable version without debug, and the version with the latest changes with debug activated. Afterward, by identifying a group of end users you can ask to use the version in debug, most users will use the stable version, while the beta tester group is already aware that they may run into small problems.

What do you think? What's the best policy to use for testing?

  •    You can't test thoroughly without relying on an outside service.
  •    You need an internal team dedicated strictly to product testing.
  •    Both of the above.
  •    None of the above (enter your comment).

{ 5 comments }

Raise your hand if you’ve never thought that one of your ideas or products was completely different from anything else in the world. I’m pretty certain that all your hands stayed down. It’s completely normal – it’s part of our nature, and it’s a common way of tackling problems and challenges.

On the other hand, the concept of differentiation is one of the principles that marketing professionals must always place at the foundation of any strategic or operational plans.

So then why do we so often find ourselves looking at so many products that all end up seeming the same? And – something that interests us much more – why is conveying our conviction that our product is different (and, of course, better) one of the most complex parts of our marketing efforts?
The answer is simple: when analyzing differentiation, we let ourselves be guided by our advance bias about our product, which makes it difficult for us to evaluate it objectively and systematically.

In order to shift our analysis back into a more structured context, it can be helpful to follow a path guided by well-defined rules. Based on the specific situation, sometimes we need to use all of these rules, and at other times only a few. In the latter case, it’s still always a good idea to evaluate whether this exclusion is based on actual need or once again on our bias.

  • Identify your reference market
    This is a crucial step that often isn’t given the appropriate consideration, and it answers the questions: who am I, what is my product?
  • Study your competitors in that market to understand where you can introduce innovation
    Many times this analysis isn’t even sketched out, because people start with the assumption that their idea or product is completely different from any other. But watch out: if there are no competitors, it means there’s no market (with all the consequences that this statement brings with it).
  • Fulfill a need that hasn’t yet been met
    It’s not easy to identify the problems that haven’t yet found adequate solutions, but it’s by working on this that you’ll increase your chances of success.
  • Have the courage to adjust your initial ideas to results
    This analysis must be done completely objectively, and this includes facing the risk of needing to address situations that create a need to change strategies that seemed clearly defined.

Each of these subjects merits much more in-depth discussion. Nevertheless, I’m convinced that by starting to reflect on these four rules it’s possible to get some good starting points right from the beginning for crafting a winning differentiation strategy.

Image: Ines Hegedus-Garcia.

{ 2 comments }

Sometimes it becomes necessary to take a very in-depth look into the exceptions that may crop up in your applications. The exact error number, the stack trace, or other information can often provide the only hints for understanding a complex problem.

Applications made with InDe manage errors and fire the OnException event precisely for this reason. Nevertheless, in support I’ve seen that in some cases, this isn’t enough. In order to find out the error number and message, you do in fact need to know what type of exception was received. But what happens if your application has integrated libraries that launch exceptions of a specific type, and perhaps with special properties? It isn’t possible to get detailed information because the InDe libraries don’t contain references to that given class of exceptions.

Also, there are certain errors for which InDe assigns its own error code. This occurs because, in the portability logic of applications created with InDe, the code should tend to be the same, but the error codes are different among the various languages supported!

In order to solve the problem and get all the information you want in your application, perhaps to write it to a specific log, simply add a specialized function to your project that deals with analyzing the specialized Exception that was reported. You can achieve this by using reflection.

Once you’ve obtained the specialized object, it’s simple to read it and display the error to the user, write it to a log file, or send it by email. From here the choice is yours.

I’ve prepared a project for you, and I’ve added a custom getException library function, which, if used in the OnException event, will allow you to show the stack trace on screen or identify it. Try clicking Simulate Exception, then Customization ON OFF, and then Simulate Exception again. You’ll see that the information is different: for example, the second time you’ll have the stack trace available.

Try the project; once in a while it can be fun to launch errors :)

Image: Gabriele.

{ 0 comments }

Hello everyone, my name is Matteo and since coming to Pro Gamma in 2014 I’ve worked in the sales department.

When I got here in April, the first thing I was asked to do was to write up the Case Studies you’ll find in the Customer Stories section. I was pleased to take on this challenge, because during my time with Dropbox – a company that owes its success in large part to how well it communicated the simplicity of its product – I learned hands-on that being effective in communicating the value of your product is just as important as developing a perfect product.

Since the others shared this belief, we followed Gartner’s advice and treated our Case Study work as a communications tool. While working on this project I learned many things – some of which are seemingly simple, but can be taken for granted – and I’d like to share them with you:

  • It has to be your customers who talk about the value of your solutions: one of Gartner’s studies finds this technique even more effective than a personal meeting or a company event. Obviously, it’s even better if the person telling the story is a customer of yours who is well-known or an industry analyst. On a scale of 1 to 7, peer referencing, meaning when a customer of yours talks about your product, is rated a 5.46, while a personal meeting comes in at just 4.88. That’s a significant difference.

  • Gartner says that there are three phases in a sales cycle in which a Case Study is effective: it can be used in the first phase to intrigue someone visiting your website, during the initial product evaluation phase to confirm the effectiveness of the product’s features, and during the final assessment to answer the most common questions. From this standpoint, it also becomes very important to know which pages of your website correspond to the various phases of product evaluation and how to link the Case Studies to these pages.

  • Then there’s the question of how to write them: writing a story full of facts, evidence, and numbers helps reinforce statements about the product. Consider that according to analysts, a Case Study with lots of images and numbers is, on average, three times more effective. The method we decided to use is to opt for a direct and natural tone, and above all to see things through the eyes of the person reading the document, who may know very little about the product!

But I’ve found the biggest value on a personal level. Doing this job has given me the opportunity to get to know many of our customers better, and to build a closer and more interesting customer-provider relationship.

The last piece of advice we received is to always keep these stories current, so you can tempt potential customers with a new story every time. With that in mind, I intend to publish a new one each month.

I think this could be a fantastic chance both to get the word out about all of your solutions, and to strengthen your relationship with us.

Are you interested?

{ 0 comments }

Tips & Tricks: how to debug large applications

22.01.2015

As many of you already know, Instant Developer is equipped with two different debug modules: the step-by-step debug, as you’d find in traditional environments, and the debug at run-time, which makes it possible to retrace and analyze the entire history of the application session. The default debug type is the run-time debug, and it’s enabled [...]

Read the full article →

Tips & Tricks: keeping elements of two projects aligned

16.01.2015

Today I’d like to talk about a functionality in Team Works, the Instant Developer versioning system, that not everyone knows about: the Team Works Components. You might immediately think of Instant Developer components introduced in version 9.0, but when we talk about Team Works we’re referring to a much earlier feature. Inside an InDe project, [...]

Read the full article →

2014: The Feedback Year

23.12.2014

2014 has now drawn to a close, and it’s time for best wishes, and for conclusions. Thinking back over the work we’ve done in the last 12 months, it occurs to me that the real star this year has been our dialogue with the developers who use Instant Developer and analyzing their feedback. I’ve told [...]

Read the full article →

Instant Developer 2015. What will be new?

18.12.2014

I don’t know if you’ve noticed, but this time the Instant Developer evolution cycle has been a bit different than usual. In fact, we’re not using the Roadmap to tell you how many new items we’re implementing, but only for fixes. The fact is that when we chose what needed to be new in 2015, [...]

Read the full article →

A development server is a necessity

11.12.2014

Before putting an application into production, you have to reduce to a minimum the chance that users may encounter errors, because every time someone sees one, their perception of the product deteriorates. The things I’ll list for you today may seem like items that should be taken for granted, but my experience in the support [...]

Read the full article →

Online courses: looking forward

04.12.2014

The first semester of the 2014-15 academic year is over, and during this time we offered online courses in the new format I presented in July. Now it’s time to plan the calendar for next year and to look for other improvements we can make to the training we offer alongside Instant Developer. From an [...]

Read the full article →