Whomsoever it may concern.
Please help with some best practices in maintaining the test cases. Understand we can open and close the project. But wonder what will happen if my project contains 1000’s of test cases.
Few ideas that comes to my mind is
> one project per application
> one project per requirement
> one project per module
> one project per test type(Regression, Sanity,…)
We can pick one of this based on the size of the test suite/type. Also, in all 4 cases we need to have control over how the object repositories and data files are managed for whole project.
Much appreciated !
Thanks Mate, Another thought
Like the way we Open Project, it would be better if Import feature is implemented at the earliest to avoid test management overheads.
Like we should be allowed to Import Test Cases(Folder) Level. This way i can limit the test cases loaded in Katalon at any given point. This will help in opening fewer tests in katalon and work on same and check in.
Below are the few suggestions:
- Project mergers
- Multiple projects can be used like Eclipse
- Option to add 3rd parties plugins like Eclipse
Here you suppose having 1000 test cases.
I do not think you are going to code 1000 test cases manually. I guess you are going to use the Web Recorder tool to generate test cases to check 1000 web pages. Am I right? If not, would you please describe how you are going to build such unbelievably huge accumulation of test cases?
Let me assume for now, you are going to rely on Web Recorder/Spy tools. I hope you to have a look at my previous post:
Let me quote myself:
I am rather afraid that those who are new to Katalon Studio may expect the test case code generated by Web Recorder is near completion. But I swear the code generation is just a start. You have long way to go for continuous rethink and rewriting codes.
I would rather start thinking about how to reduce the number of testcases: 1000 -> 100 for example. In order to elminate number of almost-similar-but-partially-different test cases, passing Groovy Closure as parameter from caller test case to callee test cases might be an effective approach
Great topic @Rajesh_Kumar_Jayapal
I have been wondering similar things…
On paper, mathematically, I should reach >1000 tests. Whether that will happen in reality, I’m not sure… doubtful, even. There are (last count) 108 pages in my AUT. At the present time, the page with the greatest amount of tests has 28 test cases written. Extrapolating that across the entire AUT would give me 3024 test cases.
Clearly, that number is both unwieldy and probably unachievable. Over time, I expect to be facing the same decisions as to how best this can be managed. But right now, my task is to increase coverage – there are many pages still with zero test cases written.
So, right now, this is one single project. Breaking it up into one project per page sounds like a management headache too – 108 projects?
I’m no where near the point where I need to decide that yet… but it’s going to happen at some point.
1.Maybe we can submit the object repository and test cases to the database, then we can work together.
2.We can submit the object repository and test cases to one portal, then do the test like QC with QTP
Yes very good topic, its a big worrie for me to manage this. i think it is always dependend on the organizational needs. For me I need to consider the esb queing as well because the applications are depenent of data and stubbing is not an option. Therefor i modularise common reuseable testcases to custom functions (keywords and util functions, a functional object repo) which i merge in the projects needed.
You are talking about central repository, right. If this can be implemented that would be awesome. For now, work around is to merge your all projects test repository into one then you can utilize as central repository. I am no sure about if you can access remotely but you can have same repository into your workspace.
if this is not the right response about your query then never mind.