mopdf.com

I agree with Jim. Aphorisms are nice, but easy to misinterpret according to your cultural bias. Theaphorism says real quality improvement always starts, not finishes, with knowing what your customerswant. That means that if you don't know what your customers want, you aren't ready to assure thatyour "quality improvement" steps are really quality improvement steps at all.Secondly, the aphorism states that you must know what your customers want, not what they think theywant, or what you think they need. To take Jim's example, your customer probably doesn't want highmaintenance costs, but quite likely doesn't understand the technical issues that will raise maintenancecosts. It's the job of the professional analyst/programmer/designer to help the customer understandthese issues.But suppose the customer, after being informed, still says, "I don't care. Just give me the quick-anddirty solution." Then your professionalism comes into play, just as it would for an engineer or doctor. Ifyou believe that your informed customer really wants something that you cannot support professionally,then you politely excuse yourself from the project—just as a physician would do if asked to performdangerous and unnecessary surgery. If you claim to be a professional, then you cannot work withcustomers who don't want professional work, as you understand it and communicate it to them.The first measure of qualityThis professional approach to quality definition is not very satisfactory to those would-be Pattern 2managers who want customer and software engineer to toe the same line, regardless of their personalconvictions. One of the first things such a software Stalin tries to do is to make measurements—usuallyof quantity because they have no idea how to measure quality.Once they discover that measuring the quantity of junk doesn't accomplish anything, they start to focuson measuring errors—declaring them to be measures of quality. This is premature for a Pattern 1organization trying to become a Pattern 2. Direct observation of customer satisfaction is needed toprovide the business motivation for a true transformation.Direct observation of customer satisfaction is not easy, just necessary. Real quality improvementalways starts with knowing what your customers want, and possibly what they need or expect. That'swhy we'll next pursue the subject of measuring customer satisfaction.Helpful Hints and Variations1. When cost accounting changes, quality changes. This is so because quality is perceived value, andcost accounting changes perceived value. In a mail-order company, when the time for answeringcustomer inquiries ceases to be "overhead" and starts being charged directly to each transaction, theperceived value of a speedy, on-line inquiry system grows. Sometimes a cost accounting change isneeded to motivate people to want the right things.2. Quality can change when a system is moved to a new environment. The first time I saw the AppleLisa (precursor to the Macintosh) I was visiting a client in Holland. They had purchased six Lisas tosee if they wanted to outfit their entire research laboratory. Unfortunately, the Lisa was hardwired forthe size of American standard letterhead, not the European standard A2 paper. Some Americansthought of the Lisa as a high-quality machine. Few Europeans did. All six machines were returned,never to be seen again.Teatimewithtesters.comJuly 2013 11

3. You can also change the quality by changing the image. This makes advertising possible—as well ascon games. If quality were not in the mind of the beholder, then vaporware would not exist.4.It's perfectly legitimate and reasonable for a company to choose which customers to shoot for, andwhich to ignore. If they make a wrong choice, however, it will hurt their business. They can have a"high quality product" and fail, because what they really have is "a product that would be perceivedas high quality by people who don't get to perceive it." So is it "really" a high quality product? This isa bit like the question of a tree falling in the forest if there's nobody there to hear it, but it comes upoften because companies do fail in this way. Saying, "But we did have a high quality product," is away for the company's backers and employees to feel a little better about their failure.5. Dawn Guido and Mike Dedolph say, "Perfectionism is one of the main reasons we over-engineerprojects. Although perfectionists may be logically convinced that your definition of quality is correct,the emotional side of this issue is still unresolved. Knowing this doesn't help us deal with theperfectionists we work with (including ourselves)."I agree. I will write a book on this subject—as soon as I have the right answer.Seriously, though, a future volume will deal more with this issue. In the meantime, Mike offers a goodparadigm from his martial arts instructor, Stuart Lauper. "Be happy about your progress, but alwaysdiscontented enough to continue to improve your skills." This is a good measure to apply toprogrammers or managers who apply to you for a job.Summary1. To produce quality software you need to know: "What is the quality of this product, right now?"There are two different approaches to answering this question—the direct approach and theindirect approach.2. For many people, "quality" is such an ambiguous term that nobody could be against it. Ultimately,everyone has the same definition of quality, and it goes something like this: "Quality is whatever Ilike."3. Quality is relative. Quality is value to some person. Value is what are people willing to pay to havetheir requirements met. Perfectionists whose strongest desire is to find the one right way will notbe satisfied with this relative definition of quality. But, then, perfectionists won't be satisfied withanything, so forget them.4. Many software organizations today are so overloaded with quality problems that they are no longercoping effectively with their business of developing software. Yet many managers fail to recognizethe relationship between this overload and quality problems.5. Managers also fail to recognize the relationship between their own actions and the results they'regetting.6. Every software problem is a quality problem. The Zeroth Law of Quality says, If you don't careabout quality then you can meet any other requirement. If you don't have to control quality, youcan control anything else.Teatimewithtesters.comJuly 2013 12

7. Quality is the most direct software measure we can find, and the only direct way to measurequality is with the people whose ideas count. The ultimate political question is, therefore, Who getsto control the definition of quality?8. Power corrupts. And what power corrupts most thoroughly is the ability to make meaning ofobservations. When software developers control the definition of quality, they may do well in theshort run, but they will ultimately drive their customers to the first competitor they can find.9. The measurement of the absence of errors is not the same as direct measurement of quality. Realquality improvement always starts with knowing what your customers want. That's the only directmeasure of quality.Practice1. Advocates of function points claim that one of their advantages is that they measure the size of anapplication from the user's point of view of functions provided. Present some arguments that wouldsupport this point of view. Present some that might invalidate it.2. Quality can also depend on when you count the customers. Over what period of time does theirvaluation count?3. We can contaminate the direct measurement of quality, by the process we use to select the peopleused to determine quality. For example, early users of a product are not typical of later users. Nor areearly non-users typical of later non-users. Nor can the developer's employees be considered typical.How would you go about choosing "typical‖.Tutorial on ‘Software Test Attacks for Mobile and Embedded Devices’Today's expectations for many software testers include addressing mobileand embedded devices. Unfortunately for many companies, churning outcomplex or critical mobile and embedded applications while keeping pacewith emerging technologies is fast becoming the norm rather than theexception it was just a few years ago. Competitive pressures place a burdenon software testing resources to succeed with shortened project schedules,minimal strategic planning and/or staff new to mobile and embeddedsoftware.In this tutorial, Jon Hagar and Jean Ann Harrison will provide specificin depth test attacks aimed at uncovering common mobile-embeddedsoftware bugs.Jon HagarFind more about this tutorial HERE.Teatimewithtesters.comJuly 2013 13JeanAnn Harrison

BiographyGerald Marvin (Jerry) Weinberg is an American computer scientist, author and teacher of the psychology andanthropology of computer software development.For more than 50 years, he has worked on transforming software organizations.He is author or co-author of many articles and books, including The Psychologyof Computer Programming. His books cover all phases of the software lifecycle. They include Exploring Requirements, Rethinking Systems Analysis andDesign, The Handbook of Walkthroughs, Design.In 1993 he was the Winner of the J.-D. Warnier Prize for Excellence in InformationSciences, the 2000 Winner of The Stevens Award for Contributions to SoftwareEngineering, and the 2010 Software Test Professionals first annual Luminary Award.To know more about Gerald and his work, please visit his Official Website here .Gerald can be reached at [email protected] or on twitter @JerryWeinbergHOW TO OBSERVE SOFTWARE SYSTEMS isone of the most famous books written by Jerry.This book will probably make you think twiceabout some decisions you currently make byreflex. That alone makes it worth reading."Great to understand the real meaning of nonlinearity of human based processes and greatto highlight how some easy macro indicator cangive info about your s/w development process."An incredibly useful book. Its sample can beread online here.TTWT Rating:To know more about Jerry‘s writing on softwareplease click here .Teatimewithtesters.comJuly 2013 14

Speaking Tester’s MindTeatimewithtesters.comJuly 2013 15

Michael bol mike talk sTimejanetFionaWhen I started off on my first software job, I worked in a company of a hundred employees who weremostly white, male. Oh we had a few women on staff to answer the phones, but when it came tomanaging, testing, and coding, it was men all the way.Fast forward 15 years, and I have recently finished at Kiwi bank, where, on reflection, I was in theminority on the team being “the white male”, not the majority.As software and the areas it touches expands and continues to grow, so the people inside the industrycontinue to diversify. Change which expands our family can only be a good thing, but it doesn‘t comeeasily.Ironically, most of the ―old guard‖ in the software industry were probably more the school outcasts,seen as nerdy or misfits. I spent a lot of time as a 10 year old in the early 80s going to libraries tryingto find about computers, and how they worked. My teacher tried to discourage me (yes, discourageme from using the library) saying computers would not change the world. I’ll let you be the judge ofwho won that argument.When the first home computers came out, a small gang of us would swap software and coding tips, tryout each others‘ machines, share magazines and books which had listings to “write your ownsoftware”. We‘d show versions of these games that we‘d customised. Our friendship was based onsharing this passion together with other “common pursuits” such as Star Wars, James Bond, DoctorWho. We had black and Asian friends from school who were included, but let‘s be clear, it was verymuch a boy‘s club. Girlz were not allowed!Teatimewithtesters.comJuly 2013 16

And so, we‘ve grown up, got into the software industry, but part of the Boyz Club mentality remains.And ironically because of this, the school outcasts have unwittingly created a clique of their own.Take a look below, you‘ll see one of my desks at home – it‘s probably a desk that‘s typical amongstdevelopers Right next to it is a stack of comics and the complete set of Monty Python scripts. Yes, this should bevery familiar. Indeed, maybe the following video of programmers as perceived in the 80s is too closefor comfort Teatimewithtesters.comJuly 2013 17

This is one of the things which attracted many of us to the IT industry, it was almost a way to continuethose Abbot Beyne Boyz Computer Clubs, to take on a job, but like Peter Pan keep hold of thatchildhood passion for life. There is a great quote though about such people, ―I love his boyish charmbut I hate his childishness‖.When I started blogging about testing I wanted to do away with some of the business lingo, and makethe ideas accessible, and so as much as possible I used my cultural frame of reference.One of the articles I was most proud of was one I wrote after a tense week called “The KobayashiMaru Of Office Relationships”. This was a piece about how like the infamous test in Star Trek, ourrelationships in the office don‘t have easy win situations, but then looks at the dynamics of this.I later shared with a couple of friends at work, who although they enjoyed it, said a lot of it went overtheir heads, as they “didn’t really do Star Trek”. Sure enough, the article is loaded with references toTV and films which I adore – my friends who enjoy the same things really got a lot out of the piece,those who didn‘t found it didn‘t have the same power.And this is the problem of the Boyz Club of IT it‘s no doubt unintentional, but there is a very realcultural clique within IT. Like “The Kobayashi Maru Of Office Relationships” we use cultural folkloreand metaphors which are comfortable for us, because their use is so incredibly powerful.We need metaphors and examples, because they take concepts and make them more powerful andreal in our minds. We might talk for instance of love, but that‘s just a nebulous concept. But if we talkabout an example that we all know about, suddenly the talk of love becomes something so much morereal. We talk of ―Romeo and Juliet‖ and the metaphor stirs powerful feelings within us unless that iswe don‘t know the story. Then it becomes something baffling and confusing to us.I have to be careful here, because I‘m about to break my rules to give an example – a very nerdyexample. But in Star Trek: The Next Generation (now if you’re not a fan, please bear with me), thereis a superb episode called ―Darmok‖ which deals with this very theme. Humanity encounters an alienrace which it just cannot understand – all communication with them feels garbled.So the alien captain kidnaps the human captain Picard, and they go to a planet where they are allalone except for a terrible monster. The two captains have to team up to survive. The alien captainhopes that by forcing the two of them to unite against a common foe, they will learn to forge afriendship and see their commonalities.He‘s right. Proximity does lead to understanding. It turns out this alien race talks excessively usingmetaphors, metaphors that the human race doesn‘t understand. Put together like this Picard learnsthe stories behind their language and thus learns not only about their culture, but how to share hisEarth culture with them.Uncle Bob Martin wrote a superb piece in the aftermath of the Dongle-gate discussions (triggered bya developer who as mentioned “his boyish charm spilled into childishness”) on “is there sexism in IT”,in it he talks about the common stories he often uses to tell our “IT tales”. Whilst they can feel a lot ofTeatimewithtesters.comJuly 2013 18

fun for some of the core audience, in actual fact people outside these tales feel alienated. And whenhe found that out, he was horrified.And this is where a lot of problems stem from. A metaphor or instance which is powerful to one group,sometimes can be alienating to another. My Kobayashi tale worked well, using a lot of shorthand tofellow film geeks, but in the end the core tale about “working well with others, championing andchallenging” deserved a wider audience, not just film students (who by the way can be male ANDfemale). This is why when I revisited it for my book The Software Minefield, I tried to broaden itsaspects as much as possible, and read the piece with both my ―Star Trek fan‖ filters on and off.My friend Gizelle (a fellow sci-fi fan, you don’t have to be male to love sci-fi) did a video assignment on“Stereotype Threat” which I‘ve also found enlightening. In it she plays a female engineer, who feelingintimidated by her office, feels like she has to almost “androgenise” herself and dress and act moremale to fit in as “one of the boys”. When we stick to our Boyz Club of IT culture too much, that‘s whatwe do, we are saying that women can participate only if they “become one of the boys”, in essencewhat Gizelles character feels compelled to do.So should we feel ashamed of the IT culture that‘s built around us? No, as my friend Jo Foster pointsout, “stories are also handy shortcuts - tell the story once, and then you just need to refer to it, ratherthan having to tell the whole thing again and again”, they do have a power, but only in the context ofour audience. We have to be aware when members of our audience in our team or workplace do notunderstand those stories, because they will feel alienated by them. It should be our job to try andbuild bridges, not to build walls.As the Star Trek episode ―Darmok‖ highlights, to understand, we need to have an environment wherewe can mutually share cultures. That means us listening to others tales as much as talking of ourown, and always respecting passion in whatever form.Sharing is important. I learned to come from the Boyz Club of IT where only guys were in the allowedto be member to my views today, not because it was ―politically correct‖ and forced upon me, butbecause I worked with people of different gender, race, culture. And I realised that a lot of differenceswere merely cosmetic, because they all needed respect, space and a chance to prove themselves asmuch as I did. Don‘t be afraid to share, invite them to come laser tag with you, but if they invite youto Zumba or karaoke, give it a go as well.There is no single IT culture. IT is multicultural. We can either choose to build walls or build bridges.Choose to build bridges.Mike Talks is a test manager in Wellington, and self-confessedmovie nut. Always on the lookout to be educated as much as toeducate, he is also the author of the LeanPub book ‗The SoftwareMinefield‘. testers.comJuly 2013 19

Teatimewithtesters.comImage courtesy : MMVI New Line ProductionJuly2013 20

Teatimewithtesters.comJuly 2013 21

In the School of TestingTeatimewithtesters.comJuly 2013 22

nilanjanleahEdge.org is a website where some of the most renowned intellectuals discuss ideas and expressopinions. Every year, the Edge, asks a question which is answered by a large number of leaders invarious scientific fields. The question in 2011 was ―What scientific 1 concept would improve everybody‘scognitive toolkit?‖ There were 165 responses from eminent thinkers. In this article I have listed theconce

JIRA combines the powerful test management features of qTest with JIRA to create a complete QA management solution. Developed by Atlassian, a San Francisco-based provider of enterprise collaboration software for product development teams, JIRA is an industry-leading project and issue management software used . JIRA requirements can co-exist .