software testing services
Rex Black Consulting Services | software testing experts providing consulting, outsourcing, and software training
CALL US TODAY
(866) 438-4830
ISTQB certification testingISTQB certification testing ISTQB certification testing
PMI

Archive for the ‘software testing’ Category

Kind Words on our Web Resources

A new reader of the RBCS website sent some kind words that we want to share here:

The RBCS web site is outstanding. Only a few days ago, I was introduced to RBCS’ work via a CAI webinar. I’m delighted to learn from the online articles and publications about the many facets of testing. Enlightening concepts include: establishing relationships and involving other members of the project team into the testing process, aligning testing goals with the business client’s goals via risk-based testing, and examining the topic of measuring to ensure that we fully understand what we’re measuring and why.

Bill Minckler, MBA, PMP, CLSSBB
Senior Project Manager State of Ohio

Thanks, Bill.  I’m glad you find the resources useful.  I hope you’ll subscribe to the RBCS monthly webinars, which are also free resources, focused on content not advertising.  You can catch then on our YouTube channel, or better yet, attend live to earn PMI PDUs and participate directly in the 30 minute Q&A at the end.

Useful Pairwise Testing Links

As people familar with my books, webinars, and training on test design techniques know, there are a few situations where pairwise and other combinatorial testing can make a lot of sense, especially for higher-risk systems.  Following a webinar, listener Terry Croskrey sent the following useful links:

I first got introduced to you on your ITUNES Podcasts and then your books. You are an excellent writer and presenter and I appreciated your enormous contribution to the Profession of Software Testing!

Thanks, Terry.

I wanted to pass on some recent software I discovered  for ALL Pairs and Orthogonal Array creation…that is easy to use.

Article: http://msdn.microsoft.com/en-us/library/cc150619.aspx

PICTS: http://download.microsoft.com/download/f/5/5/f55484df-8494-48fa-8dbd-8c6f76cc014b/pict33.msi

NIST free software: http://csrc.nist.gov/staff/Kuhn/kuhn_rick.html

ACTS GUI software: http://csrc.nist.gov/groups/SNS/acts/index.html

I’d add to this the link http://www.pairwise.org.

Test Strategies for Agile Situations

Following today’s webinar on test strategies, listener Cees Jan had some follow-up questions.  I’ll address them below, with answer interspersed in the text.

Rex,

 I really enjoyed your webinar.

Thanks, I’m glad it was useful for you.

Here is a question you did not get to: Hi I am what would qualify as a “falsifier”: Find the worst-case scenario and see how product behaves in terms of robustness and graceful termination. Quite the opposite of regression testing which I consider “trivial pursuit” (good for build stability and sanity, but never uncovering new defects). Would that be a wise strategy? I get comments that it is far-fetched, but I am stretching the limits of a system and see where it fails. It provides a lot of eye-openers. CeesJan

It sounds like, based on your earlier question the webinar (which I did answer), that you are basically following a reactive test strategy.  You are apparently (based on this comment) focused on finding a lot of bugs, especially by checking out unusual circumstances and extreme conditions, which isa typical characteristic of reactive testing. 

I’m a bit concerned about omitting regression testing, though.  Far from being “trivial pursuit” (though I realize it’s not fun when done manually), in Agile lifecycles the high rate of change makes regression risk very significant.  If you are no addressing regression risk, who is?  Are the developers doing good automation unit (e.g., with J-unit) and feature verification tests (e.g., with Fitnesse)?  If not, then the confidence-building and risk-mitigating objectives of testing are probably not being met.

The above sounds like reverse engineering: lack of requirements and undocumented legacy code force me to this “out of the box” methodology/averse strategy. Reading books like black box testing (Beizer) and black swan (Taleb) inspired me too much, I guess.

 Certainly, in testing we have to play the hand we’re dealt.  If you have no requirements and no useable documentation, then this will often force you into a purely reactive test strategy.  However, you should be aware of how limited such a strategy is.  I would think that adding analytical risk based testing, along with addressing the regression risks, would make sense.

Regards, Cees Jan den Haan (IQSTB Practitioner, CAT)

I have to correct you here, Cees Jan.  The ISEB Practitioner certification is not part of the ISTQB program, and neither is CAT.  The ISTQB program has the Foundation, Advanced, and Expert certifications.  I know that some European training providers have created confusion on this point (perhaps for marketing purposes), but it’s wrong to associate those two certifications with the ISTQB.

How Long to Become Effective?

I was recently in Moscow to give a presentation on testing and quality at the Microsoft QA Day event there.  After my talk, I had a conversation with a software tester, who followed up with an e-mail.  I’ll respond here to Nataly’s questions.

Dear, Rex.

First of all I want to thank you for your speech on the Microsoft QA Days in Moscow. Do you like the snow in late March? :)

Well, it was a bit cold while I was there.  However, having my expectations shaped by books like War and Peace, Crime and Punishment, Ten Days that Shook the World, and Doctor Zhivago, the wintry landscape was exactly what I imagined.

You may remember, I came up to you at the end of the day with the question about participation of the test team in reviews and risk analysis. But because I have not had sufficient practice in conversational English, I could not properly ask the question :(

Certainly, Nataly, your English–written or conversational–is vastly superior to my Russian! :-)

I will try to formulate the question more correctly. I’ll be very grateful if you could respond to my letter. Imagine that there is a test team with the appropriate skills, which should participate in review or risk analysis. Also imagine that the team was trained before the partisipation: they read the corresponding books about the review process or risk analysis process.

Well, Nataly, I’m not sure I would consider just reading a book on risk analysis or reviews sufficent training.  It will be for some people, but many of our clients find that they need a little more help than that before they can become truly effective.

Despite the preliminary training, we can expect that the result of the first participation of the team will be low or zero, because of the lack of experience. However, management expects that the money invested in training will pay off immediately. Therefore, it would be wise to prepare them in advance to that the benefits of the participation of the test team will not be visible immediately.

It seems that, if all management did was pay for two books, one describing risk analysis and another describing software reviews, they can hardly have high expectations about how much behavioral and capability change is going to result from that extremely small investment.  What they are going to pay for, in that situation, is the low efficiency associated with the series of practical review or risk analysis sessions that is necessary to learn-by-doing. This is exactly what you are describing.  It’s often more effecient to pay for a training session, since, if the training is carefully chosen and the participants apply themselves to it, the participants will leave the training ready to be effective in their first review.

Could you please tell based on your experience, how much time (in average) usually pass before the moment when the participation of testers will bring tangible benefit? 1 review? 2 reviews? 3 reviews…?

So, we have a one-day training for risk analysis, and a two-day training for reviews.  When we train people in how to do reviews or risk based testing, we find that they are immediately effective upon leaving that training. That’s not to say that they don’t continue to get better over time, but they are immediately capable of participating in an active and contributing fashion.  However, if all the people do is read a book, it’s hard to say what level of effectiveness they would have. 

The reason training is so much more effective than just reading a book is that training–at least good training–includes hands-on, practical, realistic exercises.  This is true for any subject.  Our training on risk based testing and reviews involves actually doing a risk analysis or reviewing a requirements specification.  The instructor is involved during the exercise, to guide the participants to success.  That way, the participants leave the training having actually, effectively and efficiently, carried out the process. 

With a book, even a book that includes exercises, there is no instructor there to help guide the reader through the process.  So, if the reader gets confused, or gets stuck, or thinks they know what they are doing but is actually wrong, the capability gained may be low.

I fear that managers might say something like: “testers spent so much time studying the theory, they spend time and money to the participation in review, so when we can see the benefit of their participation?”

Yes, this is a significant risk.  If testers get involved in activities like reviews and risk analysis, and they are not capable of carrying those activities out, that can cause significant damage to the test team’s credibility and lead to managers deciding not to include them in the future. 

Thanks in advance!

Sincerely, Nataly.

Thanks for getting in touch with me, Nataly.  I hope my response has been helpful.  If you do decide to pursue the avenue of reading books, please be sure that you arrange some exercises, just with the testers, before you try to participate in a real review or to initiate risk based testing.  However, I would recommend that you seek out good training, training that includes hands-on exercises and instructor support, to improve the odds of success. Alternatively, if you have a person in the organization who can mentor the testers, someone with experience in reviews or risk analysis, cross-training can also work.

Misusing Software Process Metrics as People Metrics

I had a query come in about a sample exam question in our Advanced Test Manager course.  Shukti asked me to confirm the answer to the following:

A given organization is using reviews for development work products like code, requirements and design specifications; test work products like test plans, quality risk analyses, and test design specifications; and, documentation and help screens. The review processes have been in place for two years and are delivering excellent financial, quality, and schedule benefits.

You are attending a management team meeting.  A senior executive raises the need to update the objectives by which the individual contributors are measured on their yearly performance evaluations.  He suggests using defect counts from review meetings.  He circulates a draft plan.  Under the plan, people will be rewarded based on the number of defects they find in reviews.  Further, people will be penalized if items they have produced incur too many defects during reviews.

Which of the following is a psychological factor affecting review success and failure that is likely to cause such an initiative to undermine the current success of the reviews?

  1. Scrutinize the document and not the author.
  2. Focus all participants on delivering high-quality items. [Correct]
  3. Try to find as many defects as possible.
  4. Assemble the right team of reviewers.

Here’s why that answer is correct.  Bonuses and other financial incentives/disincentives are based on the assumption that people are basically rational economic actors who will behave in a way to maximize their financial situation.  (Now, we can have a whole separate discussion about whether this assumption holds perfectly in all situations, but it really doesn’t need to be perfect, as long as more often than not it is true.)

So, in this scenario, what will the reviewers be focused on?  Not on delivering the highest quality items, but on finding the maximum number of bugs in each item and “claiming” those bugs for themselves (i.e., squabbling with other reviewers over who should get credit.)  What will the authors be focused on?  Arguing about every single bug that reviewers report, trying to insist that the document is perfect.  None of these behaviors is supportive of increased quality, and the authors’ behaviors are directly contrary to that goal.

In short, a really bad idea.  I wish I could say that I never saw organizations make this kind of mistake with process metrics (i.e., mistaking a software process metric for a people metric), but unfortunately it is all too common.

Missing Information a Bug in Requirements

Last week, I had a question arrive from a reader of one of my books, Pragmatic Software Testing.  The reader, Akhila, wrote:

Dear Rex,

I picked up your book with a hope to learn more about testing, as I’m new to testing. I’m through with a nice course in testing, but I’m yet to land a testing job. All said, I’m glad that your book is serving my appetite for learning more. I’m thoroughly enjoying reading your book. Little concern though is that, I’m still not finding prototype K.1, K.2 etc which you mention in the appendices. By the way, I’m going through the Indian edition of the book.

Hope to get a response.

Thank you for a wonderful bundle of knowledge.

Regards,

Akhila Hegde

Akhila, you are referring to the screen prototypes mentioned in the Omninet Marketing Requirements Document, but not provided in the requirements or anywhere else.  This is actually a bug in the requirements, one that sharp-eyed readers (such as you) typically find when they do the review exercise in the book. 

Like most of the other bugs in that document, this is not an unusual problem in requirements specifications.  Referencing information that cannot be found, or, when found, turns out to be marked “to be determined” or just an empty template, is a problem that many testers (and others) encounter with technical documents of various kinds, requirements included.

In this case, if you don’t find the bug in a requirements review, you’ll certainly run into it when you go to create tests.  This is one reason why early test design is so useful.  The attempt to create tests often reveals problems in a requirements specification, sometimes even in specifications that were carefully reviewed.

Happy Software Testers

Are you a happy software tester?  According to this article, those of us in this profession are among the happiest, most satisfied employees.  I certainly enjoy the intellectual challenges of this career, and it’s rewarding, too, to be involved in such important work. 

What makes you happy about being a software tester?  Do you consider yourself a happy tester?  Share your comments with me and with other readers of this blog.

Independent Testing in an Agile World

My Agile Testing Opportunities webinar continues to stir up discussion.  A listener, Rana Zoghbi, commented:

Hello,

I have a small question concerning this presentation:

You have talked about the opportunities of agile in testing, but what about the pitfalls that a tester can encounter in an agile environment? I am pursuing the Professional tester course – Foundation level, and it mentions that usually an agile mode is hostile towards independent testing. Can you please elaborate further on this?

 Thanks,

Rana  

Thanks for the opportunity to clarify some points, Rana. First, in terms of pitfalls, yes, there are testing pitfalls associated with any lifecycle model, and Agile is no exception.  My presentation yesterday was focused on how Agile lifecycles offer testers cetain opportunities (also present with any lifecycle model), but, if you want to hear about the pitfalls, you can listen to my previous webinar, Agile Testing Challenges.

Second, whether Agile teams are “hostile” to independent test teams is something that varies widely.  We have a number of clients that are using Agile methods and have independent test teams.  In a number of those situations, the independent test team is well-respected and well-established as a complement to the Agile approach.  The way in which the independent test team interacts with the Agile teams tends to vary, so I’d recommend that you check out my previous webinar on Test Organization Options for more details.

Historically, there certainly was some bad blood between Agile methodologists and professional testers. One early sign of trouble occurred when Kent Beck, the originator of Extreme Programming, gave a keynote at the now-defunct Quality Week conference in San Francisco in 1999.  In his talk, he was reported to have said that the entire concept of independent testing was going to fade away, since it would be made irrelevant by the Agile approach to creating software. 

Thirteen or so years later, we (the professional testers) are still here and still relevant.  There are still some dogmatists on the extreme fringes of the Agile world who reject the concept of professional, independent testers, sure.  However, my sense is that pragmatic software practitioners who are adopting Agile–and often adapting it in the process–see the value of independent test teams, staffed with professional testers, and providing testing services to their Agile teams.  I certainly see a lot of clients that are successfully doing so.

Estimation for Agile Testing

Vaibhavee K attended my webinar on Agile Testing Opportunities this evening, and asked an interesting follow up question:
Hello,

I have a query on Test Estimations techniques for Agile testing.

Which is the best method – Estimation should be done based on Sprints OR overall User story-Goal?

What kind of Estimation techniques can be used?
Regards,
Vaibhavee
Certainly some of the estimation on Agile projects need to be based on user stories in an Agile world. However, there are systemic testing concerns associated with any application.  We recommend that our clients–both in Agile and traditional lifecycles–use risk based testing to identify these systemic quality risks.  These should be considered as part of the estimation for each sprint.

Testing Terminological Confusion

Reader Art Salwin asks a good questions about an interesting distinction:

There seems to be quite a bit of contradiction in the literature between test conditions and test cases. Some places say the conditions have expected results (IEEE 829, for example). Other places say the cases have the expected results (some of the ITSQB study guides). There’s also disagreement about how high level a condition is. Some put it at pretty high level (test electronic payment, for example), others get down to if good credt card, accept; if bad credit card, reject.

Well, Art, there certainly is a lot of variation in the usage of certain terms in testing.  A number of terms, such as “test case,” “test condition,” “test plan,” “test strategy,” etc., are in very common use, but almost everyone seems to mean something a little different by them.  In addition, we have people using different terms to describe things that are the same; e.g., “test procedure” and “test script” and “test case.”  So, we get a lot of miscommunication in our profession.

To clarify communication, one thing I suggest, when talking to someone about testing, is to make sure that you’re speaking the same language.  If someone uses one of these common test terms, asking them what they mean by that term, and what specific contents he or she is referring to. Variation exists even within organizations, so a quick check to make sure you’re talk to each other, not past each other, is always a good idea.

Within an organization, it’s a good idea to adopt a single glossary for testing terms.  The ISTQB glossary isn’t perfect, but it is being constantly perfected and it’s certainly the most comprehensive testing glossary out there.  So, that’s probably a good place to start. 

It’s also important to adopt templates for common work products, because a definition by itself will not suffice.  For example, you and I could both agree on the ISTQB definition of the phrase “test strategy” and yet write different documents.  It’s important to remember that templates should be useful outlines that help people remember important topics to include in work products; templates are not straightjackets or substitutes for thinking.

So, going back to your original question.  If we take the ISTQB terminology and templates, then the test conditions are the higher level statements of what is to be tested.  In risk based testing, the risk items identified during a quality risk analysis are the test conditions (for more on how that works, see the video series on risk based testing on the Digital Library).  Examples of risk based test conditions would be “system responds too slowly to user input” and “system calculates incorrect report totals.”  In requirements based testing, test conditions are identified by an analysis of the requirements.  Examples of requirements based test conditions would be “check input field validation” and “check tax calculations.”  As you can see, these are at a high level.

The test cases are then developed to cover the test conditions.  One or more test cases should be associated with each test condition.  In risk based testing, the number of test cases for each test condition is determined by the level of risk associated with the risk item.  In requirements based testing, well, determining how many tests to have for a test condition is one of the problems with a purely requirements based testing strategy.  If you use a blended risk based and requirements based testing strategy, you can associate levels of risk with requirements to determine how much to test.

The test cases themselves can be a various levels of detail.  If you check Managing the Testing Process, 3e, you’ll find a discussion in there about the level of detail in test cases.  If enough people are interested, I can post some of that information on the blog.



 
`