#testing is like heavy metal. Doom, death’n destruction, speed’n torture’n beautiful ladies dancing half naked around.no!last is imagination
Source: @teemuvesala
Kategorien
Programming Skills
Not only Ruby is a great programming/ scripting language to do your daily jobs or to automate your testing tasks, also Perl is.
Find a free (GNU Free Documentation Licence) Perl training as HTML or PDF on the homepage of Greg London
Also Python is a great language, and a lot of free books & tutorials are existing to learn it, e.g. Learn Python The Hard Way by Zed A. Shaw, which can be downloaded as PDF. But please be aware that this is a book for absolute programming beginners!
Here a quick list of articles I´ve read during the last month:
- When do you write a concept?: When to write a concept? For governance reasons or to cover your back? And listing alternatives: e.g. a spike or take a decision based on the team´s tacit knowledge.
- A Prototype is Worth a Thousand Lines of Code – use the right prototype to emphasize the right ideas, and elicit the right feedback.
- How we got rid of time reports
- „Imagine an airplane or nuclear power plant with a fancy monitoring system that logs all kinds of data but never actually alerts anyone when something is obviously wrong…“
- ‚There is nothing so useless as doing efficiently that which should not be done at all‘ – Peter Drucker
- „Bottom line: I don’t care exactly how many hours you work, as long as it is roughly corresponds to a full time job. I do care that you are focused, energized, and motivated when you do work. Can I trust you to handle this responsibly?“
- Lateral Tester Exercise I – Status Report Virus
- Who owns quality? – „I forget how often some companies blame testers for escaped bugs. It’s not their fault.“
- It’s All About Value – „‚Just tell us when you’ll be done with all these requirements‘ is not how to guide an Agile project, be it Kanban, Scrum, or XP. Not remotely.“
- Steps to achieve higher code quality Summary about tools & techniques how to improve quality.
- Steps to achieve even more code quality Explains different kind of code reviews.
- Work in Process Multiple parallel items as wip vs. „one at a time“
- What Agile Metrics Should We Report?
- Should Story Points Be Assigned to A Bug-Fixing Story
- Stopping the line to run with zero known defects
- I Am a Certified Scrum Coach and I Am Not Nice
- Synthesizing Test Ideas – „It is very difficult to describe the process of synthesizing test ideas. It involves a multitude of information sources, a sense of what’s important, and a dose of creativity to come up with ingenious test ideas, and effective ways to execute them.“
- Context-Free Questions for Testing
- The Phoenix Checklist
- Assumptions are the mother of all … successes.
- Shower of Appreciation – or, talking behind ones back
- Dealing with “Difficult” Co-workers
- XP Days Benelux 2010
- Updated Agile Requirements Metamodel (Enterprise Backlog Model)
I´ve read a pretty interesting article about Regression Testing with an Agile Mindset, found via the GoogleReader commendations of Ralph Miarka who is an agile coach at our company.
Here are my „Ahas“ on that article:
- Realize the difference between functional tests and regression tests to avoid common pitfalls
- At the end of each sprint product owner should not only accept new features, but the overall functionality of the software
- Zero bug tolerance pay off on the long term, so it is better to reduce the scope (regarding new features) then accept (regression-) bugs
- Regression tests need to be maintained/ adapted over time
- Regression tests provide safety net, so team can focus on new functionalities during the sprint
- Fast feedback is needed, therefor regression tests should be automated
- Regression test suite != sum(Functional test suites)
- product owner defines the functionality to be tested within the regression tests
- updating a regression test is part of the user story (so it needs to be considered when estimating)
Kategorien
Book Study Group: “Agile Testing”, Chapter 4
For personel interest I decided to read chapter 4 „Team Logistics“ of Agile Testing, before we decided to do so in the book study group, here is my outcome:
- Team Structure communication is critical!
- Independent QA teams
- lead to division between programmers & testers
- are inefficient
- structures & reasons should be changed
- testers as learning CoP, QA managers as „leader“/ „teachers“
- Integration of testers into an agile project
- testers (also) need training -> critical/ crucial
- programmers need training on testing (skills)
- pairing of programmers & testers
- improves communication
- is efficient
- only 1 budget/ schedule
- -> how does this fit into a big organization with multiple scrum teams and multiple independeent QA-teams?
- testing as part of the DoD
- testers are full fledged team members (use retrospective to improve)
- testing tasks are as important as all other tasks (use retrospective to improve)
- new definition of QA & development managers to be found
- Agile project teams
- cross-functional, but „whole team effort“
- build team depending on project´s needs <- refactor as needed
- tester´s CoP, driven by QA manager
- Independent QA teams
- Physical logistics
- -> Co-location of all team members!
- support communication of distributed teams (phone, webcam, instant messaging, …)
- Resources
- tester-developer ratio
it depends… on- complexity of the AUT
- skillset of the tester
- used tools
- -> number of test taks taken by programmers (?)
- focus on skills instead of ratio
- use retrospectives to find out if hiring a tester would solve the problem (!)
- tester-developer ratio
- Hiring an agile tester
- Very similiar article online: http://lisacrispin.com/downloads/HiringAgileTester.pdf
- most important: does person fit into team
- „hire for attitude“ (not skills)
- Building a team
- self-organizing team: team can identify & solve problems on their own -> best progress
- involving other teams: bring teams together, so they can learn from each other
- performance and rewards
- measuring & rating individual performance risks undermining team collaboration
- good performance shouldn´t be victimized if team doesn´t perform well
- don´t blame the tester if a bug gets discovered in production
- set goals which
- serve business
- increase profibility
- make customers happy
- -> generalized(?): which add value?
- celebrate success
- What can you do?
- get team principles from chapter 2 to work
- communication
- feedback
Kategorien
Rubber Ducking
While reading chapter 18 of „Agile Testing“ the term „rubber ducking“ was mentioned.
During our latest book study group session some of the members of the group stated that they aren’t interested in reading the whole book, since they would not benefit from every chapter. So we decided to read the (at first sight) most interesting (looking) chapters first and then see how to go on.
So as next chapter to study and discuss, we decided on „Chapter 18, Coding and Testing“.
First of all, I have to admit, that from the title I would have expected a more technical content; I expected to see things like examples of code and unit tests, see automated tests and stuff like this, but this wasn’t the case, and at the beginning I was a bit surprised. 😉
But here we go, my notes & summary on the chapter:
For some strange reason I can´t follow (without having talked to anyone yet) the book study group decided to study chapter 21 for this week´s session. Chapter 21 has the headline „Key success factors“ and is more or less a summary of all the chapters before. Seven key success factors are given, here my notes/ remarks to this.
Things in “ are quoted directly from the book, normal text is my abstract, and things marked by an arrow ‚->‘ are my comments on something.
Two weeks ago, at work we had the kick-off-session for a „Book Study Group“.
In a former „book swashing session“ facilitated by Deborah Preuss and Sebastian Lang, it came out that we want to start with „Agile Testing: A Practical Guide for Testers and Agile Teams“ by Lisa Crispin & Janet Gregory or with „Clean Code: A Handbook of Agile Software Craftsmanship“ by Robert C. Martin.
Kategorien
Tester and programming skills
Why should (agile) testers have programming skills? They are testers, not programmers. Why to know how to code, if it isn’t your job to do so?