Skip to content

Feed aggregator

Sogeti Announces New TMap HD for Software Testing

Software Testing Magazine - Tue, 10/28/2014 - 19:15
Since 1995 TMap has set the global standard for effective software testing. Eight years after introducing TMap NEXT, the updated version of the world-renowned methodology for testing, Sogeti is yet again launching a new way of testing software; “TMap Human Driven” (TMap HD*). This new testing methodology embodies a shift from a traditional fixed formula to an innovative building-block approach. The new TMap HD is fully aligned with current trends such as Social, Mobile, Analytics, Cloud, the Internet of Things and software development using the Agile/Scrum methodologies. Sogeti’s building-block approach for ...
Categories: Communities

Testing is…

DevelopSense Blog - Tue, 10/28/2014 - 18:36
Every now and again, someone makes some statement about testing that I find highly questionable or indefensible, whereupon I might ask them what testing means to them. All too often, they’re at a loss to reply because they haven’t really thought deeply about the matter; or because they haven’t internalized what they’ve thought about; or […]
Categories: Blogs

Dutch Testing Day, Amersfoort, the Netherlands, November 17 2014

Software Testing Magazine - Tue, 10/28/2014 - 18:32
The Dutch Testing Day is a one-day conference focused on software testing that takes place in the Netherlands. This conference is a non-commercial event where scientists, lecturers, and practitioners from the software testing industry meet and share ideas; for example about the latest trends in the research and technologies of software testing. In the agenda of the Dutch Testing Day, you can find topics like “First Steps in Testing Analytics: Does Test Code Quality matter?”, “Pas de deux: a tale of test automation and service virtualization”, “Flexibilize Testing”, “Combining the ...
Categories: Communities

Hands-On Tutorial: 5 Steps to Identify Java and .NET Memory Leaks

I keep getting questions about how to best analyze memory leaks – especially when they are not always reproducible by the developer on the local workstation. If you never experienced a memory leak issue (or you simply don’t admit it) then read up on some real life examples on our blog: Fixing Memory Leak in […]

The post Hands-On Tutorial: 5 Steps to Identify Java and .NET Memory Leaks appeared first on Dynatrace APM Blog.

Categories: Companies

Track deliverables across multiple projects and multiple clients

Assembla - Tue, 10/28/2014 - 16:22

Hooray! Here is another set of improvements following our last week release of the new portfolio overview page. If you oversee multiple projects for one or multiple clients and want to track deliverables for all the projects in one place, please read on.

Quick note: Before implementing these changes, we interviewed many of our end users and collected feedback for various use cases. Thanks to all of our customers who gave us their input in designing these new portfolio features. We do realize that it's hard to satisfy all of our customers' workflows. We're trying our best, and are still collecting feedback from everyone who thinks we can improve Assembla for their use case. Please send your suggestions through e-mail ( or by clicking on the blue bubble icon with the question mark at the right-bottom corner of your Assembla application.

Many of our customers manage project deliverables using our milestones feature. In case you're not very familiar with the Milestones tool yet, just go to any of your spaces, click on the Tickets tab, and then click on the Milestones subtab.

Our new portfolio overview page released last week gives you visibility of all upcoming deliverables across multiple projects in your portfolio. In this batch of improvements, we are releasing new milestone edit/new/list pages, with some new and useful attributes for better tracking of these milestones. These changes are meant to help you oversee multiple (in parallel and/or subsequent) deliverables to your customers.

New Open Milestones List

The new open milestone list allows you review your upcoming deliverables at a glance. Based on customer feedback, we're dispalying the most important fields: Title, Due Date, Budget, and Progress.


You can quickly drill down into any deliverable and perform following actions:

  1. Get a list of closed or open tickets for each milestone, by clicking in the links below the progress bar.

  2. Browse all the tickets from any given milestone in the Cardwall. This will open the Cardwall in the workspace you are using to manage that deliverable. 

  3. View different kinds of charts for the given milestone, like Velocity, Burndown, and Cumulative Flow.

  4. Close a milestone.

  5. Edit a milestone.

  6. And finally, delete a milestone.

Most of these actions can be accessed via the context menu by clicking the gear icon:



We plan to add a Milestone Details page that will include all the information about a milestone in our upcoming releases.

New Closed Milestones List

The closed milestones list gives you information about past deliverables and is similar to the Open Milestones page:



The difference is the context menu, which is more constrained:


You can reopen the milestone from here, if you need.

New Milestone Attributes

We've introduced some new attributes to the milestone entity. 

  1. Obstacles - (Optional) A text field used to describe any roadblocks the milestone is having.

  2. Start Date - (Optional) A date field used to specify when the project/release should be initiated.

  3. Budget - (Optional) A currency field used to define the cost of a project/release.

Some of the milestone fields are not displayed in the milestone creation form, while all of them are displayed in the edit form. The screenshots below illustrate the difference between both pages:




Wrapping Up

As I said before, this is just the first stage. There are more upcoming changes that we'll be incrementally releasing in the next few weeks. Stay tuned and enjoy! 





Categories: Companies

Who is Nigel Simpson? (Lessons of Open Source Governance)

Sonatype Blog - Tue, 10/28/2014 - 16:20
If you are in the midst of creating (or even planning to implement) an Open Source Governance Policy for your organization, then you’ll want to get to know Nigel Simpson. Nigel has been leading an enterprise-wide working group with over 40 members — at a really big entertainment and media...

To read more, visit our blog at
Categories: Companies

Preparing for a Load Test With JMeter: The Vital Point You Might Be Overlooking

uTest - Tue, 10/28/2014 - 15:30

This piece was originally published by our good friends at BlazeMeter – the Load Testing Cloud. Don’t forget to also check out all of the lbz_bl_0001.24.13f_1oad testing tool options out there — and other testing tools — along with user-submitted reviews at our Tool Reviews section of the site.

If you often run load tests, you probably have a mental checklist of questions that run through your mind, including:

  • How many threads per JMeter engine should I use?
  • Can my engine handle 10% more threads?
  • Should I start with the maximum number of threads, or add as I go?

All of these questions are important and should be carefully considered – but what about the load test itself? Have you considered how the actual procedure will be managed?

It’s easy to get so wrapped up in the technical details that you lose sight of the overall picture. Even with BlazeMeter’s self-service load testing – which is designed to simplify performance and load testing for developers and QA testers – it’s still vital to take control of the process management to ensure each test runs smoothly.

Why Should I Care?

Load tests require a great deal of cooperation and teamwork. Everyone needs to coordinated in order to quickly analyze the data, identify the bottlenecks and even solve them (if possible) during the test.

For example: the developers/QA testers should create and share the script with all departments involved in the test, to make sure that everyone understands the scenario and how it can affect their particular system. An n-tier application is made up of several disciplines, each one requiring the same level of attention – be it database, front-end, back-end, or monitoring services. It is imperative that the staff understand the upcoming load test scenario, regardless of their knowledge of JMeter and/or load testing, so as to create the most agile environment for the duration of the test. If the staff clearly understand what is happening when a bottleneck is hit, it’s much easier for them to analyze the data and quickly tend to the issue. If they aren’t on par, there’s a much greater chance that they won’t be able to overcome the bottlenecks and delays will occur.

Once the ins and outs of the infrastructure are understood, further managerial tasks are needed. For example: sending out updates and involving your operations team and third parties like Akamai or Amazon to avoid complications such as blocking, shaping, or even inadvertently breaking a legal agreement during the test. While they may seem excessive, it’s really worth taking these supplementary steps before starting the load test to ensure the best results.

Technical and Managerial Perspectives of a Load Test The Technical Aspects of a Load Test

When it comes to the technical aspect of load testing, as detailed in How to Run a Load Test of 50k+ Concurrent Users, it’s important to supply everyone involved with a test scenario outlining the exact processes of the test. By taking this step, even staff members who are not JMeter experts will understand that during the test, they may experience issues like an excessive number of log-ins, ‘add to cart’ requests, image usages, database queries, and so on. The scenario should be simplified and easy to read for everyone involved. It should include a defined scaling process and explain that the ultimate goal for the number of users may only be met within a number of load tests.

The technical approach usually includes building the script (and its data) to address the specific scenario, testing it locally and verifying that it actually works in JMeter. Once the script performs as expected using the SandBox feature, you should evaluate how many threads can be applied to a single load engine without crashing (ensuring the load engines themselves won’t be the bottleneck). Then, the script will be scaled to a cluster of engines, and more clusters can be added as you go.

Important points to consider:

1. Does your data need to be unique per engine? If so:

  • Set up a different CSV for each engine
  • Use the “Split any CSV file to unique files and distribute among the load servers”
  • Use JMeter functions like __InstanceID, __RandomString(), __threadNum() to add unique data to your test.

2. Does your scenario have data manipulation in real time? If so:

3. Do you use timers? If not, you should (even if it’s just 300ms) because every user has some think time between pages

  • You can use the Throughput Shaping Timer or the Constant Throughput Timer to control your test hits/s
Managing Your Load Test

From a management perspective, of course, every company is unique. But most share the same key criteria. These include:

1. Scheduling a meeting before the actual test.  Two weeks is generally enough time for this. It allows everyone involved to see the expected script scenario and everyone can discuss issues like who to alert about the test and possible interferences.

2. Including a representative from each department during the initial load tests. This will ensure smoother sailing once the test is up and running. In later tests, you might want to schedule the actual environment you’re going to load test. For example: in a staging environment, the VP of R&D needs to know that the environment is going to be used, which may affect updates to production. Whereas, if load tests are run on production environments, a landing page should be created to notify users that maintenance procedures will take place during that particular time.

3. Creating a drawing or flow chart of the actual script. This is an additional measure but a useful one –  after all, a single picture says a thousand words. It helps people who aren’t familiar with JMeter or aren’t aware of what’s happening with particular clients or in the front-end to relate and understand what’s expected to happen.

Depending on the test’s complexity, you can make a flowchart of:

  1. Your script flow
  2. Cache warmup (after doing a reset cache)
  3. Test scenario


This method effectively divides the load test into two parts: the pre-load test, which creates all of the data, and the actual load test itself. Appointing a load test supervisor to announce the various stages of the test will help everyone involved to stay on the same page. Utilizing an organized platform, such as Campfire or HipChat will allow everyone to communicate quickly during the load test, as well as enable the supervisor to control and deliver critical assignments when needed. Additionally, these platforms provide a space for each department to present their conclusions from the test. You can also record the test – which will be a great help when it comes to running future tests and reports.

Categories: Companies

SonarQube supports ECMAScript 6

Sonar - Tue, 10/28/2014 - 13:53

The 2.1 version of the JavaScript Plugin fully supports ECMAScript 6 (ES6). But what does that mean exactly ?

What is ECMAScript 6 ?

Let’s start from the beginning. The JavaScript language is one implementation of the ECMAScript language standard. (JScript and ActionScript are two more.) Each browser has its own JavaScript interpreter, and most modern browsers support the ECMAScript 5 (ES5) standard. That means that you can write JavaScript that adheres to the ES5 standard and have it work correctly for the vast majority of your users.

ES6 is the next version of the standard, and it provides great new features to allow you to write shareable, efficient, and readable code more easily. Luke Hobbans is a member of TC39, the committee behind ECMAScript. He’s written up a great summary, of the main features of ES6, including a short description of each, complete with code snippet.
Here’s a quick sample for 2 new constructs, variable and constant declaration, and arrow function:

Block scoped binding construct: let for variable declaration and const for constant declaration.

const a = 1;
a = 2;  // error - cannot be re-assigned

if (true) {
  let b = 1;
print(b);  // b is undefined

Arrow function: function shorthand using the => syntax.

let sum = (a, b) => a + b;
Can I use ES6 today ?

A new version of the standard also means that each browser needs to provide support for it, at least the major ones. It might take years before it happens, but you don’t have to wait for that to take advantage of the innovations in ECMAScript 6!
Thanks to the availability of ES6-to-ES5 transpilers, it is possible to use ES6 features today. A transpiler will translate your ECMAScript 6 code to ECMAScript 5 code so it can be run by today’s browsers. I like the Traceur compiler, which offers an online demo. You can enter ES6 on the left side and see the resulting ES5 code on right.
AngularJS has already taken advantage of a transpiler to make the move with AngularJS 2.0.

You can follow the progress of ES6 support in browsers and for transpilers in Juriy Zaytsev’s ES6 compatibility matrix.

Use SonarQube to analyze ES6 code

The SonarQube JavaScript Plugin 2.1 fully supports ES6. What does that mean?

It means that the plugin is able to:

  1. parse ES6 source code,
  2. compute all relevant metrics accordingly:
    • a classes count is computed when classes are used
    • class complexity is computed when classes are used
    • the function count includes generator functions
    • general complexity metrics take generators into account
    • the number of accessors is now computed
  3. analyse code against rules, all existing coding rules have been updated to cover the new features, e.g: “unused variable” will detect unused variables & constants declared with let and const.

In upcoming versions, we’ll be adding new rules specific to ES6 features. We’re still figuring out what those should be, but a set of rules about classes is likely. If you’ve got suggestions, please let us know at

Wanna see a live demo? Check out Angular DI Framework using ES6 on nemo: Angular Dependency Injection v2.

Categories: Open Source

Newly Supported JS Frameworks

Ranorex - Tue, 10/28/2014 - 11:51
Ranorex 5.2 introduces support for many web development frameworks based on dynamic content.

Start automate testing your web applications based on java script frameworks like OZONE Widget Framework, Sencha ExtJS…

Download Ranorex 5.2 now…

Upgrade for free with your valid subscription (You'll find a direct download link to the latest version of Ranorex on the Ranorex Studio start page.)
Categories: Companies

GTAC 2014 is this Week!

Google Testing Blog - Mon, 10/27/2014 - 20:26
by Anthony Vallone on behalf of the GTAC Committee

The eighth GTAC commences on Tuesday at the Google Kirkland office. You can find the latest details on the conference at our site, including speaker profiles.

If you are watching remotely, we'll soon be updating the live stream page with the stream link and a Google Moderator link for remote Q&A.

If you have been selected to attend or speak, be sure to note the updated parking information. Google visitors will use off-site parking and shuttles.

We look forward to connecting with the greater testing community and sharing new advances and ideas.

Categories: Blogs

Applying Agile in Test Automation

Testing TV - Mon, 10/27/2014 - 19:43
What are the challenges to build test automation framework and automated regression test suite for Barclays’ Equity trading business? Are a geographically dispersed team in different time zones and a fast moving regulatory environment the only problems? This presentation shares some experience when applying Agile methodology for this type of project. Video producer:
Categories: Blogs

Using Comparative Testing in the Telecom Industry

Software Testing Magazine - Mon, 10/27/2014 - 18:29
The concept of comparative (or back-to-back) test originates in testing hardware, when the output of the device under test is compared with the output of pre-tested “ideal” device wherein input is provided with the same data. From the viewpoint of Telecom industry, back-to-back test of OSS/BSS (Operating/Business Support Systems) solutions is usually implemented for testing systems managing large amount of data to get maximal coverage of migration and configuration processes. In this article, Yulia Liber discusses pros and cons of implementing comparative tests in Telecom. Yulia Liber, A1QA, First, let’s have ...
Categories: Communities

On Leadership and Being a Lead - Mon, 10/27/2014 - 17:13
Henry, the “Developer”

I once worked in a team with an amazing developer, let’s call him Henry (not his real name). Henry refused to play the Tech Lead, preferring to stay as hands-on with code as much as possible. When the team had a technical problem, they would first go to Henry. He always offered a well-balanced opinion on technical decisions which meant the team almost always agreed with his proposals. Even business people recognised his technical aptitude. When he asked for time to work on important technical tasks, he always got it.

Although Henry was just a “Developer”, he lead the team in a number of ways.

// under the Creative Commons licenceTaken from under the Creative Commons licence You don’t need to be a “Lead”

My experience with Henry showed me how you do not need a title with “Lead” to demonstrate leadership. Conversely, having a title with “Lead” doesn’t suddenly bestow someone with leadership skills.

A developer who cleans up some messy code without being asked demonstrates initiative. The tester who brings the developer and Product Manager to the same understanding demonstrates facilitation skills and these play a part of leading people. In this situation, it means:

Thinking and doing something for the benefit of the team without being told to do so.

There are, of course, many other attributes to being a leader, but that is a separate post.

A Lead without leadership

You have probably worked with one of these people. A leader who tells people what to do, berates their team members for stepping slightly out of their role, even when the result is beneficial for everyone. They often have the need to supervise the smallest task and always want a say in every decision. These people are nothing other than micromanagers and demonstrate no leadership skills whatsoever.

Great leaders encourage leadership

Unlike micromanagers, a real Lead focuses on creating an environment that allows everyone to demonstrate leadership. In chaotic situations, this may require more directive action with the goal of moving the team beyond a period of chaos into a safer environment. In a safer environment, the Lead encourages team members to do what they think is right. The Lead takes on a more guiding role and allows everyone to demonstrate leadership skills.

Action is not the same as a title

Henry the developer demonstrated that people can take on responsibilities without officially playing a certain role. He also reminded me that titles, certifications and labels do not automatically guarantee competence. If you truly want to lead, you can.

If you liked this article exploring leadership, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

The featured image is shared from Flickr under the Creative Commons licence.

Categories: Blogs

Web Performance QA Tester and Load Tester 6.4 Released

Web Performance Center Reports - Mon, 10/27/2014 - 15:56
Real-browser testing can increase your productivity over other testing methods. The features added in the 6.4 release will help you work even more efficiently! Locator Suggestions One of the more challenging aspects of working with real-browser testcases is locating the element that you need to interact with. Starting in 6.4, a suggestion button next to every locator field will provide a variety of different locators that you can try if the default locator does not work. These suggestions also help you learn how to create locators – as you will see a wide variety of locator suggestions provided. Read more about Continue reading »Related Posts:
Categories: Companies

Automated Choice configuration in Web Performance Tester 6.4

Web Performance Center Reports - Mon, 10/27/2014 - 15:44
When building a testcase to simulate your users, at some point, you’ll want to ask how much variation you can add to your testcase. Real users may be doing searches, but there’s a good chance that your users are using different search terms. Likewise, users may be entering records, but most likely not every record should be entered identically. Every version of Load Tester & QA Tester support the use of datasets, to make it easy to create a list of terms, which can be supplied back as a virtual user traverses their workflow. However, for drop-downs or radio buttons, … Continue reading »Related Posts:
Categories: Companies

Testing the Limits With Testing ‘Rock Star’ Michael Larsen — Part II

uTest - Mon, 10/27/2014 - 15:30

In Part II of our latest Testing the Limits interview with Michael Larsen, Michael talks why test team leads should take a “hands-off” approach, and why testers should be taken oumichaellt of their comfort zones.

Get to know Michael on his blog at TESTHEAD and on Twitter at @mkltesthead. Also check out Part I of our interview, if you already haven’t.

uTest: In a recent post from your blog, you talked about the concept of how silence can be powerful, especially when leading teams. Do you think this there isn’t enough of this on testing teams?

Michael Larsen: I think that we often strive to be efficient in our work, and in our efforts. That often causes us to encourage other testers to do things “our way.” As a senior software tester, I can often convince people to do what I suggest, but that presupposes that I actually know the best way to do something. In truth, I may not.

Also, by handing other testers the procedures they need to do, I may unintentionally be encouraging them to disengage, which is the last thing I want them to do. As a Boy Scout leader, I frequently have to go through this process week after week. I finally realized that I was providing too much information, and what I should be doing is stepping back and letting them try to figure out what they should do.

I also realized that answering questions with questions helped them look at the problems they were facing in new ways. Often, they would come up with solutions that would not be what I would suggest, but their solution was often more inventive or interesting than what I would have taught them. This is why I value the ability to either step back and be quiet, or answer questions with questions, because I love seeing what solutions they come up with.

uTest: Specifically, you feel that too much direction is given, but not enough “free roam” for creativity and critical thinking through exploratory testing.

ML: Exactly. When we give too many parameters, or we require too many steps be processed the same way, we are cutting off the natural curiosity of the tester. Having a checklist to make sure things are covered is all well and good, but I would encourage test leads and senior testers to allow a fair amount of latitude for the testers on their team, so that their natural curiosity is engaged.

uTest: Fill in the blank. One thing missing on many testing teams is _____.

ML: Collaboration. Too many testers, even when they work on teams, get their narrow slice of projects or stories, and then they go into heads-down mode. I think testing teams would be well-served to look for opportunities where testers can interact, and look at a particular story or section as a team.

Let them explore together and ask questions of each other, share what they learn, and encourage those “a-ha!” moments to occur. We can certainly have “a-ha!” moments working on our own, but the opportunities to have them go up exponentially when we as testing teams set aside some time to explore together and riff off of each other.

uTest: It was a pleasure meeting you at CAST this summer. You were there as not only a Board member for the Association of Software Testing (AST), but as a speaker. Could you tell us a little about your session at CAST?

ML: I gave a talk along with Harrison Lovell about “Coyote Teaching,” which is in some ways a more formalized approach to the “be quiet and ask questions” approach I mentioned earlier. The idea behind Coyote Teaching is that we want to give testers the opportunity to learn and grow, and we help them grow the best when we don’t spoon feed them everything. Coyote Teaching is all about immersing yourself in the environment, looking for clues, asking questions, and answering with more questions.

Mostly, it was about how Harrison and I used the Coyote Teaching methods and model as a basis for our mentoring relationship. He explained from the perspective of a relatively new tester (the mentee), and I explained it from the perspective of a veteran tester (the mentor). I think our session was overall successful because we offered experiences from both sides of the relationship.

uTest: Are there any other endeavors coming up that you are excited about?

ML: I was chosen to be the President of AST, and in that process, the board and I are looking to do a number of things in the coming years, many of them centered around software testing education and expanding the options we offer. We currently teach the first three Black Box Software Testing courses through BBST, and we are looking at expanding from there. We are also excited about a project related to self education for software testers, and you should be hearing much more about that in the coming months.

uTest: You presented at CAST with a ton of context-driven proponents, from James Bach to Henrik Andersson. Is “context-driven” best how you would describe yourself as a tester?

ML: Yes, I believe it is critical to be able to frame the testing that we do within the correct context for the project we are working on, and within the time and constraints we need to deal with. The fact is, projects change, often dramatically, and always in real time. Being able to pivot and approach our testing based on new information, new market demands, and changing deadlines is critical.

For some, saying that you are “context-driven” may feel like we are stating the obvious. Yet so many testers doggedly plow through the same procedures day after day, regardless of the landscape and any changes that may have occurred.

uTest: You’ve said that you’re not “just” a software tester. You write, you lead, you hack, you program, and you play detective and journalist. In order for testers to be successful, do you think it’s best for testers to be taken out of their comfort zones?

ML: Having been one who has already felt how depressing stagnation can be, I will say yes, I think testers do owe it to themselves to explore new avenues, to try to do things they haven’t done before, and to avoid getting too comfortable in any given niche. Don’t get me wrong, I think it’s a good thing to have specialties, but I would encourage any tester to frequently try to reach outside of their carved-out niche whenever they can. Sure, it may be uncomfortable, and sure, there may be a chance that those explorations may be frustrating at first, or may not bear much fruit, but keep trying, and keep looking to expand your abilities wherever possible.

uTest: What keeps you busy off the clock?

ML: When I’m not testing, I enjoy spending time with my family (my wife and I are currently navigating the world of three teenagers in three different stages of schooling; we have one child in college, one in high school and one in intermediate school). I also put a considerable amount of time into being a Boy Scout leader, and have done so for the past two decades. Scouting tends to get me outdoors regularly for camping and backpacking events, so I have opportunities to completely unplug and recharge in the wild, so to speak.

During the winter months, I look forward to snowboarding any chance that I get, and I also do my best to stay active with the broader testing community through my work with AST, Weekend Testing, the Miagi-do School of Software Testing, speaking at conferences, recording podcasts and any other endeavors that will let me get creative wherever I can.

Categories: Companies

BugBuster v3: How to install the Scenario Recorder Chrome extension

BugBuster - Mon, 10/27/2014 - 13:37

With the recent release of v3, all BugBuster users now have a free full-fledged test scenario recorder as part of their subscription. This recorder is a Chrome extension available on the Chrome web store.

With this extension, you no longer need to be able to write code to build and run technical and functional test scenarios for your web application.  You simply turn on the recorder and just navigate through your application as you normally would and the recorder will turn your actions into full-fledged test scenarios.

Opening a BugBuster Trial account

Visit and sign up for a free trial account. The trial lasts 14 days and can be extended upon request.


Installing the extension from the Chrome store

Using Google Chrome, go to the Chrome Store and install the extension by clicking on the blue FREE button.

chrome store 1

The Scenario Recorder is now ready to be linked to your BugBuster account.

chrome store 1

Configuring the Scenario Recorder

Last step is to connect the Scenario Recorder to your BugBuster account. You will then be able to export test scenarios automatically right from the extension.

You need first to navigate to the Profile page then copy the API key

api key

Then paste it into the Your API Key field in the Settings section of the extension. Finally click on Go to recordings to complete the process.

api key 2

Congratulations, you are now ready to create test scenarios for your web application!

Watching the extension in action

In the following video we demonstrate how to create a test scenario to make sure that a visitor would be able to create a new account on a Magento website. The whole scenario is generated using the Recorder without writing a single line of code.


Please let us know what you think of this Scenario Recorder on Twitter or leave us a comment below. The more we share the better the Scenario Recorder will get!



The post BugBuster v3: How to install the Scenario Recorder Chrome extension appeared first on BugBuster.

Categories: Companies

.NET Developers Striking the Right Chord

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

From the windy city to a rockstar developer, we salute a couple fantastic .NET coders who know how to strike the right (or Wright) chord!  Great work John and Brian.

John Wright

ncover_mvp_john_wrightJohn Wright is a software engineer with experience developing for large, distributed networks using multiple platforms and technologies based in the greater Chicago area. He has a wide experience with software development and management across the entire development lifecycle, including requirements gathering and analysis from direct customer discussions, design, development, testing and release. Check out his blog ( as a way to keep note of interesting topics he comes across in his day-to-day work, at community meetings and events, or opinions on the technology industry and related topics. You can also catch his ramblings on twitter @Wright2Tweet

Brian Canzanella

ncover_mvp_brian_canzanellaBrian Canzanella is literally a rockstar web developer. Let us explain. He has studied and played guitar for 19+ years. 7 years ago, he decided to not just write beautiful music but to create beautiful code. He has worked on back-end (.NET/C#, Sql Server, Node, PHP), front-end (Backbone, LESS) and everything in between (ASP.NET WebForms & MVC, ServiceStack, WordPress, Drupal). Check out his personal site if you are in need of web or music help ( If you are looking for .NET, Backbone/Javascript, Node, Sql Server, and MongoDB specific, he also blogs at Or follow him on twitter (@bluevoodoo1)

The post .NET Developers Striking the Right Chord appeared first on NCover.

Categories: Companies

Agile Adoption Roadmap blog - over 100,000 views!

I am very pleased to announce that my “Agile Adoption Roadmap” Blog has just reached 100,000 hits.  This is a great milestone and it makes me happy that there are so many professionals curious about Agile including many Agile enthusiasts, advocates, champions, coaches who are visiting and even commenting on my articles.  It highlights that the many articles have value.  If you want to receive its value, consider following this blog at:  
To add to the statistics, I have folks from 45 different countries that have visited my site.  The top 10 countries include: United States, United Kingdom, India, Russia, Germany, Canada, France, Australia, Ukraine, and China. Other countries that have significantly visited my site are: Sweden, Poland, Spain, Finland, South Africa, Iran, Norway, Iraq, Romania, Brazil, Argentina, Belarus, Malaysia, Portugal, Netherlands, Switzerland, and Italy.

The Agile Adoption Roadmap blog provides the reader with a range of topics related to adopting Agile within their teams and organizations.  The content has a special emphasis on “being Agile” and bringing the Agile mindset to your work.   I have written and posted 56 articles to date (although this one technically counts as the 57th).   What are some of the top articles that Agile, IT, and Business Professionals have found of value?  The top articles include:Next time you are looking for Agile material to support you Agile Journey or you are looking to learn what it means to “be Agile”, look no further.  Consider reading the articles and following the blog.   Thank you!
Categories: Blogs

“Are you listening? Say something!”

James Bach's Blog - Mon, 10/27/2014 - 04:04

[Note: J. Michael Hammond suggests that I note right at the top of this post that the dictionary definition of listen does not restrict the word to the mere noticing of sounds. In the Oxford English Dictionary, as well as others, an extended and more active definition of listening is also given. It's that extended definition of listening I am writing about here.]

I’m tired of hearing the simplistic advice about how to listen one must not talk. That’s not what listening means. I listen by reacting. As an extravert, I react partly by talking. Talking is how I chew on what you’ve told me. If I don’t chew on what you say, I will choke or get tummy aches and nightmares. You don’t want me to have nightmares, do you? Until you interrupt me to say otherwise, I charitably assume you don’t.

Below is an alternative theory of listening; one that does not require passivity. I will show how this theory is consistent the “don’t talk” advice if you consider that being quiet while other people speak is one heuristic of good listening, rather than the definition or foundation of it. I am tempted to say that listening requires talking, but that is not quite true. This is my proposal of a universal truth of listening: Listening requires you to change.

To Listen is to Change

  1. I propose that to listen is to react coherently and charitably to incoming information. That is how I would define listening.
  2. To react is to change. The reactions of listening may involve a change of mood, attention, concept, or even a physical action.

Notice that I said “coherently and charitably” and not “constructively” or “agreeably.” I think I can be listening to a criminal who demands ransom even if I am not constructive in my response to him. Reacting coherently is not the same as accepting someone’s view of the world. If I don’t agree with you or do what you want me to, that is not proof of my poor listening. “Coherently” refers to a way of making sense of something by interpreting it such that it does not contradict anything important that you also believe is true and important about the world. “Charitably” refers to making sense of something in a way most likely to fit the intent of the speaker.

Also, notice that coherence does not require understanding. I would not be a bad listener, necessarily, if I didn’t understand the intent or implications of what was told to me. Understanding is too high a burden to require for listening. Coherence and charitability already imply a reasonable attempt to understand, and that is the important part.

Poor listening would be the inability or refusal to do the following:

  • take in data at a reasonable pace. (“reasonable pace” is subject to disagreement)
  • make sense of data that is reasonably sensible in that context, including empathizing with it. (“reasonably sensible” is subject to disagreement)
  • reason appropriately about the data. (“reason appropriately” is subject to disagreement)
  • take appropriate responsibility for one’s feelings about the data (“appropriate responsibility” is subject to disagreement)
  • make a coherent response. (“coherent response” is subject to disagreement)
  • comprehend the reasonable purposes and nature of the interaction (“reasonable purposes and nature” is subject to disagreement)

Although all these elements are subject to disagreement, you might not choose to actively dispute them in a given situation, because maybe you feel that the disagreement is not very important. (As an example, I originally wrote “dispute” in the text above, which I think is fine, but during review, after hearing me read the above, Michael Bolton suggested changing “dispute” to “disagreement” and that seemed okay, too, so I made the change. In making his suggestion, he did not need to explain or defend his preference, because he’s earned a lot of trust with me and I felt listened to.)

I was recently told, in an argument, that I was not listening. I didn’t bother to reply to the man that I also felt he wasn’t listening to me. For the record, I think I was listening well enough, and what the man wanted from me was not listening– he wanted compliance to his world view, which was the very matter of dispute! Clearly he wasn’t getting the reaction he wanted, and the word he used for that was listening. Meanwhile, I had reacted to his statements with arguments against them. To me, this is close to the essence of listening.

If you really believe someone isn’t listening, it’s unlikely that it will help to say that, unless you have a strong personal relationship. When my wife tells me I’m not listening, that’s a very special case. She’s weaker than me and crucial to my health and happiness, therefore I will use every tool at my disposal to make myself easy for her to talk to. I generally do the same for children, dogs, people who seem mentally unstable, fire, and dangerous things, but not for most colleagues. I do get crossed up sometimes. Absolutely. Especially on Twitter. Sometimes I assume a colleague feels powerful, and respond to him that way, only later to discover he was afraid of me.

(This happened again just the other day on Twitter. Which is why it is unlikely you will see me teach in Finland any time soon! I am bitten by such a mistake a few times a year, at least. For me this is not a reason to be softer with my colleagues. Then again, it may be. I struggle with the pros and cons. There is no simple answer. I regularly receive counsel from my most trusted colleagues on this point.)

A Sign of Being Listened to is the Change that Happens

Introspect for a moment. How do you know that your computer is listening to you? At this moment, as I am typing, the letters I want to see are appearing on the screen as I press the keys. WordPress is talking back to me. WordPress is changing, and its changes seem coherent and reasonable to me. My purposes are apparently being served. The computer is listening. Consider what happens when you don’t see a response from your computer. How many times have you clicked “save” or “print” or “calculate” or “paste” and suffered that sinking feeling as the forest noises go completely silent and your screen goes glassy and gets that faraway grayed out look of the damned? You feel out of control. You want to shout at your screen “Come back! I’ve changed my mind! Undo! Cancel!” How do you feel then? You don’t say to yourself “what a good listener my computer is!”

Why is this so? It’s because you are involved in a cybernetic control loop with your computer. Without frequent feedback from your system you lose your control over it. You don’t know what it needs or what to do about it. It may be listening to something, but when nothing changes in a manner that seems to relate to your input, you suspect it is not listening to you.

Based just on this example I conjecture that we feel listened to when a system responds to our utterances and actions in a harmonious manner that honors our purposes. I further conjecture that the advice to maintain attentive silence in order to listen better is a special case of change in such a way as to foster harmony and supportiveness.

Can we think of a situation where listening to someone means shouting loudly over them? I can. I was recently in a situation where a quiet colleague was trying to get students to return to her tutorial after a break. The hallway was too noisy and few people could hear her. I noticed that, so I repeated her words very loudly that her students might hear. I would argue that I listened and responded harmoniously in support of her needs. I didn’t ask her if she felt that I listened to her. She knows I did. I could tell by her smile.

If my wife cries “brake!” when I’m driving, I hit the brake. The physical action of my foot on the brake is her evidence that I listened, not attentive silence or passivity.

It may be a small change or a large change, but for the person communicating with you to feel listened to, they must see good evidence of an appropriate change (or change process) in you.

Let me tell you about being a father of a strong-minded son. I have been in numerous arguments with my boy. I have learned how to get my point across: plant the idea, argue for a while, and then let go of it. I discovered it doesn’t matter if he seems to reject the idea. In fact, I’ve come to believe he cannot reject any idea of mine unless it is genuinely wrong for him. I know he’s listening because he argues with me. And if he gets upset, that means he must be taking it quite seriously. Then I wait. And I invariably see a response in the days that follow (I mean not a single instance of this not happening comes to mind right now).

One of the tragedies of fatherhood is that many fathers can’t tell when their children are listening because they need to see too specific a response too quickly. Some listening is a long process. I know that my son needs to chew on difficult ideas in order to process them. This is how to think about the listening process. True listening implies digestion and incubation. The mental metabolism is subtle, complicated, and absolutely vital.

Let People Chew on Your Ideas

Listening is not primarily about taking information into yourself, any more than eating is about taking food into yourself. With eating the real point is digestion. And for good listening you need to digest, too. Part of digestion is chewing, and for humans part of listening is reacting to the raw data for the purposes of testing understanding and contrasting the incoming data with other data they have. Listening well about any complicated thing requires testing. Does this apply to your spouse and children, too? Yes! But perhaps it applies differently to them than to a colleague at work, and certainly differently than testing-as-listening to politician or a telemarketer.

Why does this matter so much? Because if we uncritically accept ideas we risk falling prey to shallow agreement, which is the appearance of agreement despite an unrecognized deep disagreement. I don’t want to find out in the middle of a critical moment on a project that your definition of testing, or role, or collaboration, or curiosity doesn’t match mine. I want to have conversations about the meanings of words well before that. Therefore I test my understanding. Too many in the Agile culture seem to confuse a vacant smile with philosophical and practical comprehension. I was told recently that for an Agile tester, “collaboration” may be more important than testing skill. That is probably the stupidest thing I have heard all year. By “stupid” I mean willfully refusing to use one’s mind. I was talking to a smart man who would not use his smarts in that moment, because, by his argument, the better tester is the one who agrees to do anything for anyone, not the one who knows how to find important bugs quickly. In other words, any unskilled day laborer off the street, desperate for work, is apparently a better tester than me. Yeah… Right…

In addition to the idea digestion process, listening also has a critical social element. As I said above, whether or not you are listening is, practically speaking, always a matter of potential dispute. That’s the way of it. Listening practices and instances are all tied up in socially constructed rituals and heuristics. And these rituals are all about making ourselves open to reasonable change in response to each other. Listening is about the maintenance of social order as well as maintaining specific social relationships. This is the source of all that advice about listening by keeping attentively quiet while someone else speaks. What that misses is that the speaker also has a duty to perform in the social system. The speaker cannot blather on in ignorance or indifference to the idea processing practices of his audience. When I teach, I ask my students to interrupt me, and I strive to reward them for doing so. When I get up to speak, I know I must skillfully use visual materials, volume control, rhythm, and other rhetorical flourishes in order to package what I’m communicating into a more digestible form.

Unlike many teachers, I don’t interpret silence as listening. Silence is easy. If an activity can be done better and cheaper by a corpse or an inanimate object, I don’t consider it automatically worth doing as a living human.

I strongly disagree with Paul Klipp when he writes: “Then stop thinking about talking and pretend, if it’s not obvious to you yet, that the person who is talking is as good at thinking as you are. You may suddenly have a good idea, or you may have information that the person speaking doesn’t. That’s not a good enough reason to interrupt them when they are thinking.” Paul implies that interrupting a speaker is an expression of dominance or subversion. Yes, it can be, but it is not necessarily so, and I wish someone trained in Anthropology would avoid such an uncharitable oversimplification. Some interruptions are harmful and some are helpful. In fact, I would say that every social act is both harmful and helpful in some way. We must use our judgment to know what to say, how to say it and when. Stating favorite heuristics as if they were “best practices” is patronizing and unnecessary.

One Heuristic of Listening: Stop Talking

Where I agree with Paul and others like him is that one way of improving the harmony of communication and that feeling of being coherently and charitably responded to is to talk less. I’m more likely to use that in a situation where I’m dealing with someone whom I suspect is feeling weak, and whom I want to encourage to speak to me. However, another heuristic I use in that situation is to speak more. I do this when I want to create a rhetorical framework to help the person get his idea across. This has the side effect of taking pressure of someone who may not want to speak at all. I say this based on the vivid personal experience of my first date with the one who would become my wife. I estimate I spoke many thousands of words that evening. She said about a dozen. I found out later that’s just what she was looking for. How do I know? After two dates we got married. We’ve been married 23 years, so far. I also have many vivid experiences of difficult conversations that required me to sit next to her in silence for as long as 10 minutes until she was ready to speak. Both the “talk more” and “talk less” heuristics are useful for having a conversation.

What does this have to do with testing?

My view of listening can be annoying to people for exactly the same reason that testing is annoying to people. A developer may want me to accept his product without “judgment.” Sorry, man. That is not the tester’s way. A tester who doesn’t subject your product to criticism is, in fact, not taking it seriously. You should not feel honored by that, but rather insulted. Testing is how I honor strong, good products. And arguing with you may be how I honor your ideas.

Listening, I claim, is itself a testing process. It must be, because testing is how we come to comprehend anything deeply. Testing is a practice that enables deep learning and deeply trusting what we know.

Are You Listening to Me?

Then feel free to respond. Even if you disagree, you could well have been listening. I might be able to tell from your response, if that matters to you.

If you want to challenge this post, try reading it carefully… I will understand if you skip parts, or see one thing and want to argue with that. Go ahead. That might be okay. If I feel that there is critical information that you are missing, I will suggest that you read the post again. I don’t require that people read or listen to me thoroughly before responding. I ask only that you make a reasonable and charitable effort to make sense of this.


Categories: Blogs

Knowledge Sharing

SpiraTest is the most powerful and affordable test management solution on the market today