CITCONANZ2010Sessions
- Automated Testing is not quality is not testing **
Automated testing != quality != testing
How to write better tests
Why are the tests passing but if fails on deployment?
Can't test quality into something
testing is not quality
testing is human role automated testing is for validation
Auto testing
cant detect black text on black background
sapient process of testing
Some experiments on increasing fuzzy logic for testing.
Test automation is part of testing.
Does agile think automated testing is a panacea, bigger than it is in it's role in wider testing.
If writing good tests then get better results, if just filled in, then not.
How get developers to create better tests
Not poss to automate everything... trade off of coverage.
Correlation of manual and automated testing.
Experince of ?? - need to automate 7-9 times to get value.
Frequently devs write poor tests
1. teach them to write 2. testers write tests
If poor requirements then auto testing not much value. Don't agree - tests for stuff that works is useful even not knowing
TDD is not a testing practice, it's a software design practice.
Automate the mundane crap, allows the testers to focus on the new stuff, the edge cases, the human intuitive stuff.
Test automation not replace need for people to be testing, just good for regression testing.
Should regression tests be the same always, or different each time.
Each time there's a defect, write test to test that defect, then fix it. Can't get it right first time, but add tests and improve as you go on.
Infrstructure guy: "Developers don't write good test".
Devs write tests as part of software design.
Can automate almost anythings, if test script, then can automate.
Manual tests just get bigger, so must focus on integration tests. Take long time to write high level tests, but worth it.
What about the client perspective? Does client want automated testing? Is it assumed? Or is it POC and NOT wanted at all? Ask.
Expect vendors to have good development practices.
We do code quicly, cheaply, reliably... pick any two.
Find the trade-off of scripted, ad-hoc, and automated testing. Client expectations.
Business / testers can writer at least test scripts for devs to automate. Some testers getting better and better at writing automated tests.
Automated testing is easy to pick up... devs can train testers. Diff tools getting better. Eg. Selenium record, click, done = test.
Most NZ testers from non-it background, from business, not tertiary. Changing with IT grads, not scared of getting into code.
Not all testers need to be technical.
Still see many test teams where no-one is technical.
Test automation good for smoke testing - giving it a once over - to ensure foundation is there for manual testing.
Exploratory testing is human function.
Define the balance up front of automated and manual scripted and exploratory testing.
Tester and BA's work together early to ensure requirements clear, and testable. Devs can write automated unit and functional tests.
Diff phasess of testing aims to find different classes of defects / issues. Role for devs, testers.
Automated testing should test everything in the requirements, as they are anticipated. Exploratory human testing good for detecting things NOT in the requirements.
BAs, testers, devs must be talking with each other through the proceess early on and continously... all have same goals... quality. Colocation is best way to get quality - BA, testers, devs.
Are testers gate-keepers? Do they just expose problems and give information, or can they call the shots of go / no-go. Up to each organisation to decide what works well for them.
Colocation or separation / 3rd party? Depends on if client trusts testers will find bugs. Not just about colation, but communication. Communiation easier with colocation, but not necessary, and sometimes the opposite occurs if not got culture in place.
Sometimes good to have internal and external testers... internal testing deliver to spec and get a level of quaity. External to be independent.
Zero defects is usually a destructive goal. Beware of technical debt. Zero defects is only that not found any more (not that there aren't any).
Devs who write tests usually are more productive... better thought out code.
Good to have walk-thru for use cases once requirements written.
Not really about test automation, it's about people and communication. Agile issues: need vendor who knows their stuff, and customer who knows what they want... the latter is hard to find. Sometimes waterfall better (including for infrastructure).
