Types Of Software Testing: Different Testing Types With Details

What are the different types of Software Testing?

We, as testers are aware of the various types of Software Testing such as Functional Testing, Non-Functional Testing, Automation Testing, Agile Testing, and their sub-types, etc.

Each of us would have come across several types of testing in our testing journey. We might have heard some and we might have worked on some, but not everyone has knowledge about all the testing types.

Each type of testing has its own features, advantages, and disadvantages as well. However, in this article, I have covered mostly each and every type of software testing which we usually use in our day to day testing life.

Let’s go and have a look at them.

Different Types Of Software Testing

Given below is the list of some common types of Software Testing:

Functional Testing types include:

• Unit Testing
• Integration Testing
• System Testing
• Sanity Testing
• Smoke Testing
• Interface Testing
• Regression Testing
• Beta/Acceptance Testing

Non-functional Testing types include:

• Performance Testing
• Load Testing
• Stress Testing
• Volume Testing
• Security Testing
• Compatibility Testing
• Install Testing
• Recovery Testing
• Reliability Testing
• Usability Testing
• Compliance Testing
• Localization Testing

Let's see more details about these Testing types.

#1) Alpha Testing

It is the most common type of testing used in the Software industry. The objective of this testing is to identify all possible issues or defects before releasing it into the market or to the user.

Alpha Testing is carried out at the end of the software development phase but before the Beta Testing. Still, minor design changes may be made as a result of such testing.

Alpha Testing is conducted at the developer’s site. In-house virtual user environment can be created for this type of testing.

#2) Acceptance Testing

An Acceptance Test is performed by the client and verifies whether the end to end the flow of the system is as per the business requirements or not and if it is as per the needs of the end-user. Client accepts the software only when all the features and functionalities work as expected.

It is the last phase of the testing, after which the software goes into production. This is also called User Acceptance Testing (UAT).

#3) Ad-hoc Testing

The name itself suggests that this testing is performed on an Ad-hoc basis i.e. with no reference to the test case and also without any plan or documentation in place for such type of testing.

The objective of this testing is to find the defects and break the application by executing any flow of the application or any random functionality.

Ad-hoc Testing is an informal way of finding defects and can be performed by anyone in the project. It is difficult to identify defects without a test case but sometimes it is possible that defects found during ad-hoc testing might not have been identified using existing test cases.

#4) Accessibility Testing

The aim of Accessibility Testing is to determine whether the software or application is accessible for disabled people or not.

Here, disability means deaf, color blind, mentally disabled, blind, old age and other disabled groups. Various checks are performed such as font size for visually disabled, color and contrast for color blindness, etc.

#5) Beta Testing

Beta Testing is a formal type of Software Testing which is carried out by the customer. It is performed in the Real Environment before releasing the product to the market for the actual end-users.

Beta Testing is carried out to ensure that there are no major failures in the software or product and it satisfies the business requirements from an end-user perspective. Beta Testing is successful when the customer accepts the software.

Usually, this testing is typically done by end-users or others. It is the final testing done before releasing an application for commercial purpose. Usually, the Beta version of the software or product released is limited to a certain number of users in a specific area.

So end-user actually uses the software and shares the feedback to the company. Company then takes necessary action before releasing the software to the worldwide.

#6) Back-end Testing

Whenever an input or data is entered on front-end application, it stores in the database and the testing of such database is known as Database Testing or Backend Testing.

There are different databases like SQL Server, MySQL, and Oracle, etc. Database Testing involves testing of table structure, schema, stored procedure, data structure and so on.

In Back-end Testing GUI is not involved, testers are directly connected to the database with proper access and testers can easily verify data by running a few queries on the database.

There can be issues identified like data loss, deadlock, data corruption etc during this back-end testing and these issues are critical to fixing before the system goes live into the production environment

#7) Browser Compatibility Testing

It is a subtype of Compatibility Testing (which is explained below) and is performed by the testing team.

Browser Compatibility Testing is performed for web applications and it ensures that the software can run with the combination of different browser and operating system. This type of testing also validates whether web application runs on all versions of all browsers or not.

#8) Backward Compatibility Testing

It is a type of testing which validates whether the newly developed software or updated software works well with the older version of the environment or not.

Backward Compatibility Testing checks whether the new version of the software works properly with file format created by an older version of the software; it also works well with data tables, data files, data structure created by the older version of that software.

If any of the software is updated then it should work well on top of the previous version of that software.

#9) Black Box Testing

Internal system design is not considered in this type of testing. Tests are based on the requirements and functionality.

Detailed information about the advantages, disadvantages, and types of Black box Testing can be seen here.

#10) Boundary Value Testing

This type of testing checks the behavior of the application at the boundary level.

Boundary Value Testing is performed for checking if defects exist at boundary values. Boundary Value Testing is used for testing a different range of numbers. There is an upper and lower boundary for each range and testing is performed on these boundary values.

If testing requires a test range of numbers from 1 to 500 then Boundary Value Testing is performed on values at 0, 1, 2, 499, 500 and 501.

#11) Branch Testing

It is a type of White box Testing and is carried out during Unit Testing. Branch Testing, the name itself suggests that the code is tested thoroughly by traversing at every branch.

#12) Comparison Testing

Comparison of a product's strength and weaknesses with its previous versions or other similar products is termed as Comparison Testing.

#13) Compatibility Testing

It is a testing type in which it validates how software behaves and runs in a different environment, web servers, hardware, and network environment.

Compatibility testing ensures that software can run on a different configuration, different database, different browsers, and their versions. Compatibility testing is performed by the testing team.

#14) Component Testing

It is mostly performed by developers after the completion of unit testing. Component Testing involves testing of multiple functionalities as a single code and its objective is to identify if any defect exists after connecting those multiple functionalities with each other.

#15) End-to-End Testing

Similar to system testing, End-to-End Testing involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

#16) Equivalence Partitioning

It is a testing technique and a type of Black Box Testing. During this Equivalence Partitioning, a set of the group is selected and a few values or numbers are picked up for testing. It is understood that all values from that group generate the same output.

The aim of this testing is to remove redundant test cases within a specific group which generates the same output but not any defect.

Suppose, the application accepts values between -10 to +10 so using equivalence partitioning the values picked up for testing are zero, one positive value, one negative value. So the Equivalence Partitioning for this testing is  -10 to -1, 0, and 1 to 10.

#17) Example Testing

It means real-time testing. Example Testing includes the real-time scenario, it also involves the scenarios based on the experience of the testers.

#18) Exploratory Testing

Exploratory Testing is informal testing performed by the testing team. The objective of this testing is to explore the application and looking for defects that exist in the application.

Sometimes it may happen that during this testing major defect discovered can even cause a system failure.

During Exploratory Testing, it is advisable to keep a track of what flow you have tested and what activity you did before the start of the specific flow.

An Exploratory Testing technique is performed without documentation and test cases.

#20) Functional Testing

This type of testing ignores the internal parts and focuses only on the output to check if it is as per the requirement or not. It is a Black-box type testing geared to the functional requirements of an application. For detailed information about Functional Testing click here.

#21) Graphical User Interface (GUI) Testing

The objective of this GUI Testing is to validate the GUI as per the business requirement. The expected GUI of the application is mentioned in the Detailed Design Document and GUI mockup screens.

The GUI Testing includes the size of the buttons and input field present on the screen, alignment of all text, tables, and content in the tables.

It also validates the menu of the application, after selecting different menu and menu items, it validates that the page does not fluctuate and the alignment remains same after hovering the mouse on the menu or sub-menu.

#22) Gorilla Testing

Gorilla Testing is a testing type performed by a tester and sometimes by the developer the as well. In Gorilla Testing, one module or the functionality in the module is tested thoroughly and heavily. The objective of this testing is to check the robustness of the application.

#23) Happy Path Testing

The objective of Happy Path Testing is to test an application successfully on a positive flow. It does not look for negative or error conditions. The focus is only on the valid and positive inputs through which application generates the expected output.

#24) Incremental Integration Testing

Incremental Integration Testing is a Bottom-up approach for testing i.e continuous testing of an application when new functionality is added. Application functionality and modules should be independent enough to test separately. This is done by programmers or by testers.

#25) Install/Uninstall Testing

Installation and Uninstallation Testing is done on full, partial, or upgrade install/uninstall processes on different operating systems under different hardware or software environment.

#26) Integration Testing

Testing of all integrated modules to verify the combined functionality after integration is termed as Integration Testing.

Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

#27) Load Testing

It is a type of Non-Functional Testing and the objective of Load Testing is to check how much load or maximum workload a system can handle without any performance degradation.

Load Testing helps to find the maximum capacity of the system under specific load and any issues that cause software performance degradation. Load testing is performed using tools like JMeter, LoadRunner, WebLoad, Silk performer, etc.

#28) Monkey Testing

Monkey Testing is carried out by a tester assuming that if the monkey uses the application then how random input, values will be entered by the Monkey without any knowledge or understanding of the application.

The objective of Monkey Testing is to check if an application or system gets crashed by providing random input values/data. Monkey Testing is performed randomly and no test cases are scripted and it is not necessary to

Monkey Testing is performed randomly and no test cases are scripted and it is not necessary to be aware of the full functionality of the system.

#29) Mutation Testing

Mutation Testing is a type of white box testing in which the source code of one of the program is changed and verifies whether the existing test cases can identify these defects in the system.

The change in the program source code is very minimal so that it does not impact the entire application, only the specific area having the impact and the related test cases should able to identify those errors in the system.

#30) Negative Testing

Testers having the mindset of “attitude to break” and using Negative Testing they validate that if system or application breaks. A Negative Testing technique is performed using incorrect data, invalid data or input. It validates that if the system throws an error of invalid input and behaves as expected.

#31) Non-Functional Testing

It is a type of testing for which every organization having a separate team which usually called as Non-Functional Test (NFT) team or Performance team.

Non-Functional Testing involves testing of non-functional requirements such as Load Testing, Stress Testing, Security, Volume, Recovery Testing, etc. The objective of NFT testing is to ensure whether the response time of software or application is quick enough as per the business requirement.

It should not take much time to load any page or system and should sustain during peak load.

#32) Performance Testing

This term is often used interchangeably with ‘stress' and ‘load' testing. Performance Testing is done to check whether the system meets the performance requirements. Different performance and load tools are used to do this testing.

#33) Recovery Testing

It is a type of testing which validates how well the application or system recovers from crashes or disasters.

Recovery Testing determines if the system is able to continue the operation after a disaster. Assume that application is receiving data through the network cable and suddenly that network cable has been unplugged.

Sometime later, plug the network cable; then the system should start receiving data from where it lost the connection due to network cable unplugged.

#34) Regression Testing

Testing an application as a whole for the modification in any module or functionality is termed as Regression Testing. It is difficult to cover all the system in Regression Testing, so typically Automation Testing Tools are used for these types of testing.

#35) Risk-Based Testing (RBT)

In Risk-Based Testing, the functionalities or requirements are tested based on their priority. Risk-Based Testing includes testing of highly critical functionality, which has the highest impact on business and in which the probability of failure is very high.

The priority decision is based on the business need, so once priority is set for all functionalities then high priority functionality or test cases are executed first followed by medium and then low priority functionalities.

The low priority functionality may be tested or not tested based on the available time.

The Risk-Based Testing is carried out if there is insufficient time available to test entire software and software needs to be implemented on time without any delay. This approach is followed only by the discussion and approval of the client and senior management of the organization.

#36) Sanity Testing

Sanity Testing is done to determine if a new software version is performing well enough to accept it for a major testing effort or not. If an application is crashing for the initial use then the system is not stable enough for further testing. Hence a build or an application is assigned to fix it.

#37) Security Testing

It is a type of testing performed by a special team of testers. A system can be penetrated by any hacking way.

Security Testing is done to check how the software or application or website is secure from internal and external threats. This testing includes how much software is secure from the malicious program, viruses and how secure and strong the authorization and authentication processes are.

It also checks how software behaves for any hackers attack and malicious programs and how software is maintained for data security after such a hacker attack.

#38) Smoke Testing

Whenever a new build is provided by the development team then the Software Testing team validates the build and ensures that no major issue exists.

The testing team ensures that the build is stable and a detailed level of testing is carried out further. Smoke Testing checks that no show stopper defect exists in the build which will prevent the testing team to test the application in detail.

If testers find that the major critical functionality is broken down at the initial stage itself then testing team can reject the build and inform accordingly to the development team. Smoke Testing is carried out to a detailed level of any Functional or Regression Testing.

#39) Static Testing

Static Testing is a type of testing which is executed without any code. The execution is performed on the documentation during the testing phase.

It involves reviews, walkthrough, and inspection of the deliverables of the project. Static Testing does not execute the code instead of the code syntax, naming conventions are checked.

Static Testing is also applicable for test cases, test plan, design document. It is necessary to perform static testing by the testing team as the defects identified during this type of testing are cost-effective from the project perspective.

#40) Stress Testing

This testing is done when a system is stressed beyond its specifications in order to check how and when it fails. This is performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to the system or database load.

#41) System Testing

Under System Testing technique, the entire system is tested as per the requirements. It is a Black-box type Testing that is based on overall requirement specifications and covers all the combined parts of a system.

#42) Unit Testing

Testing of an individual software component or module is termed as Unit Testing. It is typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. It may also require developing test driver modules or test harnesses.

#43) Usability Testing

Under Usability Testing, User-friendliness check is done. The application flow is tested to know if a new user can understand the application easily or not, Proper help documented if a user gets stuck at any point. Basically, system navigation is checked in this testing.

#44) Vulnerability Testing

The testing which involves identifying weakness in the software, hardware and the network is known as Vulnerability Testing. Malicious programs, the hacker can take control of the system, if it is vulnerable to such kind of attacks, viruses, and worms.

So it is necessary to check if those systems undergo Vulnerability Testing before production. It may identify critical defects, flaws in the security.

#45) Volume Testing

Volume Testing is a type of Non-Functional Testing performed by the Performance Testing team.

The software or application undergoes a huge amount of data and Volume Testing checks the system behavior and response time of the application when the system came across such a high volume of data. This high volume of data may impact the system’s performance and speed of the processing time.

#46) White Box Testing

White Box Testing is based on the knowledge about the internal logic of an application's code.

It is also known as Glass box Testing. Internal software and code working should be known for performing this type of testing. Under these tests are based on the coverage of code statements, branches, paths, conditions, etc.

Conclusion

The above-mentioned Software Testing Types are just a part of testing. However, there is still a list of more than 100+ types of testing, but all testing types are not used in all types of projects. So I have covered some common Types of Software Testing which are mostly used in the testing life cycle.

Also, there are alternative definitions or processes used in different organizations, but the basic concept is the same everywhere. These testing types, processes, and their implementation methods keep changing as and when the project, requirements, and scope changes.

Clarifying QA Roles: Making Sense of an Array of Job Titles and Responsibilities

QA roles and responsibilities in software development can be confusing. On message boards, even ones specific to testing, questions such as “What’s the difference between a tester and an SDET?” and “Is an SDET the same thing as an automation engineer?” receive an array of answers. This topic deserves some clarification.

The source of the confusion can largely be attributed to the sheer size and fluidity of the software development industry. Different companies use different job titles for the same roles and there is no authoritative source or reference for the most common or up-to-date descriptions. Many companies influencing the evolution of QA and the definition of roles are not even software-based companies, but rather huge enterprises with large IT departments, adding even more to the variability of job titles and requirements.

QA plays an important role in any company with technology products to release, whether small agile teams or large-scale IT departments with many cross-functional teams working together to develop products and services. QA can be viewed and utilized differently depending on the team size and structure, and is often tailored to the needs of the specific team and organization. QA is also often an entry role to software development, meaning that people in QA sometimes understand less how they fit into the larger puzzle of software development than others might.

So when a worker leaves a QA job at one company and searches for new positions, it can be difficult to determine what they should even search for. A Test Engineer for one company might be called a QA Analyst or QA Engineer at another. While all are titles for a Manual QA role, it might take working at a few different companies before that’s understood. Add other QA roles and title variations to the mix, with the additional understanding that the difference between software development and software testing can get blurry depending on the specific hiring practices and processes in play at a given company, and it can be near impossible to make sense of it all.

Let’s unravel the confusion. Ultimately, there are three main “roles” most commonly utilized to test a product and related systems: Manual QA, SDET (Software Development Engineer in Test), and QA Lead. All three can have different titles assigned to them at different companies (we’ll use QA Engineer for the primary Manual QA title) and might have a mix of responsibilities and expectations within a given organization, but at their core they are distinct. Let’s break them down:

QA Engineer (Manual QA)

Most Common Titles: QA Engineer, Manual Tester, Software Test Engineer, QA Analyst

Core Responsibilities: Manually test any product, service, or system; analyze requirements; write and run test cases (scripts); report defects, and verify defect resolution.

In a large enterprise, manual testers might test APIs, backend databases, management systems, and so on, but most commonly they test front-end products like websites and mobile applications where functionality and user experience is of utmost importance. While manual testers often use tools like web proxies, SQL clients, or debug consoles, most everything is usually done “by hand.”  While the trend is to automate as much testing as possible, there are still many test scenarios that are not easily repeatable (or not possible to automate) and are more efficiently done manually.  There is also no substitute for real user interaction with a product that manual testing provides.

SDET

Most Common Titles: SDET, Automation Engineer

Core Responsibilities: Create automated testing frameworks, analyze requirements, code and run automated test scripts, report defects, and verify defect resolution.

The simplest distinction between SDETs and QA Engineers is that SDETs write code and QA Engineers do not. Creating an automated test framework and writing associated test scripts requires coding ability, not only to test but also to analyze the code of the software developers to determine what/how to test. SDETs are utilized in many different ways depending on a given project. Typically, they are the primary testing resource for web services (APIs) and backend systems like databases. On front-end products, SDETs can be used for anything from unit and integration testing to UI automation. Also, because of their advanced skillsets, SDETs are often responsible for the setup and management of any continuous integration or continuous delivery tools the team may be using. Skilled SDETs also often operate as part of a DevOps team in various capacities.

QA Lead

Most Common Titles: QA Lead, Test Lead, Lead QA Analyst

Core Responsibilities: Determine test strategy and process, manage QA teams, prioritize QA tasks, create status reports, track applicable test metrics, and manage test devices.

QA Leads have a wide variety of job responsibilities because they need to not only handle the day-to-day management of a QA team and potentially interface with external teams, but also to pitch in wherever and whenever needed to keep projects on track. This means that in addition to the core responsibilities listed above, they need to be prepared to do manual testing or possibly automated testing if they have the required skills. For large teams, a good lead can make all the difference between a high-performing team and a struggling one.

On-the-job responsibilities for these three roles generally fall into the descriptions listed above, but organizations can vary the responsibilities based on their specific needs and budgets. At smaller companies it’s not uncommon for all of these responsibilities to fall on one or two individuals. Larger companies are more likely to have some combination of all three of these roles represented on one QA team, and when they do, their projects are often highly successful.

The haze regarding the numerous QA job titles becomes clearer when viewing QA as a family of the three distinct roles discussed above, with most job titles falling under one of the three categories and generally involving the corresponding responsibilities. While organization size, budget and other factors might cause some blending or expanding of the roles, these guidelines can help make sense of the seemingly large amount of confusion about these roles among QA professionals.

How to write a Test Plan?

The Test Plan document describes how the software you will develop will be tested to ensure, or at
least improve, correctness. There are several reasons why the Test Plan should be developed prior
to, or at least concurrently with, the coding phase.
• In large teams, the Test Plan team can and should be a separate entity from the Coding team:
both take their input information directly and only from the Design document, thus, if any
discrepancies arise between a test and the code, this might point out ambiguities in the Design
document, which must then be resolved before the test and the code can be reconciled.
• As an added advantage, having separate teams work on the Test Plan and the Code concur-
rently decreases the overall duration of the development schedule.
• If the Test Plan is developed after the code by the code developers themselves, it is much
more likely that the tests will be written with the code in mind, regardless of what the Design
document says or of what the User Manual specifies. While this is perhaps acceptable for
very low-level unit testing (which might benefit from being aware of peculiar implementation
details that should be stressed during testing), it is not a good idea due to the inherent coder’s
bias: humans tend to overlook their own mistakes.
A Test Plan should address the following testing activities
• Unit testing: to test individual data structures and algorithms (objects and methods).
• Integration testing: to test that multiple data structures and algorithms interface properly to
deliver the overall required functionalities.
• User-oriented testing: to ensure that functionalities and modalities of interactions described
in the Specification document or in the User Manual do indeed function as expected.
• Stress testing: to test whether the implementation is robust enough to support intense use
(e.g., manages large inputs) while requiring acceptable resources (i.e., memory and time).
For each test case, a brief English description should be provided to motivate it. Then, the test
should be specified (as a test driver, a textual input to the program, a sequence of user clicks in a
graphical interface, etc.). Finally, the expected results should be clearly stated, so that a tester can
know whether the test passed or failed.
Unit testing
The plan for Unit testing should specify, for each key class and each method in that class, the set
of actual tests that will be run. For example, for an algorithm that sorts the elements of a set on
which there is an imposed total order, one might want the following test cases:
• An empty set.
• A set with only one element.
• A “typical set” not already ordered (since the elements of a set are inherently presented in
some order to the algorithm).
• A “typical set” already ordered.
• A “typical set” in reverse order.
• A set with contiguous duplicate elements (again, this is meaningful assuming that the set is
specified by presenting its elements in some array or linked list).
• A set with non-contiguous duplicate elements.
In most cases, it also makes sense to test a class or a method for erroneous inputs. For example:
“What happens if the input to a method should be a tree with dynamically-allocated nodes con-
nected through pointers, but the method is instead called on an input which is a DAG or, worse
yet, contains a cycle?”. While perhaps not all erroneous inputs need to be managed gracefully (in
the previous example, it might be acceptable for the method not to terminate if the input contains
a cycle), it is still very valuable for the test plan to document what happens for the various classes
of erroneous inputs.
Since Unit testing is by necessity performed on a portion of the code, it usually requires a test
harness or test driver to call the function or methods under test in a controlled way, provide the
required input, and, if possible, automatically check the expected output.
Integration testing
The plan for Integration testing can be incremental, that is, one might want to test increasingly large
subsets of interacting data structures and algorithms, starting from a few related ones, up to the
entire program. This way, while the targeted code base for Integration testing becomes increasingly
larger, the required test harness might actually get simpler, as the environment required to test
certain portions of the code does not have to be specified in a test harness, but it is actually the
code itself (this is certainly the case in the final integration testing, where the only task required
of the harness is to provide input cases to the overall program and to receive the expected outputs
from it).
One of the aspects that should be thoroughly tested during Integration testing is that the interfaces
between interacting modules are correctly used, or, in other words, that each function or method
is invoked by its callers using parameters that respect the required assumptions.
User-oriented testing
This part of the Test Plan can also be merged with the final portion of the plan for Integration
testing, as they both address the test of the overall software. However, the two aim at different goals,
as their names suggest. Integration tests, even when addressing the overall software product, still
target potential errors that arise when multiple software functionalities or groups of functionalities
interact, so it is oriented toward discovering internal implementation errors. User-oriented testing,
instead, aims at exercising the overall software product to help ensure that the user can interact
with the software as specified (ideally, as specified in the User Manual, which should be already
available at this stage, at least in some rough form).
Of course, when one such test fails, it might still point out an internal error, just as an Integration
test does, but it might also, instead, discover that a required feature was misunderstood or even
completely overlooked and not implemented at all.
Stress testing
This part of the Test Plan addresses the scalability and robustness of your software with respect to
input or problem size. Some Stress testing can be already performed as part of Unit testing. For
example, going back to the sorting algorithm, one might want to perform Stress testing using the
following test cases:
• A very large set that should still fit in main memory.
• An even larger set that will not fit in main memory.
The expected output behavior for Stress testing should not just list the expected output, but also
a rough estimate of the requirements on the resources being stressed (time, memory, or both). For
the sorting algorithm, for example, one should be able to verify that the worst-case runtime is, say,
O(n2), and the way to do so experimentally is to provide a sequence of worst-case inputs of large
size (for timing accuracy) over a range of sizes (to be able to observe the quadratic trend).
For memory, it might be best to add to your software various memory monitors that automatically
collect the current memory consumption and can be used to record the maximum memory con-
sumption, perhaps for each key data structure. In addition, one might want to use an operating
system memory tracking capability to double check that the memory consumption reported by your
program is indeed correct. It should then be possible to turn off these monitors at will, so that,
when running in “production mode”, your software is not slowed down by their tracking overhead.
How to submit the Test plan
All test inputs should be given a meaningful name and be referenced in the Test plan document,
so that the actual test input files can be retrieved by the TA from each team’s svn repository.

How To Change Your Email Signature in Microsoft Outlook 2010

Sometimes, it’s the little things that can give us the most annoyances. As often as software gets updated, things that used to be common knowledge now have entirely new ways of getting done, and the way it used to be doesn’t apply. Something as necessary as changing your email signature, for example, gets lost in the shuffle of new menus and options.

This tutorial will help you to stop hunting and find your way.

How to Update Your Email Signature in Outlook 2010

Step 1 –

Click “File“, then click “Options” in the left-hand menu.

Step 2 –

Select “Mail” from the list of options, then click “Signatures“.

Step 3 –

Replace the existing signature with your desired new one. If there isn’t an existing signature, click “New” and create one.

Saving your email signature in Outlook 2010

In the top-right corner of the signatures box, you will be able to select default signatures and whether to include signatures automatically on replies. Once you are done, click “OK” and your changes will be saved.