Can Developers and Testers Love Each Other?

After the results of a previous poll focused on functional testing automation, I wondered if there was still a great divide between the worlds of development and functional testing. So I did this follow-up question to check who was performing the functional testing.

This poll was trying to determine who perform functional testing in your IT department? Here are the answers:

Software developers	15.4%
Specialized testers:	37.4%
Both	36.2%
Nobody: functional testing is done by end-users	11.0%

Participants: 409
Ending date: March 2010
Source: Methods & Tools

As you can see, in close to 50% of the cases, developers are not involved in functional testing. Trying to find the causes of this situation, I asked for explanations in various testing and agile groups on LinkedIn. Two explanations came out:

Developers do not master functional testing tools. These are specialized tools that use mostly proprietary scripting languages, even if some new tools like the WatX family use the same programming language to create tests. Then validation needs to be independent from development. Following this rule, people said that the role of analyst and functional tester can be mixed in software development projects, but you cannot ask a developer to test its own work. This opinion has been expressed both in software testing and in agile focused groups.

This situation is also representative of the mistrust relationships that often exists between development and testing teams in software development organizations and apparently Agile hasn’t’ changed it. If few people will deny the fact that the customer is the ultimate judge to validate an application, QA people often describes developers as careless people that are unable to challenge their own work and developers see QA people as disconnected from the project reality and slowing the delivery of applications to users. Having worked in large software organizations, I have sadly witnessed the truth of both cases: developers that don’t test enough their work and QA people that don’t know the domain of the application or built process that could be nice looking in theory, but practically not adding value to the software delivery.

I strongly favor the case when developers take the full responsibility from understanding the requirements to deliver the application to the user. The more specialization you involved in the process, the more information you loose when you try to transmit it. Understanding the requirements allow the developer to take the full responsibility of its code. If it cannot be trusted for functional testing, then it should be the same for unit testing…. and then it should just not be trusted as a developer. I understand that this vision could sound a little bit utopian due to the reality of human behavior, but to me it is not more idealistic than thinking that users can give you the right requirements and have enough time and knowledge to validate the delivered application.

Resources

Functional Testing Tools Directory

SQA Zone

Testing TV

New Tools Section in Methods & Tools Web Site

The Methods & Tools web site has just opened a new section dedicated to software development tools. This area will propose an html version of the tools presentations articles published in the PDF issues and also links to the other Methods & Tools articles that are focused on software development tools. The first tools to be included in this section are Express, Sonar, JMeter and Squirrel. More software development tools will be included in the future. Hudson and Fitnesse presentation articles are already scheduled for the Summer 2010 issue of Methods & Tools.

Agile + Software Testing & Quality in Methods & Tools Spring 2010

Methods & Tools is a free e-magazine for software developers, testers and project managers. Spring 2010 issue has just been published with the following articles:
* Using WatiN to Leverage Common Elements in Web Testing – structure your Web testing efforts
* Five Symptoms of Mechanical Agile- detect agile adoption issues
* Writing Testable Code – testable code is better code
* Model-Based Testing Adds Value – a quicker way to functional testing plans
* Tool: Sonar – monitor code and project quality
* Tool: Express Agile Project Management – a simple tool for Scrum
* Tool: Apache JMeter – for load and functional testing

60 pages of software development knowledge that you can download from http://www.methodsandtools.com/mt/download.php?spring10

Review of 2009 for Software Development: Many Acquisitions and a Funeral

Last year has certainly been busy for the software development tools industry. We have seen many companies merging together and also the funeral of one of the oldest brand in the software development industry.

Bye, Bye Borland

After the sale of its development tools division to Embarcadero in 2008, Borland kept only the tools dealing with requirements management and software testing. This didn’t improve its financial situation and finally Borland sold itself to MicroFocus. This was a sad end for a brand that accompanied software developer for more than 25 years. Software requirements have always been a secondary topic in the software development tools world and the trend towards agility hasn’t improved this. Now you can manage user stories with paper cards and a board. Approaches like UML are declining and you will find few items dealing with them in today’s programmers waterhole like dzone.com or stackoverflow.com, The end of Borland is just the symptom that this world is difficult for requirements tools vendors.

Oracle Buys Sun, WMware Buys Spring and You Buy Software

With a little bit of irony, just one year after having bought MySQL, Sun was acquired by Oracle. It is difficult to judge a deal that is not completed yet as the European Commission is still examining the merger. I am however afraid that the business and financial objectives of Oracle will largely lead to the reduction or the end of most of the Sun open source efforts and a serious slowdown in MySQL evolution.

Just after the future of Java becomes a topic of discussion after the deal between Oracle and Sun, WMware decided to acquire SpringSource and to give to this entity a stronger platform to promote the Java language. Since then, SpringSource has launched its Tomcat server version, Enterprise Java Cloud and Spring Roo. Previously it had acquired G2One at the end of 2008 and thus the control of the Groovy and Grails products. It is now surely the most important active player for Java software development tools.

Google is (also) a Software Development Tools Company

Google domination in the search engine world is well known, but as far as developers are concerned, it is amazing how Google is quietly occupying more and more space. Here are some of the software development initiatives of Google:
* Google App Engine
* Google Web Toolkit GWT
* Go Language
* Google open source projects forge
* Google I/O Conference

Google seems to have understood that besides the content, it should also be active in the plumbing that runs the Web. This is why software developers should be interested in what Google does in this area. You could do this following some blogs like the Google Code Blog and the Google Testing Blog. You will see that besides the well-known projects, Google releases a lot of interesting open source tools created by its development team.

More Procedures in Software Configuration Management

The last Methods & Tools poll examined how software configuration management (change management / version control) is performed by organisations. Is it an informal activity or performed with formal procedures that are validated by an automated tool?

	2009	2006
No formal procedure and no tool	13%	15%
A formal procedure but no tool.	11%	10%
A tool but no formal procedure	17%	26%
A formal procedure and a tool	36%	49%
Continuous integration	23%

Participants: 271 (346 in 2006)

Ending date: November 2009 (April 2006)

If we compare the current results with the 2006 numbers, we can see two major points. The first is that the number of participants that don’t use tools remains at the same level, around 25%. It is true that there has not been any strong innovation in the area of software configuration management tools in the recent years. The major open source products were also available three years ago. Things have change however for the participants that were using tools. The number participants using a formal procedure is now a clear majority, counting the people that do continuous integration in this category. The increased demand for regulation, for instance the Sarbanes-Oxley law, has surely influenced corporations to adopt formal policies in their software development practices.

We introduced in this poll a new answer to take into account the “continuous integration” way of software configuration management. This agile-linked practice is adopted by 23% of the participants to the survey. This result is similar to the survey conducted by Jurgen Apello on noop.nl. In his case, 29% of the participants had adopted continuous integration. As a funny conclusion on this topic, when I researched on this topic, I noticed that in the 2007 Agile Survey by Version One 50% of the participants declared that they were practicing continuous integration and 57% were currently using a continuous integration tool. This makes me wonder what 7% of the participants were using the continuous integration tool for. ;o) Anyhow, this always remembers us that we should be very cautious with survey number.

Reference

http://www.noop.nl/2009/04/the-big-agile-practices-survey.html

Related articles

Configuration Management and ISO 9001

Continuous Integration: the Cornerstone of a Great Shop

Software Configuration Section of the Software Development Articles Directory

Related videos

Simple tools to fight a big battle: “Continuous integration on a minimalist platform”