Don't Shut Up and Test, but DO Test
Opinions are worth less than a test result.
A long hypothesis about what WILL happen is not worth much. Go test and find out what does happen. The best part about being in test? It is a verb. Go test. All of that "not testing" stuff you have to do during the day? It is stealing time. If you have to choose between teaching someone else the basics of their job, of doing work that the team needs and was offloaded on to you, or you've been assigned doing tech support for the product or you've been loaned out to 3 other projects? You are NOT testing. That means the people you are working may not understand why testing is important.
It is very difficult to appreciate the absence of a pain you've never felt. I've heard testing described by many as an information service we provide a business. It is up to the business to decide what to do with that information. But how far does that go? Is it up to those who know little to nothing about testing to determine HOW the testing should be done, or what is and is not important to test? How much responsibility to we have to educate our stakeholders about testing? What if they have little interest? Is testing still just a service if you come up with a list of areas of risk and the business person in charge of the project tells you that they don't care about that? What if the area is security and all of their customers will be at risk? What if it is part of a life sustaining medical device? Is there any pointwhere you draw the line and testing becomes more than just a service to a business person? There is the classic excuse I hear that it is "just software" and that it can't kill anyone. I've worked on software that could kill a business or harm someone's reputation if it failed.
I expect to be testing. If things are ready for testing, I expect to be involved in making things testable and strategizing and learning to make testing more effecient when it can be performed. To be designing tests as the software is created. I expect the same of my fellow testers. Testing should be their default state. If that isn't possible, anything needed to prepare for testing, and if that isn't possible, anything of interest to that tester to sharpen and grow their testing skills should be the default. Yet even though "Agile" is now the default development methodology, I still see these lengthy test projects where months are spent before a single test is run, and this is by the "Testing" team! Rather than run one small test and fix it, this lengthy upfront test design procress starts and for months all testing is ignored completely, because eventually the test framewok will be up and running and "then" you'll have so many tests be run quickly that it will all be worth it. Of course, because you spent so much time setting up the automated tests, it is too late in the project to take the feedback that the tests had indicated would make it better, especially the non-crucial items with workarounds.
I'm a tester. I should be testing. I must test. Because when the project is over no one asks why you didn't hold another meeting. They'll ask, "Why didn't any one test that?" Don't shut up & test. Test first, then speak with relevant data. Share the test results, not an opinion.
A long hypothesis about what WILL happen is not worth much. Go test and find out what does happen. The best part about being in test? It is a verb. Go test. All of that "not testing" stuff you have to do during the day? It is stealing time. If you have to choose between teaching someone else the basics of their job, of doing work that the team needs and was offloaded on to you, or you've been assigned doing tech support for the product or you've been loaned out to 3 other projects? You are NOT testing. That means the people you are working may not understand why testing is important.
It is very difficult to appreciate the absence of a pain you've never felt. I've heard testing described by many as an information service we provide a business. It is up to the business to decide what to do with that information. But how far does that go? Is it up to those who know little to nothing about testing to determine HOW the testing should be done, or what is and is not important to test? How much responsibility to we have to educate our stakeholders about testing? What if they have little interest? Is testing still just a service if you come up with a list of areas of risk and the business person in charge of the project tells you that they don't care about that? What if the area is security and all of their customers will be at risk? What if it is part of a life sustaining medical device? Is there any pointwhere you draw the line and testing becomes more than just a service to a business person? There is the classic excuse I hear that it is "just software" and that it can't kill anyone. I've worked on software that could kill a business or harm someone's reputation if it failed.
I expect to be testing. If things are ready for testing, I expect to be involved in making things testable and strategizing and learning to make testing more effecient when it can be performed. To be designing tests as the software is created. I expect the same of my fellow testers. Testing should be their default state. If that isn't possible, anything needed to prepare for testing, and if that isn't possible, anything of interest to that tester to sharpen and grow their testing skills should be the default. Yet even though "Agile" is now the default development methodology, I still see these lengthy test projects where months are spent before a single test is run, and this is by the "Testing" team! Rather than run one small test and fix it, this lengthy upfront test design procress starts and for months all testing is ignored completely, because eventually the test framewok will be up and running and "then" you'll have so many tests be run quickly that it will all be worth it. Of course, because you spent so much time setting up the automated tests, it is too late in the project to take the feedback that the tests had indicated would make it better, especially the non-crucial items with workarounds.
I'm a tester. I should be testing. I must test. Because when the project is over no one asks why you didn't hold another meeting. They'll ask, "Why didn't any one test that?" Don't shut up & test. Test first, then speak with relevant data. Share the test results, not an opinion.
Posted by Testy Redhead at 23 Sep 2010 
Categories: uncategorized
Tags: opinion test methdology testing
Categories: uncategorized
Tags: opinion test methdology testing
I agree its an information service industry, but we're hired as experts in the field and should be allowed to act as experts. Directing the work of testers to a micro level is like hiring an architect and then handing them the plans you already drew up for approval. Conversely its up to us as professionals to be aware of our clients' priorities and desires. We will often see a conflict, but its up to us to understand the root cause and either address it or make sure everyone making the call is aware of the risks. Going back to the example of the architect, we need to be able to accommodate the user who wants walls of glass, but we should make sure they're aware of the added costs, time to completion, and risks of shattering during the first good windstorm.
If we're concerned our advice will not be heeded and in fact we'll be blamed when the walls come tumbling down after massive cost overruns, we can always walk off the job rather than do it.
Reply to this
This is a very nice article.
That is what tester should be. i love testing.
Reply to this
Interesting and passionate blog. I'm largely with Curtis but will add my own comments here.
I'll put my tester hat on and split the questions into sizeable chunks, then look at them in more detail rather trying to answer all as one as that would be a mistake IMO.
"Is testing still just a service if you come up with a list of areas of risk and the business person in charge of the project tells you that they don't care about that?"
Yes, that doesn't change anything about the service you provide.
"What if the area is security and all of their customers will be at risk?"
It becomes a risk for the business, not just for the project which is important to distinguish. At this point there are several options. The most likely one is to argue with the risk at hand and, if not successful, go beyond the person in charge of the project and to the department/business owner as it falls into their responsibility. Your service is first and foremost to the company that employs you, not the customers at the other end. If they are willing to alienate them it's your decision if you want to go with that or ultimately leave.
"What if it is part of a life sustaining medical device? Is there any pointwhere you draw the line and testing becomes more than just a service to a business person?"
See my last point. Again you have several options here. If it's a medical device you might be violating standards. If that's not clear you might propose to involve a governing body to assess the risk so that the company doesn't leave itself open for litigation.
As hopefully becomes clear I find it useful to look at each question in isolation to find out what the real problem is. According to Weinberg that's always people so the real question is what specific problem do you have with which specific person? Are they creating the problem willingly or unwillingly? Do they recognise it as a problem or not? If not, can a discussion be had? If not, are there escalation paths or alternative approaches? More questions will come up depending on the situation.
Reply to this
Your passionate article is very interesting and I agree with the need to test. If a product or service is good, it will pass the test with flying colors like the Ultra Ankle that has been proven to promote faster healing of ankle injuries. It was designed for complete immobility and it works. That
[url=http://www.ultraankle.com]Ultra Ankle[/url] test speaks for itself and promotes the product and doctors of sports medicine can trust the testing for their athletic patients.
Reply to this
An engaged test environment not only provides "relavent data"; but, should have the ability, and responsibility, to provide creative feedback that could improve the product. All of the critical components including ease of use, performance efficiency, and accuracy of information provided to the user must be considered for effectively testing a product.
Reply to this
. . . get involved early in a project so that the testers are perceived as valued contributors to a project's success. Releasing a product that the customer is happy with often results in demand for more, and more, and more . . .
Reply to this