As curiosity arose, I decided to look on the net to see what I can find about screenshoting without a need for an app.  Sure enough I stumbled upon this article : http://alexsleat.co.uk/2011/11/28/how-to-take-screenshots-in-ice-cream-sandwich-android-4-0-x/

You press up up down down left right left right b a select start. Oh wait. that’s a Konami code.  In all seriousness, you hold down the Volume Down + Power Button for about a second for ICS devices.

Turns out that there’s other devices that can do this as well:

http://androidcommunity.com/samsung-galaxy-s-ii-built-in-screen-capture-no-root-required-20110514/

“Hold down the home and power button on the Samsung Galaxy SII.”

“The Droid Charge requires holding back, and hitting menu.”

I confirmed the Galaxy S II and Nexus tips.  I haven’t confirmed the Droid Charge, but I get the feeling that it’s correct.

Here’s some other tips and tricks that you can do on the Galaxy Nexus : http://www.gottabemobile.com/2011/12/15/10-neat-tricks-and-tips-for-the-samsung-galaxy-nexus-on-verizon/

I haven’t found anything in regards to device video cap on ics, but when I have time I guess I might end up playing around with that option + the dev option of tapping.

So one may ask… what am I looking at here?  It’s just Socorro stuff right?  Oh … it’s hotness.  This is a picture of a URL listing of a particular crash.  All URLs listed in a particular crash if you are logged in.  What does this mean?  It means that I can just paste in the URLs from this tab without having to go through each and every signature to look for the URL and put it in a bug….  You can’t imagine how much time it saves me to have this as a tool… granted I would have done this through command line of sshing and some other stuff to look at the raw files… but now I don’t have to.  In case you’re wondering, it’s bug 550538 – Provide easily-accessible list of URLs-for-signature to logged-in users

Another hotness is this :  Java crash signatures w/ address location should be pooled together as one crash signature… bug 726385 – replace 8 digit hex addresses with a placeholder within Java signatures.  It’s helpful to have it all in one signature.  It seems we need a little more work to combine some more signatures that are related and split apart the signatures that aren’t related; We are definitely getting there.

If it wasn’t for socorro we wouldn’t look like this for fennec beta 2:

That’s right!  Beta 2 is the bottom line for crashes per 100 ADU.  And we’re hoping that beta 3 will be even better!  So kudos to the Socorro team, though it may not be exactly perfect, it’s one of the best tools out there to help fight crashiness!

Without Socorro’s presence it would be hard to determine what crashes are most important.  With more people using fennec on a daily basis (Active Daily Users), and hitting crashes; we can see the sheer volume of crashes.  This helps raise the priority of which crashes should get the most attention first, and which ones we might be able to put off until we have the resources to fix it.  So please!  Make sure you update fennec version (whether it be nightly, aurora, beta, or release) to the latest and use it every day!

For logs, there is an app called alogcat ( https://play.google.com/store/apps/details?id=org.jtb.alogcat&hl=en )

that will allow you to share or save your logs after you hit the menu button.

As for taking screenshots, it’s gotten even easier than having to install android sdk.  There are free apps out there on the market such as screenshot ( https://play.google.com/store/apps/details?id=com.geeksoft.screenshot&hl=en ) as well as pay for screenshot capture apps that do not require root ( https://play.google.com/store/apps/details?id=com.edwardkim.android.screenshotitfullnoroot&hl=en )

Having mentioned these, I am not endorsing any apps one over the other… if you find a favorite one that shows/shares logs or screenshots, I say go for it!

What is s1/s2 testing?  It’s basically a startup testing for trying to measure throbber start/stop, and drawing end times.  Manual run instructions can be found here : https://etherpad.mozilla.org/fennec-perf-ts-take2  ( Side Note : I need to clean up the wiki here : https://wiki.mozilla.org/Mobile/Performance/S1S2-Tests)

The code for the test automation can be found here: https://github.com/ctalbert/xbrowserstartup

Blassey made a tool to specifically OOM fennec.

The indicator is circled in red.

Basically if a crash signature has an uptime of less than 1 minute for 50 % or more of it’s crashes, then it will show this new indicator.  Here’s a link to the crashes for 14.0a1 so you can see for yourself :

https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/14.0a1/7

Note: the strike thru bug numbers, indicate closed bugs, dev has been working hard in trying to close out the top crashing bugs.  The numbers are cumulative of all build versions of 14.0a1 within the past week that have crashed with a certain crash signature.  So basically… please please please update and update often before testing!

Thanks to kairo and chofmann; there are other ways to look at the data that is provided by Socorro.

Kairo has made an adjustment asked by the crashkill team to his original script that I had asked for earlier:

https://crash-analysis.mozilla.com/rkaiser/2012-04-01/2012-04-01.fennecandroid.nightly.devices.html

You’ll notice in the link, that it shows the crashes that a device has, with the number of crashes to the right.  If you continue to scroll, you will notice the devices that a crash has, with the number of crashes to the right.

This helps out in determining faster whether a crash is only happening on a certain device/chipset as well as which devices to try to reproduce the crashes with.

For more of kairo’s crash reports see : https://crash-analysis.mozilla.com/rkaiser/

Chofmann has his own sets of reports.  For example :

https://crash-analysis.mozilla.com/chofmann/20120404/mobile-central-crash-trend.csv

This shows the cumulative crashes of a version per day, so you can understand where the numbers are coming from in Socorro.

For more of chofmann’s reports see :

https://crash-analysis.mozilla.com/chofmann/

Testing does not require computer science knowledge; being a good tester doesn’t
require having computer science knowledge. What it does require is having a
scientific/methological mindset.  What I mean by that is understanding what and
how to keep certain variables/conditions constant while testing one by one each
variable/condition thoroughly. Some variables/conditions could be lumped in the
same tests, and to understand that requires a deeper understanding. Having the
same vocabulary as the developers helps with that and having a computer science
background of being able to read code and understand the developers/code gives a
huge advantage in being a tester. You do not need a degree in order to have a
computer science background, but it helps to prove that you do have one. It also
helps to have some experience in trying to program.  Why?  Because it helps you
understand where you might encounter bugs as a coder and understand where
certain weak points may be in code.

Side note: one of the best testers I know doesn’t have a computer science
degree, but had learned how to program on the side by himself.  He also has over
12 years of experience working on the same code base that he does QA on. One of
the things I noticed that a good QA person does is he does not assume; based on
what is said or done, he reports what occurs in the application by testing and
verifying the results.

When are the most critical paths that you have to worry about?  When you create,
add/insert, delete, destroy something.  Something can be anything, ie, an
object, a window, an array, a pointer, or a mutex.  This is something I noticed
back in college when I was trying to create various sort options such as
insertion sort, bubble sort, etc.  Classic Comp Sci programming of various
algorithms.  The biggest thing I noticed was when I made a mistake on how to
insert or delete a pointer… it could cause the program to blow up.  Worst was
when you were dealing with recursion and the operating system doesn’t have
memory management. [Pascal programming on Mac OS 8.6]  Nightmare.  That was in
high school. heh.

For example some of the testing that devs may miss is starting from a new
account.  Starting from a blank new slate and then running the application. You
may run into initialization issues at that point.

Simple cases may work, finding the harder bug requires a better understanding of
behind the actions and when things occur and how.

An example would be sync running and looking at the bookmarks section within
Native Fennec. Two different processes running, one adding items to the
database, one viewing the database. This is where 2 applications are looking at
the same file.  (Just a FYI that bug got fixed).

The more intimate the knowledge of how things works, the better your
understanding of where things could intertwine and muck up…. the better your
chances of finding critical bugs that causes crashes or otherwise.

1) Crashes that occur due to the Native UI which is caught by breakpad

2) Crashes that are caught by breakpad

3) Crashes that are caught by the OS but not breakpad

4) Crashes that neither breakpad nor the Android OS catches

In all of these cases, if you run into a crashing bug within fennec having a logcat helps out a lot.  For crashes that happen in Native UI, those java crash stacks do appear in the logcat.  In the other cases, it does help sometimes to see what the logcat is spewing during the time the crash is happening.  So please please please try to use logcat and attach it to the bug.  ( http://aaronmt.com/?p=503 or just as good is downloading alogcat.  Pro tip: To get timestamps use command line : adb logcat -v time )

So let’s go back to point 1.  So if you look at a crash now within Socorro that has a java crash :

https://crash-stats.mozilla.com/report/index/009e2d28-1fef-4b63-971c-efd782120217

You can see a new field that has the Java Stack!  Yes, thanks to the socorro team and cpeterson, esp lars, and laura.  That is hotness.

Point 2 is a matter of looking at Socorro.

Point 3/4 … if it’s released out in the Android Marketplace, there’s methods of getting the crashes from there.  Otherwise : http://www.jnchen.com/blog/2011/11/updated-gdb#the__comments  I haven’t tried to setup jimdb yet  There’s other methods for nonFennec related apps.  http://stackoverflow.com/questions/601503/how-do-i-obtain-crash-data-from-my-android-application

JimDB is probably going to be my second next project to look at leisurely at home.  Currently, I want to finish getting robocop up and running and getting tests in for robocop.

Our goal is to provide you with mobile news and guidance towards how and where you as a tester can help out!  Thanks for helping out; your input is greatly appreciated!

What’s New in Fennec Native UI this week?

• ADUs : Aurora -  1,229 (+12%) ; Nightly -  1,196 (+4%) ; Beta -  27,042 (+3%)
• This will be the last Weekly letter, please refer to the MTD newsletter for future news
• [mobiletestdrivers@mozilla.org; https://wiki.mozilla.org/Mobile/Testdrivers_Program]
• Please make sure that you are on the most current version: there are crash fixes in 2/1 as well as 1/19 build
• Features to look at now: https://wiki.mozilla.org/Fennec/NativeUI/NightlyFeatures

Nightly:

• concentration is currently more on beta readiness
• https://wiki.mozilla.org/Fennec/NativeUI/Showcase2-1

Aurora:

• stabilization concentration : Here are searches and stuff where people can help out!
• http://shizen008.wordpress.com/2012/01/24/war-on-crashes/#respond
• If you have any questions, please comment.
• Please see the testing areas, tips and tricks in how you can help!

What’s Coming up in Fennec:

• Sync Support
•  Split-APK; XUL for Tablets, Native for Phones
•  Profile migration
• From XUL to Native profile migration
• L10N
• Required for String Freeze for Fx11 (Jan 30th): query
•  Single-locale APKs
• Feb 27 2012: Public Announcement at Mobile World Congress
• March 30 2012: Final Release

How to download the latest Fennec Native UI build:

• Enable ‘Unknown sources’ in Settings | Application Settings on your Android device
• Go to: http://nightly.mozilla.org
• Click and download the Android installer under the mobile section

Testing Areas, Tips and Tricks:

• Please test on various devices that can run Fennec Native
• Head to your favorite sites and file bugs on sites that do not work or don’t meet your expectations
• Play with the bookmarking and recent visits as well as the session history (forward/backwards navigation)
• Download the Zippity Addon: http://people.mozilla.com/~mfinkle/fennec/addons/testharness-mobile.xpi and go to about:testharness to perform various tests
• Explore away with testing these features https://wiki.mozilla.org/Fennec/NativeUI/NightlyFeatures
• Use logcat and other tools to monitor your logs to help your bug reports.  There are options:
• You can install Android SDK such as : http://aaronmt.com/?p=503
• a system monitor tool such as : https://market.android.com/details?id=com.eolwral.osmonitor&hl=en
• or alogcat : https://market.android.com/details?id=org.jtb.alogcat&hl=en
• alogcat allows you to send your log elsewhere.
• Nightly builds now support Flash (on Android 2.3 and Android 2.2)
• Note: you will need to download and have installed the latest version of the Flash Player from the Android Market
• For more tips and tricks see : http://shizen008.wordpress.com/2012/01/22/exploratory-testing-crash-course-2/#respond

We want to hear from you!

• If you think you’ve discovered a bug, you have options:
• Discuss the issue in this email newsgroup
• you can file it in Bugzilla (http://bugzilla.mozilla.org) under the product: “Fennec Native”, or just follow this link: https://bugzilla.mozilla.org/enter_bug.cgi?product=Fennec%20Native.
• Newsgroup archive is available : https://mail.mozilla.org/pipermail/android-mobile-nightly-testers/
• Feel free to discuss issues you encountered in this email newsgroup!
• You can also feel free to message this mailing list if you have questions in regards to features: https://lists.mozilla.org/listinfo/dev-platforms-mobile
• Any feedback on the newsletter can go to: Naoki at nhirata@mozilla.com
• To subscribe :  please go to https://mail.mozilla.org/listinfo/android-mobile-nightly-testers

Regards,
The Mobile QA Team