Looking for companies offering certifications
Rex King
Can anyone point me to recommendations for software certification
courses, and if possible the links to respective websites?
Specifically I'm interested in the following areas:
-Software testing
-Project management
-Configuration mgmt
-Estimation
-Risk mgmt
-Measurement
-Software sizing
Thanks
Phlip
What would the intent of all these certs be?
Some of them are too nebulous to support certification.
If the intent is employment, what company gives a darn about any of those
certs?
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Rex King
offers certifications as well, was asked to prepare this list.
John Christopher
: Can anyone point me to recommendations for software certification
: courses, and if possible the links to respective websites?
Offhand, only two come to mind. There is Learning Tree, and, although they do not
provide direct certification, there are some preparatory courses for the
IEEE CSDP.
John Christopher
David
Rex,
alt.comp.project-management, or one of the other forums I read with
project in the name, has recently discussed a few project management
guidelines and I believe certification and education for their methods.
There are many government (USA) and ISO guidelines and related
education/certification that are cropping up. I can't offer any
specifics though.
The few I've tried to read cover the topics I'd expect in a MBA
or engineering course. To require certification in such areas
hasn't been an issue for the people or companies I've worked with.
A few of the USA government regulations could change that though.
David
Kathy Johnson
candidates can't get interviews with one. Who brain washed employers
into this? I believe the brokers and some companies wanting to make
money strectching out the courses days and days of training.
I work at The Testing Center and we offer Certificates for each software
testing course to anyone who passes the final exam. To my surprise lots
of folks don't want the Certifice.
Please take a look at our sample lessons and more at www.testingcenter.com
Let me know what you think.
Kathy J.
Phlip
> I agree with you about Certification. It has gotten silly to the point
> candidates can't get interviews with one. Who brain washed employers
> into this? I believe the brokers and some companies wanting to make
> money strectching out the courses days and days of training.
Who brainwashed doctors to wash their hands every few minutes. What an
obsessive compulsion! ;-)
> Please take a look at our sample lessons and more at www.testingcenter.com
Do they cover writing tests before writing the tested code?
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Bradley K. Sherman
I think you'd get a bit more credibility if you'd stop top-posting.
--bks
Does It Matter
> I agree with you about Certification. It has gotten silly to the point
> candidates can't get interviews with one. Who brain washed employers
> into this? I believe the brokers and some companies wanting to make
> money strectching out the courses days and days of training.
There is an old saying, "those who can do, those who can't teach." I know
this is not always true. The reality is that those who try to test for a
living and fail will sometimes go into teaching. This doesn't mean people
who are successful at testing don't also go into teaching.
The sad thing is that if you get a few people taught by a bad teacher it
will taint how you feel about certification. A lot of students will also
want the quick route to a job. If given the choice of a school that will
teach them what they really need to know about testing but it will be a
long and hard road or a school that will teach them enough to pass the
interview and not enough to do the job, some students will go for the
latter.
My personal experience has been that ALL the people, with some sort of
certification, I interviewed for testing could talk a good talk but could
not walk a good walk. I learned how to interview these people to catch the
people prepped for the interview but not for the job. I'm guessing a less
technical interviewer might just notice the pattern of "certification ==
sounds good, works bad" and just not interview these people.
> I work at The Testing Center and we offer Certificates for each software
> testing course to anyone who passes the final exam. To my surprise lots
> of folks don't want the Certifice.
>
> Please take a look at our sample lessons and more at www.testingcenter.com
>
> Let me know what you think.
I looked at the web site and it looks good. The web site is more about
substance and less about looks. This gives me a warm and fuzzy feeling.
Also, if employers are gun shy about people with certification then it
would bode well to give people the neccessary training and not the piece
of paper. At the end of the course, if you gave me the necessary training
to do a good job, what does it matter if I have the certification or not?
> Kathy J.
> Rex King wrote:
> > Well..you could say market intelligence! I work for a company that
> > offers certifications as well, was asked to prepare this list.
> >
> > Phlip wrote:
> >
> >>Rex King wrote:
> >>
> >>
> >>>Can anyone point me to recommendations for software certification
> >>>courses, and if possible the links to respective websites?
> >>>Specifically I'm interested in the following areas:
> >>>-Software testing
> >>>-Project management
> >>>-Configuration mgmt
> >>>-Estimation
> >>>-Risk mgmt
> >>>-Measurement
> >>>-Software sizing
> >>
> >>What would the intent of all these certs be?
> >>
> >>Some of them are too nebulous to support certification.
> >>
> >>If the intent is employment, what company gives a darn about any of
> >
> > those
> >
> >>certs?
> >>
> >>--
> >> Phlip
> >>
> >
> > http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
> >
>
>
--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vice.pr...@whitehouse.gov
David Lightstone
"Phlip" <phli...@yahoo.com> wrote in message
news:nx__c.1366$Q4....@newssvr15.news.prodigy.com...
> Kathy Johnson wrote:
>
> > I agree with you about Certification. It has gotten silly to the point
> > candidates can't get interviews with one. Who brain washed employers
> > into this? I believe the brokers and some companies wanting to make
> > money strectching out the courses days and days of training.
>
> Who brainwashed doctors to wash their hands every few minutes. What an
> obsessive compulsion! ;-)
>
> > Please take a look at our sample lessons and more at
www.testingcenter.com
>
> Do they cover writing tests before writing the tested code?
Nice troll, Phlip. Now id only someone will take the bait.
>
> --
> Phlip
> http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
>
>
Nick Landsberg
> "Phlip" <phli...@yahoo.com> wrote in message
> news:nx__c.1366$Q4....@newssvr15.news.prodigy.com...
>
>>Kathy Johnson wrote:
>>
>>
>>>I agree with you about Certification. It has gotten silly to the point
>>>candidates can't get interviews with one. Who brain washed employers
>>>into this? I believe the brokers and some companies wanting to make
>>>money strectching out the courses days and days of training.
>>
>>Who brainwashed doctors to wash their hands every few minutes. What an
>>obsessive compulsion! ;-)
>>
>>
>>>Please take a look at our sample lessons and more at
>
> www.testingcenter.com
>
>>Do they cover writing tests before writing the tested code?
>
>
>
> Nice troll, Phlip. Now id only someone will take the bait.
>
>
Let me take the bait, because I don't really understand
this particular aspect of TDD ...
Background: I'm the "performance guy" on a lot of
projects. Performance can mean "delay" (in the case
of user-PC's) or it can mean throughput (in the case
of servers).
As I understand TDD, you develop a test to show that
"it" does not work, then you write some code to now show
that "it" does work. Repeat until the whole ball of wax
works. (Simplification, I agree, but that's what I've
heard in this forum).
As the "performance guy" on many projects, I dole out
"budgets" for the server side. These are typically of
the form of "you have about 500 microseconds of CPU time to
perform this function, and you may not use more than
4 disk I/O's to do it." (That's for real folks,
and it's based on requirements and simple arithmetic.)
Now, could someone please explain to me where
I don't understand how TDD applies to
the following scenario:
Developer A writes a test for a function as per
TDD. It fails the functionality test (as it should¡)
but passes the performance test, because it
took less than a nanosecond to fail. (Yes,
I can measure that. Run it 100,000+ times
and see the CPU usage.)
As more and more "features" are added to the
test rig, the function takes more and more
time. Assuming the developer actually measured
the server-side performance, at some point it
will likely exceed the budget which was provided
for it. (500 microseconds and/or 4 disk I/O's,
and if you haven't been exposed to that kind of
requirement, then, welcome to the world of
pseudo-real-time systems.)
What do you do now?
This is not a flame. It is a serious question.
(General platitudes will not be accepted as
serious arguments. e.g. "get a faster processor"
is a platitude.)
NPL
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Phlip
> What do you do now?
You take the time that you would have spent chasing and fixing bugs in your
database or GUI layer, and you devote that time to whatever you would have
done to address those problems you wrote about.
(Also, something about your posts makes my feeb Outlook Express skip reply
ticks. You might have the wrong language turned on. But I would have snipped
those lines anyway.)
> This is not a flame. It is a serious question.
Jay Bazuzi <jay...@microsoft.com> wrote this on the TDD mailing list
recently:
> Types of bugs I don't know how to write unit tests for:
>
> - Security
> - Performance
> - Multi-Threading
> - Usability
Concurrency, security, real-time, usability; all are not test-firstable.
Since the majority of programming occurs between those things, use TDD to
get that part of the project out of the way.
For each detail of those problems, there is a way to introduce testing. For
example, in real-time, you could simulate a CPU - just a little bit - and
let it pass the test if the production code called its hardware registers
correctly.
This stuff leads to test-first as the test side of a project fills up with
useful methods. However, no one component of your process - not even TDD -
will solve every problem.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Nick Landsberg
>
> Concurrency, security, real-time, usability; all are not test-firstable.
> Since the majority of programming occurs between those things, use TDD to
> get that part of the project out of the way.
>
> For each detail of those problems, there is a way to introduce testing. For
> example, in real-time, you could simulate a CPU - just a little bit - and
> let it pass the test if the production code called its hardware registers
> correctly.
>
> This stuff leads to test-first as the test side of a project fills up with
> useful methods. However, no one component of your process - not even TDD -
> will solve every problem.
>
With that I will wholeheartedly agree. ("No one component
of your process ... will solve every problem.")
What I had philosophical objections to was that
previous posts by proponents of TDD seemed to
imply that it would solve all problems. I'm glad
you clarified that, thanks.
It seems that what you are saying is that that TDD
is specific to the functional aspects of the application,
but does not address the "supra"-functional aspects,
i.e. -
> - Security
> - Performance
> - Multi-Threading
> - Usability
Now... how would you propose that methods like TDD
be applied these aspects? (Serious question.)
I don't propose to *not* use TDD because of these
shortcomings, but would like to see it enhanced
to take these into account. How???
Phlip
> What I had philosophical objections to was that
> previous posts by proponents of TDD seemed to
> imply that it would solve all problems. I'm glad
> you clarified that, thanks.
Oookay. Then I come at the same point from a different direction.
If you accept the responsibility to write a line of test that forces every
line of code you need to exist, then you accept the responsibility to
perform sufficient research into your space to learn how to know its needs
cold, without resorting to guessing.
For example, 3d graphics did not appear on the list. But I want to
test-first that an OpenGL image contains a T, with a vertical tube and two
arms sticking out at the top.
This is a sadistically hard problem, because OpenGL was written from scratch
to move data in one direction only - from the source code into the display
hardware. From OpenGL's point of view, asking "what did I just tell you to
paint?" is an absurd non-sequitur. 3d programs optimize when the high-level
logic knows exactly what it told OpenGL to paint.
If test-infected programmers had invented OpenGL, it would be just as fast,
but it would be sparklingly easy to TDD. Some spaces are, indeed, harder to
TDD, even from scratch. But every little bit of effort to learn how is
itself a useful kind of research.
> It seems that what you are saying is that that TDD
> is specific to the functional aspects of the application,
> but does not address the "supra"-functional aspects,
> i.e. -
>
> > - Security
> > - Performance
> > - Multi-Threading
> > - Usability
>
> Now... how would you propose that methods like TDD
> be applied these aspects? (Serious question.)
By using TDD to implementing the existing algorithms known to address those
things.
The distinction here is between algorithm generation and program
architecture. TDD rapidly solves the latter and resists bugs as a
side-effect.
If you use TDD to try to generate a new algorithm, you are performing
computer science, not software engineering, and all bets are off. TDD works
well on program architecture because TDD makes a process insensitive to
initial conditions. Programmers can accept feature requests in any order.
Designing means reconciling conflicting constraints, and incremental
reconciliation via real code and real tests is the best way yet discovered
to do that.
However, TDD used to generate algorithms is extraordinarily sensitive to
initial conditions. Early refactors, following the "merge duplication"
rules, can lead to code that obscures, not reveals, a more powerful
algorithm later.
Anyone who thinks of a generic algorithm generator is going to be a
trillionaire. TDD is a very good approach, but it's as risky as any other
technique. You won't get bugs, but you might not get a good algorithm.
If I were to implement a given algorithm via TDD, I would look it up in one
of Sedgewick's algorithm books. Then I would start with the simplest
scenario, write a simple test, and write simple code to pass the test. Then
I'd write the next most simplest test, pass it, and refactor the code
towards, not away from, the solution found in the book. I would lead the
tests thru the scenarios Sedgewick presents (and all the intermediate
scenarios that he considered obvious), and refactor until the code matched
his solution.
Note I did not say "TDD is magic, and I don't need to read no stinkin'
Sedgewick books to implement advanced algorithms with it". If I were a
trillionaire, I'd have people to do my USENET posts for me...;-)
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Peter
Look at www.crystaltest.com. They provide kind of automatic certification.
Might be useful for you.
Peter
Vladimir
> Nick Landsberg wrote:
>
> > What I had philosophical objections to was that
> > previous posts by proponents of TDD seemed to
> > imply that it would solve all problems. I'm glad
> > you clarified that, thanks.
>
> Oookay. Then I come at the same point from a different direction.
>
> If you accept the responsibility to write a line of test that forces every
> line of code you need to exist, then you accept the responsibility to
> perform sufficient research into your space to learn how to know its needs
> cold, without resorting to guessing.
Examining every line of code is not enogh to prove it will not fail if
that line was not executed by some reason. Some statements of calls
can be avoided by passing by cycles and conditional operators.
If you realy care of the quality of strutured testing you should look
into something more relyable than Statmenet coverage. I would
recommend to stick to something no worse than Condition coverage.
----
Best Wishes,
Vladimir
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vladimir Trushkin, ScienceSoft, QA Manager
mail: nikh...@tut.by (user name reversed)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phlip
> Phlip wrote:
> > Nick Landsberg wrote:
> >
> > > What I had philosophical objections to was that
> > > previous posts by proponents of TDD seemed to
> > > imply that it would solve all problems. I'm glad
> > > you clarified that, thanks.
> >
> > Oookay. Then I come at the same point from a different direction.
> >
> > If you accept the responsibility to write a line of test that forces every
> > line of code you need to exist, then you accept the responsibility to
> > perform sufficient research into your space to learn how to know its needs
> > cold, without resorting to guessing.
>
> Examining every line of code is not enogh to prove it will not fail if
> that line was not executed by some reason.
"Examining" is a little weaker than "causing to exist".
> Some statements of calls
> can be avoided by passing by cycles and conditional operators.
>
> If you realy care of the quality of strutured testing you should look
> into something more relyable than Statmenet coverage. I would
> recommend to stick to something no worse than Condition coverage.
Nobody said statement-level coverage was the only good, or the only
goal.
Focus on what I wrote: "you accept the responsibility to perform
sufficient research into your space".
Suppose you were test-firsting an OpenGL image. (Meaning you occupy a
developer role, not a tester role.) To obey the rule "less than 10
edits before passing tests" and the rule "don't write new code without
making a test fail for the correct reason", you could find yourself
writing an assertion if a given vertex is not (1-5^0.5)/4 units from
the origin.
Instead of working that math out in your head, open a scratch project,
play with it, figure out the math, and copy the assertions back to
your real project.
Whatever it takes, that much care and attention to detail is good for
code, BEFORE it enters formal testing.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces