Difference between revisions of "CITCONANZ2010Sessions"

From CitconWiki
Jump to: navigation, search
(New page: ** 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 tes...)
 
m (ATDD -> AT&BDD)
 
(14 intermediate revisions by 6 users not shown)
Line 1: Line 1:
** Automated Testing is not quality is not testing **
+
Using [http://www.flickr.com/photos/talios/4739922988/sizes/l/ this image] as a guide for session title.
  
 +
===10:00-11:00 Sessions===
 +
* [[Acceptance Test and Behavior Driven Development]]
 +
* [[Why your manager needs CI]]
 +
* [[Pair programming]] - Paul Julius
 +
* [[Getting off your version control system]]
  
Automated testing != quality != testing
+
===11:15-12:15 Sessions===
 +
* [[Enterprise CI Maturity Model - and how to go insane]] - Jeffrey - co-evolution of CI & agile
 +
* [[Testing mixed language projects]]
 +
* [[How do you unit test legacy systems?]] - Haowei
 +
* [[Performance testing in CI environment]]
  
How to write better tests
+
===2:00-3:00 Sessions===
 +
* [[Automated Testing is not quality is not testing]]
 +
* [[Data migration and testing]]
 +
* [[Testing in complex environments]]
 +
* [[Build tools and their issues]]
  
Why are the tests passing but if fails on deployment?
+
===3:15-4:15 Sessions===
 +
* [[Different CI Tools]] - Added by Jagannath Nori
 +
* [[CI in the cloud]]
 +
* [[managing requirements]]
  
Can't test quality into something
+
===4:30 Sessions ===
 
+
* [[continuous deployment]] - Jeffrey
testing is not quality
+
* [[TDD how much is too much]]
 
+
* [[can you crowd source CIT]]
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).
+

Latest revision as of 12:24, 28 June 2010

Using this image as a guide for session title.

10:00-11:00 Sessions

11:15-12:15 Sessions

2:00-3:00 Sessions

3:15-4:15 Sessions

4:30 Sessions