note Product Group App Team
Left: Kazuya Ueoka (iOS app)
Right: Kazuto Yamasaki (Android app)

With automation, we can carry out more valuable work

Yamasaki-san (hereafter, “Yamasaki”): Ueoka and I joined in 2020, and MagicPod had already been deployed at that time. The person in charge at the time was of the mindset that “when you do the same thing twice, automate it,” and decided to deploy it to ensure quality even without a QA team. For further details, see the interview article described in note.

Ueoka-san (hereafter, Ueoka): In the app team, I am in charge of iOS and Yamasaki looks after the Android side. There are three engineers including us, and when adding designers and a PM that have joint roles, we make up a team of six people. There is no internal QA team, so we do all the testing ourselves.

Yamasaki: We only have 1/10th the resources of the web team. Due to the paucity of our resources, what work we prioritize is always an important issue.

Ueoka: Our job is to “write code that brings value to users,” so it is a problem if our time is taken up by testing. We are very grateful for the fact that MagicPod is working in the background while we are coding. For example, the app team has made approximately 35 test cases for iOS and 22 for Android. If these were all checked manually, it would take up to two hours per day.

Doing the same thing multiple times is hard work, but what is worse is that it means we are unable to do more high-priority, high-value work. Our policy is to have machines do the things that machines are good at, and we should do things in which humans excel. This is becoming the culture not only of the app team, but of the company as a whole. For example, when we look at Slack, there are a lot of posts by bots, and this gives the impression of a company embracing automation as part of its culture.

Reference: “Interview summarizing the development of the note iOS app in 2020” (note)

Reduces costs of communicating between teams

Yamasaki: MagicPod is run as a batch every morning at 7:00 AM, and also when the master and release branches are pushed. If a failure occurs, we check the cause from the details screen, and carry out the necessary modification work.

Ueoka: Before the release, we spend time doing manual and exploratory testing together, but after that everything else is automated. Making fixes before release causes a flurry of work, so it is advantageous from an engineering perspective to be made aware of problems earlier by running tests daily.

Yamasaki: About 80% of the note app is fully native and 20% is hybrid, so there are times when detailed changes on the web side are not detected by us in the app team. It is extremely helpful for us that MagicPod can catch these, perform self-healing on the confirmation screen, or allow us to fetch it so we can rewrite the code.

Ueoka: We are also constantly working with the web team to create test cases to ensure quality, and we will continue to do so in cooperation with them.

Quick reflection of proposed functional improvements

Yamasaki: I think the shared steps are good in terms of functionality. It is quite convenient to create and accumulate test cases. This means that they can be tested in combination, and there is no need to create the same test multiple times. I like the way it tells us where the shared test failed.
Ueoka: I like element inspection mode. The screen is automatically analyzed when uploaded to the app, and is separated into parts. This means we can create a script by merely dragging these parts. This experience is really amazing and, if we face a problem, we can send the test results and receive advice while making an inquiry in Slack, and being able to communicate in this way is very useful.

Yamasaki: They always respond flexibly to feature requests. There are some things that, while not exciting, are very important, and “just having them makes a difference.” Our detailed proposals are reflected straight away, which I consider to be highly valuable as an engineer.

A GUI that anyone can use is an advantage in hiring

Yamasaki: At my previous job, there was one member in QA, and he wrote code in Appium. Even if we wanted to increase the number of QA members, we would run into the problem that “we could not hire people without any engineering experience.” MagicPod can also be used by non-engineers, and they can communicate issues in the form of “it seems like it is failing here. What do you think?” while showing screen captures. We feel that having a GUI with good visibility is a significant advantage in terms of hiring.

Ueoka: Also, when hiring engineers, it is great to not have to focus on whether they have testing experience. Of course, we want them to recognize that “testing is important,” and if they are able to write good unit tests, that is always welcome. However, not hiring them just because they cannot write the tests would be a waste of an opportunity.


Yamasaki: It is also important, as an engineer, to consider and develop an environment in which testing can be done. One advantage is that, as MagicPod can be operated via GUI, it allows us to orientate our mindset toward “checking the requirements, setting the identifier(s), and being able to handle successes and failures”

Ueoka: In terms of the test pyramid, ideally the unit tests will be the base, and then integration tests and E2E tests will be built on that. However, if you are just at the stage of “how should I go about writing tests?”, MagicPod is a good choice as it will allow you to create tests from nothing. Even if you start with E2E tests, once you have the confidence of “having written one test,” you can gradually increase the number of unit tests, which is the ideal way of doing things.

Notifications

At note, we are looking for engineers and PdMs to join the team.
If you are interested, please pop in for a casual interview.
・iOS engineer
・Android engineer
・Product Manager (Mobile App)