Forum Discussion

mgroen2's avatar
mgroen2
Super Contributor
9 years ago

General discussion: Should Keyword driven testing capabilities be upgraded?

Hi,

 

this is a general statement to my fellow test, and QA engineers, and I would like to hear everyone's opinion about it:

 

I am a typical validation engineer, primary focused on the funtionality of the application (software) I need to validate and test. Therefore, I am using KDT (Keyword driven testing) as much as possible, and use scripting only when necessary. In most cases, KDT supports testing actions. However, in some situations, it is required to switch to scripting.

For example, when you want to write to Excel data files.

 

Now, my statement is, that TestComplete needs to be upgrading its KDT possibilities, so that this becomes even more versatile and useful, so it becomes more usefull for the audience groups consisting of validation engineers (like, functional testers, and other non-technical oriented tester), instead of the more technical test engineers. The latter ones are mostly much more familiair with coding and use TC's scripting capabilities, while the engineers more focused on validation rely more on KDT functionalities.

 

It is my personal opinion that, ideally, there is no difference in the things you can do with TC, either in KDT or in (one of the supported) scripting languages.

 

Would like to hear other peoples ideas on this....

 

Mathijs

 

16 Replies

Sort By
  • dmiscannon's avatar
    dmiscannon
    Frequent Contributor
    9 years ago

    Don't forget the Script Extension capabilities of TestComplete. If you can script it, chances are good that you can create a KWT script extension. Script Extensions are a good way to increase the capabilities of Keyword testing.

     

    I have a whole suite of Excel script extensions that work for me and allow me to open, write to, save, and close Excel, among other things. I also have created script extensions for other functions unique to the applications I test that I need to repeat in numerous tests. For more information on script extensions, check out https://support.smartbear.com/viewarticle/69987/?q=script+extensions#_ga=1.102372737.1015556109.1449503065

     

     

     

    • baxatob's avatar
      baxatob
      Community Hero
      9 years ago

      Hi guys,

       

      I believe that 95% of all possible GUI-based test-cases can be implemented using KWT. In another 4% we should use API and we can create powerful scripts or extensions and also use them in our KWT environment. And only 1% (possibly) will require other tools. 

       

      Anyway you need better if you have at least one good coder in your QA team, if you are using any of test automation tools.

      • mgroen2's avatar
        mgroen2
        Super Contributor
        9 years ago

        baxatob I agree with you but if you have no team with testers around you,  and are the only person responsible for QA (like me), you don't have the time /focus to work on coding issues, you just want to have a framework as easy and fast as possible....

    • mgroen2's avatar
      mgroen2
      Super Contributor
      9 years ago

      dmiscannon Script Extension capabilities, I have read the info in the link you provided. Sounds interesting but you need to be able to script, to create them. Unfortunately that's not my best point :(

      But could be very usefull if there is a library of available script extensions created by other users (like you created the Excel script extensions)... Maybe you could share it with me?

       

       

  • Marsha_R's avatar
    Marsha_R
    Champion Level 3
    9 years ago

    My first opinion is that we should get away from using job titles as a comparison because they're different at every workplace and that might not be the best way to delineate TC usage.  

     

    That being said, ideally, keyword test functionality would be the same as scripting functionality, but in reality I think that is a huge thing to ask.  We do have the opportunity to ask for new or updated features from SmartBear as we each need them.  I've used TC at two different companies, from v7 and up and I have seen many new things added to keyword tests, even some that I had voted for!

     

    Where I work, we are continuously having to decide what software features to develop and who works on it when.  We have long term plans and short term plans, and all of those can get interrupted if a customer needs a fix.  SmartBear is in that same position and I don't think that just saying "make it all work the same" is something we can ask of them.  What if they spend months adapting a feature to keyword testing and it turns out that very few people have a use for it?  They could have spent that time on a feature that many people use instead, but "make it all work the same" was the plan, so that's what got done.

     

    If there's something particular that you need to have working in a keyword test, I suggest letting SmartBear know on the feature request forum.  If others have the same need, they will vote it up and it will get on the list and all of us will benefit.

    • mgroen2's avatar
      mgroen2
      Super Contributor
      9 years ago

      First of all, I think, it is all a matter of defining the roadmap of TC, combined with pre-defined mechanism which should be applied to all feature requests.

      I think this mechanism should be in the form of a matrix or something, containing several parameters and each parameter should be given a value. Imagine the following parameters were defined: 1) amount of work (effort), 2) how many votes got it 3) does it align with TC's roadmap (which is/should be defined), 4) Do we need to implement this for KDT or scripting, or both? And if both how much effort would it take to align these?

       

      Of course I realize it's a huge think to ask, but on the other hand almost everything you can do with scripting can be done with KDT as well. But, not all. And, I think it's good to share ideas, and to be ambitious. TestComplete is a very broad product it's in the name already. So, with different type of audiences (different usages), there are also different ways to work with TC. And I think all this results in different type of feature requests......

  • Marsha_R's avatar
    Marsha_R
    Champion Level 3
    9 years ago

    First of all, I think, it is all a matter of defining the roadmap of TC, combined with pre-defined mechanism which should be applied to all feature requests.

     

    Wow, no.  It is not our job to define the roadmap for TC, nor to tell SmartBear how to manage it.   However, if some company did work that way, it still wouldn't guarantee you that you would get exactly the features you want.

     

    But could be very usefull if there is a library of available script extensions created by other users (like you created the Excel script extensions)...

     

    Script library is here:  https://support.smartbear.com/viewarticle/9010/

     

     

    • mgroen2's avatar
      mgroen2
      Super Contributor
      9 years ago

      Wow, no.  It is not our job to define the roadmap for TC, nor to tell SmartBear how to manage it.   However, if some company did work that way, it still wouldn't guarantee you that you would get exactly the features you want.

       

      I am not saying it's our job to define roadmap. It should be SmartBears management who defines the roadmap. However, I think feedback from the users (functional test engineers, technical test engineers, validation engineers, etc, etc.) is/should be a very important input variable, in defining the roadmap. Don't you think Marsha_R ?

       

       

      Script library is here:  https://support.smartbear.com/viewarticle/9010/

       

      Thanks! Marsha_R

      • Marsha_R's avatar
        Marsha_R
        Champion Level 3
        9 years ago

        I've seen you post in the Feature Requests forum, but maybe you aren't clear about how that works.  Here's an example from one of your posts.  You entered it on the forum, it got enough kudos to get some attention, and it was selected for development.  We already have input.