“It’s not only about what you have in your metrics, it’s also about what you leave outside of them.” This is the principle I tried to communicate to an organization I was working with lately.
A short post about the importance of defining your metrics correctly and communicating what you want to achieve and what you are willing to pay for it, up-front and clearly.
Is there such a thing as Agile Testing? I’m not sure there is…
You don’t need to work on an agile team to work and test based on an Agile Thinking mindset.
If you are going to write-down just one (more) test case, what would that test be?
Will you write a very descriptive (and deep down) test for the most risky component/screen in your application? Or would you write an end-to-end sanity/smoke test that goes over 80% of your system? This is a question to ask yourself whenever you sit to write down your scripted testing scenarios.
Last week I took part in my first pair-programming session. Up to now I had done pair-testing many times, so I was aware of the added value from pairing, but somehow I always assumed that as a tester I had little to add to a programming session. Boy, was I wrong?!
- Is the size of a test important?
- How big and comprehensive should a test case be?
- Should tests be always small, or should you write comprehensive tests that cover end-to-end and complex scenarios in “one-go”?
All of these are important questions, and even if there is no text-book answer for them there are some guidelines you can consider when you are wondering about this subject.
The most difficult step when starting an improvement project is the first one. Many times we fall into the trap of working on monumental changes, other times we simply let everyday things stand in the way.
The only solution is to stop thinking about change and start doing the change RIGHT NOW!
© 2012 QA Intelligence - a QABlog. All Rights Reserved.