Feed aggregator

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

CAST 2010 is a conference that focuses exclusively on testers by teaching improved test practices, honing testers skills, discovering techniques and exploring new solution paths.



Testing - Programming - Business - Commercial Services - Training and Seminars

Learn agile coaching strategies and how to maintain project focus and goals from a consultant.



Project management - Agile Development - Business - Management - Agile

Learn how to take on user acceptance testing when there is no input from the client side using these expert techniques.



Acceptance Test - Tests - Programming - Commercial Services - Open Source

Developing a test plan when crucial documentation is not present can be tricky. Expert Karen Johnson teaches how to assemble a test plan when documentation and necessary information is absent.



Test plan - Tests - Business - Electronics and Electrical - Test and Measurement

Before defining a security test plan there are a few questions that need to be answered. What are the security features you are planning for, what vulnerabilities concern you most and what kind of testing do you need to do to accomplish your goals.



Security - Application security - Test plan - Consultants - General and Freelance

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.

I came up with this yesterday while running my agile acceptance testing workshop for a client.

Sounds familiar? Read How to implement UI Testing without shooting yourself in the foot

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.)

Measurement is the most central concept in any performance-related activity. If you are not measuring you are blind. As important as measuring per se is collecting the right measurements. Which metrics are the right ones depends on what you want to do. However there are some general principles which – when followed – can make [...]

During last weeks webinar – Charlie Weiblen from IntraLinks talked about how the manage performance of their SaaS running in their private cloud. You should listen to the full recorded webinar to learn more on how they transformed from traditional performance monitoring to performance management. As a teaser to the webinar I want you to watch [...]

A client of ours recently contacted me with the question: We use Keynote, WebPagetest and dynaTrace AJAX – but we get different results with these tools/services. WebPagetest tells us that our page is very slow – but dynaTrace on my local machine does not. What can be the problem here? What’s the difference? I took a [...]

If you care about Web Performance then you should check if there is a local Web Performance Meetup Group in your area. Jonathan Klein just recently started a new Group in Boston. Sergey Chernyshev runs his Group in New York City. Both guys invited me to give a detailed Hands-On overview of the latest dynaTrace AJAX [...]

An Oracle database provides several v$ views to query information about the database instance, including statistical information that can be used for monitoring and problem analysis purposes. Rene Nyffenegger wrote a nice Summary on Oracle’s v$ views that gives an overview of all available views. The following illustration shows [...]

dynaTrace Forums have been launched to give the community a new platform to interact. dynaTrace AJAX community members will get access to the dynaTrace AJAX Forums – commercial dynaTrace community members will additionally get access to the dynaTrace APM Forums. Whether you have feedback on dynaTrace, feedback or ideas for new dynaTrace Community Plugins [...]

I am hosting a Webinar with IntraLinks this Wednesday. The following overview of the webinar is taken from the guest blog I wrote for the IntraLinks blog as posted on July 13th 2010: —- The Cloud has become the hot topic in the past year, with many major technology leaders (Amazon, Google, Microsoft, SalesForce.com, etc.) [...]