I did a bugzilla search and started looking at the interesting bugs:

Bug 861397 – Automatic APN selection does not work for some mcc/mnc values
Bug 864798 – CostControl broken due to ICC MCC/MNC int to string change
Bug 835729 – B2G RIL: we shall update operator’s mcc/mnc first then longName / shortName
Bug 845629 – [Gaia] change mcc/mnc type from integer to string
Bug 828307 – B2G RIL: Change to store MNC/MCC values from integer to string

By looking at these bugs, I found that there’s a preference to store the last MCC/MNC values, that we changed some things from integer to strings (which helps for keeping the leading 0), that if we can’t detect the MCC, MNC, we fall back to using GPS (which is terribly slow and you have to be outside waiting 10 mins.. ), we also try to figure out the name of the operator based on the MCC/MNC  (which After doing some testing, does not necessarily mean carrier!)

I also learned that the follow apps use the MCC/MNC:
Browser
Cost Control
Marketplace
Settings

Finally the devs have made various test cases to test these :

Mocking Mobile connection testing:
unit test:
 apps/system/test/unit/mobile_operator_test.js
marionette test:
 dom/network/tests/marionette/test_mobile_networks.js
xpcshell test:
 dom/system/gonk/tests/test_ril_worker_icc.js

There’s still a bug in question :

Bug 824772 – PrixTel MVNO has mcc == 0 and mnc == 0 when reading data network info.
And I’m not sure we’re suppose to get the network operator, or the SIM carrier from this.  From what I understand of the code, it seems to be getting the network operator, not necessarily the carrier.

ie so if you’re using a German SIM card, and once the marketplace gets implemented to show this… and you go to the US with the same telecom.. you will get the US market not the German one.  Is what I’m gathering.

I think today, I stumbled upon a thought.  I think what measures a good qa’er is how far they are willing to go to chase down their curiosity.

It requires poster (ie you will have to run |sudo pip install poster|

you run it by |submit.py /path/to/files/*.dmp|

The submit.py script is found here : http://hg.mozilla.org/users/tmielczarek_mozilla.com/crashsubmit/file/04bad2ba2637

What it’s useful for?  Sometimes pending crashes aren’t submitted and if you could help us by submitting those, that would be awesome!  In B2G, you can find the crashes located in /data/b2g/mozilla/Crash Reports/pending

http://blogs.msdn.com/b/michkap/archive/2005/11/12/491274.aspx

Thought I would share.

http://www.brainyquote.com/quotes/authors/a/albert_einstein.html

Does this include the company?

Does this include any other company that’s involved on the project?

Wouldn’t it be beneficial to the project if we help people that’s within the community working on the project?

I do take the time out to help community members.  It makes me feel good knowing that the time I spend helping them will somehow improve the project.

“Less you have to maintain, the more you are free to do other things.”

The essence is that you are exploring each combination of things that you can do and map them as you go along… how they work, how they function.  Like any person that gets lost, it’s good to stop and ask for hints in terms of how things are built.  That helps you find bugs faster.

The more you know about how the architecture lies the more you can explore.  Ie if someone hands you a map, don’t you think you’ll be able to get to point B from A quicker?  So of course, asking the dev for more info will help.  Do you necessarily need it?  Eventually you can read the code and figure stuff out on your own, but that will take more time. So yes, I will ask dev questions because time is a limiting factor when you have a target dates… and that’s what I did during work weeks and such.  Sometimes they help me come up with more or better test cases, just from the discussion of their area and something I wasn’t aware of before talking to them.  So a QA doesn’t work in isolation from people, even though they can.

Better testing means breaking testing into areas, and sub areas, esp where things have changed in the code… and being able to go fine grain down the alley ways and hidden passages that the dev might help uncover.

I want to get away now from saying exploratory testing because it’s too vague… I suggest that we start using a more specific type of exploratory testing : Session based testing

I highly recommend please read about session based testing.  It’s a method that works for top bug finding testers.  I use a modified version of it:

http://en.wikipedia.org/wiki/Session-based_testing

30 minutes.  Tested a fix.  found 7 potential bugs.

If you want agile testing… there you go.

Now I just have check and verify they aren’t reported already… and file them if they aren’t…