> Thanks Steve, that's a great point! A training that really focus in an
> improvement for the organization.
> We have had several meetings for identifying the more reiterative
> problems and found between them:
> - Too long times writing test cases.

Do your developers run the tests after every 1 to 10 edits, with the highest
odds on 1?

Do your developers prefer to revert when a test fails unexpectedly (and the
reason is not simple & obvious, preferably appearing in the fault diagnostic)?

> - Too formal test cases that include redundant GUI testing (this
> increases the writing time).

Are the majority of your cases all unit tests that run 1 or 2 calls above the
tested code?

Could you write a new test to reach any line of code, anywhere, at any time,
without excessive research to determine how to reach that line?

> - Not much use of automation tools (only 5 of the team use QTP), this
> is mostly because of budget limits (that's why I´m trying to find an
> OpenSource alternative).

Can you test the GUI from within, by writing tests in the same language as the
GUI?

> - We don't have knowledge on security testing.

Do you TDD your security code?

No test can "prove" your code is secure. TDD tests should spot-check that your
algorithm works as designed. For example, at my day-job, we run an MD5 checksum
hash on today's date with a pass phrase and a >cough<. To test this, we
trivially mock the Date module to return a fixed date. Then we trivially compare
the result to a hard-coded checksum. As copied from the fault diagnostic on the
day we wrote this test.

Yes, the NSA could crack this with one hemisphere tied behind their backs. Our
tests allow us to freely refactor all the code in and around the security
system, without changing those odds.