This may be culture-specific, but from my point of view, you’re asking for someone to work for free. The interview should be the interview; you don’t ask someone to do more work after the interview. And from your point of view, how do you know you can trust that the person in question was the one who did the homework? If you want them to do some live ...
IMO, your interview process shows that your company doesn't really understand QA to begin with.
QA has specific goals. It isn't "sit here with our software for x hours and figure things out". It needs to be clearly categorized, and there should be a pass/fail list of objectives.
Your scenario is unrealistic, because there is no way to ever finish. At ...
You know, the funny thing is, this almost became a good interview tool.
If I walked in to a QA interview, and the interviewer said, "By the way, when you're done, we'd like you to bug-hunt our production product when you go home," my first thought would be: You clearly don't care about your QA programmers (Why would you? If you feel you can get random ...
Your boss doesn't want a flat "No" or to hear their request is impractical.
They want to reduce the risk of releasing changes to the application.
Make your boss choose your priorities, that is one of the roles of a manager.
Add scenarios based on team knowledge and work with your boss to rank them by risk.
Implement top priority scenarios
Go back to ...
John Ruberto wrote an article some years ago on Stickyminds entitled, "Is 100% Unit Test Coverage Enough?". The article can be found here:
In it he presents the argument that there are different kinds of coverage. One could cover 100% of requirements, but that doesn't include ...
And as a homework we have asked to test the game and find critical bugs
No, no, no.
It is not your place to give "homework" from a job interview, least of all "homework" that involves doing your job for you for free.
Nothing related to the core gameplay, and nothing really critical.
I'm not surprised — you put in place no structure. No ...
There are a number of tools available for testing mobile apps:
But my experience -I can suggest you Appium is the best tool for both Android & iOS mobile testing.
I'm working on Appium from last 6 months in my organization it is pretty good.
The main advantages of using Appium is-
I think it's a good practice to give some demo Game & ask the tester to find some bugs in the game it helps to figure out these basic qualities of the candidate like.
Decision making capability (Bug or not)
Attention to details (Instruction sheet)
Efficiency of the candidate
Focus on random application (Layman approach)
It's always good to use numbers to make your point-
There are N models and sub models of iPhones (for some applications you should also count the phone's network sub-type), each with M available iOS versions and sub versions (this is not entirely accurate, some models and iOS versions don't work together, but never mind that now)
Older iOS versions needs ...
The main differences between Appium and AndroidDriver/iPhoneDriver are architectural.
The AndroidDriver/iPhoneDriver work the same basic way - they are applications you launch on the phone that create a webview that you can remote control with selenium. The limitations to this approach are:
No control over hardware/operating system.
Webviews are not a real ...
My personal experience is with testing iOS devices so I can only refer to those. Your question is broken up into three separate parts so I will answer each of those in turn.
I'm thinking along the lines of a Firebug for the
iPhone/iPad/Android/BB that can truly give more insight on the
This is supported in iOS6 by enabling the "...
Actually this is a good testing question because you are evaluating the client/server functionality between a device and a cloud service, and how the mobile client behaves when it changes from one state (eg logged on in cloud w/connection) to another state (logged on with no connection).
If the user is "offline" (e.g. changes to airplane mode) or has lost ...
Some ideas for the GPS part, based on my experience testing GPS's:
Do field tests, and choose you locations wisely- from totally open skies to crowded tall buildings with limited to no GPS reception, from standing still to driving slow and fast, change heights during the tests (GPS is less accurate in reporting heights), choose different times of day, ...
• For Android
Lockito application should work for you.
It allows to emulate movement from one location to another one.
You can set the speed, the route is based on Google Maps.
• For iOS
There are at least 2 approaches:
use Xcode with GPX files
Here's good article on this. Also there is a script to generate GPX files with routes.
or add location spoofing ...
First of all, you need to know how to connect your mobile phone with Charles proxy.
Here are the quick and easy steps to set this up (I am using iPhone, but you can also connect android devices using step in this post: Debugging HTTP on an Android phone or tablet with Charles proxy for fun and profit.
Make sure that your iOS device and your laptop are ...
Do we have to test on emulators or a real devices for testing mobile
Why not both?
Some functionality of mobile applications can be well-tested on emulators. Often this mean UI, basic features, etc.
Other features may require real devices, particularly if you have device-specific functionality, or functionality that takes advantage of ...
I think it works better if you use an application that you know has issues as that helps you see if people find the deep issues or only the shallow ones.
I for instance use applications that I got from the RST training with Michael Bolton.
It also helps if you ask yourself what you would expect beforehand when they do a challenge like this. For me, in ...
I would recommend staying with your web solution, and modifying for mobile. There are plenty of tutorials on how to capture mobile traffic through fiddler on the net.
Eric Lawrence wrote a blog post about how to do this last december.
Depending on your company, this may require additional effort dealing with infrastructure departments to ensure that you ...
Top tools for testing mobile apps:
Appium: Appium is an open-source tool for automating native, mobile web, and hybrid applications on iOS and Android platforms. Appium is "cross-platform": it allows you to write tests against multiple platforms (iOS, Android), using the same API. This enables code reuse between iOS and Android testsuites.
Here's a few ideas I can think of:
Can you connect the device via wi-fi and then kill the network?
If you have access to the web server, can you turn it off from the other end so the app on the device doesn't get responses for a while, then turn it back on?
Can you change the phone settings to use airplane mode?
You can use adb to get battery consumption of your app by
adb shell dumpsys batterystats [your.package.name]
The result is very detail, so you may need to use grep to fine grain information you want and then import result into your continuous integration.
If you only need to know an over view of battery usage for all your tests in a controlled ...
The platform that need to be supported are:
iOS, Android, Windows Mobile, Windows Phone
— For your needs you can use SeeTest, EggPlant, Ranorex, Borland Silk Mobile — but they all are commercial solutions, most have free trial.
SeeTest is quite popular at the moment and has very positive feedback. Another good one is EggPlant as I know.
Use a variable attenuator between your device and AP, there are manual and controllable models and it's relatively cheap.
You'll have to connect it to the Wi Fi antennas using an RF cable , or put your device into an RF insulated box, which in turn is connected to the attenuator.
Your application probably doesn't see the signal strength reports directly, you ...
If it's a mobile application, presumably you have the handset to test it on (my old mobile shop had every handset in-house...quite an inventory). You should physically move around to get varying WiFi signal strengths.
If you don't want to use your feet, you can begin wrapping aluminum foil around the handset until the signal dies down, or throw it in a ...
Firstly you need to become a member of Apple's developer program, and understand how in app purchase works. As a starting point you should look to Apple's documentation here: https://developer.apple.com/in-app-purchase/.
Apple provides sandbox environments to facilitate testing, and it is all covered in the documents and past WWDC sessions.
Once you ...
You could to create a Test-specific build which stubs the input GPS data. By having a data-input interface (in code) you could have fake GPS information fed in - I'm not sure what the data is or how it will look, but whoever developed the application should be able to engineer this.
While this is going to be a build which is never to be released to ...
While working on several projects I've described the following procedure to install Appium:
Download Android SDK
Extract Android SDK to /usr/local/adt/
unzip -qo adt-bundle-*.zip -d /usr/local/adt
Set ANDROID_HOME and JAVA_HOME environment variables
Although i do not have much idea about it but i think you can give selenium grid a try. I read on seleniumhq.org that with selenium grid you can create a master slave architecture, where one master machine will control several slaves to send request to a common server. Maybe this can help solve your issue!
You could try Applausse the testing services based on their tester network from UTest, I have done some cross-browser and mobile app testing for them.
They offer scripted testcases and exploratory sessions where you pay per found issue.
Amazon Mechanical Turk
With Amazon Mechanical Turk you can define small work loads. Like install and do some ...
Do we have to test on emulators or a real devices for testing mobile
I agree with "Joe Strazzere on this point, that one should go for both Emulators and Device testing as per the process and that too first test on Emulators and then on actual devices. But I would like to add few more relevant points to the answer.
Whether you should go for ...