You may be right. All of my experience is with operating systems and
firmware. We've always had a QA plan, but with slips in development
schedules (both software and hardware) the test or QA schedule is always
pushed up against the release date wall. I've never been part of a test
team or worked with a test team that didn't want as much time to test
the product as possible. The only time I've seen test teams not test
right up to the release date and beyond is when they need to move on to
the next product. Any issue found in house, even if it's the day after a
release, will be cheaper to fix than an issue that gets reported by a
customer. Note, this testing done at the very end is not feature
testing. It's regression and stress testing.
I know it seems like this is a trend, but I actually don't think it's
much different now than it was 20 years ago. The tough decisions and the
war rooms existed then just as they do today. It is getting harder
though as operating systems and products get more and more complicated.
The test matrix becomes larger and larger and impossible to cover
completely.
IMHO, the days of a water fall process, where you can thoroughly test
everything weeks before a product is released are behind us. We need to
realize how complicated things are to test and come up with new
methodologies and technologies to allow us to get products out quickly
while still ensuring quality. I think changes like Agile/Lean and
Continuous Integration/continuous Deployment (CICD) are steps in the
right direction. Unfortunately, this does make customers part of the
development and test process, which I know you don't agree with.
Hopefully, the trade off though is getting fixes to reported problems
out a lot more quickly.
I don't mean to argue or disagree with you. My intent is just to offer
another opinion and share some of my own experiences. IMHO, it's an
interesting and thought provoking discussion.
On 09/28/2013 01:18 PM, Cara Quinn wrote:
Hi Chris,
it's not always true that issues are being reported up to a release date. This
depends heavily on the type of software, the complexity of course, as well as
the corporate image / culture of the company doing the releasing.
I think delaying a release until after a clean QA period is completed is in
some sense, a luxury for larger companies but I think it's also a paradigm
worth pursuing. This is sort of the crux of what I'm saying. This may seem like
a luxury but to me at least, it's a necessity. -Or at least should be viewed as
such.
It may seem outdated in the kind of environment we're living in right now but I
do think it's helpful.
Oh, and just to add a bit to my earlier note about the idea of the general user
population being adopted as free beta testers, just let me add that, as I've
said many times before, the Apple staff who deal with developing VoiceOver and
deal with issues with it are (at least in my experience) very passionate about
what they do. They will not knowingly let accessibility issues go out unsolved
if they can possibly do anything about them. My note was just to say that I
feel there is a disturbing trend happening in the general software market.
Not saying this is necessarily intentional but I do feel that an early course
correction is helpful. :)
Again, just my thoughts and thanks for such a great thread!
Smiles,
Cara :)
On Sep 28, 2013, at 10:59 AM, Christopher Chaltain <chalt...@gmail.com> wrote:
Testers, both internal and beta, are testing right up to the release date.
Issues are being reported constantly, and that's even more true for something
as complicated as an operating system like IOS. I'm sure Apple is looking at
the list of open issues, ranking them by severity, and determining which ones
have to be resolved before the release date and which can be resolved later.
There's no way Apple, or any company, could get every reported issue at every
severity fixed before the release date. I agree things like customer
satisfaction is effected when issues are found in the field, but customer
satisfaction is also effected by constantly pushing out the release date.
Business decisions, like first to market, a big splash with marketing, lining
the OS release up with a hardware release and so on, also play into these
decisions. I think you're absolutely right that releasing on time is paramount.
Apple won't postpone revenue by delaying the release of IOS and a new set of
iPhones.
I know Apple pushed back their new phone releases from the summer to the fall a
few years ago, but I doubt this had to do with issues found in the software.
On 09/28/2013 11:08 AM, Cara Quinn wrote:
For myself, I take this to mean that rather than letting apps go out that had
'allowable issues' the releases would be held until all of the known issues
would be fixed, or at least it seemed that way. :)
Obviously there will always be situations that will come up that reveal bugs
but I do think the emphasis now is on releasing on a schedule rather than
releasing after all known issues are taken care of.
Just my thoughts…
thanks and have a great day!
Smiles,
Cara :)
On Sep 28, 2013, at 7:04 AM, Christopher Chaltain <chalt...@gmail.com> wrote:
I wonder what you mean by "How I long for the days when programs had to be tight and
debugging was completed before product release." I don't recall such days. I've been
using computers since the 80's, and I don't recall a time when programs didn't ship with
bugs. How many dot versions were there for DOS 3.0? Unless you're writing HelloWorld, or
have an infinite amount of time to review code and test, you always have had and you
always will have bugs, at least in programming as we know it today.
On 09/28/2013 03:15 AM, eric oyen wrote:
you know what? I have some cheese (extra sharp cheddar) to go with that whine.
:)
Normally, I don't post much as I am a fast learner. However, today I got
saddled with several problems demanding a priority all at the same time.
How I long for the days when programs had to be tight and debugging was
completed before product release.
-eric
On Sep 28, 2013, at 1:07 AM, BBS wrote:
It's kinda stupid that all I'm reading on this list is people crying about
Apple forcing people to upgrade to iOS7. Get over it. Seriously! If you don't
like how Apple does things, then go to Android. As for me, I love iOS7 and I
haven't ran into any of the bugs that people speak of on this list. My
Voiceover runs smoothly, I love the new Siri voices although I wish we could
use them with Voiceover, and I like how Voiceover is using the new Vocalizer
Expressive engine. I love iOS 7 and when Mavericks comes out next month for my
Mac I'll probably upgrade that too unless the rumors are true that I need 8
gigs of ram for it to run properly. And I know there will be bugs with that OS
but I'm not scared of bugs. Somewhat annoyed, but not scared. I think what I'm
trying to say is that there will be bugs on any OS on any device. Our job is to
find them and report them to Apple Accessibility right away.
Shawn
--
Christopher (CJ)
chaltain at Gmail
--
You received this message because you are subscribed to the "VIPhone" Google
Group.
Post a new message to VIPhone by emailing viphone@googlegroups.com.
Search and view the VIPhone archives by visiting
http://www.mail-archive.com/viphone@googlegroups.com/.
Reach the VIPhone owner and moderators by emailing
viphone+ow...@googlegroups.com.
Unsubscribe and leave VIPhone by emailing viphone+unsubscr...@googlegroups.com.
More VIPhone group options can be found by visiting
http://groups.google.com/group/viphone?hl=en.
---
You received this message because you are subscribed to the Google Groups "VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to viphone+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
