Testing Mindset

Quality is defined on the basis of the criteria evolved from the standards. Rather standards are the dimensions of Quality.

QA's (hereafter tester) job is to ensure that the software application/ product has been developed in compliance to the target specifications, set functions and up to customer's expectations. Tester's role (as per the textbooks) commences at the very inception of a software project and spans over the complete SDLC. Wow! that's quite some thing!

       Testers work with developers and customers in a very interactive manner, holding frequent meetings (which are brief though), discussing ins and outs of a design, functionality, exit criteria, etc etc. They employ formal testing techniques in all of our tasks and yes they are Agile too, just like developers. Testers are responsible for formal certification of a software build as a Release Candidate.
    
       When i started my career as a Tester, my seniors (more experienced testers) adviced me to have a negative approach towards the applications else i wouldn't be able to find bugs. Projects kept changing but the word of advice remained the same. It is now almost 9 yrs since i have been a tester, yet somehow this word of advice has never convinced me. The word 'Quality' invites attention to the fundamentals which envisage the probing the application and identify likely, or probable gray areas. This involves in depth knowledge and rational application of testing techniques. Tester, as he gains experience, domain knowledge, learns testing techniques, puts in honest efforts into his work, tends to gain an insight of what/where can the defect havens be in application, where can things go wrong and thus he is able to quickly identify problems (read bugs/ defects/ issues). But this is a quality he has gained after putting his learning, unrelenting attitude to keep exploring the application under test. This no 'negative approach', but the will to weed out as many defects has he can within the stipulated time period (familiar term is 'QA/ testing time estimates')).
    
       Testers, should be rational to the extent of being critical if the situation demands, but should never have 'Negative Approach'. Being rational implies that after having done the preparations (understanding requirements), when a tester approaches to testing a functionality, he should test taking a formalized approach, considering testing techniques applicable in the context. Consider BVA (Boundary Value Analysis), don't we test for values inside and on the boundary too? Or is it just the outside values only (for which the application may or may not behave correctly). Testing for an integer input in a textbox, don't we test for largest integer value that can be accommodated in it or simply test if it accepts characters, special characters and alphanumeric values?.... We do.
    
       This implies testers actually make an objective assessment of the functionality under test. Their approach is to make sure that the application under test not only processes correct values, correctly, but is 'robust' enough to handle the incorrect values too.
    
       Also, on meeting fellow testers at different platforms (in my company, at conferences, over the Internet) a general perception that 'testers cannot be programmers' was found prevailing (you may disagree but ask any programmer and he will tell you). Objective bringing up this topic in this post is not to debate on this perception because i myself find it preposterous. The point that to understand here is that we do our bit and programmers their. Comparing 'apples and oranges' can only lead to ONE common thing, that, they both are 'fruits'. Similarly, tester and programmers both 'work on the same application', in different roles though.
    
         Testers and Programmers are known to have not so jovial relationship (well this a generalization :), please do not take personally). That's principally because pointing out someone's mistake is not something he/she would enjoy, certainly. How he/ she takes it depends on his/ her professional maturity, nature, tuning with the tester who reported the defect, (may be) position in the team and... may be a few more factors. Testers, therefore, should be very objective while reporting any defect. Their communication should be fact-based and neutral without criticizing the programmer. Blaming anyone or seeing the pessimistic side only is not healthy for the programmer - tester relationship. First, tester loses objectivity and secondly, ego tussles or quarrels between the two may affect the schedule of project's delivery and perhaps the overall quality of software. Also, having an out and out negative approach at work (testing, that is) sometimes begins to creep into tester's persona too. Believe me, i know a few testers who just cannot say/ think anything positive about any event happening around them. Being polite in communication, collaborative attitude with programmers and other testers is the way to go for a good tester, rather than battling it out.
    
          If testers can describe a defect as to what worked correctly, in a functionality and where did it break or what made it break, suggest workarounds (if any) that they used, it would give a positive reflection to the other team members including business analysts and programmers. Also, extending help in reproducing the identified defect time and again as needed by programmer works a long way in establishing a harmonious relation. Bottom line here is that  testers should be collaborative with programmers and not at daggers drawn, in the literal sense, that is.
    
        To conclude, a tester must have a positive mindset with the spirit to make the software better for the users and easy to mend (read fix defects) for programmers. Good interpersonal and communication skills, polite attitude towards peers, programmers, and other team members, help in getting his voice heard at all levels.