Forum Discussion

AAN's avatar
AAN
Contributor
14 years ago

Scripts that worked but when new code is introduced braek the automation run.

After having spent much time (fixing objects, changing auto width timer,

object target point & fix) & Having successfully recorded automation

runs for Timesheets, My Accounts, Key Contacts, Transmission Details,

Photographs, Correspondence works within the current code of the

application (WPF/.NET)>


When new code is introduced to the WPF Project Manager application, the Automation runs breaks

the automation runs that were previously successful.





Is there a smart way to deal with code changes?

2 Replies

  • AlexKaras's avatar
    AlexKaras
    Community Hero
    14 years ago
    Hi Aneez,



    The answer depends on the code changes introduced. If the change resulted only in rearranging UI controls, then this should not break the tests. But if the change resulted in replaced controls or modified business logic, then you will have to adjust the tests accordingly.



    Just to warn you/your management against (possibly) false hopes - you must treat test automation as a 'smaller development project within the bigger one'. Your automation efforts must be correlated with the development flow and this must be done from the very start of the development. 99% that test automation will fail (or appear to be ineffective, which is, basically, the same) if you are said to test automate already existing application. You must to establish the communication process with Development so that you are warned in advance about the changes planned for the application (replacement of the used controls, databases, business logic, etc.) so that you can prepare for them and minimize the time that your tests are non-functional. It is great if you can participate in evaluation of the UI controls planned to be used in the application to check if this or that control can be automated and how many efforts are required for this.
  • AAN's avatar
    AAN
    Contributor
    14 years ago
    Hi Alexei,



    Thanks for your detailed response:



    The only section of your comment I don't quite get is:



    "You must treat test automation as a 'smaller

    development project within the bigger one'. Your automation efforts must be

    correlated with the development flow and this must be done from the very start

    of the development."



    Right now what is happening is:

    We have a sprint, we are attempting to automate, then spend a lot of time fixing the automation. Then new code/changes are introduced (though it may not be in the particular section we automated) yet the automation run gets broken.



    I'm wondering would it make more sense to just automate when the application is more stable & there aren't as many high chances of new code constantly being introduced?