Forum Discussion

mikakoistinen's avatar
mikakoistinen
Contributor
7 years ago

test driven development, literally

Hi,

I'd like to know if are there anyone whose dev team is using testcomplete during development?

for example write test to reproduce error or write test how application should behave when working as planned, give this test to developer so he/she can save time during development time testing. especially when there are many extra steps before actual function under construction. 

I have been using this few times and really liked it. And I'm considering that my team should use it more. So before we start to buy more licenses I'd like to know. 

 

If there is somebody whose team does this. how many licenses do you have compared to developers. What are most significiant benefits ? Are there any bad side effects? what's affect to development time? Did it help in total issue pass trough time? How did individual developers react?

 

Thanks 

mika

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    7 years ago

    Hi Mika,

     

    I think that answers to your questions depend on the project.

     

    In a nutshell: it is my opinion that TestComplete is a tool for functional regression testing, but not something that is worth to be used during active development. Unit testing tools seem to be more suitable for this.

     

    From my experience, I can recollect, probably, only one project where classic test-driven development could be applied. That project was for the mature product with strict, well defined and well documented requirements as for UI and UX behavior. New UI design or UI changes were thoroughly planned initially as well as business flow and nobody was allowed to make changes after that without going through the serious change procedure.

    In a 'modern agile' development, when everything change without prior notification, too many efforts will be spend on tests support.

    Another point: TestComplete has its own project structure and tests are created using scripting language. This means that developers will have to deal with and support two separate and quite different development environments.

    One more point: I had a project once when developers were asked to help with creation of tests. It was an interesting experience for me, because (to my opinion) developers wrote the code that is usual and fine for the application code (and unit tests), but not always fine for functional tests. For example, it was quite usual to see the code like

    if (user.exists) then {...}

    This is usually fine for the application, but for the functional test quite often 'else' part is required as well to signal that for some reason the user was not found.

    Also, it is expected from developers to create a well designed and structured code. While this is also applicable to the functional test code, it is a usual situation when the functional tests *must* be executed within a tight time frame and if test code problems exist (including those caused by design/functionality change) these problems *must* be corrected before the end of the test run. In the situation like this, test code simplicity is often more vital. This means that developers will be forced to maintain 'good and clean' code for the application and switch to somewhat different coding approach and style for tests.

     

    If your tested application is created using .Net, you may consider TestLeft (https://smartbear.com/product/testleft/overview/) that is based on the same technology as TestComplete/TestExecute but is more developer-oriented.

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor
      7 years ago

      I'm with AlexKaras... while there is some part of TestComplete that can help with TDD, I think what you're suggesting might be a bit beyond... definitely look into TestLeft.

       

      As it is, though, you can play the TDD role in an Agile/Scrum/KanBan environment.  As you're developing new features of the application under test, you can start building out your regression automation.  Having a good framework for doing so will help with that, of course.  But you can start writing classes, building out functional routines, etc., based upon the assumptions from the specifications and requirements. That way, when the feature is delivered, you can start plugging it in.... and, if the feature doesn't match what the requirements communicated SAY it should, you can go back to the dev team and say, "Hey... this isn't meeting the documented requirements."  Not exactly TDD, but it IS a QA role that automation can fill.

      • Marsha_R's avatar
        Marsha_R
        Moderator
        7 years ago

        If you do end up using TC tests for developers just to run, then consider giving them TestExecute.  They're not going to analyze the test results, they just need to know if it passes/fails.   

  • baxatob's avatar
    baxatob
    Community Hero
    7 years ago

    Hi Mika,

     

    We use a few number of floating licenses. And any person within our network can install and launch TestComplete on their own machine (if not all licenses are occupied, of course). As I can see, developers do not actively use this opportunity, preferring manually perform all steps to reproduce the issue. May be this is because our tests have not complex preconditions.