I went to Showcase Gig with Ito, the MagicPod CEO.
We discussed many topics related to MagicPod, including the time before its introduction, how it is currently operated, as well as screen captures that are being used in unexpected ways.

Showcase Gig, Inc.

Since its founding in 2012, Showcase Gig has been working on creating a sustainable store model that embodies the consumer behavior of a new era. With their next-generation store creation O:der (order) platform, they provide “O:der Table” for in-store mobile orders, “O:der ToGo”, for take-out mobile orders, and “O:der Kiosk”, a next-generation touch panel-type order settlement device.

---

---

Product Department, O:der business division, Showcase Gig, Inc.
QA team leader - Mr. Masataka Yokota

The limits of QA that became apparent through manual tests

We deployed MagicPod in 2020. Until that point, the pre-release tests were virtually all done manually, but as it is not possible to run manual tests everyday, they would be done immediately before release. If a problem was discovered, they would be forced to start again, and it took resources to investigate where the problem occurred. The biggest problem was that it was not possible to allocate man-hours to other tests they wanted to run or to non-test activities.

Only MagicPod is strong in the mobile field as well

The reason they chose MagicPod was in order to run automatic tests on both native apps and browsers. There were products that only supported iOS, but I don’t think there are any others yet that support both iOS and Android. The CEO, Ito-san, is someone who has taken various approaches to test automation and Selenium-related activities, so I knew of him from before. When deploying, I was able to ask a lot of questions on Zoom, and all of my doubts were resolved, so I had a strong feeling of “I want to ask for their help”.

The connection with development is strengthened by visualizing test results

MagicPod is mainly used for “pre-release regression tests,” “post-release operational checks,” and “daily regular execution.” This is a service that relates to real stores, so it is difficult to automate all test items, but we have automated as much as possible using MagicPod.

In specific terms, “O:der Table” is run regularly every morning at 9 AM and finishes in about 20 minutes, so if a problem emerges there, the content can be communicated to developers based on screen captures and logs. If the regular test the previous day ran without a hitch but failed today, the cause is highly likely to be due to the difference in that one day, so the number of manhours before resolution will be reduced. If you run tests every day, you can detect even slight degradations right away, and I think this enhances safety as well.

The test result notifications are sent every day by email, but as these may be missed, notifications are also sent to Slack. I believe it is because the results can be seen by the development side that the system has operated smoothly since its introduction.

Reference: “I created a Slack Bot that checks MagicPod results every day” (Showcase Gig Tech Blog)

---

Left: Showcase Gig, Inc. Mr. Masataka Yokota     Right: MagicPod CEO Ito

A screen capture function that is useful in unexpected ways

It may be just our company, but we find the screen capture function extremely useful. For example, every time we add features, we need to provide a new manual to implementing stores. The screens used for that manual are created by the support team, so if MagicPod can set up a scenario to acquire screen captures, we can acquire them at the desired time. If a logo just changes in one place, we have to redo multiple screens, so it is wonderful to be able to automate screen captures as well.

Creating a QA team that can also contribute in areas outside of testing

We had an organizational change in November 2021, and created a new QA team. Until then, there had been one or two QA engineers in each of the development teams, but we changed the organization in a way that the QA team could look at each product in a cross-platform way. We are moving to transform the QA team from a team that “does” testing to one that “also does” testing.

It is because we were able to reduce the number of man-hours required for testing with the introduction of MagicPod that allowed us to think this way. By introducing exploratory testing, for example, we are able to provide frequent feedback to development engineers on defects and give suggestions for improvement. As a next step, we are looking into how the QA team can contribute in ways outside of just testing.

Reference: “The Trajectory of QA and Suffering in a Scrum team” (Showcase Gig Tech Blog)

---