How to use testcomplete in Agile
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 before develoment started. I am not sure How I can access the object before develepoment of the project?
your help will be appreciated.
Automate your testing work when your GUI is almost frozen but you have lot of frequently functional changes.
Writting automation test when the UI is not stable is not a good idea. You will be totally unaware of the control properties which you can use in automation script.
We have faced a similar situtation . We use keep lag of 1 sprint to complete our automation work.
Sprint 1 :
Dev creates new UI part & new functionality
Tester prepares test scenarios to be automated
Dev works on new task
Tester automates what has been developed my dev in previous sprint.
I hope this has been of some help.
I would like to know that ,how actually the automation has applied on agile projects?
Is the same regreassion,load and performace scripts are used?
or actually scripts for unit test(developed by programmer) is used for automation of the functional testing in testing?
whol develop the automation scripts for agile projects?devloper or tester?
Thanks for your guidance.
We were creating the regression test and adding it to our regression suit
In addition to that we were creating API tests for the same which does not require any UI.
Coming back to your questions:
Q) How actually the automation has applied on agile projects?
A) First , you need to understand what new is being developed in the currect sprint , then you need to analyse which test would suit best to check the functionality (API , UI based test etc. )& then develop the test.
I think creating API Test would suit more for your requirement.
Q) Is the same regreassion,load and performace scripts are used?
A) Yes , You can use the same suit but minimal modification may be required.
Been awhile since I was on an Agile project. But, when I was we would work with the developers (and user community) to determine which tasks (defined by our task cards) that would be in the next interation/sprint. From there we would start creating our autonated test scripts making changes as needed as we went. One code was ready to test, we would execute the test scripts. We would continue this process for each interation/sprint while at the same time building a regression testing suite we would execute after last build for that particauler User Story. Hope this helps.
We use agile and we do our automation in the same sprint as the developers work. The developers give us the framework as soon as they can so we can do name mapping while they are finishing. It may need to be changed a little for the final product, but usually not much. We plan the tests while the developers are working and then we do our coding in TestComplete when we get the final product.
We tried delaying it one sprint when we first started and for us it seemed to be too much like waterfall. The developers have moved on to something else and have to change focus back and forth if we have questions while testing. By including the automated testing in our definition of Done, we are able to stick together.
[Community Heroes] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Heroes]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Hero] signature is used with permission by SmartBear Software.
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.
Hope you share your feedback
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.
If its not broke, obviously there are not enough features
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!
For all who is interested in (predictions on) future Agile/Devops developments of automated testing and the characteristics of tools in these changing landscapes, in Agile/ Devops, view this video from WorkSoft:
Very, Very interesting!