A wild QA member appears!
I don't believe the community has heard from the QA team yet, but in terms of development, I am here to report our ongoing battle with QA automation 🙂
@katos and myself have spent restless months trying to figure out the best approach to QA automation and we went with Cypess. For those of you who don't know what Cypress is, it's a platform focused on E2E (End to End) automation. Part of being in QA is finding ways to automate most of our manual testing so that we can spend time elsewhere where it is needed most. Whether that be with our families, loved ones, other Flarum related tasks such as helping the rest of the team, automation saves so much time and man/woman power once it's set up and running.
The end goal is to fully automate our front end tests to make sure we find as much bugs as possible before a release so that the devs can either work on them before we publish a release, if the schedule allows, or work on a patch after a release to address these bugs, or even tackle them in a later release depending on it's priority.
We already have back end unit tests, thanks to our lovely development team for ruthlessly working on those so we don't have to essentially add that to our Cypress test collection. Nonetheless, one of our focuses in QA right now is automating as much as our processes as we can.
If being a non-experienced/profession QA tester has taught me anything, developing your tool-belt is only half the battle, the rest is getting those tools to work on your behalf and making sure your tests are easily readable for the next QA person to take a crack at.
To give you all an idea of the kinds of tests we are working on and figuring out what works best with our application, here is a simple login form test that I've been working on to get a feel of how Cypress can benefit us long-term:
Simple right? Well lets say you want to dig a bit deeper and stray from best practices:
Now we're digging deep!
The problem with the above code is that it falls away from best practices when developing test cases; we don't want to do this much in a test if we can easily simplify it in smaller and more organized tests.
In summary, QA testing isn't all about clicking on buttons and making sure everything works as intended in the UI; We get our hands dirty as well in some code and have the assistance of our dev team when we get stuck 😉 (shoutout to @askvortsov for helping me with an auth issue using the Flarum API!).
We are far from getting our automation pipeline working at 100% with most if not many of the test case scenarios created, but the foundation is already there for us and so is our CI/CD pipeline using GitHub Actions (shoutout to @askvortsov again for assisting QA with that as well!!).
P.S. please excuse my rambling if some of the things I said above doesn't make any sense or isn't essentially correct; it can be a huge learning curve especially for not having professional experience in QA. We all have to start somewhere right?!
😃
