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!
For the last 3 years, implementing scrum or just being agile, I have had lots of concerns reg. test strategies issued by test managers for my projects: I felt they did not take into account the specifics of the product and they turned into copy/paste test plans of previous projects.
Since we are talking about delivering working software, as a project manager/scrum master, I started writing the test strategies, approaches and test plans with support of the scrum teams for my projects. I got slightly lucky because before that I had read some books about testing inc. “Agile Testing” by Lisa Crispin and one about ISQTB so about testing and certification and some articles, especially Mike Cohn’s Forgotten Layer of the Test Automation Pyramid. Testing is now a interesting discipline thanks to numerous clever tools and techniques like BDD.
My whole goal was to make sure the test strategy and its implementation were tailored to the project and was fit-for-purpose for the project. There is a learning curve for the team to come up with the test strategy: writing a good test strategy requires thinking, lots of discussions and an understanding of what the product is as well as a knowledge of different tools and techniques.
A test strategy, like design, is “intentional yet emergent” to quote Mike Cohn: you may have to adapt it based on the lessons learned in the first sprints.
So , testing with all activities emcompassed under this name, should be part of the remit of responsibilities of the scrum teams! You build it, you test it and you run it!