Database Normalization: What to test for Second Normal Form?

In the last post, Database Normalization: What to test for First Normal Form?, I explained database normalization briefly. You also saw the tests that should be executed to check the first normal form (1NF). In this post, let us understand the second normal form (2NF) and the tests that need to be executed for checking it. View my video on Second Normal Form with examples. Then read on...

A table that is in 2NF is already in 1NF. Additionally, each column that is not part of any candidate key depends on the entire candidate key (and not a part of it). Now, let us see the examples of some tables that are not in 2NF and how to convert them to 2NF.

Database Normalization: What to test for First Normal Form?

Designing a relational database to minimize data redundancy (and therefore maximize data integrity) is called normalization. View my video on Normalization and First Normal Form. Then read on...

The concept of data normalization was introduced by Edgar Codd, right in the years after he invented the concept of the relational model of storing data. There are various degrees of normalization 1NF (First Normal Form), 2NF, 3NF and so on. Each degree of normalization is stricter than the previous one e.g. if a table is in 3NF then it is automatically in 1NF and 2NF. In this article, I will explain the First Normal Form and what to test for it. Articles on testing the other normal forms will follow.

Years ago, when I used to work as a database developer, I remembered 1NF as each table having only relevant columns, a primary key and no repeating groups. It is still useful to remember 1NF like this because most definitions of 1NF agree to this. Let us now see examples of few tables that are not in 1NF.

a. Having columns of other entities
Customer (CustomerID, FirstName, LastName, Address, SupportContactName)
Here the Support Contact does not belong to the Customer entity. Such a design gives rise to data modification and querying problems. For example, if a Customer row is deleted, then the Support Contact data is also deleted. Also, it is not possible to store available Support Contacts that are not yet assigned to any customer.

b. Having no primary key
Employee (FirstName, LastName, JobTitle)
Here it is possible for two or more employees having the same column values implying duplicate rows. There are update/ delete problems with such a table design. Which row to update if only one of the employees is promoted? How to delete just one row if one of the employee leaves the company? Also, each query written on this table needs to have the logic that includes duplicate rows.

c. Having a repeating group
Customer (CustomerID, FirstName, LastName, Address, PhoneNumber1, PhoneNumber2, PhoneNumber3)
With such a table, there are many problems. For example, many customers may have only one phone number so the space for the other two phone numbers is wasted. Each query on this table fetching phone number values needs to include three columns, impacting performance. This table cannot accommodate a customer who has four phone numbers.

Another example of a repeating group is the table
Customer (CustomerID, FirstName, LastName, Address, PhoneNumbers)
Here it is possible to store any number of phone numbers within the limit of the column width. If there is more than one phone number, this list of phone numbers is comma separated. The problem is that space for a potentially large list of phone numbers is reserved for every row and wasted. Each query on this table fetching phone number(s) has to implement the logic to understand one phone number or a list of phone numbers. Frankly, the PhoneNumbers column is not a single column but really a group of columns for the Customer table. Therefore, the table is not even relational.

In order to convert the Customer table to 1NF, it is necessary to design two tables:
Customer (CustomerID, FirstName, LastName, Address)
CustomerPhoneNumber (CustomerID, PhoneNumber)
Note that now a customer can have any number of phone numbers (zero, one or more than one). Also, the Customer data is stored in the Customer table and PhoneNumber data in the CustomerPhoneNumber table. Customer table has CustomerID as the primary key. CustomerPhoneNumber has CustomerID and PhoneNumber as the primary key. No space is wasted. There are no data modification problems e.g. deleting a phone number does not require deleting a customer. No query needs to include multiple columns for the phone number values, speeding performance. No query needs to implement the logic of understanding a single phone number as well as extract individual phone numbers from a list.

With the above understanding in mind, here the tests that should be applied to check 1NF on every table in the database:
1. Is each column an attribute of the table's entity?
2. Is there a primary key?
3. Are there no duplicate rows?
4. Are there no repeating columns?
5. Are there no multiple values in any column of any row?

Want to learn more? See more explanation with multiple examples in my video on Normalization and First Normal Form

Performance Test Scripts Sections

Performance test scripts model the virtual user's expected interaction with the system. A performance test script is usually created within the performance testing tool. The default performance test script generated by the tool needs to be re-factored, parametrized, co-related and unit tested before it can be used in a performance test. Each performance test script contains various sections. It is important to know about these in order to create robust scripts that work correctly.

1. Environment: This section of a performance test script contains the general information related to the entire script. Examples of data in the environment section are repository description of the scripts, protocol used, browser used and time units (e.g. ms) used.

2. Include: It gives the reference of other pre-existing scripts that contain functions, constants and variables used in the current performance test script. Example of an include script is the file containing all browser response status codes (e.g. 200, 404 and 500).

3. Variables: These are used when it is not possible to know the data value in advance. For example, a performance test script modeled to work with any username/ password would use variables to read these values at run-time from a data source (e.g. a CSV file) and subsequently use these variables to perform user actions. Another example is using a variable to store the cookie value, which cannot be predicted in advance. 

The scope of a variable can differ. A variable can be local to a script and a virtual user. Or it can be local to a particular virtual user across all scripts executed by this virtual user. Or the variable can be global in scope across all scripts and all virtual users in the load test.

4. Constants: These are defined once in the performance test script and may be used multiple times in the script. They provide configuration control. A change in a constant value is automatically reflected wherever the constant is used in the entire script.

5. Timers: These are special variables that track the time elapsed between sending a request to the system and loading of the responses received from the system. Timer values are aggregated to determine the response times of an entire user transaction or a part thereof.

6. Code: This is the main section of the performance test script. It contains script instructions that model a user performing a transaction in the system. It also contains the validation checks on the responses given by the system. The code is written in the scripting language generated by the performance testing tool or any scripting language that is supported by the performance testing tool.

7. Waits: These are commonly used to model the pauses given by users between operations in the system. The performance testing tool does nothing during the wait period. Note that if all Wait statements were removed, it would put an unrealistic load on the system due to the non-stop issuing of requests by the user.

8. Comments: These are useful to explain the sections in a performance test script. Comments are especially important in scripts representing lengthy user transactions.

SQL Test Online

Structured Query Language (SQL) is the programming language used to find out and modify the data stored in a relational database. Knowledge of designing SQL queries is important in software testing. Take the test below and find out your level of knowledge and the areas in which you should improve. Each question has exactly one correct answer. There is no need to consult any reference for answering these questions.

1. SELECT statement can fetch data from _______ table(s) of the database.
a. exactly one
b. at least two
c. one or two
d. any

2. What values can be included in the SELECT expression (the list following the SELECT keyword)?
a. Any columns
b. All columns
c. Computed values e.g. Price * 10
d. All of the above

3. Which function gives the total number of rows in a table?
a. SUM
b. COUNT
c. ROWCOUNT
d. This has to be done indirectly by executing a SQL query (e.g. SELECT * FROM Authors) and noticing the number of rows.

4. Which of the following SQL queries is correct?
a. SELECT * FROM Books WHERE Price BETWEEN 10 AND 25
b. SELECT * FROM Books WHERE Price BETWEEN 10, 25
c. SELECT * FROM Books WHERE Price BETWEEN (10, 25)
d. SELECT * FROM Books WHERE Price >10 AND Price < 25

5. Which JOIN clause returns only the matching values from two tables?
a. CROSS
b. INNER
c. LEFT OUTER
d. RIGHT OUTER

6. Which statement is correct for the GROUP BY clause?
a. GROUP BY allows grouping by only one column
b. GROUP BY needs to precede the WHERE clause
c. An aggregate function needs to be specified based on the column specified in GROUP BY
d. HAVING clause can be used in place of GROUP BY clause

7. What is true about Normalization?
a. It avoids data duplicities within and across tables.
b. It is easier to extend the database structure of a normalized database.
c. A normalized database structure is better than a de-normalized one when the SQL queries against it cannot be predicted in advance.
d. All of the above.

8. Which of these SQL queries is correct?
a. SELECT * FROM Employees ORDER BY LastName + FirstName
b. SELECT * FROM Employees ORDER BY LastName ORDER BY FirstName
c. SELECT FirstName, LastName FROM Employees ORDER BY LastName, FirstName DESCENDING
d. SELECT FirstName FROM Employees ORDER BY LastName, FirstName

9. Which of these statements is incorrect for the UNION operator?
a. Both SELECT statements have the same number of columns.
b. The UNION operator returns values that are duplicated in the two resultsets.
c. The column names returned by the UNION operator are taken from the first SELECT statement.
d. Either of the two SELECT statements can have WHERE, GROUP BY, HAVING and ORDER BY clauses.

10. Which of these is valid for a correlated sub query?
a. It is specified in the WHERE clause of the outer query.
b. It is specified in the FROM clause of the outer query.
c. It uses value in the outer query in its WHERE clause.
d. It is mentioned in the outer query's SELECT clause.

Click the Read More link for the correct answers. 

Risk Management in Software Testing

Risk management is a critical activity in software test planning and tracking. See my short video, Risk Management in Projects or read on.

It includes the identification, prioritization/analysis and treatment of risks faced by the business. Risk management is performed at various levels, project level, program level, organization level, industry level and even national or international level. In this article, risk management is understood to be done at a project level within the context of software testing. Risks arise from a variety of perspectives like project failure, safety, security, legal liabilities and non-compliances with regulations. An important thing to understand is that risks are potential problems, not yet occurred. A problem that has already occurred is an issue and is treated differently in software test planning. Risk management in software testing consists of the following activities:

Risk Identification

Risks are identified within the scope of the project.  Risks can be identified using a number of resources e.g. project objectives, risk lists of past projects, prior system knowledge, understanding of system usage, understanding of system architecture (see my video, Introduction to Software Architecture)/ design, prior customer bug reports/ complaints, project stakeholders and industry practices. For example, if certain areas of the system are unstable and those areas are being developed further in the current project, it should be listed as a risk.

It is good to document the identified risks in detail so that it stays in project memory and can be clearly communicated to project stakeholders. Usually risk identification is an iterative process. It is important to re-visit the risk list whenever the project objectives change or new business scenarios are identified. As the project proceeds, some new risks appear and some old risks disappear.

Risk Prioritization

It is simpler to prioritize a risk if the risk is understood accurately. Two measures, Risk Impact and Risk Probability, are applied to each risk. Risk Impact is estimated in tangible terms (e.g. dollar value) or on a scale (e.g. 10 to 1 or High to Low). Risk Probability is estimated somewhere between 0 (no probability of occurrence) and 1 (certain to occur) or on a scale (10 to 1 or High to Low).  For each risk, the product of Risk Impact and Risk Probability gives the Risk Magnitude.  Sorting the Risk Magnitude in descending order gives a list in which the risks at the top are the more serious risks and need to be managed closely.
Adding all the Risk Magnitudes gives an overall Risk Index of the project. If the same Risk Prioritization scale is used across projects, it is possible to identify the riskier projects by comparing the Risk Magnitudes.

Risk Treatment

Each risk in the risk list is subject to one or more of the following Risk Treatments.
 a. Risk Avoidance: For example, if there is a risk related to a new component, it is possible to postpone this component to a later release. Risk Avoidance is uncommon because it impacts the project objectives e.g.  delivery of new features.
 b. Risk Transfer: For example, if the risk is insufficient security testing of the system, it may be possible to hire a specialized company to perform the security testing. Risk Transfer takes place when this vendor is held accountable for ample security testing of the system. Risk Transfer increases the project cost.
 c. Risk Mitigation: This is a common risk treatment. The objective of Risk Mitigation is to reduce the Risk Impact or Risk Probability or both. For example, if the testing team is new and does not have prior system  knowledge, a risk mitigation treatment may be to have a knowledgeable team member join the team to train others on-the-fly. Risk Mitigation also increases the project cost.
 d. Risk Acceptance: Any risk not treated by any prior treatments has to be accepted. This happens when there is no viable mitigation available due to reasons such as cost. For example, if the test environment has only  one server, risk acceptance means not building another server. If the existing server crashes, there will be down-time and it will be a real issue in the project.

Few other points are:

1. Risk management brings clarity and focus to the team and other stakeholders. Though the team should avoid burning more time on risk management if it is not providing more value.

2. The risk list should be a live document, consisting of current risks, their prioritization and treatment plans. The test approach and test plan should be synched with the risk list whenever the latter is updated.

3. Bigger projects commonly involve more stakeholders and have more formal risk management process.

See also:
Risk Management in Software Projects (short video)

How to identify risks quickly? 

Example test strategy for Agile project
Introduction to Software Architecture 

How to compete against other teams and win?

Open source test management tools

Image: jscreationzs / FreeDigitalPhotos.net

SQL Injection

If you have read my earlier article, Code injection attacks, you would have some idea about SQL injection attack. This post explains SQL injection in detail so that you may understand it well.

What is the SQL injection vulnerability? Vulnerability is a weakness in the application software under test that can be attacked to cause the application (or even the underlying operating system) to behave in an undesirable manner. The SQL injection (SQLi in short) vulnerability lives in the middle-layer or the database layer of the application. It exists when the application executes a dynamic SQL query against the database without validating, escaping or rejecting the unexpected inputs given by the attacker. These inputs become a part of the dynamic SQL query and are executed against the database.

What is the SQL injection attack? It occurs when some text or even another SQL query is inserted into the application's SQL query. Attacks can be successful or unsuccessful depending on the application and the underlying database. A successful SQL injection attack may show confidential data to the attacker, allow the attacker to impersonate another user, increase the attacker's privileges to higher levels, insert/ modify/ delete data in the database tables or even perform administrative operations on the database like shutting down the database instance.

With this background, let us see examples showing SQL injection.

Example 1. The application query is

SELECT * from Salaries WHERE EmployeeName = ? AND EmployeeId = ?

The EmployeeName and EmployeeId are strings that are obtained from the client-side application. The intention of the developer is that an EmployeeName, say John, and an EmployeeId, say A100, is sent by the client to the server. After concatenating these values, the query becomes

SELECT * from Salaries WHERE EmployeeName = 'John' AND EmployeeId = 'A100'

The application then shows the salary details of this particular employee. Now, the attacker passes  "name" as the EmployeeName and "Id' OR 'x'='x" for EmployeeId. After concatenating these values, the query becomes

SELECT * from Salaries WHERE EmployeeName = 'name' AND EmployeeId = 'Id' OR 'x'='x'

The result is that the WHERE clause now contains an OR  condition that is always true. Due to operator precedence, this query returns all rows of the Salaries table.

Example 2. The application query on the login page of the application is

SELECT UserName FROM Users WHERE UserName = ? AND Password = ?

As in the previous example, there are two inputs obtained from the client-side application. Here, the developer expects two strings, say John and Smith99, are sent by the client to the server. In such a case, the query becomes

SELECT UserName FROM Users WHERE UserName = 'John' AND Password = 'Smith99'

If this UserName and Password combination exists in the users table, it returns one or more rows. Instead, the attacker passes "Administrator'--" and "password" values. After concatenating these values, the query becomes

SELECT UserName FROM Users WHERE UserName = 'Administrator'--' AND Password = 'password'

After removing the commented part, the query is effectively

SELECT UserName FROM Users WHERE UserName = 'Administrator'

The result is that if there is a user named Administrator, the attacker logs into the application impersonating this user and has all of the user's privileges on which to base further attacks.

Example 3. The application query on the search page of the application is

SELECT * FROM Products WHERE ProductName = ?

If the attacker provides the value "name'; DELETE FROM Products;--", the query becomes

SELECT * FROM Products WHERE ProductName = 'name'; DELETE FROM Products;

If the database allows batch execution (of multiple queries), the latter query delete all rows from the Products table.

I hope that you understand SQL injection now. Few other points to note are

1. SQL injection is further divided into two categories, SQL manipulation and Code injection. Strictly speaking, examples 1 and 2 involve SQL manipulation. Example 3 involves Code injection, because extra SQL code is inserted there.

2. If the attacker knows in advance about the attack SQL, he can devise complex attacks. This is possible if the application throws error messages showing the SQL query text or if it is an Open Source application or if the attacker somehow obtains access to the application source code.

3. Testing SQL injection can be automated. A variety of  tools are available for this. Examples include SQLiX (SQL Injection Scanner) and sqlmap (Open Source Penetration testing tool).

Image: Ambro / FreeDigitalPhotos.net

Team Productivity - 10 ways to ensure that your team members excel and grow

This post is about the softer skills of software test management. It is about how to have your people excel in their jobs. It is something about which I feel strongly. The end result of a project is not the only important thing. Even more important is the career benefit to your team member. Is it possible to run a project such that throughout the project, your team member matures his skills, his attitude and his professionalism? Executing projects consistently like this will ensure that your team member grows professionally. Better performance on subsequent projects will be a given. So, how does a test manager go about having their team members excel and grow? It's not easy. It's also not very difficult. Here is how.

1. Know your team member's career objectives: Every time you start working with a team member with whom you have not worked before, set aside some time for a frank discussion. You may already have some data about their strengths/ weaknesses and past performance. However, have them mention their prior experiences in their own words. Observe the things they talk about and the things they focus upon. Avoid judging them at this time. Ask them about their passions and interests. Find out the situations that challenge them. Know the things in which they pride. Take notes to refer later.

2. Determine his preferred learning style: People have different favorite styles when it comes to learning new things. One person may prefer reading the new material, another may prefer having someone talk about it and another may prefer experimenting with it. Knowing your team member's preferred learning style will enable you to decide the best option, give them time to read new material, organize a classroom training or give them time and resources to play with it. Also, your own preferred learning style may be different from your team member's. So, do not impose your preferred style on him.

3. Identify his favored working style: Different people have different favored working styles. A team member may prefer crisp and clear instructions; another may prefer an outline to decide the details himself. One person may be fast (and mistake-prone) and another may be slow (but thorough). One team member may prefer being assigned only one task and another may be quite comfortable with multiple tasks with varying priorities. One may be able to maintain focus on the given task and another may need periodic reminders. When executing the task, one person may communicate regularly with you and another may give you infrequent updates. Understanding your team member's favored working style will enable you to know what to expect from him as "normal".

4. Remember that every individual is unique: Understand the motivations, challenges and favorite styles of your team member will enable you to deploy him on project tasks that benefit the project and also the team member the most. For example, a technical oriented person would contribute the most to the technical tasks in the project, a fast team member would contribute most to the effort-intensive tasks of the project and a good communicator would contribute most to project tasks requiring co-operation with other teams.

5. For every assignment, ask him to confirm the objectives, approach and deliverables as understood by him: Knowing your team member's favorite working style will enable you to design and communicate an assignment to him in the most helpful way. But, it is possible that some objectives or approach or deliverables are not registered cent percent. So, always ask him to re-iterate these in his own words. This will enable you to identify and close any gaps in understanding them.

6. Don't simplify the work: As a manager, your role is to distribute the work assignments and track them. You may give your suggestions to simplify the work. But, always encourage the team member to think about the challenges, identify appropriate approaches to tackle them and choose the best approach. Providing him ready-made solutions would rob him of this opportunity to grow. Also, increase your expectations gradually. Raising the bar will ensure that you team member does not run out of problems and challenges.

7. Never accept failure as-is: There will be situations in which the outcome is not successful. Even so, such situations will make the team member learn what does not work (well). When faced with failure, provide your team member with the required encouragement and help until he does come up with an acceptable success.

8. Never neglect communication: Regular communication is critical to strong relationships. Keep your team member informed about relevant developments. Contact him from time to time, even if it just to catch up. At least, always be available should your team member wish to contact you for an update, an approval or even as a sounding board for an idea.

9. Maintain a consistent management approach yourself: Your team member should regard you as a fair and trustworthy person, who treats team members uniformly and says and does the same things. So, do not play favorites within the team and do not go after anyone. If you are inconsistent, your team member will be worried and unsure about you and this will impact their performance and growth.

10. Always respect your team member: Finally, always be respectful to your team member. Be ready to listen to him while suspending judgment. The thing about respect is that it's mutual; if you respect your team member, he will automatically respect you. Respect will ensure that your team member stays focused on excelling and growth.

If you are a manager, follow the above 10 points over and over again. You will have an exclusive understanding of your team and you will make prudent business decisions. Also, your team members will grow professionally.
If you are a team member, show these 10 points to your manager. Understanding, open communication and consistently working in challenging situations are sure to make you grow faster.

Image Courtesy: Salvatore Vuono / FreeDigitalPhotos.net

Accessibility Testing Checklist

Accessibility is the attribute of a software application that makes it possible for people with disabilities use it. Accessibility is very important because a large number of potential users have limited abilities or disabilities. Examples of disabilities include visual impairments (from colorblindness to partial sight to complete blindness), deafness (partial or complete hearing loss), mobility impairment (inability of use hands or other parts of the body) or neurological (ADD, epilepsy etc.). Examples of limited ability people include people with limited education, old people with medical conditions and children. Thankfully, a number of assistive devices (e.g. screen readers, speech recognition software and Braille terminals) are supported in a number of operating systems. As testers, it becomes our responsibility to ensure that people of limited abilities or with disabilities are able to use the assistive devices with the application that we are testing. So what things we must test to ensure that the software application is accessible?

1. Each functionality and content is available using only the keyboard (not using the mouse at all). There is no requirement of a minimum speed of individual keystrokes.

2. Each page, each section and each table has a title that indicates its purpose.

3. Each text has a contrast of at least 4.5:1.

4. Each abbreviation or unusual word is explained.

5. Each link is self-explanatory.

6. Each label in the application is self-explanatory.

7. Each non-text content like image, audio or video has an equivalent text/ transcript.

8. Sufficient time is available to the users to read the content and take action based on it.

9. Each error message has text that explains the occurred error.

10. Help is available in text to the user from any place in the application.

11. It is possible to know the current location from anywhere within the application.

12. Color is not the only means of communicating any information. There is also an equivalent text indicating this information.

13. Similarly, shape/ size/ location on the page is not the only means of communicating any information.

14. There is no content that flashes more than 3 times per second.

This is only a partial checklist to ensure an accessible application. Refer the Web Content Accessibility Guidelines here for more information.

Image Courtesy: Teerapun / FreeDigitalPhotos.net

Many websites use a type of software testing called A/B testing or split testing. The objective of this testing is to determine and positively influence the user experience on the website. It involves testing distinct design layout options of the website. A/B testing is also performed on non-web elements of the website such as emails. Many large companies use A/B testing. So, what is A/B testing?

A/B Testing

A/B testing determines the better of two content or design options on real users using web analytics tools. It requires an existing benchmark to measure against. For example, let us say that you test an ecommerce website. Looking at the website logs or analytics, you know that only 20% of the users who start a checkout process actually complete it. You suspect that your multi-page checkout process could be a cause of checkout abandonment. Instead of directly changing the checkout process to single-page, you decide to execute an A/B test. For this, you set up two checkout options - the current multi-page and the new single-page checkout. From now on, 50% of the users who start the checkout get the multi-page checkout option and the others get the single-page checkout. In order to not confuse the users, you record which option was presented to which user and continue to provide the same option to the users on their repeat visits too. You monitor the test results for a month. Then you analyze the results and take necessary action.

Possible test results
1: Multi-page Complete = 10%, Single-page Complete=30%: This is strongly in favor of the single-page option. So, you decide on deploying this option.
2. Multi-page Complete = 18%, Single-page Complete=22%: This is a minor difference. Maybe, the cause of low checkout completion is not the number of pages. So, you decide to look for other elements and then run a different A/B test.
3. Multi-page Complete = 28%, Single-page Complete=12%: This is in favor of the existing option. So, this is not the cause of low check out completion. You decide to test another element e.g. the actual text on the checkout pages.
4. Multi-page Complete = 10%, Single-page Complete=12%: This is marginally in favor of the new option. But, more urgently you need to find out the cause of both options performing below the benchmark.

Points to keep in mind
a. The two options should have only a very limited number of differences. If there are many differences, it is hard to pin-point the improved element with accuracy.
b. The sample sizes in A/B testing should be statistically significant. For example, the results based on an A/B test on 200 users is realistic. A test on just 5 users is not.
c. The two options should be tested simultaneously, rather than one after the other. If tested consecutively, it is possible for other factors (e.g. changed user patterns/ demographics) come into play and this may skew the results.
d. Instead of just two options, multiple options can be tested. In this case, it will be called A/B/N testing (for N options).
e. Each and every element of the web application interface is a candidate for A/B testing. The elements to be considered include home page, actual text, font faces and sizes, colors, images, links, linked pages, placement of elements and so on.
f. A/B testing should be done on an ongoing basis. After improving one element of the user experience, the next should be targeted and tested.

I hope that you now understand A/B testing. There is an A/B test currently in progress on the home page of this blog. Can you spot it?

Code injection attacks

If you are going to do software security testing of applications, you must be aware of possible code injection attacks. This is especially required when testing web applications because they face a hostile environment, the internet. Code injection means adding extra code to an executing application with the purpose of modifying the application behavior. This extra code can be in the form of HTML, Javascript or SQL or even unhandled type of text (e.g. special characters and long strings). Here are the types of code injection attacks.

Common Security Terms

I thought about mentioning some important computer security terms. It would be good if you know and understand these terms which are commonly used in computer security. See my video, Cyber Security Basic Terms and Concepts or read on.

1. Authentication
It is the process of confirming the genuineness of an entity or data. For example, when a user logs into a website, the website tries to confirm if the user is genuine. That is, he is using the correct user name and password which are active in the site database. There can be other user data involved in authentication e.g. security token, Personal Identification Number (PIN) or finger prints/ retina print.

2. Authorization
It is the grant of permissions to do certain actions. For example on a website, a general user may view their transactions and modify their profile. But, if the general user is inactive, he may only activate his account and not even view his own profile. An admin user may view and modify the settings of the website, but may not view any user's data.

3. Cryptography
It is the use of techniques to assure secure communication. Such techniques include using encryption algorithms and digital signatures. For example, a website may require encrypted data sent from the server to the client browser. This data is decrypted in the client and then rendered to the user.

4. Exploit
An exploit can be a wide range of items e.g. a set of commands, a set of data or even a particular system. It is possible to use an exploit against an insecure information system with the purpose of generating undesirable behavior in the system. Exploits always target a vulnerability (see below) in the system. For example, an attacker places exploit code on a trusted website. A user accesses the site from an insecure client machine which results in the user's browser executing the exploit code. The attacker then runs some attack using the user's machine with user credentials.

5. Firewall
A firewall is a software-based or hardware-based device that can be configured to allow genuine network traffic to go through and stop malicious traffic. For example, a firewall may intercept all network packets sent to an application, such as a browser. If the traffic originates from a known dangerous source, it may drop all the packets preventing harm to the client machine.

6. Identity
It is the set of data that is unique to a person. The digital identity of a person is the identity that is used on-line. For example, the identity of an employee may comprise of attributes such as Employee number, Date of joining, First name and Last name. The employee is then required to use this identity within the organization throughout their stay.

7. Penetration test
It is a test to check the security of a network while pretending to be an external attacker. It is also called a pentest. The goal of a pentest is to gain access and some level of control over a device within the network. Valuable information is discovered by a pentest e.g. vulnerabilities present in the network and the effectiveness of automatic network scanning software.

8. Physical security
It is the presence of physical barriers to information resources of an organization. Examples include gated access manned by security guards, access card swipes required to enter the premises and logged access to restricted areas within the premises.

9. Threat
It is a danger to the information resources of an organization. It can be intentional e.g. an external attacker or accidental e.g. an earthquake. There are usually numerous threats to the information resources e.g. natural catastrophes, power outages, hardware/ software failures and malicious individuals/ organizations. Information resources of different organizations may face the same threats.

10. Vulnerability
It is a weakness within the information system of an organization. For example, software vulnerability arising from insufficient testing, hardware vulnerability arising from its insecure storage and physical site vulnerability arising from its location within a natural disaster prone area.

If you are interested to know about many more computer security terms, you can visit the SANS glossary of terms here.

Automation Criteria - guidelines on how to write test cases that will be automated

Everyone knows that a strong house can be built on a strong foundation only, never upon a weak one. This post is in continuation to the earlier post, How to write automatable test cases? Test cases here mean "manual" test cases, the kind that a tester can execute against the application under test by hand. Each of the following guidelines is also applicable to create valid test cases that would be executed, so there is no special effort here to prepare such test cases for automation.

1. The test case must be correct. It is obvious that the test case must be correct with respect to the workflow and expected application behavior. This guideline is especially important for automation because though it is possible for a manual tester to ignore obvious incorrectness in a test case, the automated test script would not be able to do the same. False negatives would be reported every time the automated test script is executed.

2. All the business scenarios must be covered by the test data. This refers to the completeness of the test case. The test case must contain test data for all applicable business scenarios that users would face.

3. The test case should have sufficient detail so it is possible for another person to execute it without asking questions or getting clarifications. Pre-conditions, test steps, test data, expected results and post-conditions are important components of a test case. The test case should be written with the target consumer in mind. If the automation engineer has good knowledge of the application under test, the test case components may be summarized. If not, they should be detailed out.

4. [Important] The test case must be capable of finding bugs in the current release of the application. If a test case has not caught a bug in the last few releases of the application, the likelihood of it doing so now is limited. Extra effort is required to automate test cases. So, why not automate the test cases with a high likelihood of catching bus?

5. The test case should have been accepted by the team. The test case that would be automated should not be in a raw state e.g. just whipped up by someone. It should have been reviewed/ discussed, stored in the correct file and accepted by the team as a valid test case.

6. The test case should be under version control. Placing the test case in the version control repository shows the changes made to it subsequently. Changes to the test case should be propagated to the automated test script, whether the latter is under construction or already built. Therefore, there must be a process to update the automated test script whenever the test case is revised and accepted.

Correct, complete and up-to-date test cases are important assets for any testing team. Due attention is paid to such test cases. Similar attention should also be accorded to the automated test script of such a test case. After all, its the same test case, just written in a different format. Therefore, the automated test script should be reviewed/ discussed, accepted and placed under the version control repository. The results of each execution of the automated test script should be given similar attention.

Image Courtesy: renjith krishnan / FreeDigitalPhotos.net

Do managers have bigger brains?

Within the last couple of days, I have been intrigued by a news item that said that Managers have bigger brains. Then, I used Google to find out the related text. The purpose of this post is not to analyze whether or not "managing" results in a bigger brain, or even the implications of this discovery. The focus of this post is to analyze how simply using natural language to describe the result of a study can distort what is being communicated. Then, move on to the application of this analysis to requirements analysis in software testing.

Managers have bigger brains: Since this study was conducted University of New South Wales researchers, I searched the UNSW website and found this article here. My comments were:

1. I found the following text at this link "UNSW researchers have, for the first time, identified a clear link between managerial experience throughout a person’s working life and the integrity and larger size of an individual’s hippocampus – the area of the brain responsible for learning and memory – at the age of 80." So, they are not talking about the entire human brain but only one of its parts.
2. The article talks about finding a relationship between the size of the hippocampus and the number of employees managed. It does not state the exact relationship.
3. Per the article, the researchers used MRI in a sample of 75 to 92 years old. Around the middle, the article moves on to the relationship between exercise and learning and other topics presented in the symposium where this study was presented.

This news item also appeared on other websites such as MSN India here.
4. I found the text "Staffers agree or not, managers do have bigger brains, says a new study." The prior article had no mention of the staff agreement to the manager having a bigger brain. So, did the research take the subjects' staff's agreement into account?
5. This news item says "Researchers, led by the University of New South Wales, have, in fact, for the first time, identified a clear link...". The previous article just mentions "UNSW researchers". So, were there teams from elsewhere involved in the research?

What can we take away from the analysis?
a. It is possible for people to over-generalize or over-specialize a description. So, we should probe further to find out the caveats and exceptional conditions. For example, a requirement may say "The user account shall be locked after 3 unsuccessful attempts". On probing further, we may find that this is true for all users, except the administrator user. The system may be rendered in-operational if the administrator gets locked out :)
b. It is possible for people to just provide references to other information, without naming it explicitly. Instead of relying on our assumptions, we should ask for the reference directly. For example, a requirement may say "Other requirements implemented in the previous release shall continue to be supported". We should ask for which release - the last major release, the last release (major or minor), the first release or any other release? If there is a conflict between the requirements of this release and the "previous release", is it okay to have the requirement of this release take priority?
c. We should question the source of the requirement. Has it come directly from the customer or system analyst or just a suggestion from somebody? In other words, is it a genuine requirement? For example, someone may suggest making reports completely configurable. It may be against the client's objective that any user comes up with any format of a report, leading to confusion. The suggestion should be declined. Of course, suggestions made by the management need to be declined tactfully, if infeasible to implement.

Testing Training - How I train professionals?

Ever since I started my career in software testing, I have been asked to give training sessions on testing topics. The topics on which I have trained people include basics of software testing, writing correct and re-usable test cases, rapid test execution, bug tracking systems and defect management to test automation approaches, performance testing, system security testing and test methodologies. 

I do have a couple of advantages. First, two years experience in giving software training during my initial career. Second, I have always been keenly interested in how people learn (probably because of 6 teachers in my family, including my mother). I am life-long student of the psychology of learning.

Let me explain the approach I use during training. This is both for your benefit and my benefit. Your may benefit from these tips by increased recall of the participants after the session which leads to more application of the training material in projects. I will benefit by looking up my tips to ensure that I continue to follow them and build them further.

1. Know your topic
This is most important. You should know your topic really well. Not just a little more than the participants, but many times more. Why? In order for learning to take place, the participant has to believe in the superior knowledge of the trainer. For example, let us say that you are training on creating automated test scripts. You have done this before using a functional test automation tool. Someone in your class asks about parameterization and you are stuck. What will happen? What you say from that point onwards would not be credible. Therefore, give training only on topics that you know inside out.

2. Plan your training session
You should know the objectives that the training session should achieve. This information is available from the sponsor of the training. Also, if you know the participants, you can find out their current knowledge level and their expectations from the session. If you don't know the participants in advance, you should spend some time at the beginning of the training session to find this information. For example, if you are training on system security, the participants need to know the basic security concepts like information integrity, information confidentiality and information availability. The training session should cover the material required to increase the participants knowledge from the current state to the desired state.

3. Create your training material
Once you are clear on the objectives of the training, the next step is to design the sub-topics and training material. For example, if you would be training on writing test cases, you should cover the inputs to the test cases (requirements documentation, design documentation, prior test cases, test case formats etc.) and tips on how to write test cases (with all scenarios, pre-requisites, test steps and expected results). The training material can include practical examples of good test cases.
One caveat: The training material should not be too lengthy or cluttered. The main focus should be on the participants understanding the topic well. They can always look up the references if they need more details later.

4. Starting the training session
For learning to take place, the participants should be engaged in the training session. A useful way to do this is to explain the objectives of the training session in terms of what they already know and how the training will help them work in a better way. For example, if training on bug tracking systems, the objective is to use the bug tracking system more efficiently, you could mention that you will share tips on using the bug fields correctly and setting up email notifications for more efficiency.

5. Treat the topic logically
If you plan your training session well, you would have identified the logical sequence of the sub-topics. Answer questions from participants as required but stay on course. For example, if training on performance testing, the logical sequence for you may be creating the automated test scripts, parameterization and correlation, modeling the test, test execution and analyzing the results. If you have moved to test modeling and you get a question on parameterization, answer it quickly and then say you are moving back to test modeling. Also, explain any new concept or term with more than one example as soon as you introduce it.

6. Make the session interactive
People like sessions during which they can ask a question any time. If the question is related to the training session, you should answer it. In fact, you should always pause for questions on the conclusion of a sub-topic. If a question is not directly related, you could park it. For example, if you are training on functional test automation approach and someone asks you which tool is best for automated testing, you could say that it is not directly related and you would take it offline later. You always need to be respectful of the participants' time that they have chosen to spend listening to you.
One trick I use to keep my session interactive is to pretend that a term or word has slipped my mind. This forces people to think and they come back with suggestions energetically.

7. Summarize the training session
After completing the session and answering questions, be sure to summarize the main points in the training session. The material covered must be linked to the objectives of the training session. For example, if you trained others on object repositories, you could say that by now the participants should have awareness of the types of object repositories and they should be able to make an informed decision to use the best type in their project.

8. Finishing up
Spend a little more time sharing the training material, providing further references and providing a contact to answer questions later on. Also, reiterate the expectation from participants now they attended the training session.

Well, these were but some of the guidelines I use when training others. Your training session should be more productive if you use the above. What do you think is most important in making a training session successful?

Database Testing Example

I have explained database testing with examples in my video, Database Testing and SQL Tutorial for beginners.

Now, I received several emails from the my viewers asking for advice on how to practice database testing. This post contains one example to practice the same. I have explained SQL queries and SQL joins in my SQL Tutorial for Beginners | SQL Queries Tutorial using multiple examples.

Create a practice database with three tables, Products, Orders and OrderDetails or use the database that I showed in my SQL Queries tutorial above. It does not matter which database management software you use. It is simple to anticipate the relationships here. Products table is related to OrderDetails table, via the ProductId field. Orders table is related to OrderDetails table via the OrderId field.

Now, write and execute queries to check the following:

1. Is there any product which exists in the OrderDetails table but is missing in the Products table?

2. Does any OrderDetails row have an OrderId that is missing in the Orders table?

3. Is any ProductName, Serialnumber or ProductDescription duplicated in the Products table?

4. Does any product have a negative UnitsInStock?

5. Does any order have a ShipDate which is earlier than the OrderDate?

6. Does any order have a future OrderDate?

7. Does any OrderDetails row have a Quantity value less than 1? Or a Quantity value which is fractional?

8. Does any OrderDetails row have a zero or negative SalePrice or UnitPrice value?

9. Does any OrderDetails row have a UnitPrice for a product, different from that product's UnitPrice in the Products table?

10. Can you enter Price values (UnitPrice in Products table and SalePrice and UnitPrice in OrderDetails table) in decimal (up to 2 digits after the decimal point)?

How to impress your boss and team?

Would it not be great if you could impress your manager and team by putting in just a little more effort? Here are some ideas for building a great perception of you. Note that 3 out of the 8 ideas relate to communication, very important to impress others.

1. Maintain stable work timings

It is important for others to know when to reach you. You can make it easier for them if you are always in office, say before 9 a.m.. Maintaining fixed in-timings shows commitment to work. When you are on vacation, make sure that you set up an Out of Office message notification with information of another person to contact, if urgent.

2. Ask lots of questions during meetings

If you are attending a meeting, you might as well ask questions. Use the 5 W's (What, Why, Where, Who, When) and How to frame questions to get more information for you and others. Asking questions during meetings shows that you are engaged with the topic and eager to understand more.

3. Volunteer for high-visibility assignments

Volunteers are asked for in meetings or written communications. Be eager to take up a task that only one person can do, but which will benefit the whole team. Also, look for small tasks that nobody else is doing. And complete them.

4. Communicate regularly

Whatever you have completed and are doing at present, be sure to communicate it regularly. If you maintain data about your daily tasks, it will be possible for you to communicate daily. Then summarize weekly, monthly and even annually, and communicate those summaries also.

5. Communicate using the correct vocabulary

Different companies and teams have different preferred vocabulary. If you use the specific terms preferred by your manager and team, your communication will be easier to understand. Also, these words show that you are engaged with your team and company.

6. Keep building material for later communication

Have you seen well-structured emails from others with a number of original thoughts? And wondered how much time and effort they spent on creating that email? You, too, can do the same. For important emails, instead of writing whatever comes to your mind and shooting off the email, collect your thoughts in the draft first. Don't send it. Keep updating the draft when you get any good ideas. Soon enough, you will have a worthy email that will impress others.

7. Ask for inputs

When you create a project deliverable (test plans, test cases, automated test scripts etc.), always ask for review comments from your manager and team. You may not get review comments every time. But, whenever you do, it is a good input to refine your deliverable. Also, this shows your commitment to quality.

8. Say "Hi"

Finally, take a couple of seconds to wish your colleagues whenever you meet them. This helps others think of you as a courteous and approachable person.

Please let me know if you liked these ideas and the benefit you got from them.

Image Courtesy: renjith krishnan / FreeDigitalPhotos.net

Why bad software testing happens?

It is possible for software testing to go wrong in a project. Look out for these red flags in your project and make corrections immediately to avoid bad testing.

1. Customer inputs ignored

2. Poor knowledge of the application under test

3. Application technology ignored

4. Incorrect test strategy

5. Old test process followed mechanically

6. Unorganized testing

7. Poor observation and analyses

8. Insufficient communication

9. Lack of perseverance

10. No self-critique/ correction in the team

Automated test script review checklist

Reviews are a great way to find common problems with a number of test automation artifacts, such as automated test scripts like the ones that I wrote in my Selenium Python tutorials. By an automated test script, I mean script code implementing a test case's test steps and expected results e.g. the second script in my Selenium Python Tutorial 2. The automated test script may be written in any programming language or scripting language. It may be generated by a functional test automation tool or written by hand.

Here is a checklist that you can use to review your or others automated test scripts. You should customize the questions according to your specific needs. For practice, review the automated test script to answer a quiz automatically. Post your review comments below.

Inputs

1. Does the script implement each step of the test case?

2. Does the script implement each step in the correct order?

3. Does the script implement each validation given in the test case?

4. Does the script have each validation after the correct step?

Execution

5. Does the script logic call the correct functions? Are these functions called with the correct arguments?

6. Does the script take application input values from the correct input test data file(s)?

7. Does the script execute user operations against the correct objects?

8. Does the script give the application sufficient time to transition to the correct test state e.g. the correct screen?

9. Does the script validate application output values against the correct output test data file(s)?

10. Does the script validate the state of the correct objects?

11. Does the script load only the necessary objects in memory?

12. Is the script free from unnecessary delays?

13. Does the script handle application errors as designed?

Miscellaneous

14. Does the script have a unique identifier?

15. Is the script free of any magic numbers or magic strings?

16. Is the script commented at each appropriate place in it? Is each comment correct?

17. Is the script free from unnecessary or extra code?

Let me know if you find this checklist useful in your reviews.

Automate tasks in software testing

When the term automation is mentioned, it is common for people to think of automated tests. But, time and effort can also be saved by automating other tasks such as generating test data and reporting test results automatically. A few factors should be considered for effectively deciding whether to automate a task or not. Last year, we had fruitful discussions on this topic within the STS group.

Let us see some candidate tasks for automation. Testers spend a lot of time on these tasks. If such tasks are fully or partially automated, the saved time can be spent on testing the system.

1. Test identification based on risk or other factors

List all the available test cases along with related features, components and priorities. The automation can take the inputs e.g. impacted features and generate the list of test cases that should be executed on the new application build.

2. Test estimation

Automation can be used to help estimate the test effort and duration. This can be done based on the preferred estimation approach. Whether by querying the historical data for actual efforts and durations, or by applying a custom formula to estimate test effort and test duration.

3. Generation of test data

Build a library of business rules for your test data. Build the initial seed data manually. The automation can use the seed data and generate test data based on the chosen business rules. Since test data generation is usually consumes much time, the automated generation can be performed ahead of time. Then, the pre-generated test data can be used directly during test execution.

4. Generation of bug reports

This automation can be built into the test automation framework. Whenever an automated test script confirms an error, it logs into the bug tracking system and reports a bug with required information. Such as bug title, steps to reproduce, test data used, environment used and so on.

5. Generation of test reports

This automation can execute queries against the test management system (and bug tracking system, if different) and generate test reports. Even distribute them by email or publishing to a website.

6. Release notes preparation

Release notes contain both static and dynamic data. This automation can execute queries on the test management system to retrieve the dynamic data such as features passed, bug fixes passed and known bugs.

Before prioritizing the automation development, always analyze the following factors.

a. Degree of automation achievable

b. Skills required to automate

c. Effort required to automate

d. Number of proposed users

e. Effort required to train users

f. Effort required to execute automation

g. Effort required to maintain automation

h. [Important] Manual effort saved

In the future, I see a number of such tasks automated with the help of vendor tools or bespoke in-house automation.

Let me know if you liked this post. I would love to know your thoughts on this topic.

Image Courtesy: Ambro / FreeDigitalPhotos.net

Software testing myths

Myths abound in the software development industry. Software testing is no exception. People tend to hear such statements and pass it on to others minus the full context. Not only that, they even tend to use such myths when making own decisions, especially when in hurry.

1. A ratio of 1 tester to 5 developers is enough to get good test coverage.

This myth may be true in long-term new development projects with multiple stages of testing (e.g. SIT, alpha, beta and UAT). This ratio may fall short in:

a. Maintenance projects with highly inter-dependent components, requiring testing of all impacted components

b. Projects requiring huge effort to create an independent test environment

c. Projects requiring extensive regression tests (due to, say, business impact, contracts or regulations)

2. Anyone can test software.

Anyone can test software if they know what to do. A professional tester is well-versed in the project requirements, software testing concepts, test design and test execution techniques and is also an assertive communicator.

3. Developers can test software better than testers. After all, they are the ones who developed it.

While developers know the code they develop intimately, they may not be the best people to test it (or test code written by other developers), especially at the integration level or system level. Testers execute their tests in a clean test environment with a fresh mindset, doing both positive and negative testing. Developer testing complements (and does not substitute) testers' testing.

4. Test cases are only derived from requirements.

Requirements are only one input to write test cases. A professional tester uses many other inputs like design documents, standards, checklists, prior test cases, past bugs reported by the customers and prior versions of the application/ similar applications.

5. Testers need only execute a set of test cases.

A static test case suite is unlikely to lead to the discovery of new bugs in the application. Before execution, the test suite should be updated by removing the useless or redundant test cases, completing or correcting the existing test cases and adding new test cases to increase the likelihood of discovering fresh and interesting bugs in the application.

6. Tests already executed need not be repeated in the release.

It depends. If the new builds do not impact the application areas covered by the tests already executed. Much more likely, some tests need to be re-executed to re-gain confidence in those areas.

7. Testers test every permutation and combination of inputs a user can provide to the application.

This is not possible except in very trivial cases. Even testing all possible inputs of a form with a few text, date and numeric input controls within the given time may well be impossible. What testers actually do is to design the minimum number of input sets that tests each input control. Specific inputs to each control are limited by using testing concepts like equivalence partitioning.

8. Testers can test equally well (if not better) when the time is short.

Nobody can perform a thorough job if rushed. Testers are no exception. If the available time is reduced too much, a tester prioritizes the tests to execute and keeps executing the higher priority tests until time runs out.

Image: Idea go / FreeDigitalPhotos.net

Simple testing

Lately (actually since a while), I have been looking for ways to increase my productivity. One of the ways I recently came across is simplification. Why?

1. Better focus, especially on creative or complex tasks
2. Less stress, due to elimination of so many unimportant tasks
3. More time on hand

So, how to simplify our software testing tasks? Here are some examples. Design your own according to your unique situation.
1. Analyze your work and establish what is important in your role. Put it down in a sentence. For example, Maintaining your test suite, executing it and reporting defects may be critical to your role. Formatting your status report or pointless gossiping with your colleagues is definitely not.
2. Allow yourself time to plan. Plan simple i.e. think about the easiest set of actions that will complete your task.
3. Guard your time. If someone interrupts you, dismiss the interruption asap. If someone approaches you for help, consider helping once you are done with your tasks or say no.
4. Own your work. If some task had a problem and requires re-work, don't blame other people. They would respond with their reasoning and you would end up spending time on this exchange. Then attend to the problem. Instead, just fix the problem at once and move on.
5. Use software apps to your advantage. See examples.
a. Block your mail calendar for important tasks in advance and in order of importance. This would allow you to see your upcoming tasks for the next day, week or month and you can better prepare for them.
b. To be responsive, check your email a limited number of times in the day. If you leave it on, you would get distracted every time you get a new email. And you will have the urge to stop your current task and read/ take action on the email you got.

This was a short and simple post and it made me feel better writing it.

Interviews of Thought Leaders - Freddy Gustavsson

Having started his career as a software developer, my dear friend and a key member of the Software Testing Space group, Freddy Gustavsson made the leap into testing in 2001 after realizing that a carefully designed test approach will greatly increase the chance of success in any software project. He is interested in all parts of the test process, and has experience from several international projects. He works as a consultant for System Verification in Gothenburg, Sweden, where he specializes in test strategy, test design, test automation, test process improvement and test education. Freddy is an ISEB/ISTQB certified test analyst who also teaches courses on software testing and serves as a member of the internal Senior Advisory Board.

Here is the interview. Enjoy and learn.

[Inder] Did you start your career with software testing or have you held other software roles as well?

[Freddy] I actually made somewhat of a detour to reach my current position in software testing. At first I had no intention at all to work in the IT industry. Instead, I wanted to pursue a career as a teacher of languages at college level. So I studied German linguistics for two years at the university and prepared for some advanced English studies. However, my passion for web development grew stronger, and I decided to make a shift. In 1999 I started working as a web developer for one of Germany's e-business providers. There I learned tons of good stuff about development, projects, team work and testing. In 2001 I joined the QA team and became a tester. Later, I've finished a 3 year university education and a B.Sc. in Software Engineering because I wanted to understand my profession truly. I've also taken complementary courses in project management, usability, accessibility etc. Additionally, I spent one year teaching programming courses at university level, which was useful.

[Inder] Not all people appreciate software testing as a highly intellectual work; they feel that it is quite easy to test. Can you talk about few technical challenges that you have faced in your career?

[Freddy] It's a known fact that some employers will view testing as an entry point to development. It's as if they told their candidates: "We're sorry, but you're not qualified to play with the developers yet. But let's move you into testing. If you work hard and prove yourself worthy, then some day you might actually be allowed to work in development." Even worse is the situation where employees, who were rejected by other disciplines, are brought into testing, because managers feel that they "do least harm" there. This approach is just so wrong.

Testing is by no means a trivial task. Anyone who has worked as a professional tester knows this. However, not all people coming from other disciplines will understand testing well enough to realize its challenges. They might think of testing as "happy testing" or "randomly clicking around", not realizing that testing requires a controlled process. The presence of structure is vital to our job. At the core of the tester's job is the comparison of actual and expected results. However, this is surrounded by numerous items such as plans, strategies, procedures, methods and tools. Designing and implementing all of this in an effective and efficient way requires excellent business, technical, administrative and social skills.

Common technical challenges include quickly learning new applications and tools, understanding the environment in which each tool operates. Sometimes you also need to learn new protocols, scripting languages, or get an understanding of complex system architectures. This is part of the tester's job. Being curious and eager to learn new things is definitely helpful.

[Inder] Looking back at your software testing career, what have been some of the highlights?

[Freddy] The first highlight would be the recognition of testing as a profession. The second would be the insight that some of my carefully crafted test cases were actually detecting failures. The developers would lovingly refer to me as The Merciless Tester. Their indignation over each found problem would not last long. Instead they asked me to do more testing on their code. Although I have occasionally, and unintentionally, upset a few people through my work, in most cases the work with other disciplines has been both interesting and rewarding. The third highlight would be the move into consulting and a focus on test strategy, which might be the best job ever. Number four is the mentoring and educative role where I get to spread the word and (hopefully) make other people interested in learning more about our craft. Highlight number five would doubtless be this interview. ;-)

[Inder] Do you find testing enjoyable? How can software testing professionals derive more satisfaction from their craft?

[Freddy] Yes. Just like for other professionals there are a number of things that motivate me to do a great job. The most important is probably the feeling of making a valuable contribution to the client. Sometimes also to the community. For instance, a few years ago I was on the system test team for the national Swedish command and control system. The system was built for operation in emergency situations where ambulance, police or fire brigades might be needed. Any failures in the software might possibly have catastrophic (life or death) consequences. In that case every defect found and removed would benefit the whole community. As a tester you knew your work made a difference.

Having a good, respectful working relationship with coworkers and managers also makes it to the top of my list. Another important thing is the possibility to control your job, to be able to suggest ideas and improvements.

[Inder] What are some good resources for people wanting to enter software testing or establish them in this career? What activities can one do in their spare time to enhance their testing skills?

[Freddy] I want to refer to a good seminar on this topic, which I attended at the EuroSTAR 2010 conference in Copenhagen. Markus Gärtner from Germany gave a presentation on alternative paths for self-education in software testing. A number of options were presented:

• Using social media (e.g. Twitter, LinkedIn, web sites, forums)
• Learning to program (e.g. scripting languages, design patterns)
• Reading books on testing
• Joining online testing courses
• Participating in testing challenges
• Participating in organized problem solving activities like testing dojos, weekend testing or the Miagi-Do school of testing.

[Inder] What are your future career plans?

[Freddy] I look forward to an exciting future in which software testing will undoubtedly play an important role. Personally, while keeping an eye at the entire field of testing, I plan to specialize further into the areas that interest me most: test strategies, test process improvement and test design methodologies. I also plan to extend my teaching assignments in the future, since lecturing is a great way to spread the knowledge about testing while learning a lot myself. As they say: you learn as long as you teach.