Developing a New Major

resources

agile manifesto – seems to be a core document – to be doing agile you need to buy into these core rpinciples, might implement differently or use any of the varieties of agile, but they should all use these core principles – http://agilemanifesto.org

mike cohn’s site – http://mountaingoatsoftware.com

lisa crispin – wrote book on agile testing -  http://lisacrispin.com

elisabeth hendrickson – http://testobsessed.com

Dawn Cannan – speaker at the conference about agile testing – http://passionatetester.com

a good testing automation tool – http://fitnesse.org

there’s a yahoo group about agile testing – agile-testing@yahoogroups.com

new keywords to look up – extreme programming, lean manufacturing, regression suite/regression testing, refactoring, unit tests, suer stories, vertical slices, certified scrum master, certified scrum instructor

book – innovation games

book – succeeding in agile

book – collaboration explained by jean tabaka, 2006

agile testing

• huge part of agile development – code isn’t done till it’s been tested and bugs fixed and retested and documented where necessary – - don’t want bugs going from one iteration to hte next, if code fails tests then it’s not done
• testers and developers have to collaborate in reality, not just in words – it’s not “over the fence” testing where developers “finish a project and just toss it over the fence to hte testers while the programmers walk away to do something else
• agile is into continuous integration – new junks integrated right away with old chunks and tested so you can have your workable deliverables at end of each iteration
• develop test acceptance plans before iteration and developers and testers have to agree on them or go back to team or to users/cusomters – programmers can develop for the tests and that helps cut down on bugs too
• lots of testing automated – automate the tedious taks – unit tests for when little chunks put into existing project or combo’d with other little chunks, acceptance tests (for api stuff, integration level and software below the interface), GUI tests (these can be hard to automate and be hard to maintain as gui changes), manual tests (things that can’t be automated, you need to explore system and see if stuff breaks, you need to think and analyze, usability tests, alpha nd beta versions of some features before they stabilize) — there are lots of tools for automating tests – she mentioned Fitness – fitnesse.org
• tests done on every single check in or can have a regular testing schedule
• unit tests should be runnable in like 10 minutes so programmer can see right away if they broke anything

pair programming – can take longer than a single programmer working on a project but much higher quality

agile about defect prevention not defect detection

lots of testing during and at end of each iteration

testers and programmers have to talk before during and after iteration so testers know about any changes, can develop test cases as software develops so team can reach goal of releasable code at end of each iteration

feedback is given and acted on – testing is part of the feedback so are retrospective meetings

customer wants to see product, not 400 pages of documentation and a broken project

gotta figure out if you’re looking at a symptom or a problem – can’t waste tiem treating symptoms – have to figure out the problem and treat it, have to ask a lot of why’s to get to the real problem sometimes

agile isn’t dogma, everybody implements a little differently, there are many flavors of it

but if you say you’re doing agile then you should be doing short iterations, doing quick unit tests so developers know within say 10 minutes of integrating their chunk of the build fi they broke something or not, smoe places run automated regression tests twice a day to check integrity of the project

short iterations gets you lots of feedback, forces you to break user stories down into smaller and smaller chunks that can be more easily finished

teams

• have to be really integrated – include testers – testers have to understand the user stories that the developers are working from so the testers have to be in on the planning sessions
• sometimes a company has to change their team structures, team mentality

have stuff for testers to test iwthin a couple days of start of each iteration so they can catch many bugs and get htem fixed before the iteration ends

company has to buy into the idea of testing and quality that comes from testing

acceptance testing

• set up the acceptance tests during hte initial planning meetings so tester and programmer agree on what the chunk to be worked on really does, what user story it is designed to solve
• programmer knows what htey have to do to get their code to be marked as done – and that helps eliminate bugs and useless features
• if programmers  and testers don’t agree about the acceptance tests they can go back to users or to managemetn to get clarification without wasting any time

make process and metrics visible – big charts publically displayed – so new people can see where they fit in, to remind old hands about all the tasks that needs to be finished

good to have a coach internally to help people with the transition to agile

use your retrospective to tackle little problems at the end of an interation or to address larger issues at the end of a project (bring in someone from outside the team to facilitate so everyone on the team can participate)

mangaers need orientation and training about agile – they’re afraid of it at first – some not happy about idea of self-organizing teams – so they know its benefits, so they see that agile can help make processes more transparent, more efficient, that products can ship faster and with fewer bugs – lots of rumors about bad code from agile and no documentation but that’s not a part of agile overall – chaotic development is not agile

failure to meet deadlines is so common in software development companies and folks are in denial big time – there’s so much room for improvement if you can get past the denial  – and agile is one way to get that improvement

amazon has the concept of the 2 pizza team – no more people on a team than you can feed at lunch with 2 pizza – like 6 to 10 people – easy to coordinate – that’s what agile wants too

scrum meeting – what you’re finished yesterday what you’re working on today, what you need help with – then people can offer to help after the meeting – - team talks to each other – management stays out of hte conversation except to take note of where htey need to help remove impediments

user stories

be sure to get from users ways to know that project is done

need to talk with stakeholders to get details about what they want and why and what they want to do to figure out what they really need – what they need isn’t always what they say they need

split the user stories up into small chunks and prioritize

the list of chunks is the product backlog – the priority is based on the value to the business of each chunk

put some of the most important ones on teh sprint backlog and start

lots of people seem to like 2 week cycle

daily 15 minute scrum meeting

at end of 2 weeks have retrospective meeting to get feedback for future scrum, to deal with problems to prevent htem from recurring in the future, not judgemental, goal is to get better, develop metrics, start/foster discussion

at end of iteration have finished, tested releasable chunk

stuff that didn’t get finished – decide if it stays on backlog or gets moved to make room for something else

Lean

reduce waste like deadtime as far as customer is concerned, waiting for meeting, developing a piece of software that you can’t use for a year, feature creep

optimize the whole – use queuing theory to speed process up

build quality in

lean uses terms management and mba types recognize, agile uses engineering terms

waterfall

• aim before you shoot
• lots of design upfront and then you follow that plan regardless and then test
• but so many things are hard to measure, hard to anticipate and they mess up the plan, change the software
• all the testing done at the end of a long project
• test cases made at hte beginning may not still match the software’s purpose (which may have changed over time
• often programming runs over schedule and there’s no time left to test – can’t do it in one day
• mini-waterfalls (kind of lloooks like iterative development except programmers consider their job done wihen they give the code to testers and start on the next chunk – even tho first chunk hasn’t been test and debugged – so mini waterfall is bad – bugs propagate thru the system

Trackback URL