jbs06civicsi said:Just after the newly released BETA 5 Apple announces that they will drop BETA 6 on the 17th. Just an FYI.....
Sometimes I wonder why don't they just do everything that they need to improve on before they let it out. I mean they have their own judgement.
Skull One said:The answer to that question is rather long. But I'll give you the short version.
iOS is a mulit-million line Operating System that has to be compiled for the following hardware: iPhone 3GS GSM, iPhone 4 GSM, iPhone 4 CDMA, iPad 2 WiFi, iPad 2 GSM/WiFi, iPad 2 CDMA/WiFi, iPod Touch 4th Gen, iPhone 5 GSM, iPhone 5 CDMA, iPad 3.
That means they need to be able to test every application currently on the Market against every WiFi configuration, every screen resolution, every cell phone carrier, every memory configuration, every CPU clock speed, etc, etc and etc....
Just that list alone results in trillions of combinations that need to be tested. The staffing required to test would be in the tens of thousands. That would be very cost prohibitive. Their solution is simple, they release it to us developers and we can help find the issues. Since we do have a vested interest in the success of iOS 5.
Since every iOS developer is under an NDA there should be no news what-so-ever concerning the status of iOS 5. But the reality is, some people don't care what they signed or the consequences of their actions. Personally, I abide by the NDA, which is why I have not posted a single sentence since I have switched to it.
Jani said:17th? August? September?
Edit: Nevermind...found it. 17th of august. .)
Google is my friend.
Skull One said:As an after thought, I would like to provide one other insight into the process.
Many developers categorize software issues into several buckets. The top 3 are usually:
1) Hardware/Software crash.
2) Software produces unexpected results.
3) Users perception of how to use the software produces unexpected results.
The reason Apple only wants Developers to test Beta versions of iOS is because we have the ability to list which bucket a bug belongs in and a gauge of the severity. It also helps that we have the ability to type up the steps needed to reproduce the issue. Or at least provide the scenario that produced the issue. Those insights are very critical to tracking down the nastiest bugs.
Now the funny thing is, I listed the bugs in the order of easiest to hardest in terms of troubleshooting. That's right, software crashes are simple to troubleshoot compared to user perception issues that create unexpected results.
When I code a new module for an application I have a simple five step process for testing when it comes to input and output.
1) No data.
2) Partial data.
3) Expected data.
4) Corrupted data.
5) Unexpected data.
The first 3 are easy to generate and test. The 4th is a tad harder but usually has to do with over/under flowing of data. But the 5th one is the nightmare. A user types in something that seems 100% legit to them but your program didn't account for it.
Let me give you a real world example to help explain.
I have a multi-million line code base that is used in the HVA/C industry. I have users in several countries. I decided to create a new Date Widget that would allow the user to type in the date or hit enter in input box to bring up a simple widget. It worked perfectly in "standard windows configuration" but failed under a condition I never thought to test, my case 5. A user always has to set his Calendar date input format when installing Windows. My program reads this setting directly from Windows at input screen instantiation. At the time that makes perfect logical sense. Except when a French Canadian user decides that he needs output a quote from my program in US Dollars just once. So he goes into windows setting to adjust the display from 1.000,00 to 1,000.00. Normally that would be no big deal but he also thought he had to adjust the date format as well. He adjusted Windows while the data input screen, with that widget, was open and waiting for input. He then typed in the date of 09/24/2010. The program suddenly crashed. Since my program, when it relaunches, auto recovers the users information, suddenly everything was fine and the program behaved as expected. UNTIL... He did the same thing in reverse. He started a job, got to that screen and remembered "I have to switch back to my normal currency and date". He does so, types in 24/09/2010 and BAM another crash. He then calls me for tech support because the program has now crashed twice in the same place and it shouldn't be. Most of the programmers reading this have already figured out what happened because I gave away the clue early on to the actual failure. Because I set the preference in the Widget at the time the screen was created, the computer saw the wrong date format and barfed. Basically I tested to see if the data was nn/nn/nnnn. Since that test passed, I then tested to see if the nn were within range. But I had taken a short cut and only tested for 1 to 31 on both of the first two numbers. Big mistake. Because when I fed the date to the widget it barfed because I had set the format BEFORE Windows had been changed. Feeding the day of 24 to a month parameter caused a crash of "Illegal Date" and because I wasn't expecting an error there I treated it as an unrecoverable error. Took me the better part of 4 hours looking over the two error logs and interviewing the user for 45 minutes to piece it together. The fix was dirt simple. Move part of the setup code to the validation of the data. That way the users could switch date formatting at will.
Just imagine how many issues like this they have to deal with considering how many languages and regions the iPhone is going to be deployed to in the next year alone.
RickyWithoutTheRoss said:When is iOS 5 coming out
When is iOS 5 coming out