WHO WE ARE
Founded in 1994 by top thought leaders in the software testing industry, LogiGear has completed software testing and development projects for prominent companies across a broad range of industries and technologies.
LogiGear provides leading-edge software testing technologies and expertise, along with software development services that enable our customers to accelerate business growth while having confidence in the software they deliver.
LogiGear is headquartered in the heart of Silicon Valley with the majority of the software testing and software development staff located in Ho Chi Minh City and Da Nang Vietnam. We are among the largest employers of software testing and development professionals in Vietnam, and our close partnerships with universities throughout the country allow us to attract and recruit top software engineering talent.
LogiGear continues to grow as companies realize the benefits of outsourcing their software testing and development. We have been listed among the fastest growing privately held companies by Inc. 500|5000 in 2009, 2012, 2013 and 2014.
The senior executive team has co-authored several top-selling books on software testing and test automation, including:
- Testing Computer Software, by Cem Kaner, Jalk Falk and Hung Q. Nguyen
- Testing Applications on the Web, by Hung Q. Nguyen, Michael Hackett and Robert Johnston
- Integrated Test Design and Automation, by Hans Buwalda, Dennis Janssen, Iris Pinkster, and Paul Watters
- Global Software Test Automation, by Hung Q. Nguyen, Michael Hackett, and Brent K. Whitlock (foreword by Apple Computers co-founder Steve Wozniak)
An insider's guide to the AI and IoT testing process
Testing the internet of things is one thing, but AI takes it to the next level. A LogiGear executive shares what the company learned from its first serious foray into this world.
For software testers, change is inevitable and unlikely to stop anytime soon. And nowhere is that more true than when it comes to AI and the IoT testing process. For an inside look at what this is really going to be like, we asked Phuoc Nguyen, software testing engineer at LogiGear, about the company's recent experience testing an AI/IoT product from gaming company Anki. In the first part of this two-part series, we asked Anki Test Director Jane Fraser how it all worked from her perspective. Nguyen offers an insider's very detailed look at the AI and IoT testing process.
Is this your first serious foray into an AI/IoT testing process? What lessons can you share for other companies struggling to test these cutting-edge technologies?
Phuoc Nguyen: We have completed testing for other clients' embedded systems, but this is our first serious foray into the AI/IoT testing process. The first game we tested was a racing game where the robotic car is built with AI using the client's application on iOS and Android smartphones and tablets.
We learned a lot about AI. Specifically, when we first started, we wondered how these cars build their intelligence and could do things like identify the target to defeat its opponent exactly. We learned that, from a player perspective, defeating AI was really difficult, especially an AI car with a high level of intelligence. The higher level of AI allows the car to become smarter.
At that time, we thought that the intelligence was implemented inside the AI car. However, after some time testing, we see that the intelligence of an AI car is actually based on the way the engineer writes a code of application. Through technology and algorithms, each car knows where it is on the racetrack, and where the other car is on the racetrack is based on the infrared camera on the bottom of cars. After scanning code from the racetrack, the car relays the information back to the smartphone or tablet via Bluetooth. The engineer receives that information and, as a result, enhances the AI, allowing it to decide to use the most suitable weapons to attack the opponents based on their positions on the racetrack.
After we understood these factors, we developed strategies that included physical intervention to impact the way AI acts while testing. For example, when playing a game with AI at its high level, players (especially people with less experience in playing the game) couldn't win it if their cars drove in front of the AI car. Thus, we chose an AI car equipped with a forward-firing weapon. In the game, if the AI car was behind the player car, we picked the AI car up and put it in front of the player car. That way, we could defeat the AI more easily. This scenario helped with developing a comprehensive strategy.
In conclusion, an AI's intelligence depends on a human's programming, not its own self. As a result, a human can create testing methods for it based on the rules made by the programmers.
You used error guessing in the AI and IoT testing process. Can you expand on what that is, how you used it and how it helped?
Nguyen: Error guessing is a technique which is based on the experience of testers to guess the problematic areas of the application. We usually use this technique to identify where the team should focus when executing the testing to create an effective strategy and avoid wasting time on the stable areas. Based on the experience we had gained during four years in the project, we could understand what the AI did and how the system worked. So we were able to easily find out the weaknesses of the application, as well as AI, by our assumption and guessing. This helps us save a lot of time as we focus on the questionable areas.
Stochastic testing is one technique you used. Can you expand on what this is and how you used it, and why is this particularly helpful for an under-14-year-old demographic and as part of the IoT testing process?
Nguyen: Stochastic testing (sometimes called monkey testing or random testing) is a technique where a tester randomly tests applications to find problems. Most gaming audiences in our project are children who are under 14 years old. Thus, we often play the game as children to see if the application can handle cases in scenarios that would not happen often with adults. For example, we usually test cases where the children could potentially break an application in a common real-world scenario. Examples include tapping two buttons at the same time, tapping on a button multiple times, tapping on multiple buttons/links continuously, interrupting, tapping everything on screen to see what their functions are (they don't usually go through the tutorial), etc. All of these actions may cause an application to get stuck or crash.
We've talked about the IoT testing process, so what about exploratory testing and AI? Everyone is wondering how to get their hands around AI testing. Can you be specific about how you approached this and what you learned from it?
Nguyen: Testing AI is a challenging task since we didn't have much documentation on how Anki's AI was programmed. Thus, we had to discover and explore to get familiar with AI, as well as understand AI behavior. Then, while testing, we took notes and recorded the actual test, so when the bugs occurred, we checked our recording to find the cause of failure. We observed the whole context, environment, platform, device, the emotion on the robot's face, the robot's battery, the device's battery, as well as the game we played, and used the experience of game testing we had gained during the project to narrow the "bug zone."
For example, we're testing a robot that is introduced as an intelligent guy with a big mind. He has the ability to remember, be curious and explore and get to know people. He is almost like a human. Thus, we first focused testing on the robot since we thought the intelligence was based on him. However, we found the intelligence was actually on the device application (after getting familiar with AI and the application using this test type). Basically, the robot is a collection of lights, motors, sensors and firmware running on processors. Firmware has the duty to communicate with the application via the robot's Wi-Fi (the robot acts as a Wi-Fi access point) to store data persistently, run motors, etc. Thus, once the firmware changes, we often focus testing on communication between the app and robot instead of the robot's behaviors only.
How long did the IoT testing process take, and do you have an idea of how many tests total were run?
Nguyen: Actually, this is a difficult question to answer. There are no written test cases for the above test types since they are techniques that are based on the experience of each tester to test the system. However, one certainty is that we often write test cases for test types called functional testing and smoke testing in which we apply the test case design techniques, such as equivalent partitioning, boundary analysis, constraint analysis, state transition and condition combination, to design test cases. Until now, the total number of test cases for the three games we tested is around 8,000 test cases. We combined all type tests, such as exploratory testing/ad-hoc testing, error guessing, stochastic testing, functional testing and smoke testing, during the testing phase to make sure we had maximum test coverage.
We often hear about automating software testing. This seems counter to that argument because, for so much of this IoT testing process, you needed human testers and lots of them working together. Can you expand on those thoughts?
Nguyen: Test automation is using computer time to execute tests. There are a lot of benefits of test automation, such as running the automated tests unattended (overnight), reliable repetitive testing, increasing speed in test execution, improving quality and increasing test coverage, reducing costs and time for regression testing, execution of tests that can't be done manually, performance testing to assess software stability, concurrency, scalability, etc.
We cannot apply automation testing for AI since it is just useful for stable systems with written test cases. Whereas AI behaviors are very complicated and random, so AI testing is more suited for manual execution. However, in our current project for Anki, we applied automation testing, which helped the team free up time.
For example, one week after a release, we often clean up crash reports on Jira that no longer happen on the latest release. Crashes are errors generated and sent to [the] server when players get crashed while playing game. These crashes are logged on Jira automatically. We created a bot to query crashes that no longer happen on the latest release in Jira, then add [a] comment and close them. Thousands of bugs are closed that way after every release [each] week, which help[s] manual tester[s] free up time. Another example is we often run unit tests to check basic functions when we have a new build to make sure the build is testable. This also saves time for us since we will not have to wait until manual testing to see if any function is broken because this function check process is already covered by unit testing. One final example is we run daily regression tests for the website where products of client[s] are sold. The website is quite stable now, but we need to run regression testing everyday (overnight) to make sure the website is working well since sometimes a developer makes minor changes on the website. This saves a lot of time as a manual tester cannot execute thousands of test cases every day.
Test Design Demystified
A long time ago…
If we go back in time, to about 120 years ago, people were riding around in horse wagons or carriages. Then suddenly, the horse were gone and replaced by an engine and a steering wheel. But all in all, it still looked like carriage. A horseless carriage, to be more specific.
Today, the cars we drive no longer look like those carriages. Although, in this horrendous Bay Area traffic, it might not be such a bad idea to take a horse carriage on a different route to work!
So how does the history of the automobile relate to software testing? Take a look at this infographic:
How good test design propels your automation
Automation is like the engine. It’s not as much of a technical challenge as it is a test design challenge.
Yes, occasionally there is a technical challenge. For example you might have a third party control on your screen that your test tool doesn’t quite understand. But ideally, that will hold you up for only a short amount of time. You fix the technical problem, and then you can quickly go back to your text design and focus on that instead.
Test design is not only important for quality, but it also helps your automation. Quality will be better and automation will be easier. There’s no reason not to pay attention to your test design. To learn more about test design and test automation, check out our resources section or peruse the LogiGear Magazine!