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.