Answer My Query

From the site, http://www.softwareqatest.com/qatfaq2.html, I came across this statement. There are many forms of software testing. What I am discussing herein is related to white-box testing, automation and framework development, performance, and security testing

What makes a good Software Test engineer?

“A good test engineer has a ‘test to break’ attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers’ point of view, and reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk or critical areas of an application on which to focus testing efforts when time is limited.”

In my opinion, more emphasis should be placed on the statement italicized above. Taking it a step further, I would say a developer with previous development knowledge of the product under test is even more valuable. Obviously domain knowledge is what increases this value. From previous experiences with organizations, the development skills of the tester are often largely ignored.

“Writing code? That’s what our developers do, not our testers.”

If we are not placing a greater emphasis on the development skills of the tester, we are missing opportunities to fully test the product. Testers with a development background are more familiar with the developer’s perspective. They know the tricks developers do when writing code, they know their shortcuts and tendencies. These testers can also provide developers with insight into defensive coding, adding hooks to make automation easier, securing the product from attacks, ect.

I would argue the inverse is true as well, that having previous testing experience of the product would add value to the transition of a tester into development. A developer with a testing background should improve the testability and security of the product, because they, too, understand the importance and impact of test.

To me, test and development should be shared responsibilities. If a developer is out sick, on vacation, or the team needs a resource, a tester should be able to fill in, developing product code. If a tester is needed for similar reasons, a developer should be able to switch gears and fulfill that need as well. Neither should be more exciting nor glamorous. The organization should respect both disciplines equally. Testing is the last line of defense. 

The software engineer should have two personae, constructive and destructive. Perhaps this is similar to Dr. Jekyll and Mr. Hyde, where we replace the “evil” in Mr. Hyde with “destructive product testing.”

When a visitor registers a new account on an ASP.NET website that uses the Membership system, they are prompted (by default) for their username, password, e-mail address, and other pertinent information. Along with functionality for registering new accounts, the ASP.NET Membership system provides page developers techniques for modifying information about users. For instance, with just a couple of lines of code you can change an existing user's e-mail address, approve a user, or unlock them (if their account was locked out). However, there are certain bits of user information that cannot be modified through the Membership API, such as the username.

For most sites this is a non-issue. Once a visitor has registered an account that username is fixed; if they want a different username, well, they'll just have to register a new account. But consider a website that has customized the account creation process so that instead of prompting the user for both a username and e-mail address, the user is only asked to enter an e-mail address and that it is used as both their username and e-mail address on file. Anytime a user switched e-mail addresses - which can happen when changing jobs, changing ISPs, or moving to the new, hip, web-based e-mail provider of the day - they need to also change their username on your site.

In order to change a user's username we'll need to bypass the Membership API and work directly with the user store. This article shows how to interface directly with the SQL Server database schema used by the SqlMembershipProvider to change an existing user's username. Read on to learn more!
Read More >