“26th Day of June 2019. Our pilot date will be on the 29th of July 😀 then our UAT dates would be on the 8th day of July. It’s crunch time!”
These phrases are very familiar and common to most of the development team. The agony of a tester waiting for all the services/app to be deployed so we could test it thoroughly, the bouncing back of bugs to the dev and tester, and all the arguments about who has to do testing.. and of course, last but not the least, the ego.
I am the only QA in the team of 6 developers, and I could feel the pressure of making sure the app we deliver is top caliber quality app. I am developing all the test cases for the upcoming UAT and my integration tests – my integration test is actually 1 week!!
I easily get bored and while being bored, I went thru our slack community channel which is the Techwell Hub. Someone had to ask about how to create a portfolio for QAs – and yes, I wonder how that works too because we don’t usually develop and use GitHub (automation testers say otherwise). I will get into the automation testing phase later on but in the meantime, I guess it is time to go back to basics and apply it to our everyday tasks. This blog can be a black boxy type but hey, black box testing is neither good or bad :).
The app that I am currently testing is a mobile app created around a patient’s everyday events. The parent, or legal guardian, has the ability to see a patient’s clinical appointments, travel itineraries, housing reservations, housing events, and resources about their journey in our Children’s Cancer Research Hospital. There is also an embedded Wayfinding app that would allow patients and parents to navigate our campus without getting lost. I thought that the app is pretty cool! Our hospital offers all these for free! We accept and use donations. The company I am working for is a non-profit so it feels great to work for something that has a mission.
I’ll use this platform to document every testing that I had been doing and tools that I had been using, to comply with the 30 day Mobile Testing Challenge.
Note: I had already set up my early stages of mobile app testing framework. I wrote my codes in C# and used Appium libraries to mimic user’s action – it works like that of Selenium but in a mobile environment. I am not currently using it as it needs more refactoring but I will discuss this topic in a separate blog. I am doing more manual testing and test strategy at the moment.
Day 1: Take a photo of your mobile testing lab
This is a partial part of my desk. I have my MacBook Pro, two mobile devices – iPhone 8 and Samsung Galaxy.
The tools I currently use:
- Vysor – for mirroring android mobile phone screen. Users can manipulate the phone’s actions thru desktop. It is free! Check it out here: https://www.vysor.io/. Cons: It can’t record user’s actions :(.
- Quicktime – this is only available for MAC OSes. Connect your iPhone and click New Movie Recording. Cons: It can’t be used in Windows.
- DU Recorder – for recording your actions on the phone. Be careful with your potty mouth on this as it could record your audio. It is free. Download it thru Google Play and App Store.
- Postman – the common tool to check for web services and the backend.
- Azure CosmosDB – our database. The data that is being displayed is called collections. They are written in JSON so they’re easy and fast to retrieve. We can write a simple select query to find the data that we are looking for.
- The ‘ole Microsoft SQL Server – again for our database. Most of our integrated systems go here first, then, it goes to Azure cosmosDB to the phone.
- Microsoft Azure – where all the magic happens 🙂 it is the Disneyland of the phone.
My mobile testing lab consists of real devices plus emulators and simulators. If you are planning to use emulators and simulators, make sure you have access to the code (for simulators) and .apk files for emulators.
If you want to learn more about automation testing in Mobile, I have written my experiences so far here:
- Configuring Appium environment for real iOS devices: https://medium.com/@marjorieivy/configuring-appium-environment-for-ios-real-device-310c7bc863e4
- POSTMAN basics: https://medium.com/@marjorieivy/api-testing-using-postman-basics-3b1abf7eee74
Day 2: Use a Proxy Tool, for example, Charles Proxy, to intercept the traffic between the app and the back end. For Example, check the calls for encryption and describe your findings.
I use Fiddler most of the time to intercept traffic between the app and the backend. In the meantime, I don’t know how to make it work with MacOS and iPhone, instead, I used CharlesProxy. Charles Proxy is not free, unlike Fiddler. Charles Proxy though is easier to set up with MacOS and iPhone. All you need to do is find your IP address and configure your HTTP Proxy into manual. Enter the IP address on where the Charles proxy resides, then enter 8888 as the port. Then capture the traffic from Charles proxy.
We have seen an issue where a message SSL error has occurred and a secure connection to the server cannot be made. So I went on to check it in Charles Proxy and see what is going on with the connection. I am seeing that our app connects to a third party connection, but all of our ports are open. I can successfully connect to the website using the Safari browser but I can’t on our app’s webview. Turns out that the TLS certificate of our third-party app is not updated :). A little Stackoverflow research sometimes goes ways.
Day 3: Perform a mobile security test
Our app is using B2C login – it is a cloud identity management solution by Microsoft’s Azure. If you are familiar with Active Directory, then B2C sort of works like that but this does multi-factor authentication with minimal configuration. Our mobile app asks for an email address/Password. Once the app and our back end say, you’ve found, then we’ll send you a verification code via SMS. After that, the user is prompted to enter the setup Passcode. Then, the user is logged in.
Day 4: Share a mobile testing blog post with a mobile developer or designer
We have gone through almost all testing tutorials in Pluralsight. I myself have designed my test cases using Mobile Apps Testing: Sample Test Cases and Test Scenarios.
Our testing is not automated – well, except for Unit tests which are automated. We are using Azure DevOps to make automation possible. I am very disappointed that we could not set up anything free with Azure DevOps for testing. It had us require using AppCenter (any QA who says otherwise, please let me know, I am very open with ideas). AppCenter is not a cheapo but you have to pay according to the plans. The configuration is easy. We are working with someone who told us that they would automate the tests but sadly due to time constraints, they thought automation is not helpful.
Day 5: Use the android monkey provided in the Android SDK to send random commands to your Android app and describe your findings.
Well, this is not applicable at the moment of testing. I am an android person and of course due to the nature of the job, you can’t side on one side only. So I had to immerse myself with iOS and Mac world – which is so foreign to me! Right now I had the luxury to use Xcode and its tools to do something with an app. In the meantime, I have not been given rights to the swift codes yet.
momwhocodes.wordpress.com 
One Comment Add yours