Dealing with programmers or Developers

When I started my career as a software tester, I was made aware of an ongoing antagonism between developers and testers. And it took me no time or effort to be convinced that this is all too common. I received the kind of unwelcome response from developers that I think all testers experience at some point during their careers.
From indifferent shrugs to downright hostility (sometimes cloaked as sympathetic smiles), a tester has to endure a lot from developers. It can be hard to keep a positive attitude. But it’s up to us to keep our priorities straight, and push toward a quality project.
I picked up a beautiful line from Cem Kaner’s Testing Computer Software: “The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed.”
So how can we do that?
Be Cordial and Patient As a tester you may find it more difficult to convince a developer about a defect you’ve found. Often, if a tester exposes one bug, the programmer will be ready with ten justifications. It’s sometimes difficult for developers to accept the fact that their code is defective—and someone else has detected it.
Developers need support from the testing team, who can assure them that finding new bugs is desirable, healthy, and important in making the product the best it can be. A humanistic approach will always help the tester know the programmer better. Believe me, in no time the same person could be sitting with you and laughing at mistakes that introduced bugs. Cordiality typically helps in getting the developer to say “yes” to your bug report. An important first step!
Be Diplomatic Try presenting your findings tactfully, and explaining the bug without blame. “I am sure this is a minor bug that you could handle in no time. This is an excellent program so far.” Developers will jump and welcome it.
Take a psychological approach. Praise the developer’s job from time to time. The reason why most developers dislike our bug reports is very simple: They see us as tearing down their hard work. Some testers communicate with developers only when there is a problem. For most developers, the software is their own baby, and you are just an interfering outsider. I tell my developers that because of them I exist in the company and because of me their jobs are saved. It’s a symbiotic and profitable relationship between a tester and a developer.
Don’t Embarrass Nobody likes mistakes to be pointed out. That’s human nature. Try explaining the big-picture need for fixing that particular bug rather than just firing bulky bug reports at developers. A deluge of defects not only irritates the developer, it makes your hard work useless for them.
Just as one can’t test a program completely, developers can’t design programs without mistakes, and they need to understand this before anything else. Errors are expected; they’re a natural part of the process.
You Win Some, You Lose Some I know of testers who make their bug reports as rigid as possible. They won’t even listen to the developer’s explanations for not being able to fix a bug or implement a feature. Try making relaxed rules for yourself. Sit with the developer and analyze the priority and severity of a bug together. If the developer has a valid and sensible explanation behind her reluctance to change something, try to understand her. Just be sure to know where to draw the line in protecting the ultimate quality of your product.
Be Cautious Diplomacy and flexibility do not replace the need to be cautious. Developers often find an excuse to say that they refused to fix a bug because they did not realize (or you did not tell them) how serious the problem was. Design your bug reports and test documents in a way that clearly lays out the risks and seriousness of issues. What’s even better is to conduct a meeting and explain the issues to them.
A smart tester is one who keeps a balance between listening and implementing. If a developer can’t convince you a bug shouldn’t be fixed, it’s your duty to convince him to fix it.

Introduction to Internet Information Services (IIS)

Introduction to Internet Information Services 7.0

The basics of Internet Information Services 7.0 also known as IIS 7.0. IIS 7.0 is the web server role in Windows Vista and Windows Server 2008.

Introduction

Internet Information Services 7.0 (IIS 7.0) is Microsoft’s latest version of their web server. IIS has been included with Windows Server since Windows 2000 Server as a Windows Component and since Windows NT as an option. IIS 7.0 is available with Windows Vista and Windows Server 2008, which is scheduled for release in Q1 2008. IIS 7.0 has gone through a major overhaul and has been completely redesigned from scratch. This has been done to make the most flexible and secure platform for web and application hosting.
IIS 7.0 has been designed to be the most secure and flexible web and application platform from Microsoft. Microsoft has redesigned IIS from the ground and during this process the IIS team has focused on 5 major areas:

• Security
• Extensibility
• Configuration and Deployment
• Administration and Diagnostics
• Performance

What’s New

Almost everything is new in IIS 7.0. Microsoft has focused on modularity when building IIS 7.0, which means that only the binaries needed is installed, this minimizes the attack surface of the web server.
An example to this: If you need the FTP Server or the Caching feature in IIS, you install the FTP Server or Cache modules to manage and enable either the caching activity or the FTP Server.
Windows Server 2008 will include all the IIS features needed to support hosting of web content in production environments. Windows Vista only has some IIS features and the features depend on your Vista version. IIS 7.0 in Windows Vista is ideal for building and testing web applications. Additional modules and features will be available from Microsoft or you can code your own, maybe even buy some from 3rd party vendors.

Architecture

Besides the changes to the core components of IIS 7.0, the focus has been with modular design in mind. The modular design gives more flexibility and security to IIS 7.0, compared to previous versions of IIS.

Figure A: Overview of the main modules and components of IIS 7.0
The main advantage of the new modular design is that it helps to reduce the footprint, which results in a more secure web server platform, since the attack surface has been minimized.
IIS 7.0 provides a new native core API, which replaces the ISAPI filter from previous versions of IIS. With the new API it’s now possible to extend IIS with extra modules or even replace any of the built-in modules with custom written modules.
New modules can be downloaded from Microsoft’s IIS.net website, where Microsoft maintains a download repository for IIS: http://www.iis.net/downloads

Administration

There are several ways of administrating IIS 7.0.

• The GUI way using IIS Manager
• APPCMD command tool
• Remote administration using IIS Manager
• Scripting using Windows PowerShell
• Microsoft.Web.Administration API interface

The GUI Management interface has also been redesigned, the new IIS Manager is now more task-oriented and action based, as we know from ISA Server and the new Exchange Server 2007.

Figure B: Screenshot of the IIS Manager
IIS Manager can be used to configure IIS and ASP.NET settings, the configuration settings will be written to the xml configuration files. As something new, Health and diagnostics information can now be seen and run as integrated tools directly from within IIS Manager and is already a part of IIS 7.0.
APPCMD is the new main general purpose command prompt tool for IIS 7.0, which can be used for administration and configuration of IIS. APPCMD is the new enhanced version of the old adsutil.vbs, for those of you who are familiar with that tool from IIS 6.0.
Remote Administration has been enhanced and is now possible using the IIS Manager, communicating securely over https to the web server.
There’s also the option of scripting all IIS management. This is now done using Windows PowerShell, which is Microsoft’s new scripting language. It’s an easy and effective way of handling administration of IIS on your web server and this is especially useful if you manage several web servers or large web farms. Windows PowerShell can be used directly against the WMI interface of IIS or used to read and write in the IIS 7.0 XML configuration files.
IIS 7.0 has backward compatibility with the IIS 6.0 metabase and the ADSI and WMI scripting interface known from IIS 6.0, which means that all your old scripts for IIS 6.0 will still work on IIS 7.0.
Microsoft.Web.Administration API is the interface targeted to developers, who want to code their own programs or scripts to manage IIS 7.0.
In IIS 7.0 it’s now possible to delegate the management of IIS and the web sites. You can now delegate full administrative access to the site owners of a website. The site owners can then control and manage all the website settings using IIS Manager, without compromising server security. All the settings the site owners manage, are written to the web.config xml file of their own website.

Configuration

The configuration has been made simple and is based on distributed XML files that hold the configuration settings for the entire IIS and ASP.NET.
Configuration settings can be done globally for the entire web server or for specific websites using either the XML files or through the GUI Management interface. The GUI just writes the configuration settings to the same XML files. The main xml configuration files in IIS 7.0 are:

• Applicationhost.config
• Global web.config
• Machine.config
• Site web.config
• App web.config

By using xml based configuration files, deployment and scale-out in large web hosting environments has been optimized. It’s fairly easy to copy the IIS configuration to a new server and be up and running relatively quickly.
Handling replication of web server configuration is also relatively easy with IIS 7.0 compared to IIS 6.0, because of the xml based configuration files. This makes it very easy to replicate and deploy configurations in larger web farm environments. With IIS 6.0 this was best handled by using Microsoft Application Center 2000 or other 3rd party products.
Shared Configuration is a new feature of IIS 7.0, which is designed for web farm scenarios. With Shared Configuration it’s now possible for multiple web servers to share a single configuration file (applicationhost.config). A master of the applicationhost.config file will be placed on a common UNC path. The Shared Configuration feature is a great alternative to the perspective of replicating IIS settings.
The Applicationhost.config xml file is the main configuration file of IIS 7.0, this configuration file contains all the information about sites, virtual directories, applications, application pools and global settings for the web server.
Content replication can relatively easy been managed by simple x-copy or robocopy commands, as well as specific website configurations, which are saved in web.config xml files within each website.

Conclusion

With the redesign of IIS, Microsoft has really focused on making the IIS 7.0 a better web server for everyone, from IT Professionals, Developers to Web Hosters. To sum up I’ll try to highlight some of the main reasons why I believe IIS 7.0 is a strong product:

• The product is more secure – only the binaries needed are installed
• It’s extendable in a flexible way, because of the new modular architecture
• It’s easier to scale-out – because of the simplicity in configuration, based on xml files
• Better performance – due to the improvements to the core of IIS (http.sys)

There are plenty of opportunities for trying out IIS 7.0 yourself and getting familiar with it before the official release.
IIS 7.0 is available for public download together with the latest version of Windows Server 2008, currently in Beta 3. You can download the Windows Server 2008 beta from: http://www.microsoft.com/windowsserver2008/default.mspx.
Microsoft has created a special Go Live license, which is available for free and permits customers to deploy beta releases of IIS 7.0 in live production environments, before the official release of Windows Server 2008, which is scheduled for release in Q1 2008.