Forum Discussion

Darshana's avatar
Darshana
Occasional Contributor
10 years ago

How to use testcomplete in Agile

Hi   I am new to testcomplete.I have started to use it with functional testing for deskstop application.   But I want ot use it in Agile project.   Also I want o use it to generate test script ...
mgroen2's avatar
mgroen2
Super Contributor

Marsha_R, Darshana, blacy, vajindarladdad

 

I am facing similar situation. The company I am working for right now is using Agile and CI/CD (Continious Integration / Continious Development), and feedback on the tests is important and needs to be done quickly. 

So, there is no time for extensive scripting, because every day new software is delivered so all maintenance on the framework needs to be done in max. 8 hours.

Also, we need to automate as much as possible (to test as much possible in the available time), and maintenance on the automated tests needs to be every efficient en fast.

 

I like TC as test automation tool, but I think it has its shortcomings in Agile/ CI / CD environments.

 

That is why I want TC to be more intelligent on signalling changes in the UI of the AUT (Application under test).

There is a discussion on this thread

 

Also, I have 2 feature requests which I think would greatly improve TC in handling Agile / CI/CD software approaches.

 

These can be found here and here

 

Hope you share your feedback

 

mes6073's avatar
mes6073
Contributor
9 years ago
mgroen2 wrote:

Marsha_R, Darshana, blacy, vajindarladdad

 

every day new software is delivered so all maintenance on the framework needs to be done in max. 8 hours. 

If this is a web application that is undergoing constant evolution, then you would probably need a data driven test harness capable of first investigating/mapping out the web interface structure before starting any functional tests. Realistically, since the process that runs the UI components of the web interface are much less volatile, you would probably realize better results by concentrating automation efforts on a verbose set of tests for the back end functionality that processes user input and returns applicable outputs to the UI.

  • Colin_McCrae's avatar
    Colin_McCrae
    Community Hero
    9 years ago

    Been working in an Agile environment for years.

     

    Tests can be run overnight, automatically, against the most recent nightly build. Full functional run takes 4-5 hours against a multi-site web application. All kicked off automatically as part of the CI/build process so results were there and available when we come in first thing.

     

    Everything (for TestComplete) was pulled down from version control by the build system so the most current tests always run.

     

    That project is now pretty mature. Been running for around 3 years. No longer run on nightlies (stable and mature enough that it's no longer required). That one is run and maintained as required. Design is good so maintenance is minimal. (I stopped actively writing any new test code for it over a year ago and it still runs fine now with only small tweaks.)

     

    Working on a desktop app now. Which is massively more complex. No desire to run against nightlies for that. Way too complex and they know and accept this.

     

    My framework is pretty much bomb proof. I can't remember the last time a run crashed. Tests may fail. Some legit, some due to changes. But it ALWAYS copes and keeps going.

     

    If you're having problems keeping up, my thoughts would be:

     

    1. You're automating too early. If an application is at early build stage, and still subject to large scale change, you probably waste more time than you save by constantly re-writing things.

     

    2. Good automated (aka - ones that last long term) tests need to be built properly. Write badly, write several times. Hacked together rubbish does NOT last. Rome wasn't built in a day and all that. If you have a good framework and mapping use/process in place, it makes things a hundred times easier.

     

    3. You are not an island! If you want to stay as close to dev as possible then THEY need to be involved as well. And if you have a build team/engineer, then so do they.

     

    4. If you think you can produce 100% maintenance free automated tests (for anything more complex than a "Hello World!" application) .... forget it. All automated tests will require some maintenance, at some point. Accept it. And make sure management do too!