Friday, September 11, 2009

I ship the Information!

I was following a discussion thread in Software Testing Club. When I read the title of the discussion "No issues in application" with description "What do you do when you are not finding any issues in the application you are testing?" I did not know what author had in his thought while he wrote the description. Was he witnessing, what he had written in title and description or it was a thought asking what should be done when (it is or it will be or it was) witnessed? This question remained along with many other views of me for the very same title and description.

Following the discussion, I understood that the author was witnessing what he had written in the title and description of the discussion thread. The reason for witnessing this might be the illusion, biased and the other things too if it exists and one discovers it. Focus and defocus might help here to discover, generate, invent and explore the new ideas -- the heuristics.

The few words, phrases and sentences from the discussion helped me to unlearn and learn -- how can I infer and perceive the information:

/* These are the few words taken as it is from the discussion thread. */
  • wrong tests.
  • if the main functional user test cases pass, then the quality of the sw may be good enough (depending on how critical the sw be in the real world).
  • Why are there no defects in this application?
  • Pesticide Paradox.
  • there are always defects, they must be somewhere.
  • Perhap I could see where other defects have been reported in the past and test around those areas.
  • Why are the test cases all passing?
  • Have I tried end-to-end or process driven testing?
  • Ship the application.
  • I typically step back and look at the tests I've run and try to identify patterns in what I've been doing. With my next set of tests, I attempt to violate those patterns.
  • Julian Harty's techniques around six thinking hats for software testers.
  • trying different tours of the application to generate new test ideas.
  • better develop my mental model of the application.
  • pairing with others on the project team.
  • are you asleep and dreaming this.
  • It really meant that the test cases you are running - either they are not updated ones or just clicking on "PASS" on any behavior.
  • This scenario will not come.......if it comes well.....time for all the testers to pack their bags. :)
  • Take a step back and think just what you are supposed to be doing and what you are actually doing.
  • If you're not finding any defects then there's something fundamentally wrong with your approach.
  • if you're not finding problems then you're doing something wrong.
  • In all my 20 years of testing it have never happened!
  • If am not finding any issues in application as per System Requirements / use cases. i start doing negative testing.
  • try to brake Application by any means. if it still survive then the application is ready to be Delivered.. :)
  • Application has gone through all the negative testing and has survived, however I still have couple to days time to test.
  • Hence I was trying to find if there are any issues.
/* End of selected words from the discussion thread. */

Looks like the application that was said, might have been shipped which made to close the discussion thread.

When I began to learn and unlearn my understandings with the above words, phrases and sentences which were written in the discussion thread, the skeptical notions I am inferring and perceiving are as below:

  • Test(s) give the information when they are executed. I don't know and I am investigating yet how to classify, call and negotiate them as wrong tests and correct tests. Words are always ambiguous. In this context, both wrong test(s) and right test(s) provide the information.
  • Testing provides the information. If my test cases fail, still I am getting the information which might be of value to the people who matter. If quality is value to the people, then isn't the failed information is useful intellectual cognition? Why test cases marked as passed the test(s) alone get the importance?
I understand 'Quality' is not in the software which is used, but it is the emotion of the user when the model is used. I remember the words of Gerald M. Weinberg "Quality is value to some person". If I wear a silk (which is said to be of high quality by fabric person who weaved or manufactured that silk garment) shirt of bigger size (than I need) that hides my trouser when that shirt is not tuck in or which makes me not to wear trouser or I am unable to tuck in the shirt due to its size -- am I getting quality on wearing it? Am I satisfied, enjoying and loving to wear that silk shirt?

It depends from a user to user along with other factors which can have the influences for wearing a silk shirt or not. And if I don't like to have that shirt, where is the quality for me in that shirt which might have passed the test, to say the silk used in fabric is of high quality? But, if I wish not to spend money on buying a trouser and this bigger size silk shirt covers my shoulder to ankle and I am comfort with it and happy using it, might be the value for the money what I have given is with me.
  • When idea(s) or heuristic(s) does not bring the information that tells it fails to meet the claims, it is not a failure idea. It is the information that shows how the model does what is supposed to do, in yet another way too. If the idea(s) or heuristic(s) does discover the information, how the model fails yet in another way of using it -- it is not a success. It reveals another way how the model does not do what it is supposed to. One can get such plenty of information which makes him or her to infer the model (appear as) to work or not work. So failure and success cannot be defined with the information given by the Tester's Testing. And, may be the model cannot be shipped by decision makers, with tester(s) information alone.
  • I am not against test case writing. The first law of documentation is to document it (from Rapid Software Testing). If I am just executing the steps in test cases, it is more of like verification and validation of test cases and not the testing of model under test and testing of the being executed test cases. Writing the test cases is also an art as testing is, where both require skills, practices, failures and the explorations.
  • If System Requirements are written in a document, then is that document itself is the requirement(s)? Requirement document(s) has (ambiguous) words which describe the requirement(s); and the document(s) are not the requirement(s). Man makes mistakes while writing, so computer can also do the same.
Computer or document model does not tell the requirement(s) or whether what I am writing is correct or incorrect or this is what was expected by the user or user does not want this. In simple, document or document software model does not ask questions or answers for what is in my thoughts about requirement(s). It just processes whatever I give, if it is able to take what I give and I perceive this as computer as understood my question and given the solution; where all these are nothing but an illusion. It appears to me as document software model has done what it was desired to do.

If sensing a impulsive feel like model under test is matching to requirement, then it is not too late to understand, testing is not matching or not just matching alone (as matching may involve few tests). 'Matching' reminds me the writings of Michael Bolton on Checking, Testing and Problem. One may feel the information from matching are sufficient but does not feel information from testing are enough, since it always reveals or shows new things apart from those seemed as matched and did not match.
  • Negative Testing and Positive Testing might be the textbook words. Whatever it might be, the information from so said 'Negative Testing' or 'Positive Testing' adds its own values. If inferred as value given from so said 'Negative Testing' is high than so said 'Positive Testing', then one day it might happen such that positive(s) can be negative(s) and negative(s) can be positive(s). I remember the words of James Bach, "Testing is infinite process of comparing the invisible to the ambiguous so as to avoid the unthinkable happening to the anonymous."
  • The information obtained from testing is more than the ambiguous strings 'PASS' or 'FAIL' or 'NOT EXECUTED'.
  • Tester cannot take the decision or tell to ship the model under test, but might make the influence on the shipping decision by decision makers with the information given from her or his testing. I don't know yet, how the moment would be if the decision maker is the only tester.
  • Challenging the assumptions might challenge statements, "No issues in the application" and "What do you do when you are not finding any issues in the application you are testing?"
  • Saying "I don't see any problem here" is a problem which might produce 'n' number of problems. Still seeing anything as 'no problem here', then questioning 'when it can be a problem?' or 'how it can turn to be a problem?' might help.

I owe all the credits to the people who participated in the said discussion thread.

A Tester does not ship the model he or she is (or will be) testing. A Tester ships the information from her or his testing.


  1. Written contents from me for the discussion thread:


    >> Please let me know what the 'issue' or 'issues' mean to you. And what others perceive for your understanding of 'issue' or 'issues'. Is both are one and the same? For example, wearing no sun glass might be a problem to one, but for other it might be comfort wearing no sun glass.

    >> When the 'issues' said by you, were not found?

    >> Was the 'application' said was available to use?

    >> Was the 'application' said was not yet built?
    Tester tests when the application does not exist or exist. When the application does not exist (unavailable to operate it by me on a machine) and I am testing it, it will be a kind of review. Review is also a testing. How do I infer now that still I am testing? Though, application was not available to operate by me, can I able to model it? If I am able to model it within myself, Can I test it and find ‘issues’ said by you?

    >> Who (or) the 'users' unable to find the 'issues' said, in the application? If found, what kind of ‘issues’ was found? Does *all* the 'issues' needed to find by the users, has been found? If ‘all’ inferred as no more issues, then reminds me of ‘Is there a problem here?’ and ask myself ‘What More Can I See Here?’ Seeing no Problem(s) is a problem which may produce 'n' problem.

    >> How can you infer and show that, 'I was TESTING' or 'I have TESTED' or 'I am TESTING'?

    >> Any particular approach, methodology, practice and technique were exercised and it did not show any 'issues' you said while testing? Or every available approaches, methodologies, practices and techniques was exercised and they all did not show any 'issues' you said?

    Let me do not automate myself just to find the ***********. I want to construct and build myself to discover, create, invent and reinvent the ***********.

    Rephrasing the heuristic "What do you do when you are not finding any issues in the application you are testing?", I infer it as:

    "What do you do when you are not finding A or Above 'N' Y issues in the application you are testing?"

  2. Let me do not automate myself just to find the ***********. I want to construct and build myself to discover, create, invent and reinvent the ***********.

    "***********" = information.

    Let me do not automate myself just to find the information. I want to construct and build myself to discover, create, invent and reinvent the information.

  3. Have you not written test cases?

  4. @Anonymous

    Have you not written any Test Cases?

    It is asking like:
    >> Have you not closed your eyelids while sneezing?
    >> And you have not opened your eyelids after sneezing if you are alive?

    I do write test cases.

    But, my writing of test cases is different. I don't write the test cases prior to any testing. My team encourages it. I collect the mission details and clarify them. I brainstorm with the ideas and write them down on a writable source. Upon making sure the test environment is available and usable for testing with required tools (not test automation tools and automation tools [I use open source or free tools] needed if any), I will begin to design and execute the tests simultaneously by making note of what I do, observe and perceive in the sessions.

    At end of the day or by the date of submitting the test report, will convert them to test cases as this might help for the auditing purposes.

    The test cases might serve as the ideas for me and might be for others too. I keep the observations in the format where it can be put into understandable test cases -- which will have summary, description, steps to reproduce, observed behavior, tester expected or wished behavior, attachments, details of test environment configuration and resource used, heuristics and oracles made use, test data, possible impact of the behavior observed and investigations carried out.

    I don't depend on test case(s). They are the references for me and who need it. The test report document will have the details of the test sessions. I will focus on test design and execution and then on test cases on priority basis.

  5. I understand 'Quality' is not in the software which is used, but it is the emotion of the user when the model is used.

    Can you explain it.

  6. @ Anonymous
    I understand 'Quality' is not in the software which is used, but it is the emotion of the user when the model is used.
    Can you explain it.

    Value is not anonymous but it is onymous, but "how" is the question I believe which made 'Anonymous' to ask this.

    You love your mother right? Your mother loves you right? If yes, how would you measure the love, your mother showers to you and the love you have for your mother? If no, still how do you measure it?

    I believe there is a kind of thinking and imagination would be going on now about the measure in your mind. But whatever you measure, it would be still less for the love your mother gives to you and for your love to your mother. Love cannot be measured but it is surely valued and that is the quality of love. Means it is understood when felt rather than just seeing or hearing or knowing it.

    Probably here the love and its value is seen in the area which is not viewable or not available or not exist or not seen or indescribable; but still we create it and felt and we term it as the emotions.

    Anything and everything depends on how we look and feel at it and so our emotions are. More the emotions, more the value is. But what kind of emotions do I have shows what values it gives for me and I give for it.

    So as the quality is not in the software model given to the user. It is in the feel or the emotions of the user when she or he used or using the shipped software model.

    I did chose ‘love’ in above written context since most of us all would have felt mother’s love and know its value; if not still we know what it is, when we don’t have it or never felt it. Yet another context: also think of the place where you are standing or seated or walking or running or sleeping or whatever, it has no enough or sufficient oxygen to breathe and you are feeling suffocation. How you feel being there (emotions) and what value you give for that place? Each one of the context can have contexts. Again it depends on, how you look and feel at anything and so the nature is.

    If willing to talk, discuss and debate upon our ideas and thoughts, please write a mail. We can meet in any one of the public parks if you are in Bengaluru. If not, still we can talk. I am waiting to meet and learn from you.


Please, do write your comment on the read information. Thank you.