Here’s my current situation. My team builds and maintains 3 (soon to be 5) different mobile applications, each of which is built independently for iOS and for Android, making a total of 6 (soon to be 10) unique applications. To date, I’ve been building a single Katalon project for the first of those application pairs so that I can trigger a single test suite to run both the iOS and Android versions of the same app concurrently on Kobiton devices.
Now I’m starting to work on the second of our application pairs, and it’s spurred a seemingly important question. What’s the best way to group that many applications?
Should I lump common applications into shared projects, despite being on different platforms? Thus creating projects for App 1 (iOS & Android), App 2 (iOS & Android), etc…
Should I group applications into a shared project by platform? Thus creating projects for iOS (App 1, App 2, etc.) and Android (App 1, App 2, etc.)…
Should I collect all applications and platforms into one, big, master project?
Perhaps I should do something else entirely that I’m not thinking of?
If you’re in a similar situation, how do you structure things? What are the pros and cons of your methods?
Thanks in advance for any response you all can give!
When a set of tests (a suite) are running, these “things” are known:
Target Application
Target Platform
And possibly
Test Suite name (assuming you have more than one suite targeting a given app).
The question I’d ask now is, how does a given test run come by that info? Well, it’s the profile in the project, right? So then I’d wonder how might I generate that info to automate the entire process…
That would lead me to writing a script that spat out a suite to be injected into the pipeline with all it needs to know to execute the suite already in place in the generated profile – and passed to Jenkins (for example) on the KRE command line.
Katalon may not have enough smarts (yet) to make what I’m suggesting easy – a “super” project that writes a project profile and/or suite and then executes it. But I’d certainly try to do it like this.
Why do it this way? It scales. Doesn’t matter how many apps or how many platforms. Just add another couple of switches to the super-project which writes out yet another KRE command line.
I will structure them based on the development cycle.
I suppose, not all apps are developed at the same time, but for any iteration (new feature, bug fix etc) one app is developped and built / released for both platforms, iOS and Android, usually.
So choosing option 1 (group by app) makes sense for me.
How to structure them is another story, but let’s say you will have at least TestSuites separated based on platform (end eventually wrapped in collections)
For the testcases, no idea, i suppose you have to segregate them also, since being different frameworks most probably you cannot reuse the code / selectors, but you may eventually have some common code (like a data provider etc) which you can group under custom classes/ keywords.
Option two does not make too much sense for me, and definetly not three, having everything in a single project is a terrible idea.
Ofcourse, it depends also on the QA team structure. If the same person is in charge with testing the app for both platforms then, definelty 1.
But if different persons are in charge for testing for each platform, then perhaps 2 may be suitable, so the testers do not conflict when updating the code (yeah, it happens sometime, if the process is not handled carefully, e.g properly using branches, you can have issues with merge conflicts)
I appreciate that input, @Russ_Thomas. Unfortunately, I think it’s over my head. I’m a manual tester with no development background only learning to script now that I’m in Katalon. We also don’t currently have our automations integrated with the build pipeline; for now, I kick them off manually before releases. Pipeline integration is something I’d like to get to, but it’s a ways out still.
Thanks for your input, @bionel. That’s the way I’m currently leaning, but I wanted to get some outside insight before committing to the path. And yes, you’re right that the separate suites are lumped into a big collection for running both platforms at once—I realize I didn’t use the right terminology there.