Skip to content

Feed aggregator

How to Approach Application Failures in Production

In my recent article, “Software Quality Metrics for your Continuous Delivery Pipeline – Part III – Logging”, I wrote about the good parts and the not-so-good parts of logging and concluded that logging usually fails to deliver what it is so often mistakenly used for: as a mechanism for analyzing application failures in production. In […]

The post How to Approach Application Failures in Production appeared first on Compuware APM Blog.

Categories: Companies

How to test your eCommerce website

BugBuster - Tue, 07/22/2014 - 09:03

iStock_000020935925SmallIt may seem that once your eCommerce website is created, testing it is not such a big deal – developers did that before anyway, didn’t they? This assumption is far from true actually, since eCommerce, as other CMS-based and data-driven web sites, have a different set of key points to be tested.

Technical tests are not the issue here – again, this should have been taken care of by the developers - we are more concerned about testing the actual content. Do all the products have a proper description? Do all of them display a price? Are they all displayed in the correct language? Is the social networks bar displayed on each page? The more we think about content consistency, the more questions arise about what and how to test on an eCommerce website.

That is, of course, without forgetting some critical work flows for your business: the whole product purchase cycle and the customer registrationprocess.

Here we have compiled a small list with a few key points and tricks to test them:

Ensuring content consistency

Content consistency may mean different things depending on the website. In the case of a typical eCommerce application, a good strategy would be to check that, for each product, there is a product name, a price, a description and a picture. This is particularly easy to do with BugBuster thanks to its Shallow Explorer scenarios, that will set an automated crawler to go through your site clicking on links and discovering new pages. Unlike other tools, BugBuster works by actually producing click actions on the page’s DOM, and therefore its behavior can be controlled to, for instance, avoid interacting with some given sections of the page (headers, footers, menu) and focus on the content that matters. The following picture shows BugBuster‘s Shallow Explorer scenario:

BugBuster's Shallow Explorer Scenario

As we can see, one of the extensions that we can add to the scenario is a custom script, which is what we can use to check the content of each product page BugBuster visits. First of all, let’s confine the exploration to the  products listing by adding a DOM Element black list:

Blacklist DOM Elements Scenario Extension - BugBuster

In our example, since we are testing our KitchenSink eCommerce demo, we don’t want BugBuster to click on anything but the list of best selling products. The reason to write a black list instead of a white list (click only on the list of products) is that, depending on the page layout, this list may have different forms and CSS identifiers. The footer, header, sidebars and advertisement slots won’t.

Blacklisted CSS elements

Now, let’s add an extension with some custom code, so that BugBuster knows exactly how to assert that the content is OK. The next lines will check on each newly discovered page, provided it is a product page (detected by checking the existence of a breadcrumbs bar), that the title, details, price and picture informations are not empty.

BugBuster will crawl your eCommerce application by discovering new links to product pages, and automatically check content consistency on each new page it finds, until the session runs out of time or there are no more links to visit.

Checking products’ language

User language is usually a matter of life or death when it comes to eCommerce applications. If a French-speaking customer on a multilingual web shop suddenly bumps into a product explained in the wrong language (like German, Russian, Chinese, or anything she does not understand), high chances are that she won’t buy it. Again, with BugBuster it is so easy to test that the page language is the one expected! Just add a custom script extension to your scenario with the following code, and that’s it!

More information about BugBuster’s language module

Ensuring that social network widgets are loaded

Showing social network widgets on your website is a way to connect with your audience, and to tell your potential customers that other people, maybe within their circles, already trust your brand. Therefore, it is important not to forget them on any page of your eCommerce site! The following code will check that the Twitter Follow button is always present:

The product purchase cycle

Checking that users can purchase products by going through all the process is quite easy with BugBuster. OurBugBuster allows to do these kind of end-to-end tests with a single sequence of events, without the need to wait for pages to refresh or load. Let’s see an example, also based onMagento:

Customer registration process

Are you sure your potential customers can register in order to buy products from your web shop? A function outage here due to a poorly tested system would be dramatic! BugBuster‘s web-to-email feature comes in handy to test the full user registration and validation cycle. It is really easy to use, as the following code shows:

More information about web-to-email testing with BugBuster


  1. This test plan on Testing Web Sites
  2. This article on Optimizely
  3. This article and this one on PracticalEcommerce
  4. This article on

The post How to test your eCommerce website appeared first on BugBuster.

Categories: Companies

Ruby - If Ternary, Until, While

Yet another bloody blog - Mark Crowther - Tue, 07/22/2014 - 01:58
We’re making good progress getting some of the key basics of Ruby understood. Variables are of course central, Arrays allow a more complete way of data handling, Case and If statements are the building blocks of ‘flow control’ in our program.
In looking at these, we’ve also learned a few tricks with getting, printing, chomping and interpolating data and a few neat tricks to present and evaluate data in different ways, to get a True or False state so we know what to do next. That’s quite a bit in a few hours, congratulations if you’ve followed along so far!
With this stuff understood, let’s loop back on ourselves somewhat and add in more detail on a couple of things. To start with, let’s finish off a few more aspects of flow control.The if statement as we saw it before also has a shorter version, called the ternary or base three operator. Here’s an example:
a = 2a == 1 ? (puts "Banana") : (puts "Cheese")
Here we set the value of our variable a to 2, in the next line we ask does a equal 1? If True then puts Banana, else puts “Cheese”. In the brackets we could include whatever code we wish to, just like the longer form If statement. However, the ternary or base three version easily gets difficult to read and should only be used for small tasks. This might be concatenating two string or doing a quick piece of math.
In addition to Case and If statements, we also have Until and While loops available to us. These allow us to execute a block of code until a certain condition is trueor false.

·         For Until, the code executes so long as a condition is evaluated to false·         For While, the code executes so long as a condition evaluates to true
First, here’s an example of Untilin action:
c = 1
 until c == 6
   puts "C = #{c}"
   c +=1
We’ll see five lines printed to screen, stopping when c evaluates to 6, as the condition is now true. Note in the last line how we increment the value of our variable.Let’s look at an example ofWhile in use:
d = 1
 while d < 5 do
   puts "D = #{d}"
   d +=1
As with the Until, here we’ll see five lines printed and the code will stop executing once the condition is false. The do keyword is optional. However, it’s more correct to use it, just like adding then in our If statements.
Read More


Categories: Blogs

The Journey to a Software Testing Center of Excellence

Testing TV - Mon, 07/21/2014 - 23:39
What happens when the company that has engaged you as some kind of process expert has no clue how to test its applications & systems consistently or thoroughly? Where do you start? Where do you lead them, with what software testing best practices, tools, technologies? This will be a little personal journey through this rocky […]
Categories: Blogs

Upcoming webinar: Top tactics to reduce your open source security risk

Kloctalk - Klocwork - Mon, 07/21/2014 - 22:58

Open source is embedded in over 50% of enterprise applications and development environments today yet very few developers are aware of the inherent security risks. What steps should you take to maximize the benefits of open source software while substantially reducing risk?

Join us on Wednesday, July 30th for our “Top tactics to reduce your open source security risk” webinar that will explore policies and tools to help identify where issues can happen and discuss strategies to deliver safer, more secure software. We’ll look at a combination of open source governance and management tools along with static code analysis to see how they can assist you in managing the security risks present in your open source.

During this webinar, you’ll learn about:

• Building a comprehensive solution to effectively manage both known and hidden security issues
• Developing an OSS security policy
• Finding security issues in real-time, as you’re developing code

Wednesday, July 30, 2014
10:00am PT / 1:00pm ET

Featured Speaker
Dave McLoughlin, Director of Auditing Services, OpenLogic

Dave McLoughlin is the Director of open source auditing services at OpenLogic, a Rogue Wave company. He joined OpenLogic in 2006 with over 20 years experience in the software industry. He has experience in product management and pre- and post-sales support with companies that include Netscape, Frame Technology, and Motive Communications. Dave is based in Boulder, CO.

Categories: Companies

VectorCAST Testing Tool Supports MISRA C: 2012

Software Testing Magazine - Mon, 07/21/2014 - 18:51
Vector Software has announced that the VectorCAST software test solution now supports the MISRA C: 2012 (MISRA C3) standard. The new benchmark offers improvements to earlier versions and extends support for the MISRA C: 2012 C99 version of the C language (ISO/IEC 9899:1999). The VectorCAST software test environment is widely deployed in safety-critical applications that utilize the MISRA C standard, and the regulation is the most widely used set of coding guidelines for C language development. VectorCAST/Lint utilizes the powerful Lint source code analysis engine from Gimpel Software, and is configured ...
Categories: Communities

REMINDER: Share Your Opinions on the State of Medical Device Development

The Seapine View - Mon, 07/21/2014 - 17:30

Over 300 of your peers have provided their insights and opinions on issues affecting innovation, compliance, time to market, and other issues critical to developing tomorrow’s medical devices. If you haven’t joined them, there’s still time to participate in Seapine’s 2014 State of Medical Device Development Survey. You can help benchmark the medical device industry by sharing how your team manages core product development artifacts, compliance, and traceability.


What’s keeping you from improving?

The biggest issue preventing teams from improving their product development processes remains the same as 2013: budget. That’s really no surprise, given we’re still on a global economic roller coaster.

It is surprising, however, that the second biggest issue is “overhead involved in validating new tools or processes.” Only 27% total respondents identified it as an issue in 2014, which put it fourth place. This year so far, 47% have selected it.

What's keeping you from improving?

Budget is still the main impediment to process improvement in medical device development.

The traceability matrix takes you how long?

Building and maintaining a traceability matrix is often a mandated requirement for gaining regulatory approval to sell a medical device. Unfortunately, traceability matrices can be time-consuming to create and maintain. Most medical device development teams take hours or even days to update a traceability matrix. Are you among the few that can get it done in minutes? Or does it take you even longer?

How long does it take?
It takes most respondents hours or longer to generate a traceability matrix for their project.
Add your voice!

Take the survey today and help us continue to establish benchmarks for the medical device development industry. The survey is open to medical device development professionals through August 31. All participants will be emailed a free copy of the report after the results are tabulated and analyzed.

In addition, you’ll also be registered for a chance to win a FitBit One, an Amazon Fire TV, or a Withings Wireless Scale.


Share on Technorati . . Digg . Reddit . Slashdot . Facebook . StumbleUpon

Categories: Companies

Testing the Limits With James Bach – Part I

uTest - Mon, 07/21/2014 - 15:00

JamesBach150James Bach is synonymous with testing, and has been disrupting the industry and influencing and mentoring testers since he got his start in testing over 25 years ago at Apple. Always a great interview, James is one of our most popular guests and we’re happy to have him back for his first Testing the Limits since 2011. For more on James’ background, his body of work and his testing philosophy, you can check out his blog, website or follow him on Twitter.

In Part One of our latest talk with James, he talks about a future that involves a ‘leaner’ testing world, the state of context-driven testing outside of the United States, and why you’re “dopey” if you’re a manager using certain criteria in hiring your testers.

uTest: We know you don’t enjoy certifications when it comes to testers. In fact, in a recent blog, you mentioned that ‘The ISTQB and similar programs require your stupidity and your fear in order to survive.’ Do you feel like certifications are picking up steam when it comes to hiring and if they’re becoming even more of a pervasive issue?

JB: I don’t have any statistics to cite, but my impression from my travels is that certifications have no more steam today than they did 10 years ago. Dopey, frightened, lazy people will continue to use them in hiring, just as they have for years.

uTest: Speaking of pervasive problems, what in your opinion has changed the most – for better or for worse – in the testing industry as a whole since we talked with you last almost 3 years ago?

JB: For the better: the rise of the Let’s Test conference. That makes two solidly Context-Driven conference franchises in the world. This is related to the general rise of a spirited European Context-Driven testing community.

Nothing much else big seems to have changed in the industry, from my perspective. I and my colleagues continue to evolve our work, of course.

uTest: In a recent interview, you mentioned that you see the future of testing, in 2020 for instance, as being made up just of a small group of testing “masters” that jump into testing projects and oversee the testing getting done…by people that aren’t necessarily “testers.” Do you see QA departments going completely by the wayside in this new reality of a leaner testing world? Wouldn’t this be a threat to the industry in general?

JB: I’m not sure whether you mean QA groups, per se, or testing groups (which are often called QA). I don’t see testing groups completely going away across all the sectors of the industry, but for some sectors, maybe. For instance, it wouldn’t surprise me if Google got rid of all its “testers” and absorbed that activity into its development groups, who would then pursue it with the ruthless efficiency of bored teenagers mopping floors at McDonald’s (a company as powerful as Google can do a lot of silly things for a very long time without really suffering. Look at how stupidly HP has been managed for the last 20 years, and they are still, amazingly, in business).

Remember that railroads existed for many years without reliable braking systems until the 1889 Armagh rail disaster. Dangerous sweatshops were normal in America until the 1911 Triangle Shirtwaist factory fire. Credit default swaps were all the rage before the great economic collapse of 2008. It sometimes takes catastrophes to make companies take risk seriously.

In many innovation-oriented companies, I think it would be healthy to see smaller groups of testers who were better trained and more serious about their craft. I don’t think that is a threat to the industry, because I don’t believe that an industry full of fake-certified knuckleheads is anything to be proud of. It’s those unambitious testers who will lose their jobs in the world order I envision. That’s okay, because it isn’t the number of testers that matters—it’s whether there is a market for every serious, skilled tester who wants a job. I think there will be such a market.

uTest: Continuing on testing departments for a bit, if there’s one constant amongst all testing teams that managers don’t get right when building out their teams, what is it?

JB: There is no constant among all testing teams, really. But one common problem is that they don’t establish a system to develop and assure craftsmanship in their teams. They don’t train. They don’t comprehend the skills of good testing.

uTest: What’s the one piece of advice you’d give to a tester when it comes to preserving the tester-developer relationship?

JB: Build your credibility. With credibility, you will get the support and access you need to get your work done.

uTest: We know that as a context-driven tester, you’ve called “best practices” a “hyperbolic propagandist’s phrase.” Are you against the idea of best practices in general, or just best practices in testing?

JB: If you are asking that question, then I guess you must not understand why I make fun of people who say “best practices.” Okay. I understand. You haven’t read my blog posts on this. That’s cool.

I’m against people for whom incompetence is a lifestyle choice and who seek to protect their lifestyle by dumbing down a vibrant intellectual craft with flowery protestations of unfounded excellence. All competent thinking professionals know that they didn’t get that way by blindly following others. And there is no reason for the phrase “best practice” other than to encourage uncritical acceptance of an idea that would not otherwise stand on its own contingent merit.

Whenever you want to say “best practice,” just say “practice” instead.

uTest: You’re a presenter at Let’s Test Oz in Australia in September (an event for which uTest is offering uTesters an exclusive discount), a conference that has context-driven principles at its core. How is the state of the context-driven community in areas like Australia? Are we still at the point where it’s an emerging set of values in testing communities outside of the US?

JB: Australia does not yet have a strong skilled testing culture. Local heroes such as Anne-Marie Charrett, David Greenlees and Richard Robinson aim to change that. Let’s Test will help that process.

uTest: Any other events coming up that you’re excited for – testing or not?

JB: I’m going to China for the first time, very soon. I’m quite nervous about that. You know, in the best of circumstances, I am routinely misunderstood and misquoted. Whenever anyone teaches something out of the mainstream, their words will be filtered through an “autocorrect” filter that does alarming things to their message. But with China, there are three additional problems: they haven’t encountered my work before, they don’t speak English well, and their culture is not one which routinely celebrates free and independent thinking.

Frankly, I’m not sure why they want me to teach there. If I were them, I think I would hate me.

But this is very important. China is an emerging technology market that I have to assume will get bigger and bigger. I have to try to make my “buccaneering” message work in their context.

Be sure to stay tuned for Part II of James’ interview next Monday, where James will field questions from our tester community.

Categories: Companies

.NET Developers To Follow

NCover - Code Coverage for .NET Developers - Mon, 07/21/2014 - 13:07

We appreciate that the .NET developers of our community are as multifaceted as the tools we use to write great code.  In particular, we salute all those who are driven to make the applications they deliver to the world and the community we collectively work in so inspiring.  Keep up the awesome work!

Wm. Barrett Simms

.NET Developers Barrett SimmsBarrett is, as he says, “slightly obsessed with quality and effective development processes.” We like that kind of determination for building quality code. He has been working in the software industry since 1996. He provides companies the tools they need to drive successful IT projects. His website has a wealth of information on agile management and C# programming. Stay on top of trends and find great resources at his site: or follow him on twitter @wbsimms.

Mike Martin

.NET Developers Mike MartinMike Martin is Microsoft Lead Consultant and Architect at Crosspoint Solutions (part of the Cronos group), a company with a strong focus on BI, Data and CRM. Mike is works across the complete Microsoft product stack and ise very flexible to work with. He has been active in the IT industry for over 15 years and has performed all types of jobs, including coaching and leading teams, architecting and systems design, and training. Today he is primarily into the Microsoft Cloud Platform and Application Lifecycle Management. He is not a stranger to both dev and IT Pro topics. Stay on top of all all cool things Azure related at his blog: or follow him on twitter: @TechMike2kX.

The post .NET Developers To Follow appeared first on NCover.

Categories: Companies

How Models Change

DevelopSense Blog - Sat, 07/19/2014 - 21:38
Like software products, models change as we test them, gain experience with them, find bugs in them, realize that features are missing. We see opportunities for improving them, and revise them. A product coverage outline, in Rapid Testing parlance, is an artifact (a map, or list, or table…) that identifies the dimensions or elements of […]
Categories: Blogs

Campus Explorer Reduces Testing Time From 72 Hours to 72 Minutes Using Sauce Labs

Sauce Labs - Fri, 07/18/2014 - 19:31

We sat down with Senior QA Manager Sage Rimal to hear how they use Sauce Labs at Campus Explorer.  Sage shared how they’ve automated their tests on Sauce, and have since reduced their testing time from 72 hours to 72 minutes.

Watch the video below to get the latest!

Want to share your story? We want to hear from you! Submit a request here.

Categories: Companies

Are There Enough ‘Intellectual’ Software Testers?

uTest - Fri, 07/18/2014 - 17:38

imagesJames Bach is no stranger to tackling heated topics, and in general, being one of the most influential disruptors in the in the testing industry.

So it comes as no surprise that in a recent blog, James provided some fodder for a great discussion in the uTest Forums, arguing that there aren’t enough intellectual testers in the field — that is, testers that are willing to challenge themselves or the status quo:

“The state of the practice in testing is for testers NOT to read about their craft, NOT to study social science or know anything about the proper use of statistics or the meaning of the word ‘heuristic,’ and NOT to challenge the now 40 year stale ideas about making testing into factory work that lead directly to mass outsourcing of testing to lowest bidder instead of the most able tester.”

While there was a fair amount of pushback to this, a surprising amount of uTesters tended to agree, including one tester that even went so far as to call it a “pet peeve” of his. However, while agreeing with Bach’s assessment, these same testers argued that it isn’t necessarily their fault — it’s a product of their environment:

“To conclude, I believe that the issue lies with how projects are managed. If no time is left for more robust testing, then it almost doesn’t matter how intellectual or technically savvy a tester is if all he/she is going to have time to do is create and execute tests against specifications. In other words, intellectual testers don’t have much opportunity for more intellectual testing. A strong tester would not be able to showcase those skills in this environment.

“To James’ credit, we as software testers owe it to ourselves – and to the integrity of the profession – to stay educated on the latest techniques, then attempt to blend/incorporate these techniques into projects. The problem lies with the organization, however. The organization has to be mature enough to embrace exploratory testing.” – Jay M.

“Some of this also comes from the ‘unspoken’ acceptance of this behavior by management…there is no encouragement given to the testers to learn, management just maintains the status quo.” -Teresa P.

So let’s bring this discussion out of the Forums a bit and into the greater community. First off, do you believe that the lack of ‘intellectual’ testers is a pervasive problem in the industry? If it is, do you agree with our testers that change needs to come from the top down in organizations before testers can actually seek to change themselves? We’re interested to hear what testers think, so please let us know in the Comments below.

Oh, and speaking of James Bach, be sure to stop by at the uTest Blog Monday for Part I of a brand-new interview with Mr. Bach himself.

Categories: Companies

Wrapping Up Life Sciences Customer Day 2014

The Seapine View - Fri, 07/18/2014 - 17:30

SeapineCustomerDay2014Thanks to those of you that joined us at our first Life Sciences Customer Day last week. Based on informal chats and formal survey feedback from attendees, it was a huge success for all involved! Seapine presenters covered a variety of topics throughout the day including the new TestTrack 2014.1 release, better ways to manage risk with TestTrack, and how to use TestTrack Matrix reports.

Of course, we didn’t want to do all of the talking so there were also roundtable discussions with customers, which included TestTrack’s versioning capabilities, tool validation challenges, and the adoption and use of Agile within medical device development to name a few. Those discussions were the highlight of the day for me and many of our customers. It’s really exciting to hear firsthand how customers are using our tools and the challenges they face in their daily work, and I heard from several of them that it was great to be able to provide feedback to the product team face-to-face.

Slide decks from the presentations are available below. If you were there last week and have any further feedback please shoot us an email or leave a comment here. Thanks again to everyone that helped make this event a huge success!


What’s New in TestTrack 2014.1



Decomposing and Evolving Requirements for Better Traceability


Using TestTrack for Better Risk Management



Using Link Definitions for Better Context and Reporting


Configuring a Matrix Report for Traceability and More

Share on Technorati . . Digg . Reddit . Slashdot . Facebook . StumbleUpon

Categories: Companies

To Successfully Adopt Continuous Delivery, Organizations Need To Change

In a recent Forrester Research report, Modern Application Delivery Demands a Modern Organization, Kurt Bittner, John Rymer, Chris Hines and Diego Lo Giudice review the differences between the 'modern organization' of yesterday and today and the shifts that need to be taken to keep up with not only customer demand, but the success of more agile competitors.
When you look at the structure of a successful organization, it is rare to find silos of any sort. The reason being that when you shift the emphasis from individual performance optimization to a team-based structure focused on optimizing delivery, you get faster output. Why?
When an individual is focused on their own task lists, priorities slip for other projects that get held up. This ultimately creates a bottleneck of work. What is the natural thing you may do when you are waiting for someone else to do the next step of a project or be told to do so from a superior? You start something else. Because you are working on some new project, a new bottleneck is formed when your resources are needed. You are not available any longer and someone is now waiting on you. They start a new project while they wait and so on and so forth.
The Culture Shift
We are members of a culture of multi-tasking – we must always be busy. This is not always good. In the modern culture, resources are dedicated and at the ready to move projects along, even if they are underutilized. So now you have resources that are not moving on to new projects and are ready when their resources are needed.
Now going back to the silo vs. team approach, we start to see less specialization and more focus on distributing knowledge. So now you have a team that can be the next in line instead of one person. It’s now about cross-functional teams vs. superstars.
The focus also needs to change. Our culture wants us to get the Employee of the Month award and achieve personal objectives but what if we focused less on how much we could get out of top performers and more on how much output we could deliver to our customers?
This would mean another huge cultural shift and this time it’s about the management team. Management must be agile and allow for teams to make decisions quickly without having to cut through yards of red tape to get something across the finish line. It’s more about holding your team accountable vs. tracking and monitoring their every move.
The report concludes by stating: “While process and automation are essential enablers of these better results, organization culture, structure, and management approach are the true enablers of better business results.”
Continuous Delivery can be a tremendous game changer for your organization but the organization needs to be modernized in such a way that it will be a successful game changer. 

Christina Pappas
Marketing Funnel Manager

Follow her on Twitter
Categories: Companies

JUC Israel report

This year marks the 3rd annual Jenkins User Conference in Israel. While the timing of the event turned out to be less than ideal for reasons beyond our control, that didn't stop 400 Jenkins users from showing up at the "explosive" event at a seaside hotel near Tel Aviv.

Shlomi Ben-Haim kicked off the conference by reporting that JUC Israel just keeps getting bigger, and that we sold out 2 weeks earlier and the team had to turn down people who really wanted to come in. The degree of adoption of Jenkins is amazing in this part of the world, and we might have to find a bigger venue next year to accomodate everyone who wants to come.


It turns out most of the talks were in Hebrew, so it was difficult for me to really understand what's going on, but the talks ranged from highly technical ones like how to provision Jenkins from configuration management (the server as welll as jobs), all the way to more culture focused one like how to deploy CD practice in an organization. Companies large and small were well represented, and I met with a number of folks who actively contribute to the community.

There were a lot of hall way conversations, and those of us at the booth had busy time.

Thanks everyone who came, thanks JFrog for being on the ground for the event (and congratulations for the new round of funding) and CloudBees for hosting the event. Please let us know if there are things we can do better, and see you again next year!

Categories: Open Source

Web development best practices for functional testing

BugBuster - Fri, 07/18/2014 - 15:24

Functional Testing with BugBuster!When conducting IT and software projects, there usually is a tight constraint on time, money, engineering resources, or any combination thereof. It is therefore critical to ensure a project’s quality by focusing on the testing domain that can produce the highest and quickest return on investment, and this is functional testing. While we could argue for days about the convenience of setting test cases at all levels of your application (unit, module, integration, interface, stress, performance and so forth), functional testing is the discipline that finds most of the major bugs faster, and additionally, those whose impact on the product is usually higher – they impede the “function” of the system.

So far, we have helped dozens of clients transform their functional test cases into BugBuster scenarios that take advantage of our unique API to direct our automated exploratory technology towards specific goals. From this experience, we have summarized a few general tips that are applicable in many situations and that can ease the creation of test cases, notably situations in which testers do not have access to change the application’s source code.

This is the list of tips that make testing web applications a lot easier when writing automated integration and functional testing: unique identifiers for action elements, semantic page CSS classes and writing single-purpose scenarios.

Unique identifiers for action elements

Having unique classes on a particular page for actions (.btn-add.btn-cancel), or unique IDs (#signIn), makes testing a lot easier. You are able to easily add steps, such as clicking, triggering events, or validating elements. Keeping them consistent throughout your development makes maintaining test cases’ code a lot easier too: they don’t depend on the DOM tree anymore, you can move them around while keeping the functionality, therefore your tests will not break. If you use CSS selectors representing a hierarchy tree, every time you move/change an element in this tree, you’ll have to rewrite your tests to represent the new tree.

It is even more useful when your test cases require producing actions on elements that depend on other actions to be visible, like hovering over a main menu element to draw its sub-menu and then click on any of its entries. Using unique identifiers will keep your test code clean, modular, reusable and closed for modification.

Examples : Github

Example from Github

Wordpress login page

Example from WordPress login page

Semantic Page CSS Classes

Having a way somewhere in the DOM tree to easily differentiate one page from another is helpful when crawling an app/website with automatic exploration or just to assert specific things when some given conditions are met. For instance, some e-commerce CMSs set a CSS class at the top level DOM element indicating whether the rendered page is a product detail page, a product list, the checkout page, etc. You can then easily check that the add-to-cart button is on the product page, or that the link displaying a product list is not a dead link. Otherwise, knowing which page the test robot is on would be just an educated guess based on previous actions – which may be inaccurate.

This way, you are not trying to find specific elements like actions, hidden text, or any other things to identify a page. That may work for some applications, but you need something independent from the content, as it can change with another language or country, for example.

Examples : Example from Magento

Example from Magento

Example from Magento

Example from Magento

Using BugBuster : If you can detect which page category you are testing, you can use automatic exploration to crawl around your web application and have watchers for specific pages, identified with CSS classes, as seen in the picture above. We have e-commerce clients using BugBuster’s automatic exploration to scan their whole e-commerce website and do some specific event-driven tests such as checking price accuracy or ensuring pictures are present; when there is a checkout form, BugBuster tests whether automatic filling works, and so forth.

Writing single-purpose scenarios

When creating a scenario, it’s easy to add assertions for every state of the test case. In the long run, it is not ideal as it does not put boundaries around features and you will have to run your test suite all over again when you just want to ensure one case is working. Following the single responsibility principle, every test scenario should test one and only one feature, and be independent and isolated from other test cases.

A tip here: besides having several single-purpose scenarios that check individual features or test cases, we also recommend having bigger scenarios that test the whole path, from the beginning of a sequence to the end (eg: a registration form with several pages, or a product edition process that goes through several interfaces). This kind of scenario can have only one assertion or goal whenever the directed test robot gets to the end of the process, but ignoring potential failures in the middle (already tested by single-purpose test cases).

It is better to have multiple delimited scenarios that will only test few elements. You could run theses scenarios quickly and often during the development phase, and then run a complete integration test of all scenarios before going into production, for instance.

Let’s say you have a feature allowing someone to buy a product on your application. You could have multiple small scenarios to test the checkout page with a regular client, an unknown user, a user blacklisted by banking companies, a user living in a country you do not support, etc. This will check how your system reacts in all these different situations; then, you can have a scenario to test the happy path of the whole purchase process, from choosing the product to paying.


These guidelines are based on feedback we received at BugBuster from our clients. Any other comments and contributions are more than welcome to further improve BugBuster. Also, if you found this useful, do not forget to share it!

And of course, you can try a 14 day free trial of our cloud testing solution: smart exploration and bug discovery for web apps in the cloud, templates for speeding up test case creation and a great JavaScript API for functional testing!


  1. Open/Closed principle on Wikipedia
  2. Single responsibility principle on Wikipedia
  3. Happy Path on Wikipedia

The post Web development best practices for functional testing appeared first on BugBuster.

Categories: Companies

Since Heartbleed, more vulnerabilities emerge

Kloctalk - Klocwork - Fri, 07/18/2014 - 15:00

The Heartbleed security vulnerability was unquestionably one of the most significant cybersecurity-related discoveries in recent years. OpenSSL was and remains one of the most popular open source solutions in use around the world, and, consequently, Heartbleed posed a serious risk to a huge percentage of all content on the Internet.

In the wake of Heartbleed, serious debates have emerged concerning whether open source solutions are as secure as was previously believed. Many security experts argued that Heartbleed was an isolated incident, one which should not be read as carrying significance for open source's overall cybersecurity capabilities.

However, TechRepublic contributor Frank Ohlhorst recently asserted that Heartbleed was just the beginning, rather than an anomaly, as more vulnerabilities continue to be discovered.

A worrying trend
Ohlhorst noted that the OpenSSL project recently announced the discovery of six more vulnerabilities. These flaws include denial of service, potential remote code executive and information disclosure. As he explained, all of these should be worrying for firms using OpenSSL's cryptographic capabilities to secure corporate IT resources.

Ohlhorst went on to describe in detail two of the most serious vulnerabilities highlighted by OpenSSL. The first, CVE-2014-0195, was described by OpenSSL as "[a] buffer overrun attack [that] can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server." This, Ohlhorst explained, suggests that any organization utilizing DTLS should be wary of such an attack and take proactive steps to shore up its security.

The second vulnerability, CVE-2014-0224, can pose a major problem for firms, but only if both the client and server are running vulnerable versions of OpenSSL – the flaw is irrelevant if the impacted SSL-TLS component is not present in both cases. On the one hand, this limits the impact of the vulnerability in question. However, as Ohlhorst explained, this does not make the flaw meaningless.

"Nonetheless, there are situations where SSL/TLS and OpenSSL are quite common, take for example public WiFi hot spots and open source VPNs," he wrote. "Simply put, there are a whole lot of applications using OpenSSL as evidenced by the impact of Heartbleed."

Corrective measures
The writer recommended that firms worried about these issues instruct their users to avoid unencrypted public WiFi and to implement software patches frequently – sound advice for cybersecurity in general. He noted that many OpenSSL vendors are now hurrying to release updates that can counteract these and all other identified flaws.

However, the number and scope of these and other recently highlighted open source issues suggest that businesses may need more proactive measures to ensure the security of their open source efforts.

To this end, organizations should consider embracing high-quality scanning and governance solutions. These resources can have a major impact, greatly improving the overall quality of a company's overall cybersecurity as it seeks to take advantage of open source's flexibility and cost-efficiency.

Categories: Companies

5 Secrets to Professional Service on Client Engagements

Yet another bloody blog - Mark Crowther - Thu, 07/17/2014 - 21:55
If you think contracting and client work is about billing hours and F*&k all else, stop reading, there's nothing for you to see here. If you feel there's something more to it, that engagements are a precious slice of interaction to be valued, read on.

Still here? Good!

As often happens, I had a interesting and unexpected conversation with a colleague in work today - about professional service on a client engagements.

Every engagement has it's good and bad parts, its ups and downs. At all times though, you need to stay professional, but what does that look like?

Here's my attempt to capture some of what was said and add in a few thoughts of my own.

1. Serve the Client
The single most important thing to remember, is that you are being paid to provide service. Not necessarily 'a' service, even though a Statement of Work may say that. Service can be defined as 'acts of helpful activity'. In any engagement, you'll always be performing acts (see what I did there...)

Therefore, as you are a servant, drop any pretense or arrogance, borne of imagined technical or professional  superiority, and humbly serve your client to the best of your ability, by executing helpful acts as best you can.

That service may come in many forms. Working a little earlier or later. Listening attentively to what is and isn't said, perhaps coaching and mentoring. Speaking well of them in front of colleagues and customers. Producing a good report in time for an important meeting. Apologising for being late... the list goes on, enjoy expanding it. Service is not subjugation.

2. Deliver the best work you can, right to the very end
When we first engage with a Client, there's a lot of positive high energy and excitement about what's to come. We do our best work and give or all, thinking of the positive outcomes it will bring. What comes is often success in a shape we didn't imagine, coupled with a lot of frustration and all too often a slow winding down of a project, where it doesn't have a defined done-done.

It's essential that every engagement, good or bad, successful or not, finishes on a crescendo. Make sure you stay strong to the end. I'll claim there's good science behind this, it's called the Peak End Rule. Clients remember the most intense thing you do and then the final thing you do, then forgetting most of the stuff in between, form a view of what you were like. As time passes the peak levels off and the end is what they remember most.

I implore you, for the security of your reputation and future employ-ability, finish strong!

3. Help the Client succeed
Your glory and success must always be a by-product of the success you bring the Client. You succeed if the Client succeeds. If they fail, you fail. No exceptions. Your reward is getting paid, everything else is a by-product for you.

Constantly look for what is hampering the Client's success and seek ways to resolve it. That could be a lot of things, related to the specifics of the engagement or not. As in 1. above, you might need to step out of the engagement's remit and give that 10% extra on the 100% you're already doing.

Some of helping them succeed will call on your professional skills, maybe technical skills, your network, your ability to coach, heck maybe even just to listen. Ask yourself, is the Client looking good, winning, growing, succeeding? If not, figure out what you can do about it.

4. The Client isn't always right, but they're never wrong
Like a good Barrister, you'll take your instructions and look to follow them as best you can. However, on occasion, your Client will be misguided, ill informed, limited in their understanding, shallow in their perspective, inexperienced in approaches - they will never be wrong.

Don't like the test approach? Think the automation used is rubbish? Seeing sub-optimal management practices? Dislike the organisational structure? Feel the project is hampered by bad supplier relationships?

Great, well done on noticing! It's your job as a professional to offer your insights, experience, training, etc. to highlight ways that things could be improved so that you help the client succeed and deliver the best work you can. It's not your job to belittle the Client and make them feel wrong wrong wrong! That's not how we server the client is it?

Coach and guide, but ultimately if they don't want to follow your guidance, they're not wrong and you'll have to perform your acts of helpful activity in support of what they've asked for. Hey, no one said it would be plain sailing all the time!

5. It's not over until... well never
How long is your career going to be? I'll make up a figure and say on average 15 to 20 years. Where is your work going to come from? Again I'll guess and say people you know (certainly as a consultant) or people that know the people you know. That means anytime you have an engagement it never really ends, as the continuation is that (Linkedin) connection back in time to them through the community and your reputation.

As an example, assuming I make it to the end of 2014 in the current engagement, my network will have directly come to me with engagements for 4 years straight. No looking around, no interviews, just a journey through the bullet points in this post.


6. Have fun with them, sometimes!
Given Clients are so important, as customers, people and fellow professionals. Given you're hoping to engage with them for months on end, that they are people just like you, with hobbies, interests, families, hopes and dreams. It's OK to just leave work in work sometimes and go do something fun.

That might be a few beers after work, inviting them to a corporate do or just demanding they let you buy them lunch as a thank you once during the engagement. (Clients of mine are now thinking of the Spanish meats and wine they've be loaded up with from time time... yum).

The real bonus secret...

... is that it's all about professional relationships. Build it through service, maintain it through reliability and secure it through trust. Sprinkle it with a little fun along the way!


Liked this post?Say thanks by Following the blog or subscribing to the YouTube Channel!

Categories: Blogs