Great presentation with great learnings out of controlled experiments
- UX principle: “Don’t make me think”
- Controlled experiments are not the panacea for everything -> see paper
- If you’re going to experiment, try more variants, especially if they’re easy to implement
Great examples of AB testing for user screens.
The related paper
Great insights into Elisabeth’s daily troubles. Worth the 30minutes
My favourites (which I see a lot)
- Why doesn’t separation of duties between engineers and testers work?
- What’s wrong with the approach of writing and executing manual test scripts?
The article sheds some light on test terminology.
Some important ones are missing like:
- Smoke test
- Black and White Box test
- Penetration test or
- Sanity Testing
Wow! No wonder we are overwhelmed!
—-> Don’t be afraid to ask if someone throws these terms around!
Great explanation from fellow trainer Ralph Jocham about ATDD + Scrum, where he explains how to approach testing in Scrum with the goal to have a “ATDD Ready Sprint Backlog”
This is one of the topics ATM that I am most excited about
BTW: Steve Freeman has exactly done this with an XP team in London
thinking before debugging is extremely important
Great article that goes into the details behind testing “SQLite”.
Every project should have these test harnesses as a goal
the project has 1177 times as much test code than production code
Great article that goes into the details of testing Android apps.
- Android is growing -> 850,000 new activations per day
Key challenges in testing mobile apps
- Amount of different devices, software versions, …
- How to tighten the feedback loop
- Specialty shops handle mobile QA testing now like Testology
- It was harder in the past
So while Android fragmentation seems like a headache, your dad’s mobile app maker was trudging seven miles uphill in the snow QA testing with 400 different phones and dealing with business development people from a hundred carriers.
- Defect Reduction
- Faster Feature Time to Market (aka Cycle Time)
- Improved Focus
- Parallel Efforts Without Conflict
- More Test Code
- Learning Curve
- Test Maintenance
Heaps of good stuff in this article from Patrick Smacchia about writing tests
The tests should be written before the functionality that is being tested’.
I don’t agree with that. Tests for a portion of code should be written at the same time as the code itself.
About Code contracts and assertions (Debug.Assert)
Assertions in tests are not much different than code contract assertions.
Although Code Contracts are way slower on compile time, which is #pain.
It is a good practice to tag a class that has been 100% covered with an arbitrary [FullCovered] attribute, because it documents that the class is, and must remain 100% covered
Great idea. The build should fail if someone is not following that rule (marked by the attribute)
…writing a complete test suite naturally leads to good design, enforcing low coupling and high cohesion.
Best bits from the article by James Grenning
Every iteration, not only does the new functionality have to be tested, but the prior iterations’ working features have to be retested too. No problem, just add some more resources; I mean plug compatible testing units; I mean people with the needed skills and knowledge.
Full article from James Grenning
ATDD isn’t about a tool like FitNesse, Cucumber, or Robot Framework. ATDD is about making sure that your development team develops the right product
What I was missing in that article is
#1 “Gherkin” as a DSL that helps discuss a specification between shareholders, business people and developers
#2 Distinction between Feature and Scenarios
Great article about detaching your code from 3rd party libraries
In the middle of the article Misko asks: ‘What would an ideal API look like for my application?’
My 2c: TDD helps to answer that question
If you use 3rd party libraries, make sure to be independent from them à Adapter to the rescue
Have I mentioned the value of testing?
Don steps through Unit-Testing, TDD and BDD to help us write maintainable high-quality code.
Who doesn’t want that?
Questions to consider:
- Should you test private methods?
- Should you test every getter/setter?
- What changes when you call your tests, “behaviours”?
Find the recording and many more on the Scrum.org webcast website
Great article with the history behind of BDD and the “differences” between ATDD and BDD.
A great statement can be found in the comments:
I also conclude in that video that the difference doesn’t matter – as long as we’re delivering products that matter.