Skip to content


Should our front-end websites be server-side at all?

Decaying Code - Maxime Rouiller - 4 hours 25 min ago

I’ve been toying around with projects like Jekyll, Hexo and even some hand-rolled software that will generate me HTML files based on data. The thought that crossed my mind was…

Why do we need dynamically generated HTML again?

Let me take examples and build my case.

Example 1: Blog

Of course the simpler examples like blogs could literally all be static. If you need comments, then you could go with a system like Disqus. This is quite literally one of the only part of your system that is dynamic.

RSS feed? Generated from posts. Posts themselves? Could be automatically generated from a databases or Markdown files periodically. The resulting output can be hosted on a Raspberry Pi without any issues.

Example 2: E-Commerce

This one is more of a problem. Here are the things that don’t change a lot. Products. OK, they may change but do you need to have your site updated right this second? Can it wait a minute? Then all the “product pages” could literally be static pages.

Product reviews? They will need to be “approved” anyway before you want them live. Put them in a servier-side queue, and regenerate the product page with the updated review once it’s done.

There’s 3 things that I see that would require to be dynamic in this scenario.

Search, Checkout and Reviews. Search because as your products scales up, so does your data. Doing the search client side won’t scale at any level. Checkout because we are now handling an actual order and it needs a server components. Reviews because we’ll need to approve and publish them.

In this scenario, only the Search is the actual “Read” component that is now server side. Everything else? Pre-generated. Even if the search is bringing you the list of product dynamically, it can still end up on a static page.

All the other write components? Queued server side to be processed by the business itself with either Azure or an off-site component.

All the backend side of the business (managing products, availability, sales, whatnot, etc.) will need a management UI that will be 100% dynamic (read/write).


So… do we need dynamic front-end with the latest server framework? On the public facing too or just the backend?

If you want to discuss it, Tweet me at @MaximRouiller.

Categories: Blogs

You should not be using WebComponents yet

Decaying Code - Maxime Rouiller - 4 hours 25 min ago

Have you read about WebComponents? It sounds like something that we all tried to achieve on the web since... well... a long time.

If you take a look at the specification, it's hosted on the W3C website. It smell like a real specification. It looks like a real specification.

The only issue is that Web Components is really four specifications. Let's take a look at all four of them.

Reviewing the specificationsHTML Templates


This specific specification is not part of the "Web components" section. It has been integrated in HTML5. Henceforth, this one is safe.

Custom Elements


This specification is for review and not for implementation!

Alright no let's not touch this yet.

Shadow DOM


This specification is for review and not for implementation!

Wow. Okay so this is out of the window too.

HTML Imports


This one is still a working draft so it hasn't been retired or anything yet. Sounds good!

Getting into more details

So open all of those specifications. Go ahead. I want you to read one section in particular and it's the author/editors section. What do we learn? That those specs were draft, edited and all done by the Google Chrome Team. Except maybe HTML Templates which has Tony Ross (previously PM on the Internet Explorer Team).

What about browser support?

Chrome has all the spec already implemented.

Firefox implemented it but put it behind a flag (about:config, search for properties dom.webcomponents.enabled)

Internet Explorer, they are all Under Consideration

What that tells us

Google is pushing for a standard. Hard. They built the spec, pushing the spec also very hary since all of this is available in Chrome STABLE right now. No other vendors has contributed to the spec itself. Polymer is also a project that is built around WebComponents and it's built by... well the Chrome team.

That tells me that nobody right now should be implementing this in production. If you want to contribute to the spec, fine. But WebComponents are not to be used.

Otherwise, we're only getting in the same issue we were in 10-20 years ago with Internet Explorer and we know it's a painful path.

What is wrong right now with WebComponents

First, it's not cross platform. We handled that in the past. That's not something to stop us.

Second, the current specification is being implemented in Chrome as if it was recommended by the W3C (it is not). Which may lead us to change in the specification which may render your current implementation completely inoperable.

Third, there's no guarantee that the current spec is going to even be accepted by the other browsers. If we get there and Chrome doesn't move, we're back to Internet Explorer 6 era but this time with Chrome.

What should I do?

As for what "Production" is concerned, do not use WebComponents directly. Also, avoid Polymer as it's only a simple wrapper around WebComponents (even with the polyfills).

Use other framework that abstract away the WebComponents part. Frameworks like X-Tag or Brick. That way you can benefit from the feature without learning a specification that may be obsolete very quickly or not implemented at all.

Categories: Blogs

Fix: Error occurred during a cryptographic operation.

Decaying Code - Maxime Rouiller - 4 hours 25 min ago

Have you ever had this error while switching between projects using the Identity authentication?

Are you still wondering what it is and why it happens?

Clear your cookies. The FedAuth cookie is encrypted using the defined machine key in your web.config. If there is none defined in your web.config, it will use a common one. If the key used to encrypt isn't the same used to decrypt?

Boom goes the dynamite.

Categories: Blogs

Renewed MVP ASP.NET/IIS 2015

Decaying Code - Maxime Rouiller - 4 hours 25 min ago

Well there it goes again. It was just confirmed that I am renewed as an MVP for the next 12 months.

Becoming an MVP is not an easy task. Offline conferences, blogs, Twitter, helping manage a user group. All of this is done in my free time and it requires a lot of time.But I'm so glad to be part of the big MVP family once again!

Thanks to all of you who interacted with me last year, let's do it again this year!

Categories: Blogs

Failed to delete web hosting plan Default: Server farm 'Default' cannot be deleted because it has sites assigned to it

Decaying Code - Maxime Rouiller - 4 hours 25 min ago

So I had this issue where I was moving web apps between hosting plans. As they were all transferred, I wondered why it refused to delete them with this error message.

After a few click left and right and a lot of wasted time, I found this blog post that provides a script to help you debug and the exact explanation as to why it doesn't work.

To make things quick, it's all about "Deployment Slots". Among other things, they have their own serverFarm setting and they will not change when you change their parents in Powershell (haven't tried by the portal).

Here's a copy of the script from Harikharan Krishnaraju for future references:

Switch-AzureMode AzureResourceManager
$Resource = Get-AzureResource

foreach ($item in $Resource)
	if ($item.ResourceType -Match "Microsoft.Web/sites/slots")
		$plan=(Get-AzureResource -Name $item.Name -ResourceGroupName $item.ResourceGroupName -ResourceType $item.ResourceType -ParentResource $item.ParentResource -ApiVersion 2014-04-01).Properties.webHostingPlan;
		write-host "WebHostingPlan " $plan " under site " $item.ParentResource " for deployment slot " $item.Name ;

	elseif ($item.ResourceType -Match "Microsoft.Web/sites")
		$plan=(Get-AzureResource -Name $item.Name -ResourceGroupName $item.ResourceGroupName -ResourceType $item.ResourceType -ApiVersion 2014-04-01).Properties.webHostingPlan;
		write-host "WebHostingPlan " $plan " under site " $item.Name ;
Categories: Blogs

Switching Azure Web Apps from one App Service Plan to another

Decaying Code - Maxime Rouiller - 4 hours 25 min ago

So I had to do some change to App Service Plan for one of my client. The first thing I was looking for was to do it under the portal. A few clicks and I'm done!

But before I get into why I need to move one of them, I'll need to tell you about why I needed to move 20 of them.

Consolidating the farm

First, my client had a lot of WebApps deployed left and right in different "Default" ServicePlan. Most were created automatically by scripts or even Visual Studio. Each had different instance size and difference scaling capabilities.

We needed a way to standardize how we scale and especially the size on which we deployed. So we came down with a list of different hosting plans that we needed, the list of apps that would need to be moved and on which hosting plan they currently were.

That list went to 20 web apps to move. The portal wasn't going to cut it. It was time to bring in the big guns.


Powershell is the Command Line for Windows. It's powered by awesomeness and cats riding unicorns. It allows you to do thing like remote control Azure, import/export CSV files and so much more.

CSV and Azure is what I needed. Since we built a list of web apps to migrate in Excel, CSV was the way to go.

The Code or rather, The Script

What follows is what is being used. It's heavily inspired of what was found online.

My CSV file has 3 columns: App, ServicePlanSource and ServicePlanDestination. Only two are used for the actual command. I could have made this command more generic but since I was working with apps in EastUS only, well... I didn't need more.

This script should be considered as "Works on my machine". Haven't tested all the edge cases.


Switch-AzureMode AzureResourceManager
$rgn = 'Default-Web-EastUS'

$allAppsToMigrate = Import-Csv $filename
foreach($app in $allAppsToMigrate)
    if($app.ServicePlanSource -ne $app.ServicePlanDestination)
        $appName = $app.App
		    $source = $app.ServicePlanSource
		    $dest = $app.ServicePlanDestination
        $res = Get-AzureResource -Name $appName -ResourceGroupName $rgn -ResourceType Microsoft.Web/sites -ApiVersion 2014-04-01
        $prop = @{ 'serverFarm' = $dest}
        $res = Set-AzureResource -Name $appName -ResourceGroupName $rgn -ResourceType Microsoft.Web/sites -ApiVersion 2014-04-01 -PropertyObject $prop
        Write-Host "Moved $appName from $source to $dest"
Categories: Blogs

Microsoft Virtual Academy Links for 2014

Decaying Code - Maxime Rouiller - 4 hours 25 min ago

So I thought that going through a few Microsoft Virtual Academy links could help some of you.

Here are the links I think deserve at least a click. If you find them interesting, let me know!

Categories: Blogs

Temporarily ignore SSL certificate problem in Git under Windows

Decaying Code - Maxime Rouiller - 4 hours 25 min ago

So I've encountered the following issue:

fatal: unable to access 'https://myurl/myproject.git/': SSL certificate problem: unable to get local issuer certificate

Basically, we're working on a local Git Stash project and the certificates changed. While they were working to fix the issues, we had to keep working.

So I know that the server is not compromised (I talked to IT). How do I say "ignore it please"?

Temporary solution

This is because you know they are going to fix it.

PowerShell code:

$env:GIT_SSL_NO_VERIFY = "true"

CMD code:


This will get you up and running as long as you don’t close the command window. This variable will be reset to nothing as soon as you close it.

Permanent solution

Fix your certificates. Oh… you mean it’s self signed and you will forever use that one? Install it on all machines.

Seriously. I won’t show you how to permanently ignore certificates. Fix your certificate situation because trusting ALL certificates without caring if they are valid or not is juts plain dangerous.

Fix it.


Categories: Blogs

The Yoda Condition

Decaying Code - Maxime Rouiller - 4 hours 25 min ago

So this will be a short post. I would like to introduce a word in my vocabulary and yours too if it didn't already exist.

First I would like to credit Nathan Smith for teaching me that word this morning. First, the tweet:

Chuckling at "disallowYodaConditions" in JSCS… — Awesome way of describing it.

— Nathan Smith (@nathansmith) November 12, 2014

So... this made me chuckle.

What is the Yoda Condition?

The Yoda Condition can be summarized into "inverting the parameters compared in a conditional".

Let's say I have this code:

string sky = "blue";if(sky == "blue) {    // do something}

It can be read easily as "If the sky is blue". Now let's put some Yoda into it!

Our code becomes :

string sky = "blue";	if("blue" == sky){    // do something}

Now our code read as "If blue is the sky". And that's why we call it Yoda condition.

Why would I do that?

First, if you're missing an "=" in your code, it will fail at compile time since you can't assign a variable to a literal string. It can also avoid certain null reference error.

What's the cost of doing this then?

Beside getting on the nerves of all the programmers in your team? You reduce the readability of your code by a huge factor.

Each developer on your team will hit a snag on every if since they will have to learn how to speak "Yoda" with your code.

So what should I do?

Avoid it. At all cost. Readability is the most important thing in your code. To be honest, you're not going to be the only guy/girl maintaining that app for years to come. Make it easy for the maintainer and remove that Yoda talk.

The problem this kind of code solve isn't worth the readability you are losing.

Categories: Blogs

Do you have your own Batman Utility Belt?

Decaying Code - Maxime Rouiller - 4 hours 25 min ago
Just like most of us on any project, you (yes you!) as a developer must have done the same thing over and over again. I'm not talking about coding a controller or accessing the database.

Let's check out some concrete examples shall we?

  • Have you ever setup HTTP Caching properly, created a class for your project and call it done?
  • What about creating a proper Web.config to configure static asset caching?
  • And what about creating a MediaTypeFormatter for handling CSV or some other custom type?
  • What about that BaseController that you rebuild from project to project?
  • And those extension methods that you use ALL the time but rebuild for each projects...

If you answered yes to any of those questions... you are in great risk of having to code those again.

Hell... maybe someone already built them out there. But more often than not, they will be packed with other classes that you are not using. However, most of those projects are open source and will allow you to build your own Batman utility belt!

So once you see that you do something often, start building your utility belt! Grab those open source classes left and right (make sure to follow the licenses!) and start building your own class library.


Once you have a good collection that is properly separated in a project and that you seem ready to kick some monkey ass, the only way to go is to use NuGet to pack it together!

Checkout the reference to make sure that you do things properly.

NuGet - Publishing

OK you got a steamy new hot NuGet package that you are ready to use? You can either push it to the main repository if your intention is to share it with the world.

If you are not ready quite yet, there are multiple way to use a NuGet package internally in your company. The easiest? Just create a Share on a server and add it to your package source! As simple as that!

Now just make sure to increment your version number on each release by using the SemVer convention.

Reap the profit

OK, no... not really. You probably won't be money anytime soon with this library. At least not in real money. Where you will gain however is when you are asked to do one of those boring task yet over again in another project or at another client.

The only thing you'll do is import your magic package, use it and boom. This task that they planned would take a whole day? Got finished in minutes.

As you build up your toolkit, more and more task will become easier to accomplish.

The only thing left to consider is what NOT to put in your toolkit.

Last minute warning

If you have an employer, make sure that your contract allows you to reuse code. Some contracts allows you to do that but double check with your employer.

If you are a company, make sure not to bill your client for the time spent building your tool or he might have the right to claim them as his own since you billed him for it.

In case of doubt, double check with a lawyer!

Categories: Blogs

Who Moved My Cheese Sandwich?

Jonathan Kohl - Thu, 08/27/2015 - 17:59

My Dad was a school teacher for 25 years. For several years, he had the same thing for lunch: a plain cheese sandwich. My Mom enjoyed getting all of us ready for school in the morning and would make us our lunches, put them in a brown paper bag, and label them. My sister and I were finicky eaters at best, constantly changing our minds, or feeling jealous of classmates who had “cooler” lunches (usually junk food.) My Dad stuck to what he wanted, and it made my Mom’s job easy. She’d make him a plain cheese sandwich, and he happily took it to work.

Then one fateful day he snapped.

He told my Mom he never wanted to see a cheese sandwich ever again because he was sick of them. She was a bit shocked at first, but we all had a big laugh about it, since it had only taken him years of having the same thing for lunch every working day to get tired of it. Most of us have far less patience and are far more discriminating in our tastes and a need for variety. I’ve worked for years as a consultant helping software development teams, and I see their versions of the cheese sandwich constantly.

Software development team’s version of the cheese sandwich tends to be process-related. Teams do the same things over and over because that’s what they are used to, because they are dogmatic in their alignment with a process ideal, or because it seems that is what everyone else is doing.

A few years ago, I was helping David Hussman with a book project that eventually became a Pragmatic Press production: Cutting an Agile Groove: The Live Sessions. As I looked over a collection of David’s writings, three key phases of team productivity came to mind:

  1. Getting Started
  2. Getting Productive
  3. Staying Productive

Most teams I have observed are pretty good at getting started and getting productive, but a huge majority have a lot of trouble staying productive. Many teams plateau and even drop off over the life of a project, and especially when they work on projects together year after year. A big part of why they plateau is because they don’t change up their processes and practices, and they get bored.

If the team isn’t willing to change, they won’t. My Mom tried for years to suggest things to mix it up. My Dad stuck with the cheese sandwich. However, once he made up his mind to change, he was ready for it, and he went for it. You can’t force change on people, you can only really support it. It can be frustrating to work with a team that has obvious problems, yet they refuse to look at simple, proven solutions and won’t try anything new.

After slavishly sticking to one thing for so long, Dad got rid of it altogether. Sometimes this is worthwhile, but on software teams this can be overkill. I see this with software development teams all the time – the old way is wrong, throw it all away! This can be unfortunate. There might be good things that are getting thrown aside. What you were doing before wasn’t necessarily all wrong, you are just tired of it and enamoured with something new. Or, it is still a good practice, it just doesn’t work for your team anymore.

Recently, a team I was working with decided to get rid of using a wiki. They had process dysfunction, and saw a fantastic presentation by Ralph Boden “Changing the Laws of Engineering with GitHub Pull Requests” that challenged the usefulness of wikis. The team Ralph was working on got rid of wikis, and had some compelling reasons for doing so. Instead of using this presentation as an example of what worked for one team, the take away was that wikis were bad and now have no place on a software development team. It turned out that for this team, the wiki was a useful tool and throwing it away altogether was premature. We see this a lot in software development communities, often in the form of “___X___ is dead!” pronouncements. No, X isn’t dead, it just doesn’t work for you anymore, so don’t discourage other teams from doing X. Just because your team doesn’t like cheese sandwiches anymore doesn’t give you the right to disparage cheese sandwiches and anyone who enjoys them.

Software development is complex and difficult. It is a huge challenge to get a team together, get productive, stay productive, and sustain this over several product releases. The lesson in the cheese sandwich is to not stick with one process or practice for too long. Just like with food, software processes require variety, serve different needs for different people, have different requirements and restrictions, and will get stale over time.

See Things Change and So Should Processes for more on this theme.

Categories: Blogs

More haiku updates

I’ve added some new ones, need to take one out. At some point, there should probably be a bunch of Scaled Agile haiku.

See the agile haiku page.

Categories: Blogs

Cloud Testing; How to Test on the Cloud?

Software Testing Zone - Wed, 08/26/2015 - 11:52
Unless you've been living under a rock you must already be knowing that 'Cloud Computing' has been making a lot of buzz over past couple of years -- whether it your peer meeting, a client interview, a demo POC session with a prospect, the recent Red Hat Enterprise Virtualization Online Event on January 18, 2012 -- the talk about cloud is everywhere.

And why wouldn't it be? After all,  if industry analysts and virtualization experts are to be believed then cloud based computing and business solutions are going to be the NEXT BIG thing of this decade.
So I guess it is only natural if you find yourself to be asking yourself questions like 'what is cloud testing?',  'how to test on cloud?', 'how can we use cloud to better our testing?', 'how does cloud impact how we used to test before?' etc.

However, since all these queries pose different questions, the answers to them would be unique. For starters, if you are looking for cloud testing, it simply means a testing environment that utilizes cloud infrastructure for performing software testing.
How to leverage Cloud to Transform Software Testing?
If you are someone who heavily use tools while testing then IBM (IBM Cloud) and Hewlett-Packard have already jumped into the market for software testing in the cloud. Thankfully, if done smartly, cloud based computing can prove to be a great value-addition for both software development and testing. The reason is simple -- the very nature of a cloud based infrastructure allows for great team collaboration.
As an added advantage, cloud based testing (as well as programming) environments are easy to setup (on-demand). In today's tight budgeted IT world, this can be a much bigger advantage than it appears at first. It is no secret that IT managers are operating under a very tight budgetary constraint and when it comes to testing phase, the budget is even smaller.
Traditional approaches to setting up a test environment involves high cost to setup multiple servers with various OS, hardware configuration, browser versions etc. And if you are going to simulate user activity from different geographic locations you will have to setup test servers with localized regional language OS, which in turn can add up to the cost. But using cloud based infrastructure, the team wouldn't have to setup expensive physical servers -- rather, setting up new testing environment will be fast and efficient and VMs (virtual machines) and test servers can be launched and decommissioned as needed.
On the other hand, as a tester you might also be required to one of those ever emerging cloud based SaaS applications that aim to cater to various large and small customer base, on-demand. If you are testing such a cloud based application then your challenges are double-fold. Because, testing all the layers - from your application to the cloud service provider - is something that as a tester you will have to become efficient in.
As a closing note, if you are a tester and if you are intrigued by all these buzz surrounding cloud testing, then here are 2 main reasons why you might consider trying it out -- Cloud based software testing infrastructure  greatly helps in reducing capital expenditure and these testing setups are highly scalable, thus allowing your team to expand or decommission your test servers on-demand, as needed.
Are you someone already using cloud testing? Share your experience with me and other readers by leaving your comment below.
Categories: Blogs

Top 5 Software Testing Traps and How to Overcome Them

Software Testing Zone - Wed, 08/26/2015 - 11:49
If you are a software tester and have been in this field for a while then you might have run into situations (let me call them traps and hurdles) that limit your efficiency and effectiveness as a tester. It could be a common problem like lack of enough time and/or resources to finish testing or could be because you are surrounded by coworkers and colleagues who don't realize the importance of your work. But if you're like me who cannot work on projects and with people unless you have got credibility, respect and their confidence in the work you do, then you must be aware of these pitfalls, mistakes, traps and hurdles that any tester can face in their life.
I started writing this blog when I began my software testing career (exactly 9 years from today) and I don't know about you but I have run into plenty such software testing traps while working on various testing projects at various stages of my career. And every time I ran into them, it gave me a chance to look for magic spells, ways, methods, techniques, tricks, tips and anything and everything that could help me come out of such situations. And today's article is a compilation of some of those top 5 traps that I've ever run into in my software testing career and some of the ways that helped me overcome them, in my context. The following case points and suggested solutions can help you overcome many common real-life software testing problems.

#1 Running Out of Testing Ideas?  This is by far the most common problem that a tester can run into while on a project. How many times have you been in a situation where you didn't know what else to test and how? I call this phenomenon as  "tester’s block syndrome"  [a condition, associated with testing as a profession, in which a tester may lose the ability to find new bugs and defects in the software that (s)he is testing]. If you're curious, which you should be (if you are or aim to become a good tester), then you can read more about it in the article titled The Se7en Deadly Sins in "Software Testing" that I wrote a while back.How to overcome this trap?Pair Testing: You can use Pair testing to your advantage to generate test ideas that seem to have dried up when you try alone. Pair testing is nothing but a testing technique where two testers work in pair to test the software under test.
BCA (Brute Cause Analysis): Testers can employ this unique brainstrom technique when one tester thinks about a bug and the other tester thinks of all possible functions and areas where this bug can manifest.
Think 'Out of the Box': Instead of thinking about the feature/function/application in front of you, rather try thinking in opposite directions. Take a step back and reassess the situation. Have you been trying to run functionality test when you ran out of ideas? How about performance, load and stress tests? How about tests involving data, structures, platforms, browsers, devices, operations? #2 Missing the Testing Goal?How many times were you in a team meeting where your manager or someone from the dev. team was talking about this cool new/enhanced feature that needs testing and everybody else in the meeting room appeared to be 'getting it' whereas it was only you who had no idea what it was? When in such situation, nodding your head as if you are able to understand everything may seem like the natural (easy) path but trust me; it is not the best path to go unless you want  to end up in trouble later in the test planning and execution phase of this feature!How to overcome this trap?Ask Relevant Questions: The importance of good questioning skills can not be stressed enough if you plan to be an excellent tester. And this very skill can come to your rescue when you are trapped in a situation like the above. It's okay to admit you don't understand something and then get it clarified than to not admit and be ignorant for rest of your life.
Brainstorm: Okay, so you have asked tons of relevant questions about the upcoming feature/application/product that needs testing and have taken notes. Now what? Now is the time to pull your testing team and brainstorm ideas to find all sorts of possible test ideas, strategies, plans etc for this test project by gathering a list of ideas that come spontaneously by the teammates.
Read between the lines: More often than not, when starting working on a new product or technology or even a tool you can find some level of available documentation on the same to help you get started. But a word of advice -- take everything that you read there with a pinch of salt. I'm not saying not to read them at all. But when you do, be careful about all those things that might not have been put down in words but are implied. Sometimes, proactively being able to find and underhand these implied messages in the project documents can help you in a big way to understand the testing goal.#3 Suffering from In-attentional Blindness?How many times have you missed a very obvious bug or a defect or an error that was right there on the screen, staring right back you and yet you missed it because you were busy ticking off the other test items from the testing checklist or executing the test case document? Situations like these can be very embarrassing not only because you missed something that is so basic and so obvious but also because it happened when you were actually busy religiously following the test cases to find things just like these!How to overcome this trap?Stop blindly following the Test Case and Test Matrix: Before starting to use a test case for your testing always ask yourself the following questions and then adjust your test cases to fill any missing links.
    - "Why is this test case important?"
    - "What are the things that are covered by this test case? What are not?"
    - "What portion of the product functionality does this test case cover?"
    - "Can this test case be tested in any other methods or ways? If yes, how?"

    Change the Focal Length of Your Testing Approach: When following the test cases and test matrix to test something, keep and open eye for anything else that might be going on during test execution. Explore other related areas even though they are not mentioned in your test case/matrix. A control object that flickers a little when you save your inputs in another section of the form, a ding sound coming from the speaker when certain button is clicked, a slight change in the color of a Submit button when you click  inside another test area -- all of these subtle looking actions may be an indication of an approaching catastrophic system failure.#4 Not Sure if 'It' is Really Working... or Not?How many times have you come across issues that you didn't report as errors and bugs because you were not sure if it was really a bug or something that you did wrongly and later those same issues were found and picked up by a coworker or your manager or, god forbid, your clients or the customers?How to overcome this trap?Trust Your Tester's Instinct: IF your instinct is telling you that something is fishy and what you're observing and experiencing could very well be a bug, then follow your instinct and report it to the devs. After all, what could be the worst case scenario? The devs might come back and say it is something that you did wrong (misconfiguration of certain settings, misunderstanding of the actual feature etc) and not a bug. It is still much more better than ignoring it thinking it might not be a bug and later your manager or customer finding it.
    Start with a fresh set of eyes: Fresh eyes find bugs, and if you are still unsure then take a short break and retest and confirm that what you're seeing is really not a bug.
    Have it tested by a fellow tester: Pick one of your fellow testers and ask them to go through the same test scenario and see what they come up with.#5 What to Test and What can be Skipped... Safely?How many times have you been in a situation when you felt overwhelmed by the number of possibilities and choices to approach testing? With the complexity of software and technology becoming more complex day by day, often the number of things that a tester needs to consider while testing can be overwhelming. And with the project deadline approaching fast it can be very challenging to decide what to test, where to begin, how to begin and what can be skipped.
    How to overcome this trap?Gather Intelligence Data: First of all, look at the existing bugs in your bug tracker tool and make a note of critical bugs. Talk to developers and ask them to think of top 10 most critical things in the product that affects majority of end-user functions and make a list of them too. Go though the review docs, user manuals, implementor's guide and basically anything that can give you an idea of things that are going to be most important for your customers and end users.
    DIQ approach (Dive In/Quit): Now that you have the list of all these important things that need testing, let me introduce to you the magical DIQ approach (Dive In/Quit). In this testing approach, pick any of these most critical test items and just dive in and test. While testing, if it appears too hard for you then quit and take another item, dive in and test until you have exhausted all your test ideas on it. Repeat! So basically you take an item > dive in > quit when you can't test it any further > repeat it with another item > come back to initial item when you have finished all other test items.#And finally... Learn to Accept FAILURE, once in a while!Due to the intrinsic nature of complexity of modern day software and communications systems, software testing is turning more complicated. As a result, more efficient and effective testing heuristics, techniques and methodologies needs to emerge. If you are not evolving fast enough as a tester then the chance of failure is exponentially high and you should be prepared to face failure once in a while. After all, we are testers; not magicians! But as long as you are learning from your past mistakes, upgrading your testing skills and updating your testing heuristics to accommodate those mistakes so they never happen again, I think you should be fine.
    Categories: Blogs

    Top 5 Lame Excuses for Not Having Enough Testers/Testing

    Software Testing Zone - Wed, 08/26/2015 - 11:46
    It’s amazing how many product teams never give enough importance to testing (and testers). And the excuses you hear are even more astonishing; albeit funny. With all the free and open source testing tools, services, sites, blogs and books available, one can no longer have any more excuses not to perform software testing on their product before they release it. It might come as a surprise to some, but in most cases many developers do not get the opportunity to work with a truly competent tester and hence they don't know what that is like. Ignoring the importance of testing and testers in a team is such a hideous false economy that it is hard to believe so many organizations and people still believe in it and hence have to resort to these stupid excuses for not having enough testing/testers.
    I realize that it may be hard to rank these (dumb) reasons that people like to use for not doing enough testers (and hiring enough testers) but here are the top 5 stupid reasons people don't hire testers. Read on...My Product isn't Finished YetIn today's rapid development age where methodologies like agile scrum and sprint are mainstream, how more absurd could your excuse be than this one? Even if you work in an environment where several Beta versions are released first before the final product, will you be willing to risk losing your customer's trust and your reputation by releasing versions that are laced with defects?Also, will you be willing to bet that your star programmer doesn't leave you and join another organization with a dedicated testing team and proper QA methodologies in place, because he got fed up reading through and fixing hundreds of customer reported bugs everyday? The sooner you realize the importance of finding and fixing bugs earlier in the product cycle, not only will it save you revenue but also your reputation.Quality is Everyone's Responsibility; No Dedicated Testers are NeededSuch excuses usually come from teams that (at least believe that they) follow the mantra "Quality is everyone's responsibility", and hence they jump into this inappropriate misconception that you can actually get great results without dedicated testers. Theoretically, this all works. But the problem begins when everyone starts assuming that every other guy in the other cubicles are already testing the product and hence it is okay if he skips it.An extension to the above excuse that I hear frequently is that the programmers will become lazy and end up writing buggy code if they know there is a testing team responsible of finding the defects. But let's face it; programmers are either lazy or they're not! A programmer who takes pride in his work will rigorously test his code no matter whether or not you have a dedicated team of testers.We have Budget/Time Constraints.Who doesn't? Do-it-yourself testing by your programmers can save you some dollars and can even be effective (if they’re imaginative). Also, it is still cheaper to hire an average tester than it is to hire an average programmer. And if you don't hire testers, you're going to end up having your programmers doing testing. From my own experience, not only the programmers are mediocre when it comes to testing but they also tend to overlook errors in their code as compared to a tester testing it. Everyone has budget constraints. But great product teams are good at realizing the importance of a dedicated QA team on board and they know it is more of an investment than an unnecessary expense. And here are some things to consider if you're worrying about testing on a tight schedule.My Product is Perfect. It doesn’t need Testing.Actually, NO! If your product is perfect then either it is not a product or isn't actually perfect. In either of the cases, this means that all products need testing as long as they are complex enough to qualify as good usable products (software, website, web application etc).A separate QA team can build an 'Us vs Them mentality', which is not HealthyI've worked in teams where test and dev reported to the same manager, and also in teams where the testers reported to dedicated test managers. In my experience, both of these can work well provided the office politics is kept under control and the team's manager is responsible at ensuring so. Good teams realize that a dedicated testing team is essential to the team's overall success and that the QA team not only saves the programmers a lot of time (and credibility) by helping them fix defects before they find their way to the customers but also save the stakeholders substantial revenue that would otherwise be spent on fixing the bugs in a post-release scenario and would require subsequent patches to be released; not to mention the frustrated customers and angry investors.As per the 'Us vs Them mentality', it is in the hand of the team's managers and the stakeholders and how they manage their resources. There is a reason why people still use the old saying -- 'garbage in is garbage out'!
    Let me know if I missed any more stupid excuses that people make justifying their decision not to hire more testers and not to do more testing. Happy Testing...
    Categories: Blogs

    “Don’t Freak Out!” Product Management & Emotion Management

    Jonathan Kohl - Tue, 08/25/2015 - 18:43

    As a product manager, some days it seems like half of my time is spent calming down team members who are freaking out about the project. And on those days, most of the other half seems to be spent re-establishing and maintaining team alignment on a product release. (Usually this is because the people who need to calm down have spread their uncertainty around to others.)

    I used to feel side tracked because I felt that I should be spending my time on market research, helping with monetization plans, supporting sales and marketing, planning and prioritizing features and helping make a decision on a UX improvement or to help the team re-prioritize a feature because of some unforeseen event. I didn’t expect to spend so much time helping keep people calm, and repeating the product vision, priorities and keeping the team on track. I’m a collaborative person, so I always have buy-in before proceeding. Why then, do some days seem like most of what I do is listen, talk, repeat myself, listen, talk and repeat myself some more? Didn’t we all agree on this stuff? What’s going on?

    At first, when someone freaked out over something we had settled on and agreed to as a team, it was tempting to just point them the product vision statement written in huge letters and posted above our development board. Or opening a product roadmap, and pointing at it as the person ranting to me insisted we should be doing something else. What happened to the agreement that we had as a team, and more importantly, your agreement and endorsement? What happened?

    What I learned is, a lot of times people are just freaking out. Some people freak out more than others, and we all freak out in different ways. As a product manager, I am often the first person they come to when they are freaking out. And, an important part of my job is to deal with freak outs. If I can keep people calm, focused and productive, that helps us reach our shipping targets.

    The truth is, we are all emotional creatures and software development projects are incredibly difficult. We all freak out a bit on projects from time to time if we look at the big picture and think of all the work we have to do in such a short time. At any point in time during a software development project, it can be overwhelming if you think about it too much. However, people sometimes also freak out for good reasons.

    Techies may get worried that we can’t meet commitments, or implementing a new technology isn’t going as well as planned. Or we may just get bored of the technology, learn about something new, and feel that there is a better way to move ahead than our current roadmap and plan. As business people, we get all kinds of tantalizing offers from potential customers, and we are very swayed by the people who are willing to spend money. It can take what seems like forever for a technical team to deliver a release (because it is so labour intensive), so we may get distracted away from the current release, and start talking about an idea for some time down the road. To be honest, I get freaked out a bit too. Here are some recent minor freakouts:

    • Did we pick the correct web framework? What if it doesn’t support the browser that our first client uses in their organization!??
    • Did I do enough research with our monetization model? What if my research and recommendations and my interpretations of consultations with experts are wrong?
    • Did I misinterpret the usage statistics and engagement metrics from our apps which could potentially mess up our priorities for the next release? At worst, what if we change something that the majority of people are using and annoy our best customers?

    See? I can be as neurotic as the next person. I deal with my own freakouts by having my own personal support network. Sometimes I just need to vent to someone else who isn’t directly involved with the team. Other times, I need to bounce ideas off of senior team members to re-evaluate our current path. What if I am missing something important? I also research any freakouts when others agree. And sometimes, we just have to find out and adjust accordingly when we release. If I guided us towards the wrong monetization model and the wrong priorities, we just need to be on top of it and adjust based on market feedback.

    Once in a while, someone is right to freak out and disrupt our current path. They had some doubts, researched and realized we are off track and we need to change now. How do I tell the difference between someone who is freaking out and needs a bit of reassurance, and a real issue we need to deal with right now?

    Usually, we get unsettled due to reasons that we can’t explain. Some people say our subconscious or our intuition are at work here. When someone brings up an issue but they can’t provide you with a clear explanation of what is wrong, let alone an alternate solution, it is important not to dismiss it. So I always ask for proof driven by research. Can you spend some time looking into the problem to see if it’s a real issue, or just a minor freakout? If we need to change, why? What is the business case? Where is the evidence I could use to show stakeholders we are off track? Once a team member starts to make their freak out defensible, two things usually happen:

    1. once they start to research, they realize their freak out is unfounded, and they calm down by looking at evidence that supports that we are on the right track)
    2. as they gather evidence, they are able to reinforce their misgivings by forming a better idea of what the problem is, and are able to communicate it much more convincingly

    In the first case, we just let it go and move forward. In the second case, the freakout turns into a strategic business or technical decision.

    Sometimes, freakouts are symptoms of communication problems, poor tools (or poor use of tools) or other issues unrelated to the project itself. These are important to watch for too, because even simple issues can cause people to spend time freaking out instead of working because something is wrong.

    As my colleague Aaron West points out, it’s important to provide a safe environment and provide permission for people to freak out. If I am the person they feel safe freaking out to, and we can deal with their feelings in a healthy way, that minimizes them having to go to others and sidetracking them. If the environment is repressive, and there aren’t healthy outlets, people will undermine the mission of the project by releasing that tension in other ways.

    When I presented for the first time at a large international software development conference, I was really nervous. The facilitator could tell, and tried to calm me down with a little pep talk. She told me about her office, how outnumbered the technical IT members were, and how they had insane deadlines with multimillion dollar projects all the time. The projects were heavily publicized, so any delay brought embarrassment to the company, as well as the potential to lose money. It sounded like a very stressful environment to work in, but she said she had learned to thrive there. It was a really easy place to get freaked out in, and a small team could waste time and effort if they got freaked out over the wrong things. So, she printed out a huge poster that said DON’T FREAK OUT! and hung it in the development team bullpen. That didn’t stop people from freaking out, but it helped calm people down, and reduced the freakouts over trivial issues. If someone came to her freaking out, they were freaking out for the right reasons. The message was that I really didn’t need to freak out about presenting my talk, there are a lot more important things in life to freak out over than public speaking.

    Sometimes I have to tell myself not to freak out and I remember that pep talk and that DON’T FREAK OUT! poster. Is it really worth freaking out, or am I just stressed and worried? Late at night on a stressful project, all kinds of problems seem large and insurmountable. I have to ask myself, is this worth being freaked out over? Do I need to ask for another opinion? When others come to me freaking out, I need to help them either channel that energy into something productive, or decide that they are freaking out about something important, and we do need to change what we are doing.

    Different projects have different levels of freak outs, and they occur during more stressful times on a project. I have to remember that helping people navigate freak outs is just as important as the cool tasks in my job description.

    Categories: Blogs

    10 Ways To Initiate Change In An Organisation That Doesn’t Want To Change

    The Social Tester - Tue, 08/25/2015 - 17:00

    I get lots of questions from people who want to initiate change in an organisation that doesn’t want to change. It’s a very common question…

    The post 10 Ways To Initiate Change In An Organisation That Doesn’t Want To Change appeared first on Rob Lambert.

    Categories: Blogs

    Virtual Teams – Agile or Bust

    A collaboration by David Grabel and Mario Moreira
    You’ve just been given a plum assignment, heading up a major new application development project. Congratulations! Your boss just got off the phone with a large off-shore contracting firm.  At the labor prices they are quoting, we’ll save a fortune and come in under budget. He knows that you’ve been experimenting with virtual teams; it’s time to kick this into high gear and really cut our labor costs. DON’T DO IT!By the time you factor in the extra costs for travel, the high costs of the locally based support personnel (project managers, architects, etc.), the increased systems and telecommunications cost, the miscommunication caused by lack of face-to-face conversations, and the rewrites this will require, the cost savings will evaporate. They will never complete it on time and the missed revenue alone will eat up all of your savings.

    There are good reasons to rely on virtual teams. Cost savings is not one of them. Real world constraints can make virtual teams unavoidable. Your company might have a liberal “work from home” policy. Your development centers could be scattered about a large campus, across the country or around the world. You may have a strong relationship with an off-shore development company that has delivered high quality software on time in the past. You might be partnering with a company from another state. All virtual teams are distributed, whether it’s a single member working from home or dozens of teams scattered around the world. Co-located teams will almost always be more efficient and effective than virtual or distributed teams. When virtual teams are unavoidable, the key to success is to Be Agile. If you follow the agile values and principles you can successfully deliver valuable working software, quickly, with high quality, even with virtual teams.  Let us explore how the Agile values and principles can be put into action to help with virtual teams.
    • Value people and interactions over processes and tools by enabling virtual and physical face-to-face conversations. If team members are in different time zones, encourage flexible hours and provide high quality video conferences for stand-ups and other ceremonies. Supplement the teams with collaboration tools. Bring the teams together periodically to learn each other’s business contexts, cultures, and individual needs. Virtual teams necessarily need to rely more on electronic tools like agile project managers and collaboration software. These tools help, but virtual teams need to nurture the interpersonal relationships that allow trust to develop. Trust within and across teams is vital to agile success.
    • Value working software over comprehensive documentation by writing stories about the users experience and by delivering small increments quickly based on those stories. The traditional wisdom has been that virtual teams require very detailed requirements and design documents. These heavyweight artifacts don’t exist on agile projects. Very detailed requirements create the illusion of completeness and accuracy. All those details about what they system shall do obscure the problems we are trying to solve
    • Value customer collaboration over contract negotiations by scheduling regular demos with customers to get their feedback and deepen the understanding of the business problems to be solved. This is more important than checking the boxes on a requirements document. This is a case where virtual meeting tools can bring remote teams and customers together even when they are physically apart.

    The agile values and principles are the best guiding lights available today to make virtual teams work. If you have to use virtual teams, please consider using agile practices and staying true to the values and principles. To learn more about virtual teams and best practices to make them successful consider attending the webinar “Virtual Teams- Future or Fiction”.  For more information go to
    Categories: Blogs

    TDD With Refactoring Maniacs

    Testing TV - Mon, 08/24/2015 - 18:10
    Classic old-school TDD recommends refactoring as part of every cycle — red, green, refactor. In fact, it recommends refactoring mercilessly. Relentlessly. To succeed at classic TDD, you have to be some kind of refactoring maniac! Refactoring maniacs are an endangered species, but you’re in luck: we have one of the last remaining pairs. See for […]
    Categories: Blogs

    How to include screenshots in ReportNG report?

    Testing tools Blog - Mayank Srivastava - Mon, 08/24/2015 - 17:55
    Any test automation report is incomplete without the screenshots and including them in ReportNG is not that much difficult. In today’s post we will see how we can include the screenshots in ReportNG report. If you are wondering how to configure ReportNg with selenium then you can refer my previous post. Here I am again […]
    Categories: Blogs