If you ever had a complaint from a customer that something on your website is preventing them from buying, you are not alone and in fact, you are lucky. Usually, users will just leave and purchase what they need from the shop “next door”. In this article, we are going to talk about what you… read more
This year, Altom turned 11 years old. The one-shot anniversary video we uploaded back in September, was one of the most challenging projects we have been involved in as a team this year. To those of you who have already watched the video and shared their positive feedback with us, we wish to give you… read more
AltUnityTester v.1.5.2 This is a small release in which we fixed several bugs caused by 1.5.0. We also made some improvements on the GUI and added a new command GetPNGScreenshot which will make a screenshot of the game in png format. For more details about all the changes check: https://gitlab.com/altom/altunity/altunitytester/blob/master/CHANGELOG.md AltUnityTester v.1.5.0 What’s new: Refactoring… read more
We are proud to announce that AltUnityTester Version 1.4.0 is out. This update does not include as many changes as 1.3.0 but it is the first update in which we try to expand AltUnityTester to a different type of devices other than Android and iOS. What’s new The biggest thing that happened in this update… read more
Today we just released an update for AltUnityTester (v. 1.2), a Unity3d plugin that enabled UI automation on games and apps developed in Unity. We described the reasoning behind AltUnityTester and our motivation in a longer blog post, here: https://altom.com/altunitytester-unity-using-appium The first version of the plugin relied heavily on Appium for all interaction with elements,… read more
AltUnityTester is an open source tool for Unity testing that lets you find and interact with elements from a Unity app/game from your Python Appium scripts. Before going into details about AltUnityTester, I want to tell you a bit about my own context and the struggles I’ve had in mobile games automation.
It all started with an e-mail. It was that time of the year and we were anxious for it. What would be the challenge this year? Who will rise from their chairs and demand a place in the team?
The quiet settles and a new email asks shyly, “Who wants to be in the TeamStar competition this year?”. The possible contenders are partially known – Dorel and Dolly. Both of them have been on this path before. Later on, they are joined by Oana and Elena.
We recently had a meetup in Cluj focused on testing tours, with the occasion of Eurostar’s contest Teamstar. As part of their contest entry some of our colleagues decided to create a workshop in which we would practice with tours. They prepared intensely for a few weeks: searched materials on this technique, picked a list of tours, practiced with them, and created an exercise for the meetup.
The first thing I realized from this experience is that there is a lot out there about testing tours. The organizers kindly provided some materials to read before the meetup, from diverse sources. Going through them, I found references to even more materials on tours. (You can find them at the end of the article). So it seems to be quite a known technique.
But why all this focus on testing tours? In what ways are they valuable?
I sat down with James to talk about his approach in teaching the RST course. Some interesting behind-the-scene insight came out, including particular ways that James uses to give feedback to his students.
I felt honored to have been invited to facilitate the Test Lab at STAREAST. Being my first Lab at this particular conference, I was lucky to have Bart Knaack, James Lyndsay and Wade Wachs there to ramp me up. They told me about their experiences with the Lab at STAREAST and gave me valuable insights from their personal kit of lessons learned. Their input helped me change the regular approach I had when running other Labs at EuroSTAR and BTD. Once again, context wins over pre-established “how to”s.