For QA in an agile development team, SPEED is everything. It is a game on a high-speed roundabout, developers introduce new features and fixes every day, and you better test everything before the next iteration. Besides the new features or fixes, you still need to handle a full UI regression smoke test, how is that possible? Hire more staff? Test automation is a way out for smart teams, and that’s what we do at Oursky.
The basic aim of Test Automation is to replace repetitive human work with computers.
So, to get started, all you need to do is no more than wrapping up your existing test plans, and to decide which parts are to be automated. If you already have a comprehensive test plan, with step-by-step test cases and well-defined expected results, congratulations! You are perfectly ready for automation.
Or else, some preparation are needed.
Get crash reports from Sentry
We have been using Sentry for collecting crash reports and stack traces for our front-end js, Python, and Rails applications. It is reliable with affordable pricing. Simple to setup with it’s open-source SDK.
However, there’s a fundamental problem when it comes to iOS.
What? No symbolized data returned?
Sentry only returns the crash report with a piece of memory address but not a meaningful method name.
As an iOS developers, you should have noticed that it requires a dSYM file to symbolize the stack trace. It helps to identify these addresses with the appropriate dSYM file.
We thought we can upload dsym files and get symbolized information returned when Sentry claims it works on iOS.
Unfortunately, it is not the case:
No one can understand the iOS Stack trace with memory address only. Proper support of dSym is needed.
(BTW if you can debug with memory address, please consider joining us.)
One of the possible solutions is to fork a piece of Sentry code and get our hands on it, but we don’t want to get into the complexity.
Instead, we write a micro service that will reply to a Sentry notification with de-symbolized stack trace on Slack, here is what we did.
As mentioned in our previous post, at Oursky, we use Travis CI to build, test and automatically deploy our software applications. While the command line control has been super developer-friendly, we should also care about the feelings of less technical roles in the team, say PM, QA, and Designers. 🙂
Hence, we introduced Chima and Faseng, both are bots to assist the deployment process. (For cats in our office, see this post.)
What is ChatOps?
We learnt about this from GitHub — its open source chat bot (Hubot) for ops: automating deployment, graphing, monitoring, provisioning, tweeting, and many other things.