Everyday I use software, I don't just test it. As a tester who uses software I can think of countless examples of empathy I have for customers who come in contact with bugs in the software I test. (Bugs, using James Bach and Michael Bolton's definition of a "bug is something that bugs somebody that matters".)
Usually the examples that "bug" me the most are with the very software I use to log bugs/get reports/test with. I have reported some of these issues to the companies that develop them. Sometimes it gets fixed, sometimes it doesn't. Sometimes I am pointed to a newer version or an altogether different application because they are "no longer developing" the application in question.
We are tasked with finding ways to improve our processes and "work smarter not harder", but the truth is that more often than not in this world of ever changing technology, it is the technology itself that is an impediment to process improvement and working smarter. This is not just in software development, but in just about every business these days.
While thinking about this, I came across a great presentation by
David Pogue, over at TED, titled Simplicity Sells. It is a funny talk, but full of reasonable insight on simple/elegant design for an age of technology where users are constantly struggling with using software.
Followers
Sunday, January 23, 2011
Saturday, January 22, 2011
On Ignorance...
I recently attended a webcast hosted by Software Test Professionals, presented by Alan Page, titled "Better Test Design for Everyone".
One of the things that I learned about was The Five Orders of Ignorance by Phillip G. Armour. I found this to be an interesting view of software development and since I believe that testing is part of development, I feel it too can be viewed through these five orders.
I thought about ignorance and how it can have both positive and negative outcomes in the development and testing of software.
In a positive light, it is what drives some of the questions that arise in testing. The hope is, as the questions are asked and the answers come, that the level of ignorance is lowered and the questions become the more important ones for the project/stakeholders/customers.
In a negative light, if knowledge is only gained in the development of the product/application/system, and not inclusive of the end user/customer needs, the risk of ignorance is catastrophic. The end result could be a great "storage of knowledge" that is really not what was wanted/needed. (I have bought books that have had this same end result with me. They have appeared to be something useful and ended up on the shelf. They simply do not meet my need.)
These positive/negative lights, among others, are why I like the Agile approach in software development. It involves every level that can be affected by the end result - from stakeholders to customers. It is an ideal approach to limit ignorance.
***Merriam-Webster defines ignorance as "the state or fact of being ignorant : lack of knowledge, education, or awareness". This definition led to a philosophical discussion in my head. While the concrete part of me seeks to achieve a level of knowledge that is completely removed from ignorance, the abstract part of me believes it to be un-wise to ever embrace that level. If I look at learning as a never ending process, and if I believe I have reached a level of knowledge that is removed from ignorance altogether, then might I find myself back to the level of "not knowing what I don't know I don't know"?
One of the things that I learned about was The Five Orders of Ignorance by Phillip G. Armour. I found this to be an interesting view of software development and since I believe that testing is part of development, I feel it too can be viewed through these five orders.
I thought about ignorance and how it can have both positive and negative outcomes in the development and testing of software.
In a positive light, it is what drives some of the questions that arise in testing. The hope is, as the questions are asked and the answers come, that the level of ignorance is lowered and the questions become the more important ones for the project/stakeholders/customers.
In a negative light, if knowledge is only gained in the development of the product/application/system, and not inclusive of the end user/customer needs, the risk of ignorance is catastrophic. The end result could be a great "storage of knowledge" that is really not what was wanted/needed. (I have bought books that have had this same end result with me. They have appeared to be something useful and ended up on the shelf. They simply do not meet my need.)
These positive/negative lights, among others, are why I like the Agile approach in software development. It involves every level that can be affected by the end result - from stakeholders to customers. It is an ideal approach to limit ignorance.
***Merriam-Webster defines ignorance as "the state or fact of being ignorant : lack of knowledge, education, or awareness". This definition led to a philosophical discussion in my head. While the concrete part of me seeks to achieve a level of knowledge that is completely removed from ignorance, the abstract part of me believes it to be un-wise to ever embrace that level. If I look at learning as a never ending process, and if I believe I have reached a level of knowledge that is removed from ignorance altogether, then might I find myself back to the level of "not knowing what I don't know I don't know"?
Subscribe to:
Posts (Atom)