Each project is different although the approach is the same: common sense, simplicity and capacity of a team to execute a high level plan i.e. deliver working software. This is a model that can fit some types of projects where governance is important to an organization, where project management is being used and where UX work is key to the launch of a product.
I would highlight again “simplicity”: agile is about making improvement and a good way to identify improvements is to ask yourself: “Can this cost less energy? Can this be reused? Can this be replaced by something that already exist if I change it?”
This picture shows 3 levels of planning, a gated process with review of business cases (yearly budgeting and quarterly funding) as well as quality criteria such as INVEST, DEEP for the product backlog, DoD etc
Everybody is talking about “agile” but hardly nobody agrees on the meaning? What is “agile”? I have tried to see what makes you agile and thought…
Common sense is key to success: without common sense, you get mindless chaos (Steve McConnel) and smart people will not stay round for long.
Common sense drives simplicity: you cannot solves issues you do not understand; you cannot make progress if your people don’t understand what directions you are taking etc
Simplicity drives values: you clarify the key values; what is really important and people is “something” you value more than processes and documentation
Values drive principles: once your values are clear, you set out principles to follow
From your principles, you establish and improve a framework driven by common sense and simplicity and that support your values and principles.
Extract from Ken Schawber, Project Management with scrum, 2004:
“Common sense is a combination of experience, training, humility, wit, and intelligence. People employing Scrum apply common sense every time they find the work is veering off the path leading to the desired results. Yet most of us are so used to using prescriptive processes—those that say “do this, then do that, and then do this”—that we have learned to disregard our common sense and instead await instructions.”
Agile does not scale -> Applying common sense does not scale
Agile does not work for fixed cost projects -> Applying common sense does not work for fixed cost projects
Agile is not for complex projects -> Applying common sense is not for complex projects
Agile is not for junior members -> Applying common sense is not for junior members
Agile is prescriptive -> Applying common sense is prescriptive
Agile does not apply to all projects -> Applying common sense does not apply to all projects
I’ll bring some more… Just a start…
Sometimes, not everything can be automated. So how can you optimise your manual regression testing so the test suite can be run quickly and is easy to maintain? I have used the tips below and it is turning out to be very effective!
- Make your tests UI independant:
Exemple: instead of *click on the button “Save” to save your data*, write *Save your data*. This is a minute difference with a big impact: if you change the title of the button or change from a button to a drop down list, the second test is still valid, the first one is invalid.
Testing requires common sense and intelligence: having your tests UI independant means you need to get your brain work a bit more on the first time you run the test, the second time it gets faster and the third time, you just know what to do.
Also, tests are simpler to read and far easier to maintain!
- Make your tests business focused:
Because of the history in your company, tests might be written with lots of details such as “The pop-up should open” but this is pointless as the pop-up exists because there is business workfow behind so by writing tests that represent business workflows, the test will fail if the pop-up does not open even if you don’t check explicitly this is the case.
- Combine tests that are similar and find the path that tests most cases:
Let’s say you have 2 tests testing these 4 cases:
- A -> B -> C
- B-> C ->D
- Can’t you have a test that does A->B->C->D?
- And if you write a new test: B->D->E then why not having only A->B->C->D->E?
- Use consistent way of writting tests:
One way is to use the Given/When/Then pattern:
- (Given) some context
- (When) some action is carried out
- (Then) a particular set of observable consequences should obtain
- Add as many verfications as possible with the tests:
The purpose of the tests is to find defects if any so add as many verification as possible including verifying impact on data and other screens.
Conclusion: I have used the tips above, based on BDD principals for most, and this has been very effective: we can run more tests, validate more cases and still have not that many tests to run that are easy to maintain. Indirectly, your tests could be now automated quite easily!