Forum Discussion

icopycode's avatar
icopycode
Occasional Contributor
3 years ago

Team use of TestComplete & TestExecute

I'm looking at a team strategy for using automated tests for when we work on bugs/defects.  The proposal is that the QA person would create a keyword test that replicates the error.  Then the dev would playback the test and see replication steps and the error.  After resolving the bug, the dev would be able to self-test by playing back the test again and seeing that the error does not occur.

 

How do we make this happen?  I am thinking the QA uses TestComplete to create the test in a Shared Mode project that exists on a shared network location.  Then the dev uses TestExecute to replay the tests as needed.

 

Has anybody here used TestComplete this way and did it work well for you?  Since the dev would only be replaying tests and not writing them, would they have any need for TestComplete, or would TestExecute be sufficient?  All criticism and suggestions are welcome.

  • vinniew's avatar
    vinniew
    Staff
    3 years ago

    Hi icopycode 

     

    Interesting thread...

     

    Is the playing back the script critical for the dev team? 

     

    What I mean here is,  as a Dev if I receive a Jira ticket with the steps nicely attached as part of a log. 

     

    Typically some level of triage is done to verify that defect/bug

     

    Is the log sufficient enough to enable devs replicate, fix and verify ?

     

    The log will contain everything, steps taken, images, input values, including validation checks (checkpoints) error logs etc. 

     

    These too can be shared to devs even if they dont use TestComplete either adhoc, via Jira  integration, issue tracking templates etc or hosted via Sharepoint

     

    Thats my 2 cents anyways 

     

    KR

    Vinnie

    • Marsha_R's avatar
      Marsha_R
      Moderator
      3 years ago

      I think I vote with vinniew  here. 

       

      If these bugs came from TestComplete, then I already have code that will duplicate the error. I don't want to spend QA time trying to write more test code just to have a standalone test for the dev that's never going to be used again. I also don't want to spend the time debugging the standalone test on the dev machine because there will be differences just like there are between QA machines. 

       

      Faster than all that, Vinnie has taken the manual steps I gave him and fixed the bug already and I ran my existing test on it and also created a new case to cover the bug.  🙂