What is User Acceptance Testing?

Once upon a time, a clinical laboratory realised that, if instead of having to find the paper documents related to each test and writing down the results by hand they could have a smart monitor, they would save a lot of time.

The practitioner would only tap on the test they were working on and quickly update its status with a second tap. They found an engineering firm and explained to them what they needed and the engineering work began.

A dedicated team of engineers started working on the product. There were so many parts: the software, the touch screen, the computer-like device running the software, the height-adjustable stand, etc.

After several months of hard work, the product was ready. Not only had they tested every single part on its own, but they had also even tested the larger components after coming together. They provided a demonstration to the lab, showing the software and how they can put it in any room thanks to its simple design of only one height-adjustable monitor.

The order was delivered and everyone was satisfied; until they started using it. The lab came back to the engineering team complaining that the monitor is useless because it only detects the touches of the bare hand.

It was a disaster. The engineering team had no idea that the practitioners are required to have medical gloves on at all times in the lab. All the different parts of the monitor were tested. The only issue was that it was tested by the wrong people and in the wrong environment.

The idea is clear. In the process of testing our products, it is also important to give the actual user a chance to test it too because, well, they are the user of this product. If they are not satisfied with it there is no point in producing it anyway.

It might seem like this does not apply when the product in question is software but the reality is it does apply the same if not more. This part of the testing is called User Acceptance Testing or UAT for short.

Most of the other types of testing you might be familiar with happen in the process of development or deployment. We write unit tests to make sure each individual function of the code does what we expect it to do, similar to testing if the power button on the monitor in that clinical lab turns it on. The very last test that happens right before the product is pushed out is UAT.

Let me interest you in another anecdote about manufacturing. In the early 1800s wristwatches were becoming a thing and manufacturers were about to emerge. However, a Swiss company that had managed to be one of the first to export watches to foreign countries was having a frustrating issue.

They would export the watches all around the world and a lot of them would be returned reporting that the watch was not working. They would try these returned watches to see what the issue is only to find out there are no issues and the watch is working perfectly fine.

They would send the watches back again as all tests were showing that the watches were fine but the same thing would happen again - most people found the watches to quickly get out of sync so they would return them.

After thorough investigations, they finally found what the issue was. The mechanical pieces behind the watch were designed to move with the speed that would represent a second… in Switzerland! Other countries with significantly different altitudes would have different air pressure which meant the same mechanics would not work on the watch and the handles would either move faster or slower, causing the time to get out of sync.

There are many lessons to learn from that story but the one we are interested in is that, not only UAT should happen by the end-user but also it should happen in the exact same environment the product is going to be used.

Let us put it all together in the context of software development. The product is developed and all unit tests, integration tests, etc. have passed. The final step of testing is UAT. We said UAT should happen by the end-user but how is that possible in software?

It really depends on who your user is. Sometimes companies have a group of test users who are willing to test the products. Sometimes your customer is other businesses using your APIs and tools so if their automated tests on your new version pass it can act as a UAT for you. And in some cases, you will have a Product Owner that will represent your end-user for you. If your team cannot be directly engaged with the customer then the product owner is your customer. They will define the requirements and then they will also test those requirements at the last stage.

The second thing we talked about was being in the same environment that the product is being used. This can be of special importance if your “production” environment is different from what the developers have on their local computers.

A lot of the companies that have an online service have something called a UAT environment. This is basically what that is. It is an environment with the same data and databases, the same networking and infrastructure and basically the same everything. The only thing that is different is the product/service. That way, you can ensure that the product is being tested in the same environment as it is going to be used and any performance issues or bugs will be discovered. The only difference between a UAT environment and a production one is who uses them.

Fun fact, this article was also UATed - I sent it to a couple of other engineers (the type of end-user I am expecting here) so they read it on their computers (the environment I am expecting you to be in) and make sure they understood it! And they did so I hope you got an idea of what User Acceptance Testing is too and why it is incorporated into the delivery process of engineering teams.

Of course, just like any other type of testing or any process really, there is a lot more to know about its good practices and frameworks, dos and don’ts, etc. that you can search about and find heaps of good articles on the internet!

Did you find this article interesting? Do you think others can enjoy it too? Feel free to share it with your friends!

MARCH 2022 HACKDAY (Part 1) The Morse Man bot

.. - ... / .... .- -.-. -.- / -.. .- -.-- / .- - / -.- --- --. .- -. -.-.--

The above elegant line of dits and dahs is Morse code. Developed in the 1800s, it has stood the test of time, and with its combination of nostalgia, intrigue and retro vibe, it’s primed for a resurgence in popularity. Instant messengers can feel a bit synthetic and for those who long for a more analog, authentic communication, Morse code may well meet this need. As part of our regular hack days at Kogan.com, and with the intention of improving Slack by adding personalised features, a Morse code bot was just one of a plethora of bots that was created on the day.

So how did we achieve this greatness?

It started with a repurposed Google Cloud project and a quickly assembled Flask app to lay the solid foundations on which to build. Because we care about developer experience, we added UAT builds on push to our dev branch, and because we care about consistency, we set up some pre-commit checks. Once that was done, it was time to start with the meat and potatoes, and get some functionality working. After examining Slack documentation we knew vaguely what we needed. That was to create a custom Slack app bot and use slash commands to access our Flask app. Essentially, one can access a Slack app bot by typing “/bot-name” into the message box and whatever message you write after this is sent as a parameter to the request url specified. The response from this request is then posted in the channel from which it was sent. We could now start work on the individual bots.

The Morse Man bot:

Our progress so far had worked well, but we soon stumbled upon a constraint that was rendering the Morse bot worthless. The problem is as follows, should you wish to utilise the Morse bot to encode a message, the bot replies to the channel with both of the following messages:

Morse Man Slack bot posts:

@userTryingToBeSecret sent this message: /morse Here is my super secret message

Morse Man Slack bot posts: .... . .-. . / .. ... / -- -.-- / ... ..- .--. . .-. / ... . -.-. .-. . - / -- . ... ... .- --. .

No point sending a secret message if you send the real message with it at the same time. Concerned that this could affect uptake and not wanting to jeopardize the project, a better technical solution would be necessary. Further investigation found there is an option to set the bot response to only be visible to the sender, and it was also found the Slack API can be used to send messages ad hoc. Combining these 2 possibilities we are now able to do the following:

• Use a slash command to call the bot
• Send a request to the Flask app (and return no response)
• The Flask app receives the message as a parameter, and using sophisticated algorithms encodes it into Morse. At the same time we get the channel ID from the request API
• Using the separate Slack web API, make a request to the channel and send the message!

Lastly, our Slack bot could only be taken seriously if it has a legitimate avatar, and hence our UI/UX designer got involved to add a polished feel to the project. The end result can be witnessed below.

The Horse Man bot:

Following on from the development and good learnings of the Morse Man bot, but instead of converting into Morse code, it uses an alternative proprietary encryption method to convert into horse dialect. Also complete with its own avatar.

Impersonator bot:

A skunk works project that was developed in the shadows. Someone noticed that you could supply any name and icon with the API request, and this essentially meant you would be able to impersonate any user on Slack(this is true apart from the small word ‘app’ after the username indicating its true source) By using the Slack API that returns user details, the bot can accept a username and a message, then automatically retrieve the users Icon and repost the message as that user. A dangerous discovery that was essentially banned immediately.

Humor bot:

Using the same foundations, but then uses external APIs to fetch jokes from Chuck Norris and Ron Swanson to inject some humor where required.

Dashboard bot:

A truly value adding bot. The idea was for a bot to provide snapshots of our Grafana dashboards when requested on slack. This could provide quick access for everyone and also add value if needed as part of a discussion. It leverages Selenium to login and render the dashboard, as well as take a screenshot, which is then returned with the Slack web API.

Unmorse bot:

Decodes Morse code. This has proven to be particularly useful, as it turns out not many people can read Morse code directly.

We now have a bunch of nifty bots at our disposal and a better understanding of the functionality available for integrating with Slack. At Kogan.com, hack days are considered an important tool in giving us the time to pursue alternative projects of our own choice. The skills and ideas seeded from a hack day can result in something that adds direct benefit or can be an opportunity to learn and upskill ourselves.  It also adds to the culture of our workplace and supports team work by giving us the chance to work with people outside our normal team.

Celebrating International Women’s day

Tuesday 8 March was International Women's Day, a celebration of women and their achievements. A day of celebrating the social, economic, cultural, and political achievements of women. This day also marks a call to action for accelerating women's equality. This year we thought we’d celebrate by spotlighting an incredible group of women who work in the Kogan.com engineering team. We’ve cultivated an inclusive environment to ensure that women in our team can thrive, from providing equal opportunities, coaching and mentorship at every career stage to various benefits that support home and work life. Here’s what this group of Kogan.com women had to say about why they love working in our product, design & engineering space and how to grow—personally and professionally. Check out their stories!

Why do you love being an engineer at Kogan.com?

“ There’s always something that pushes me to get out of my comfort zone, whether it’s a simple feature implementation or a head-scratching problem. I’m surrounded by very talented and driven teammates, so there’s never a boring day. Most importantly, I feel supported and I’m constantly reminded that working within the Engineering space doesn’t have to be monotonous.”

Ana Teo, Software Engineer.

“ Working in the Engineering Team is rewarding because we get to work on a variety of features and continuously learn new things. We have an amazing, talented team and the work environment is friendly and fun.”

Hanna Koskela, Software Engineer.

What do you love most about the product and design space at Kogan.com?

“ Before I became a member of the Kogan.com engineering team, I was an avid customer. I loved the vast number of products that Kogan.com offered and that I could buy anything from home appliances to clothes to setting up a credit card. Being a pre-existing customer I was already fairly familiar with the end-user experience, after joining I got to see how things operated to make the whole platform run smoothly. I enjoyed meeting the people behind the scenes, from the people involved in the financial operations to the customer care team. I’ve learnt so much from these experiences. I love that there are always new things to learn. This has encouraged me to think outside the box and keep developing my professional skills. Our team has an incredible opportunity to grow as every new project provides new experiences to learn from. No day is the same and I always feel like I am learning something new.”

Hien Do, Product Owner.

“ We don’t limit our products on e-commerce itself. We have brought Australians the most in-demand products and services such as Kogan Internet, Kogan Insurance, and Kogan Super. As a designer, I will continue exploring the possibilities with my colleagues, and designing a user experience that can benefit our customers as well as support our Kogan staff.”

Mengfei Hu, Senior User Experience Designer.

What comes to mind when you think of growth in the technology space?

“I think about growth and development as a tool to cultivate ownership. The more responsibility you give someone, the more ownership they have. Our team provides a wide range of growth paths for engineers and within our product design space. Team members get to really think about the details of what they want to do and chart their path so they get to have a high impact. Having clear goals and direction and using tools like CultureAmp, provides clarity so that each person knows what success looks like and how to get there.” 

Anita Rajalingam, Talent Acquisition Lead

“User experience has become one of the most widely used term in the technology space. Kogan.com is well known as one of the largest ecommerce platforms in the technology space that cares about their customers’ experience. They are meticulous about the product design as well as the functionality to ensure the users’ needs are always being listened to and responded. It’s such an honor for me to work as Senior UX Designer at Kogan. I endeavor to continue bringing immersive experiences to my product users.“You’re limitless if you go out of the box”

Michelle Huynh, Senior UX Designer

What is the best advice that you’ve received, or want to share to other women in technology?

“Perfectionism is the enemy of progress” 

Working in a male-dominated field, it’s easy to get into the mindset of having to “prove yourself” and wanting to do things perfectly. I learned early on that nobody will be as critical of my work as I am. Don’t let your sense of perfectionism stand in the way of delivering great work. 

Sandra Kärcher, Senior Product Manager

“Be exactly who you are and stay true to your values! The key to thriving in your work environment is authenticity. Also, take on any opportunity to learn something new - keep an open mind and don’t be so afraid to not succeed that you never try different things. The technology sector is incredibly diverse, and people are surprised that I work within the field despite not having formally studied computer science or IT. I remind myself every day that I don’t have to know everything, I just need to bring together the right people to find our solutions.”

Christine Kha, Product Owner

Supporting and celebrating women worldwide

We’re thrilled that we get to celebrate the accomplishments of women around the world—and within Kogan.com. Keen to see how you can take your engineering career to the next level at Kogan.com? We’re growing our engineering team and would love to hear from you!

Technology Talks

I recently delivered a short talk to the Kogan.com engineering team on GraphQL - a technology that has not yet seen adoption at the company, but for which there arguably exists a need. Customers shop on Kogan.com across devices with different data requirements, and our reliance on traditional REST APIs leads to cases of under-fetching and over-fetching. GraphQL is a potential solution to this issue that can also make calling our APIs more simple, flexible and intuitive.

Presentations like these serve two main purposes: to educate and to inspire. Hosting regular discussions around technology practices helps share knowledge between engineers and identify where improvements can be made. At Kogan.com, we hold regular presentations and discussions about technology, typically hosted by members of the engineering team. These come in two flavours – hour-long “tech talks” and 15-minute “lightning talks”. Each is held roughly once a month, and the responsibility to host them cycles between each member of the engineering team. My presentation was a lightning talk, but another engineer in my team recently delivered a tech talk on OpenAPI practices. An effective talk appeals to all members of the audience. Despite having experience with OpenAPI, there were still valuable things that I learned.

Technology talks are important to organisations, so that they can share the best ideas and keep up with continual change. There will certainly be more talks this year at Kogan.com; I look forward to learning more about what my colleagues have to share.

DECEMBER 2021 HACKDAY (PART 3) v2

Tick tick, boom gate opens!

And by boom gate I am referring to the Kogan.com office car park boom gate. Kogan.com office parking spots are a scarce resource, but the staff members that are lucky enough to have an allocated spot aren’t always using them. Most days there is enough space for other staff members to utilise the parking spots, but there aren’t many remotes to open the car park boom gate. Is there perhaps a way to remotely open the boom gate by using the Kogan app only, without needing an individual remote?

During the recent hack day, team “Kogan Boom” took on solving this problem. We also managed to surprise and perhaps thoroughly confuse some passers-by when we were testing our solution and randomly opening the boom gate from the comfort of the office. This project had everything; electronics, hardware, software, app integration. It was a fun action-packed day for the team and everyone got to contribute.

The Boom Gate project comprised of three software systems:

1. The Boom Box: An ESP32 wired into the physical RF remote control for the Boom Gate.  These remotes are in short supply and why we wanted to build the project in the first place!

2. IoT Cloud: We used AWS IoT Core to register the ESP32 as a ‘Thing’.  AWS IoT made it simple to generate the MQTT authentication certificates that were copied to the Arduino code running on the ESP32.  We created pub and sub topics via AWS MQTT for which to issue commands to the ESP32 controlling the gate and for the ESP32 to communicate back.

3. Web App: A mobile app and web service that enabled authorized users to toggle the car park Boom Gate. Instead of registering this service like another ‘Thing’ - we used AWS boto to publish the message to the MQTT topic and generated a service account for authentication with permissions to publish.

 Overall, when a logged in user hits the ‘Open’ button in the APP, a POST request is made to the web service which then pushes a message to the MQTT topic.  The ESP32 subscribes to the same topic, receives the message and toggles the PIN which connects the circuit on the RF Remote Controller and opens the gate.  The RF signal from the remote conveniently reaches the Boom Gate from within the office!

The Electronics

 The electronics part of the project included connecting a physical car park remote to a wifi enabled Arduino chip, requiring some delicate soldering work. Well it just so happens that Hanna used to do soldering professionally! She had a summer job at an electronics factory a long time ago and got to do a lot of soldering. Hack day impromptu workstation pictured below. It is good to note that neither staff nor equipment was harmed during this process. 

The ESP 32 Arduino chip was programmed using the Arduino IDE. We connected the ESP32 chip using USB Micro cable to our laptop. Testing whether the code is working or not is one of the most challenging parts. Using the IDE, the code is then uploaded to the chip. Then using a multimeter, we checked whether we received the expected HIGH/LOW signals on the right port.

Using the pin diagram we picked pin 5 to write high/low. Thee ESP32 chip was then soldered to the remote which requires a HIGH single to open up the boom gate. Since ESP 32 is WIFI enabled, therefore the code running inside the chip subscribes to relevant AWS Iot pub/sub channels and listens for the relevant incoming messages from AWS ref. https://iot-esp32.workshop.aws/en/module3/configure_esp32.html. Based on the message from AWS, which in our case was plain “open”, a HIGH signal is sent to the remote which then opens the Boom gate. We didn't need to program anything for closing the boom gate as this was handled by the boom gate itself.

The Mobile App and Web Service

Mobile app section of our team worked on the design and implementation of a new “Kogan Boom” app feature, which is only displayed for Kogan.com staff. There is a button to open the boom gate. Since the boom gate closes automatically, a specific button to close it was not needed.

When a user taps the ‘OPEN’ button, a web request is sent to the web server which then publishes a message to the AWS IoT MQTT topic that the ESP32 is listening on.  We achieved this without needing to register the web service as another IoT ‘Thing’ and instead used the AWS Python boto library to publish to the topic via a service account.  This was fairly trivial once we figured out the command to run!

The service account we created was given the AWS IAM access policy: arn:aws:iam::aws:policy/AWSIoTDataAccess so that it could publish to the IoT MQTT queue.

Putting it all together

 The finished hardware prototype turned out to be a rather sketchy-looking box full of electronics and wires. Some of the time the box was even ticking! Perhaps the name “Kogan Boom” was not ideal after all? 

Our hack day project came together nicely in the end and we were able to open the boom gate using the button in the Kogan.com mobile app. All in all, it was a successful hack day full of collaboration, new learnings, laughter and some very tasty donuts! We are very much looking forward to the next one. 

My experience onboarding with the Engineering team at Kogan.com

Can you describe your experience leading up to your start at Kogan.com?

The recruitment process for a software engineering position at Kogan.com was fast, smooth and enjoyable. The whole process - from the initial recruiter conversation to the final interview included a focus on technical excellence and soft skills. It began with a phone conversation, followed by a technical interview, and then a meeting with our Head of Engineering, CTO and Director of People & Culture. The process was efficient and purposeful.

Now that you have joined the team, can you describe what your remote onboarding experience has been like?

I joined Kogan.com at a steep inflection point in the growth of the engineering team. The size of the team roughly doubled in one intake of new engineers. Given this, one would expect onboarding to be chaotic and met with challenges. The reality was contrary to this - onboarding was a pleasant experience met with ample support.

My first day was highly educational and filled with meetings covering technical architecture, business context and culture. Given the pandemic, everything was remote. However, the team did a wonderful job in organising an onboarding that was not impaired by work-from-home conditions. The company even delivered us all food for lunch.

During onboarding and day to day where appropriate, the team practices pair programming. Tell us more about your experience:

Pair programming has been an encouraged practice throughout onboarding. It has provided me with a short feedback loop for rapid upskilling and given me the opportunity to socialise with other engineers, despite the remote conditions of work. In some ways, remote pair programming has advantages over its in-person counterpart. It ensures that both engineers get to use their ideal computer setup, allows for concurrency in certain operations (such as each engineer simultaneously exploring different parts of the codebase on their own screens) and does not require sharing desk space.

Now that we have returned to the office and are working in a hybrid environment, what are you enjoying most about meeting your colleagues in person?

I am enjoying meeting my colleagues in-person. Although Kogan.com has done an excellent job in maintaining company culture whilst we’ve worked remotely, there are some aspects that cannot be replicated. It has been nice to experience the full culture, have lunch and grab coffee with others. I tend to ask a lot of questions, and it’s easier to do that in-person.