Software Testing
These days, many of us work in Agile teams or in integrated SCRUM teams. We're no longer the development team and the test team and the design team. Instead, we're one team working together to ship product. At least, that's what we tell people.divbr //divdivIf this is you, though, are you ireally/i a team? Is this really all one group going toward a single goal?/divdivbr //divdivThree simple questions will help figure this out:/divdivulliDo you assign tasks to individuals?/liliDo developers do test tasks when the team is crunched? Do testers help with system configurations when the team is trying to get set up for new development?/liliWhen a bug is found in the field, who gets yelled at and tries to figure out how to prevent that kind of problem from making it out to customers again? Your testers? Or your team?/li/uldivIf you're still playing "developer" and "tester" roles, then it doesn't matter whether you call yourself one team or two, you're still restricting yourself. You're still saying that you do your bit, the other guy will do his bit, and if we're all good and lucky, then good things will happen. That's not a team. That's a group of people./div/divdivbr //divdivA team is a group of people working toward the same goal. Some have more experience than others in different things, but if you're really a team, then each member will happily do whatever is standing between the team and release./divdivbr //divdivThe difference between a group and a team is very simple:/divdivbr //divdivbTeams succeed together and teams fail together. /b/divdivbGroups pass or fail, each individual alone./b/divdivbbr //b/divdivIf you want to be a team, be a team, not a group./divdiv class="blogger-post-footer"img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8341729382206275662-3558910408512807739?l=blog.abakas.com' alt='' //divimg src="http://feeds.feedburner.com/~r/Abakas/~4/HaDpVQVvqNw" height="1" width="1"/
Hi folks,br /br /Here is a great blog post from The Next Level Blog by Scott Elbin. Those who know me, know I'm big on the human factors in software development and testing. A big part of that is culture. One of Dr. Demming's 14 points is to "Drive out fear." What does that mean? Well, here's seven ways NOT to do it. See if you recognize any of them. Have a great day!br /br /a href="http://scotteblin.typepad.com/blog/2010/07/seven-simple-rules-to-create-a-fear-based-culture.html"http://scotteblin.typepad.com/blog/2010/07/seven-simple-rules-to-create-a-fear-based-culture.html/adiv class="blogger-post-footer"img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/24100580-5923955706602692205?l=randallrice.blogspot.com' alt='' //div
There are a number of techniques that can be used to gather software requirements. In this expert response, you'll be pointed to a learning guide that explains the differences, it will teach additional techniques and find out the key to successful business requirements.
Business - Retailers - Industry-Specific - Epicor - Small business
Jason Gorman quickly illustrates how to apply the Collapse Heirarchy refactoring to eliminate a lazy subclass
span style="font-family: Verdana, sans-serif;"There is a lot of talk about testers breaking software: articles, blog posts and even books on this topic. It seems that a lot of testers get their job satisfaction in breaking stuff and a sign of a good tester is that they can break anything. But when they’re testing, are they really breaking s/w? /spanbr /span style="font-family: Verdana, sans-serif;"/spanbr /div class="separator" style="clear: both; text-align: center;"a href="http://1.bp.blogspot.com/_YzKCMr-tcMM/TBtniIZf3OI/AAAAAAAAAPw/EhctHBHOAww/s1600/cartoon1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"img border="0" height="386" qu="true" src="http://1.bp.blogspot.com/_YzKCMr-tcMM/TBtniIZf3OI/AAAAAAAAAPw/EhctHBHOAww/s400/cartoon1.jpg" width="400" //aspan style="font-family: Verdana, sans-serif;"/span/divdiv class="separator" style="clear: both; text-align: left;"span style="font-family: Verdana, sans-serif;"If this was the case, different techniques for breaking s/w would have been created and refined over the years… /span/divspan style="font-family: Verdana;"/spanbr /div class="separator" style="clear: both; text-align: center;"a href="http://1.bp.blogspot.com/_YzKCMr-tcMM/TFLJypaqJ_I/AAAAAAAAARY/oEeqKKxiv_A/s1600/cartoon2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"img border="0" bx="true" src="http://1.bp.blogspot.com/_YzKCMr-tcMM/TFLJypaqJ_I/AAAAAAAAARY/oEeqKKxiv_A/s320/cartoon2.jpg" //a/divdiv class="separator" style="clear: both; text-align: left;"span style="font-family: Verdana, sans-serif;"Or /span/divspan style="font-family: Verdana, sans-serif;"/spanspan style="font-family: Verdana, sans-serif;"/spanbr /div class="separator" style="clear: both; text-align: center;"/divdiv class="separator" style="clear: both; text-align: center;"a href="http://3.bp.blogspot.com/_YzKCMr-tcMM/TFLGoz5zLNI/AAAAAAAAARA/eaEIgRq5ZcM/s1600/cartoon3_Hourse.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"img border="0" bx="true" height="400" src="http://3.bp.blogspot.com/_YzKCMr-tcMM/TFLGoz5zLNI/AAAAAAAAARA/eaEIgRq5ZcM/s640/cartoon3_Hourse.jpg" width="640" //a/divbr /span style="font-family: Verdana, sans-serif;"And possibly in a galaxy far, far away.../spanbr /div class="separator" style="clear: both; text-align: center;"a href="http://1.bp.blogspot.com/_YzKCMr-tcMM/TBtoC_p4SzI/AAAAAAAAAQI/_bgeb_wNM9Y/s1600/cartoon4_yoda.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"img border="0" height="320" qu="true" src="http://1.bp.blogspot.com/_YzKCMr-tcMM/TBtoC_p4SzI/AAAAAAAAAQI/_bgeb_wNM9Y/s400/cartoon4_yoda.jpg" width="400" //aspan style="font-family: Verdana, sans-serif;"/span/divdiv class="separator" style="clear: both; text-align: left;"span style="font-family: Verdana, sans-serif;"Another opinion which is very different is that testers don’t break s/w, but rather the s/w is already broken before testers get their hands on it. In this case, a major role of the tester is to identify where the software is broken. /span/divspan style="font-family: Verdana, sans-serif;"br //spanspan style="font-family: Verdana, sans-serif;"Initially, testers may question the s/w engineers’ abilities since they are delivering broken code. But on reflection, the errors may have been introduced before the coding had started and if it wasn’t for the engineer’s mistakes, the tester wouldn’t have a job to do anyway./spanbr /div class="separator" style="clear: both; text-align: center;"/divdiv class="separator" style="clear: both; text-align: center;"a href="http://1.bp.blogspot.com/_YzKCMr-tcMM/TFLIGeqTJfI/AAAAAAAAARQ/AhNW62KX5EA/s1600/cartoon6.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"img border="0" bx="true" height="400" src="http://1.bp.blogspot.com/_YzKCMr-tcMM/TFLIGeqTJfI/AAAAAAAAARQ/AhNW62KX5EA/s400/cartoon6.jpg" width="400" //a/divbr /span style="font-family: Verdana, sans-serif;"Therefore, the testing techniques and methods deployed by the tester when testing the s/w should revolve around identifying the areas that are broken. /spanbr /span style="font-family: Verdana, sans-serif;"br //spanbr /span style="font-family: Verdana, sans-serif;"When something is broken, it’s an error that has manifested itself as a software fault, or bug. The tester’s role is to spot or discover these bugs as they reveal themselves. An expert tester is able to spot them quickly, in an effective manner. /spanbr /span style="font-family: Verdana, sans-serif;"How do they spot them quickly? It’s because the expert testers believe in the ancient Chinese warrior Sun Tzu, who taught his men to “Know your enemy”. Expert testers know their bugs. They know where they often hide, know how they operate, what kind of diversion techniques they use and they know how they reproduce. /spanbr /div class="separator" style="clear: both; text-align: center;"a href="http://1.bp.blogspot.com/_YzKCMr-tcMM/TBtoaq7RynI/AAAAAAAAAQY/rDWhT6cKag8/s1600/cartoon5_cctv.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"img border="0" height="400" qu="true" src="http://1.bp.blogspot.com/_YzKCMr-tcMM/TBtoaq7RynI/AAAAAAAAAQY/rDWhT6cKag8/s400/cartoon5_cctv.jpg" width="400" //a/divbr /span style="font-family: Verdana, sans-serif;"Would you like to be an expert tester? To be an expert tester you need to start thinking like a bug, get in the bugs’ shoes. Get to know everything about bugs./spanspan style="font-family: Verdana, sans-serif;"br //spanspan style="font-family: Verdana, sans-serif;"br //spanspan style="font-family: Verdana, sans-serif;"Every time you approach s/w to test, think before you start: How would a bug reveal it self in this s/w? Or in short: What Would Bugs Do? This can be shortened so it’s easier to remember: “WWBD?” And if that is still hard to remember, there is lots of stuff out there you could order to help you recall “WWBD?”: T-shirts, wrists bands, mugs, etc. /spanbr /div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"span style="font-family: Verdana, sans-serif;"br //span/divdiv class="separator" style="clear: both; text-align: center;"a href="http://1.bp.blogspot.com/_YzKCMr-tcMM/TFLF9VmvxSI/AAAAAAAAAQ4/_lsf55Qj9-w/s1600/ladybirdflyMug.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"img border="0" bx="true" height="300" src="http://1.bp.blogspot.com/_YzKCMr-tcMM/TFLF9VmvxSI/AAAAAAAAAQ4/_lsf55Qj9-w/s640/ladybirdflyMug.jpg" width="640" //a/divspan style="font-family: Verdana, sans-serif;"Happy bug hunting :o) /spanbr /br /br /span style="font-family: Verdana, sans-serif;"*************************************************************/spanbr /br /span style="font-family: Verdana, sans-serif;"Of course, the ultimate testing expert doesn’t have an enemy. The ultimate testing expert works closely with the developers to reduce the number of bugs created in the first place… but that’s another story./spanbr /br /span style="font-family: Verdana, sans-serif;"*************************************************************/spanbr /span style="font-family: Verdana, sans-serif;"br //spanbr /span style="font-family: Verdana, sans-serif;"Trivia:/spanspan style="font-family: Verdana, sans-serif;"br //spanspan style="font-family: Verdana, sans-serif;"The first testers who came up with the idea that testers don't break software were most likely Cem Kaner or John Bach during the mid nineties. A gold star for anyone how cannbsp;confirmnbsp;the correctnbsp;date and place for this./spanbr /br /span style="font-family: Verdana, sans-serif;"Links:/spanbr /span style="font-family: Verdana, sans-serif;"The main theme of the post is around discovering bugs. This links well to exploratory testing, do check out Michael Bolton’s list of /spanspan style="font-family: Verdana, sans-serif;"a href="http://www.developsense.com/resources.html"resources for exploratory testing/anbsp;articles/blog posts./spanbr /span style="font-family: Verdana, sans-serif;"The next testing book I wan to read isnbsp;"a href="http://www.amazon.com/How-Break-Software-Practical-Testing/dp/0201796198/ref=sr_1_1?ie=UTF8amp;s=booksamp;qid=1276292942amp;sr=1-1"How to break software/a" by James Whittaker. He seems to have a different opinion to this blog post. I'll let you know if James changes my mind./spanbr /br /span style="font-family: Verdana, sans-serif;"Here’s another cartoon from /spana href="http://simply-the-test.blogspot.com/2010/04/different-goals.html"span style="font-family: Verdana, sans-serif;"Torsten J. Zelger/span/aspan style="font-family: Verdana, sans-serif;" about breaking software./spanbr /br /span style="font-family: Verdana, sans-serif;"*************************************************************/spandiv class="blogger-post-footer"img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/5551319643480633154-3887104905393975664?l=cartoontester.blogspot.com' alt='' //div
A couple weeks back (which means it’s now available on the Web), Larry O’Brien covered user testing to show that development shops could actually, you know, see how users work with a software tool.
Nut grafs:
There’s a part of me that loves user testing; the same part that enjoys visiting ThereIFixedIt.com and watching videos of people destroying their trucks by felling trees on top of them. I take comfort in believing, however briefly, that there are people more foolish than myself. My source code often makes me despair of my own sentience, but I like to tell myself that I wouldn’t need to be prompted to use a button marked “search.”
My major reaction to user testing, though, is often resignation. User testing invariably reveals distasteful work—layouts that need total reworking, dead-end navigation paths, and corner cases that the library API doesn’t cover. The interesting algorithmic stuff that you developed while surrounded by a stack of heavily annotated journal articles and intently pored over on a statement-by-statement basis? That stuff works fine.
Unfortunately, the temptation to skip user testing is often encouraged by clients. While experienced developers know that user testing will lead to a certain amount of dismay, inexperienced clients dismiss user testing because they’re invariably overconfident. I don’t think many are as bad as my above-mentioned client, who was confident that word would spread like wildfire that one could cycle colors by directly clicking on the product. More generally, the problem is the opposite: Clients have seen so many mockups and prototypes and test versions that they cannot see it with fresh eyes.
Keep in mind, QA, in all the situations where your organization is too cheap to provide user testing, you have to be the eyes of the user. Designers love their cutting edge design, but applications should not make only as much sense as a Christo or Serra installation. Applications should behave more or less like all the other applications in the whole world regardless for how much disdain the developers have for the bourgeois sensibilities of users. And so on and so forth.
But read O’Brien’s piece as usual.
An author identifies some of the ways Starbucks order taking and processing mirrors software:
I just returned from a 2 week trip to Japan. One of the more familiar sights was the ridiculous number of Starbucks coffee shops, especially around Shinjuku and Roppongi. While waiting for my “Hotto Cocoa” I started to think about how Starbucks processes drink orders. Starbucks, like most other businesses is primarily interested in maximizing throughput of orders. More orders equals more revenue. As a result they use asynchronous processing.
That’s all well and good, but we here at QAHY want to extend the metaphor further.
Ways Starbucks is like a development team:
- They’re very expensive for what you get.
- Anything besides the basic product costs extra.
- The customer is the only QA.
- Those who participate believe their in a superior class, but the rest of us use the word clique.
Ways Starbucks is not like your development team:
- Starbucks produces the same thing over and over again, so they get good at it, unlike your development team who build slightly different things using new technologies they want to learn on the fly. It’s like having every barrista be a trainee every day.
- Barristas won’t try to adjust a drink if the order changes in midstream. They rightfully throw it out and start again and sometimes charge you again. A development team will just try to remix the existing espresso, sugar, and flavor shot so that you get hot chocolate at the end instead of a triple Venti cappuccino.
- Starbucks gets its money up front and doesn’t have to wheedle and do just one more thing to get its paycheck.
- You like to see a Starbucks product or representative first thing in the morning.
And in closing, I’d like to point out that management from your software development team could probably run a Starbucks, but not vice versa.
Feel free to add your own below.
(Link seen on Megan McArdle via Instapundit. That’s enough chain of custody to introduce it as evidence, werd.)
While many software professionals would like to develop code for open source software projects, the best way to learn is to start with documentation and testing. Professional development and growth can be attained by contributing to supporting functions of open source projects.
Open source - Source code - Programming - Articles - Directories
Lazy classes add little value for the maintanance burden they incur. In this example, Jason Gorman illustrates how to safely inline a lazy class into its containing class.
I was reviewing this user interface designed in an old technology, when suddenly I was struck by the infeasibility of the maxlengths assigned to the fields:
Click for full size
That’s a maximum e-mail address of 20 characters. Chop 4 or 5 off for the domain extension, the dot, and the @ sign and suddenly you’re limited to a username and a domain name of 15-16 characters. If you’re not at MSN or AOL and an early adopter at that, you’d better hope that they call you on the phone if you’ve won.
Okay, aside from that, what’s the other problem on the page?
I've been doing a lot of phone screening lately, and there have been some real doozies. I've heard all sorts of things:divbr //divdivi"I left my last job because everyone was incompetent but me. It went through two whole teams like this." /i/divdivWow - ego coming through! There are definitely incompetent people out there but to run into such a high proportion says that you either have truly terrible luck .... or that there's something wrong with your idea of competence./divdivbr //divdivi"Oh, my weakness is I don't do automation."/i/divdivThis is only strange once you know that the position is for a QA Automation Engineer./divdivbr //divdivi"I'm just looking for a job before my skills get too rusty."/i/divdivOn the one hand, this one is kind of sad. On the other hand, he's not doing anything to keep up or expand his skills, apparently, and that's a problem. I don't want to have to push for every new learning experience./divdivbr //divdivThere are a lot of decent resumes out there. Phone screens really weed a whole lot out, though. Be careful what you say; the hiring manager is probably listening./divdiv class="blogger-post-footer"img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8341729382206275662-1136651773641216801?l=blog.abakas.com' alt='' //divimg src="http://feeds.feedburner.com/~r/Abakas/~4/iGw-D4Q4JMg" height="1" width="1"/
Based on a tweet this morning lamenting the dearth of proper test plan sample documents on the Internet, I put together a sample document in PDF format that you can use when putting together your own test plans.
You can view that sample here.
I hope that my regular readers and especially those of you who got here by a Google search find it useful for your testing documentation.
This does not represent a good practice of synchronizing your application data with the real world:
Twice we had ordered a pizza with extra-large pepperoni. Twice it had arrived without the extra large. See, the order is calibrated to hit everyone’s preferences, and my daughter will only have pepperoni, so: her half has pepperoni and extra-large pepperoni. But twice the pizza has arrived without.
“I’m going to call them,” I said.
“No, Dad, don’t! It’s okay! Don’t make a fuss about it.”
“Honey, a manager would want to know these things.”
So I called, and explained, and the manager asked if I ordered online. I said that I did, modern-type person that I was. That’s the problem. Extra-large has been discontinued, but it’s still on the online menu. Can you tell me what the printout on the bottom of the box said? I noted that it had elided the extra-large issue altogether. So the problem wasn’t on their end. [Emphasis added.]
This isn’t a simple change made on the fly, either. It’s a menu change determined probably by a national pizza chain’s HQ and telegraphed to its franchisees by semaphore or something. Somehow the change managed to dodge the people responsible for the Web storefront.
Forget keeping your application data synched with the other online data. Your application has to keep up with the real world, too. A lot of IT teams and vendors can rationalize not keeping up if the customer doesn’t keep up, but you need to make it easy to change and to grab your client/internal stakeholders by the lapels to ensure they keep you up to date.
James Lileks, from whose blog I took the anecdote, is a patient customer and does not blame his local pizza shop. However, another client will quit a brand for that sort of thing. Especially if that client is in QA.
|