When we test, we often point out the bad, the negative, the superflous, the deranged, the obsolete, the missing, the obvious, the truth..and for that we often receive some pretty bad press. We are seen as negative. The quality police. The pain in the backside.Let’s not get too blinded by the bad side of the product though. Let’s also notice the good stuff and shout about what’s great. If we feedback on the good and the bad we give a more balanced view. We add confirmation to certain ways of working, ideas or implementations. We could even have a positive effect on moral. Why not give it a go and let me know. Do you report the good stuff also?
I watched this excellent little Ted Talk from Charles Limb about his research in to whether improvisation whilst playing music uses a different part/function of the brain than scripted/copying. It’s a great insight in to how the human brain works whilst improvising music and rapping. I can’t help but wonder whether exploratory and scripted testing use different parts of the brain; require different personal characteristics and require different experience levels. I have my ideas……let me know your thoughts.
I may be miles away, but even so, fun little video…..and he even does some rapping 🙂
I’ll be hosting and running an Official Software Testing Club Meetup in Oxford in April of this year. It will be a blast. We’ve had a couple of people volunteer to do some lightning talks too..the more the merrier.
There’s also another official meetup by community members Andy Glover and Adam Brown in Nottingham.
We’ve got an official meetup page here for both of them: http://www.meetup.com/SoftwareTestingClub/
I do hope you’ll be able to make it 🙂
I’ve heard a lot of people recently talking about how they have been asked to “test better” or “test more” after bugs have been found in live. This is a question/statement often asked by people who assume (or expect) that testing guarantees no bugs in live. And here is the main problem. In a sense testing could continue forever on certain projects and you’d still potentially have bugs in the code. Most testers know that, but expectations and assumptions of others might not align.There is also a misunderstanding of what testing is and how it is done. In my experience, the most experienced testers are those people who have never done testing, at least it appears that way when they talk about “testing better” or “testing more”. Testing is seen as the poor alternative to programming and an easy job to do. It’s often seen as someone running pre-defined test cases and ticking boxes.
Many people ignore the human element; skill, culture, outlook, motivation, experience, awarenes, understanding of features and requirements, competency levels of using certain technologies etc. And this ignorance of the human element is why many people assume one tester is the same as another and that testing can be done by anyone.So statements like “test it better”, “test it more effectively” and the general expectation of completely bug free features are formed, in large, from a misunderstanding of what testing is, how skilled it can (and should) be and how relatively easy it is percieved. But more worrying, in my experience, is the assumption in statements like “test it better” that testers are the only ones responsible for quality. That the buck stops with testing to ensure our products are good and our customers are kept happy. I think we need to challenge statements like this and make people aware of other factors that can, and should, be considered when we find a bug in live. I’m not advocating pushing blame away or adopting sloping shoulders. Far from it. There are times when a tester needs to hold their hand up and say, “Yep. Missed that one which I really should have caught”, learn from it and move forward. But there are times when in addition to saying “we should test it better” we should add in statements like:
- We should specify it better
- We should gather requirements better
- We should budget better
- We should resource it better
- We should focus better
- We should project manage better
- We should code it better
- We should unit test it better
- We should integration test it better
- We should UAT test it better
- We should dogfood it better
- We should support it better
- We should train our end users better
- We should communicate better
- We should prioritise our work better
What we absolutely should not be doing though, is settling for anything less than a fair statement about testing. If we messed up, fair enough. If we did our job with pride and resolution then it’s time to step up and say so.
For the last 12 months I’ve been spending time tracking what I’ve been doing in my journey through my testing career. It’s been mainly at a higher level but in some areas I’ve delved deeper. I’ve tracked the books I’ve read, the content I’ve created, my thoughts on testing, my inspirations and ideas, my successes in testing and of course, areas for improvement.One of the main areas of inspiration for me is the area of reading. I like to read. And from reading I learn. But I also get inspiration for blogs, for content for The Software Testing Club and for other side projects which I’ll be sharing with you throughout this year. I guess this is a form introspection. It’s a chance to pass a reflective thought over what I’ve been doing. It could even be called a journal. It could also be a form of measure.
A way of managing my thoughts and ideas.Like Jurgen Appelo states on his latest blog post – “You cannot manage what you don’t measure.” Whatever I call it, it’s a really great way of looking at where my learning is going, where I draw inspiration from and what makes me tick. Why am I doing it? It’s a way of me looking for patterns in my reading habits. I’m also able to compare what I’ve read to what I’ve created (I’ve not shared that part as there are still lots in final prep – due out this year through The Software Testing Club). This introspection could lead to all sorts of insightful information about me and what I do. Some positive, some not so. Why Share It? Lots of people share their book lists and I think it’s important to share information like this so we can all grow our learning if we wish to. I look at other peoples reading lists and add them to my backlog of books with the aim of getting round to reading them…at some point. Is it complete? Not at all. I am sure, especially in the early months of last year, that I didn’t record everything I read. I have also not included blog posts, PDFs and other online content which takes up a huge amount of my reading time. I’ll be including that for this year’s record. Why a timeline? I stumbled across the TimeGlider software around Feb last year and loved the ease and simplicity of it. A timeline is also a great way to track my work and the software enables links and other information to be included. I’m also interested in finding new ways to show data and this mini project has given me a chance to experiment with TimeGlider and timelines as a way of sharing content. What findings did you stumble across? I’m still looking through the book list but I’ve noticed some trends: I often have multiple books on the go at once. I dip in to books for a few chapters at a time. I read based on my mood, my level of concentration and my interest in that subject at that time. I read a lot more about topics outside of Testing than I do testing books. I do read testing blogs though, so maybe blogs have surpassed books for my test learning. I read about business, sociology, communication, people, teams and management. I need to start adding in the eBooks and PDFs I’m reading as they give a much more rounded view of my learning and reading. I probably read more PDFs and eBooks than I do “normal” books. I shall add these throughout this year. There is a spurt of reading about Creativity. This was in the lead up to Agile Testing Days where I presented on Killing Creativity. I read a lot of “old school” literature from the Victorian and Edwardian eras. I like the way the writers of the time framed ideas and views. I think ideas from this long ago haven’t changed that much. There is a lot to be learnt from writing from all periods of history. I can see lots of seeds of ideas for my blog posts and content when I compare my list of reading to list of writing. Maybe I should also add in a list of listening to or watching. I get ideas from all over but I suspect the management of this kind of information is maybe too much. I have periods in the timeline where I don’t read much. This was partly due to prepping my presentation for Agile Testing Days but also because this is when I’m writing material, editing The Testing Planet or taking time out to rest. How to Use The Timeline
At the right hand side there is a zoom viewer. Best to use it at a level around 28 (1 qtr). Each item is clickable which will open a small dialogue box. In the dialogue box is the book information and a link to the book on Amazon. (the links are NOT affiliate links)
Scrolling left and right is done by clicking and dragging on the canvas (background)
All of the references and book information is taken from Amazon.co.uk
All of the links are to Amazon.co.uk except the direct links to original download sources.
None of the links are affiliate links, so click away.
The date of the entry does not always relate to the date of finishing the book. It is within about 2 days though….
The only exception to the above is The Web Application Hacker’s Handbook which I’m still reading on and off. On initial purchase I skimmed through the pertinent information for my context. I see this book as a reference book.
If you can’t view the embedded timeline below, it’s available here too : http://timeglider.com/app/viewer.php?uid=line_c98d028f02666e6f782b3bae081a5aab
After meeting Shmuel Gershon, probably the most energetic and enthusiastic tester on the Planet, at EuroSTAR 2010, I was introduced to a man of many talents. Not only does he like to read, write and talk about testing but he’s also adding back to the community in other ways with probably the most useful tool I’ve ever used whilst testing.I introduce to you…….Rapid Reporter. In essence, it is a reporting tool that allows you to jot down your thoughts, bugs, tests, notes, configs and setups as you test. Things I would have normally used Notepad++ for or a simple writing pad. But the tool is more than that really because it not only allows you to write down your testing notes, but it frees you up from breaking your lines of enquiry/testing by being so simple and easy to use. The interface is incredible lean and minimalist and everything is pretty much controlled from the keyboard. It allows screenshots and rich text and pushes it all out in CSV format afterwards meaning it’s fairly generic. It’s got some neat little features like the transparancy setting which I find myself using a lot whilst running multiple desktops, each one cluttered with various heads-up feeds or information radiators or browsers. Another neat feature is the countdown of session time and warning when you exceed the session time set. Nice. Rapid Reporter has become my favourite little tool of choice now and no testing session starts without it running in the background. It’s proven invaluable when troubleshooting, retrospectively analysing sessions and tracking what sequences/patterns show bugs. I find myself typing more notes than I would have traditional entered and I also list out a lot more data than before which means more data when logging defects or replicating bugs. So why not give it a download and see how you get on with it. And don’t forget to check out Shmuel Gershon’s blog too.