From a respected and experienced software tester in the field I got the following feedback.
Well, before we can answer the question if something CAN or CAN'T be tested we first need to know what 'TESTED' means. Let's take Wikipedia as a starting point for the sake of simplicity:
Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not necessarily limited to: .....etc
The difficulty with this page (read the full page) is that it does NOT say that this examining must be done by a person who's official role is software tester on the monthly payment slip.
In many places however the expectations are that those people are the ones that do the testing.
-What is it about some things that prevent them from being tested?
We all know these type of overlapping circles, right?
If we only talk about the person in the role of software tester doing the actual testing... then there can be many reasons why the examining by this person can not be done.
- lack of application knowledge.
- lack of domain expertise (no knowledge of banking, insurances, etc)
- lack of SQL knowledge (not possible to verify if this new code is technically okay)
- lack of experience in software testing (incl. test methods / test techniques / etc.. )
Whatever the case, it is resulting in: testing can't be done... by that person. (or assistance is needed.) But does that mean that something can not be tested?
Well, NO! because maybe some more experienced tester can test it, or some other person in the company with huge amounts of application knowledge. Maybe together they can test it?
So, again, what is the actual meaning of: it can not be tested?
Isn't it a more technical related statement then?
Sometimes as tester we hear the phrase: only the production environment is suitable for that.
Only the production environment is set-up in that way.
So does that mean that all testing has to be done before production, but...
when things are in production, then the "test phase" is actually still lasting because... (otherwise not "everything" can be tested)?
- Why does this matter?
It matters because as a well respected software tester you want happy customers of course. You want to give an organisation the information that they need, an as good as possible status overview of the test object at hand.
In order to being able to do that you need to know 'what can be tested? / what can't be tested?'.
You need to know: what should I test? what is being tested by others?
Is it okay that not everything is verified (examined) by me?
Preferably you would like to read what an organisation's test policy, test strategy and view on software testing is.
Is the test report or the advice of the test team decisive for the product going live?
Maybe not and management sees the report as an advice or guideline and decides (for whatever reasons necessary) to go live despite the report recommending the contrary.
Does the statement 'It can't be tested revert to a person (or team)?'
In some cases a person is not able to test it. (a part of the artifact)
In some cases a person was not even allocated to test it. (a part of the artifact).
or does the statement 'It can't be tested to the test object?
Maybe in some cases it is not even possible to "test the object under test"...
but it is very hard to come up with a good example.
So maybe 'It can not be tested' should be looked at more like:
Not everything can be tested well under the circumstances presented to the tester at the time?
Maybe a better (underlying) question (then: Is everything testable/tested?) is:
Should everything always go according to plan?
But that arises new problems... Because what is that plan then? (are we talking about a test plan in such case?). Is it possible to get everything in that plan? considering:
Who's got input for Chapter 3?
I'd really would like examples of situations or scenario's when something was literally NOT testable!
120 unieke bezoekers per week.
Uw banner ook hier?
Dat kan voor weinig.
Tweet naar @testensoftware
This website uses marketing and tracking technologies. Opting out of this will opt you out of all cookies, except for those needed to run the website. Note that some products may not work as well without tracking cookies.Opt Out of Cookies