Right now, there are 375+ Feature requests done by users of TC. Only a couple of them (about 20) have been implemented. It would be great if product would be improved by implementing the feature requests done by the users. A lot of them have only 1, 2 or even 0 votes but implementing those would still made the product a lot better (if no existing functionality gets broken). Please team Smartbear work on implementing (lets say) top 100 of currently feature requests! :)

This topic came up in yesterday's "Ask Me Anything" session with the various product owners within the SmartBear organization. While there wasn't anything specifically said about "Kudo count" or anything like that, what was said was encouraging. There were several people throughout the days at the Connect conference that mentioned that, when they asked for SmartBear to add a feature to a tool for them (whether it was TestComplete or ReadyAPI! or something else), SmartBear did give them that feature. And this was reinforced at the "Ask Me Anything" session. One thing that yesterday's session opened up with were talks from the CTO and other product owners of the products and some upcoming roadmaps of what they are hoping to do with the various tools. Regarding TestComplete, one thing that was mentioned was that they want the tool to be as "frictionless" as possible meaning that they want to develop it in such a way that, if you're using the tool, there should be no impediments to being able to being successful with the tool, whether you are someone who writes complex framework code or is a more "beginner" level user. So, when it comes to developing the tool, that balance is taken into consideration (again, reinforced in "Ask Me Anything"). One thing that was reinforced over and over and over again both in LinoTadros training on Tuesday as well as in the many talks given on Wednesday was that, with regards to TestComplete, there are many ways of achieving the same results. This flexibility I would imagine also is taken into consideration with regards to feature requests. If they implement a feature, does this restrict the user to having to do things "The TestComplete Way" or will it allow the user to determine how they want to utilize it. One thing I do see about a lot of the feature requests out there is that many of them are on the lines of having TestComplete do things in a very particular way. So, if someone is using the tool and they want to achieve a particular task, they would have to do it that way and that flexibility of the tool is lost. So, with the vision in mind of a "frictionless" product that provides a flexibility of usage for a variety of skill levels with regards to the automation person and does not interfere with the general roadmap of the product... I would imagine that all this is taken into consideration with regards to feature requests. But, and this was reinforced yesterday, if there is an overwhelming response from the user base that "Yes, we MUST have feature A", then SmartBear listens and implements it. So... there are 375 feature requests... but they don't have a lot of popularity. This is no reflection on the intrinsic value of the request... it may be a very useful feature. But if only 1 or 2 people out of a user base of millions (and they aren't all here on the forums) like the item, then it would be a feature added for a very small subset of the over all userbase which would then "break" that vision. So... the take away: If there is a feature that you think should be voted up, mention it, campaign for it. Could be that there are a bunch of folks who just don't know about it. SmartBear DOES listen. But don't be surprised, however, if not a lot of response is given. Like myself, there are some very creative people in the SmartBear user base who, when presented with a problem to solve, instead of asking, "How can I convince SmartBear to add this feature?" they ask, "How can I use the tool to solve my problem?" And, in listening to many different users yesterday, the most successful users of TestComplete ask that second question and then go on to achieve amazing things.

Counting in the list of feature requests, you only have to go through the top 30 before the number of Kudos drops below 10. In those top 30, 11 are selected for development3 are implemented 6 are open for discussion 11 are new Looks to me like the list is already being worked on "seriously". If an idea can't get at least 10 Kudos, then it's probably not worth the development time to add it.

Hi, The "Feature Request Section" is not so popular among society members. So 10-Kudos achievement can take years... I believe that new feature implementation should be based not only on kudos count.

Hi, I'm fully in line with all previous posts.Feature Requests and Kudos do not look like something a lot of people pay real attention to. P.S. Besides TestComplete, there is LoadComplete forum here as well. :) It is much less active than TestComplete's one. Is this because LoadComplete is much less used? Or because LoadComplete is good enough for people who are using it and they just use it without the necessity to visit the forum? Mathijs (mgroen2) posted a lot of good requests there recently based on his real current experience, but most of them have one or two votes. This is definitely the area that must be improved somehow...

Well we got TanyaYatskovska's gingerbread at the user conference. That was a great reward!

When is Smartbear going to work seriously on the Feature Requests

22 Replies

tristaanogre
Esteemed Contributor
7 years ago
This topic came up in yesterday's "Ask Me Anything" session with the various product owners within the SmartBear organization. While there wasn't anything specifically said about "Kudo count" or anything like that, what was said was encouraging. There were several people throughout the days at the Connect conference that mentioned that, when they asked for SmartBear to add a feature to a tool for them (whether it was TestComplete or ReadyAPI! or something else), SmartBear did give them that feature. And this was reinforced at the "Ask Me Anything" session.

One thing that yesterday's session opened up with were talks from the CTO and other product owners of the products and some upcoming roadmaps of what they are hoping to do with the various tools. Regarding TestComplete, one thing that was mentioned was that they want the tool to be as "frictionless" as possible meaning that they want to develop it in such a way that, if you're using the tool, there should be no impediments to being able to being successful with the tool, whether you are someone who writes complex framework code or is a more "beginner" level user. So, when it comes to developing the tool, that balance is taken into consideration (again, reinforced in "Ask Me Anything").

One thing that was reinforced over and over and over again both in LinoTadros training on Tuesday as well as in the many talks given on Wednesday was that, with regards to TestComplete, there are many ways of achieving the same results. This flexibility I would imagine also is taken into consideration with regards to feature requests. If they implement a feature, does this restrict the user to having to do things "The TestComplete Way" or will it allow the user to determine how they want to utilize it.

One thing I do see about a lot of the feature requests out there is that many of them are on the lines of having TestComplete do things in a very particular way. So, if someone is using the tool and they want to achieve a particular task, they would have to do it that way and that flexibility of the tool is lost.

So, with the vision in mind of a "frictionless" product that provides a flexibility of usage for a variety of skill levels with regards to the automation person and does not interfere with the general roadmap of the product... I would imagine that all this is taken into consideration with regards to feature requests. But, and this was reinforced yesterday, if there is an overwhelming response from the user base that "Yes, we MUST have feature A", then SmartBear listens and implements it. So... there are 375 feature requests... but they don't have a lot of popularity. This is no reflection on the intrinsic value of the request... it may be a very useful feature. But if only 1 or 2 people out of a user base of millions (and they aren't all here on the forums) like the item, then it would be a feature added for a very small subset of the over all userbase which would then "break" that vision.

So... the take away: If there is a feature that you think should be voted up, mention it, campaign for it. Could be that there are a bunch of folks who just don't know about it. SmartBear DOES listen. But don't be surprised, however, if not a lot of response is given. Like myself, there are some very creative people in the SmartBear user base who, when presented with a problem to solve, instead of asking, "How can I convince SmartBear to add this feature?" they ask, "How can I use the tool to solve my problem?" And, in listening to many different users yesterday, the most successful users of TestComplete ask that second question and then go on to achieve amazing things.
- nebsta
  Contributor
  7 years ago
  tristaanogre I see your point but this kind of feedback is unquantified and may not represent the views of users as a whole. I think there should be more visibility on feature requests e.g. average age, number created vs number resolved, number of requests that have changed status etc.
  
  The top two requests both relate to improvements to the NameMappings where AFAIK there is not currently a work around, they have been raised since 1H 2015 and seem to have been put into the 'too hard basket'. Even as the two two ideas - perhaps having only 56 and 58 kudos votes gives the impression that they are not really needed by users but I would guess that the vast majority of TestComplete users have never used the Smartbear Community, let alone reviewed the feature requests section. If there were an alternative way to achieve the feature request ideas easily then I would not be so worried about them but I don't believe there is.
  
  I totally appreciate that there is limited dev resources and we shouldn't be encouraging custom workflows within the tool but IMO there are some very valid ideas with high votes that have been around for a long time and are not being considered.
  - tristaanogre
    Esteemed Contributor
    7 years ago
    Actually, based upon what was said at Connect, those two items are being worked on... but, as you noted, they are tricky. Again, just because it has the most amount of Kudos does not mean it's going to be completed first.
Marsha_R
Champion Level 3
7 years ago
Counting in the list of feature requests, you only have to go through the top 30 before the number of Kudos drops below 10.

In those top 30,

11 are selected for development
3 are implemented
6 are open for discussion
11 are new

Looks to me like the list is already being worked on "seriously". If an idea can't get at least 10 Kudos, then it's probably not worth the development time to add it.
- baxatob
  Community Hero
  7 years ago
  Hi,
  
  The "Feature Request Section" is not so popular among society members. So 10-Kudos achievement can take years... I believe that new feature implementation should be based not only on kudos count.
  - mgroen2
    Super Contributor
    7 years ago
    baxatob wrote:
    Hi,
    
    The "Feature Request Section" is not so popular among society members. So 10-Kudos achievement can take years... I believe that new feature implementation should be based not only on kudos count.
    baxatob I agree 100%.
    There should be a more active approach to society members to let this become a success.
    Also, some feature requests may have 0-1-2 kudos but are relatively easy to build/implement, while others with more kudos are not that easy (eg require a complete redesign). But working on the low valued kudos (with 0, or only 1, 2 kudos) might get to result that the product becomes much better!
    
    All in all I do not see the kudo voting thing, resulting in improvements of the product to be very effective: when I look at the last few TestComplete releases compared to the implemented feature requests, there is no clear relationship between those.
- nebsta
  Contributor
  7 years ago
  Marsha_R wrote:
  Counting in the list of feature requests, you only have to go through the top 30 before the number of Kudos drops below 10.
  
  In those top 30,
  
  11 are selected for development
  3 are implemented
  6 are open for discussion
  11 are new
  
  Looks to me like the list is already being worked on "seriously". If an idea can't get at least 10 Kudos, then it's probably not worth the development time to add it.
  Marsha_R I disagree - it seems that "Selected for Development" just means that the idea is in the Smartbear backlog for TestComplete - it doesn't indicate that it will ever be worked upon in the near future and in fact one of the comments on the second highest rated idea suggests that given the current architecture it cannot be implemented:
  "According to our development team, the official status of the feature should be "Not in progress".
  According to the product owner, the feature request would be a great enhancement but based on our current architecture we are unable to implement this yet. Therefore I do not have a definite answer on when name mapping will be refactored."
  
  I have to agree with mgroen2 that not much progress is being made on the implementation of feature requests, especially those with the highest ratings which have been around for a long time. If they are not possible then they should not be marked as "Accepted for Development" as this is misleading. We used to get an update in the monthly newsletter on the number of feature requests submitted vs implemented. As I have mentioned before I think this should be brought back to give better visibility and a thorough triage of the current statuses undertaken.
  - mgroen2
    Super Contributor
    7 years ago
    nebsta wrote:
    Marsha_R wrote:
    Counting in the list of feature requests, you only have to go through the top 30 before the number of Kudos drops below 10.
    
    In those top 30,
    
    11 are selected for development
    3 are implemented
    6 are open for discussion
    11 are new
    
    Looks to me like the list is already being worked on "seriously". If an idea can't get at least 10 Kudos, then it's probably not worth the development time to add it.
    Marsha_R I disagree - it seems that "Selected for Development" just means that the idea is in the Smartbear backlog for TestComplete - it doesn't indicate that it will ever be worked upon in the near future and in fact one of the comments on the second highest rated idea suggests that given the current architecture it cannot be implemented:
    "According to our development team, the official status of the feature should be "Not in progress".
    According to the product owner, the feature request would be a great enhancement but based on our current architecture we are unable to implement this yet. Therefore I do not have a definite answer on when name mapping will be refactored."
    
    I have to agree with mgroen2 that not much progress is being made on the implementation of feature requests, especially those with the highest ratings which have been around for a long time. If they are not possible then they should not be marked as "Accepted for Development" as this is misleading. We used to get an update in the monthly newsletter on the number of feature requests submitted vs implemented. As I have mentioned before I think this should be brought back to give better visibility and a thorough triage of the current statuses undertaken.
    
    Totally agree with nebsta. With the additional remark that amount of Kudos should not be the only factor. Some feature requests might have little or 0 kudos but might be very handy to the user who initiated it. Also it might become handy for other users as well but not yet realised (by them). Some users are more experienced than others you know. These feature requests might be very easy to implement, in the sense that it costs little development / test time. The quick wins, so to say.
AlexKaras
Champion Level 3
7 years ago
Hi,

I'm fully in line with all previous posts.
Feature Requests and Kudos do not look like something a lot of people pay real attention to.

P.S. Besides TestComplete, there is LoadComplete forum here as well. :) It is much less active than TestComplete's one. Is this because LoadComplete is much less used? Or because LoadComplete is good enough for people who are using it and they just use it without the necessity to visit the forum? Mathijs (mgroen2) posted a lot of good requests there recently based on his real current experience, but most of them have one or two votes.

This is definitely the area that must be improved somehow...
- Marsha_R
  Champion Level 3
  7 years ago
  It's certainly easy enough to post a request or add a kudo to one you agree with. I'm afraid what you're looking for is a way to make people care more. Another way to vote or express opinions is not going to help with that.
  - tristaanogre
    Esteemed Contributor
    7 years ago
    For my part, when I log in here and see that a new feature request has been given, I go take a look. If it's something that I think I could use and would be beneficial to the tool, I give it a Kudo. I'll say that there are a lot of feature requests that come through that are "nice to haves"... things that would be cool bells and whistles to apply to the tool but, if they aren't done, I can certainly live without. Or they are feature requests for which there is a legitimate way of achieving the same thing without having to wait for a modification to the tool. Sure, it would be nice if it was available "out of the box"... but I'm a bit of a pragmatist so, if I can already do it, why wait?