Software Testing Knowledge

When you introduce automated tests in your organisation you have to keep in mind that it is not only a matter of choosing the best tool. Such a move also entails many changes in the organizational scheme of the team. There are also many other factors that have to be considered before you start introducing automated tests. How to prepare for it so that your “mission” would not be a failure?

According to the World Quality Report 2018-2019 prepared by Capgemini, end-user satisfaction became an important priority for QA and strategic software testing teams. As we can read in the summary of the report, “Low levels of automation and challenges with test data and test environments are holding back QA and testing efficiencies”. At a time when more and more software is developed and there is a permanent lack of people able to test it, appropriately selected and implemented tool for test automatization is worth its weight in gold. The tool itself is not a guarantee of success understood as an increased effectiveness of the work and test coverage if you don’t take into account the following issues:

## Testing strategy in the project

„Automated tests” is a keyword that describes the whole group of solutions on different levels of advancement. On this market there are available simple extensions for recording tests in the browser, created 10 years ago, as well as state-of-the-art tools based on artificial intelligence. Before you make a decision about using free software you may want to ask yourself few questions.

- What kind of bugs do you want to detect the most?
- What kind of tests do you want to automate (mobile application or the website? GUI or compatibility issues? Security or operating fluency?
- What parts of the project in which you would like to implement automated tests are the most prone to bugs?
- Which bugs in the software that you test would be the most expensive taking into account the end-user satisfaction? (or its lack) Which ones would be the most expensive for the sake of the amount of time needed to fix them?
- What are the security requirements for using such a tool in your organisation?
- How the project management methodology (Agile, waterfall) implemented in your company can determine the scheme of testing?

Answers to these questions could help you select the criteria for the automated tests programme that will suit your projects best.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Who do you want to convince to invest in the automated tests?

Regardless of your choice of the tool, bear in mind that you will not use it alone. Although convincing testers’ team to it would be easy, the managerial team can require hard evidence that this would be a good investment. It seems obvious that before meeting with them it is good to prepare data regarding estimated increase of the testing team effectiveness and enhanced bug detection. The second (and often overseen) factor is the workflow in the project – not only in testers’ team, but also between developers and business unit. If you show how the tool you selected will improve the work (i.e. thanks to the reports that business will surely appreciate, or map of the bugs which will enable for faster submission of amendments to developers) it would be perceived as a big asset.

## Choosing the best tool for your team

List of requirements created by the testers’ team would be a good start; you can also consult it with developers. Apart from precise comparison of the offers from different vendors you can also take into account the following advantages:

- Was this particular tool for automated tests designed taking into account its future users? Is it intuitive?
- Can it – despite its advanced features – be launched from the browser?
- Does it enable you to edit tests and add new parts to them without recording the whole scenarios from the beginning?
- Does it have a built-in modulus enabling for minimisation of so-called flaky tests?
- Does it provide the map of the bugs, thanks to which you can identify the most prone to bugs parts of the code?

Real added value to your research would be recommendations from your colleagues as well as getting acquainted with the demo versions of the tools that you take into account. Read article about features every test automation tool should have.

![bb-7-1.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_7_1_ddd248eaf2.png)
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Who would be using this tool? Is he competent to do it?

Members of the testers’ team differ in terms of competences and predispositions . Some of them are beginner manual testers, others – more experienced – prefer exploratory tests. Some of the automated testing tools available on the market require programming skills on different levels. Not every tester can boast of them. And even if he can, he may not have enough time to programme automated tests. Fortunately, modern tools for automatization available on the market don’t require such skills from the tester – it is good to take a look at these offers too.

## Automated tests – do they pay off?
This question concerns not only the subscription fee for the tool. You should also take into account the cost of time that your employees would have to devote to learn how to use this programme. On the bright side, in your calculations you can also include the benefits such as work acceleration and increased effectiveness of your team.

Introduction of the new tool for automated tests in your company would require a lot of time and effort (i.e. devoted to comparing the offers). Although this task (on condition that it would be done properly) can translate into real improvement of testers’ work and comfort, as well as have positive impact on the overall results of the project. It is worth trying.

large_bb_7_0_62723368a7_3e236eb12b.png

medium_bb_7_0_62723368a7_3e236eb12b.png

small_bb_7_0_62723368a7_3e236eb12b.png

thumbnail_bb_7_0_62723368a7_3e236eb12b.png

bb_7_0_62723368a7_3e236eb12b.png

5 Challenges of Introducing Automated Tests

want-to-introduce-automated-tests-in-your-organization-here-are-5-challenges-that-you-have-to-face

Product

Selenium IDE is a tool for recording and launching application tests. It was created by Shinya Kasatani in 2006 (sic!) and is based on „record & playback” idea, which nowadays is no longer a novelty. The problem with most of the tools available on the market (including Selenium IDE) is not the outdated idea, which basics still can be perceived as elegant, but its realisation. Below we listed the biggest accusations that can be directed towards Selenium IDE and solutions to them offered by the tool named BugBug.

## Generation of improper elements’ selectors

While recording the application tests, the newest version of Selenium IDE is able to generate several selectors for the element with which the interaction was made. The problem is that this tool doesn’t give you the possibility to configure which type (or types) of selectors should be set as default ones. It also prefers wrong approach to the generation of selectors, based on the names of the CSS classes. Nowadays, when CSS-in-JS approach is becoming more and more popular (i.a. due to [styled-components](https://styled-components.com/), which generate random class names), it makes the user responsible for modification of all selectors generated during the recording session. The result is that the work that should be automatically done by the tool is done manually and at a much slower pace by the user.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Solution to the problem provided by the BugBug

During a recording session, BugBug – just as Selenium IDE – generates many selectors for the elements with which interaction was made. The difference is that in this case the user decides about the hierarchy of the generated selectors. It can be easily modified in the configuration of the project:

![bb-blog-6-1.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_6_1_373223ad89.png)

Thanks to this solution you have complete freedom and control over the generated selectors – you just act accordingly to the project requirements. Nowadays, testing in the projects very often is based on the data-test or data-testid attributes, that are also preferred by the BugBug. However, if you have to deal with the older type of the project, you can always prioritize generation of the selectors based on the CSS classes or elements ID. The key here is that the user independently decides what he needs and changes configuration of the project accordingly.

While recording the application tests we are not always sure if the selectors are correct. That is why the BugBug at the first launch and after each change in the test verifies selectors and corrects them if there is such a need – for example if the selector disappeared for some reason (it could be caused by the random CSS classes) or it points to the improper element. Thanks to implementation of these mechanisms interference of the tester with the process of the selectors’ selection is reduced as much as possible. He also saves his precious time, so far wasted for manual searching and creation of the selectors.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Lack of active waiting for the elements (waiting conditions)

Another common problem with the record & playback tools, which concerns also Selenium IDE, is lack of active waiting for the elements with which interaction should be made. In practice it works like that: if the chosen element is embedded on the website (in DOM), Selenium IDE attempts to interact with it, even though it can be invisible, moves, animates or is covered by another element (loading overlay). The result of such scheme of actions are so-called “flaky tests”. This notion defines the tests which once work, and another time they don’t. The reason for such behaviour is very often lack of appropriate waiting conditions for the element with which the interaction is to be made.

## Solution to the problem provided by the BugBug

Creators of the BugBug took into account defects of the tools available on the market and effectively addressed them. On the level of the project configuration you can define waiting conditions that have to be met so that the interaction with the element could proceed:

![bb-blog-6-2.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_6_2_1eed216be1.png)

The global configuration of the project is inherited within all steps of the test. Of course there is also possibility to overwrite this configuration on the level of the single step. You can also add additional conditions there, such as waiting for the page reload:

![bb-blog-6-3.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_6_3_ed8486fb8b.png)

Thanks to this solution BugBug emulates the human behaviour, what means that it waits for an appropriate moment to proceed with the particular step of the test. The tool can actively wait when:

- element animates or changes its characteristics (CSS animations and transitions): the tool identifies that the element animates/moves and waits till the end of this process.
- element is invisible: BugBug’s mechanism is able to assess whether the element is in fact visible for the user. If so, it proceeds with the planned steps.
- element is covered by another element.
- element is inactive.
- element changed its position: the tool is able to identify change of the element’s position while it is proceeding with the step. In such a scenario the interaction is repeated.
 competitors.

Implementation of all the mechanisms listed above reduces the risk of „flaky tests” to minimum. Thanks to that BugBug offers much more stable tests than its competitors.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Misleading process of replaying the steps (with the use of JavaScript)

Selenium IDE as well as most similar tools available on the market proceeds with the steps of the test that only partially emulate behaviour of the average user. In practice it means that tests recorded this way can behave very unpredictably, leading to serious errors. It would be easier to explain with the use of the specific example:

The step click on any „Log in” button realised within Selenium IDE would trigger the following event in the JavaScript browser:

- click

## Solution to the problem provided by the BugBug

The same step realised in BugBug results in the sequence of the following events:

- mousemove
- mouseover
- mouseenter
- mousedown
- mouseup
- click

The difference described above stems from the constraints of the Selenium IDE architecture, which can emulate the user’s behaviour only with the use of JavaScript. Architecture of the BugBug and implementation of the [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/) gives it full control over the browser. Thanks to it the behaviour of the user can be accurately emulated. It is crucial in testing contemporary, very extensive and complex applications (Single Page Applications).

## Application tests are not launched separately

Majority of the record & playback tools has a problem with performing the tests separately. It results in a situation, when launch of the particular test impacts another one. The problem resides in the fact that cookies or localStorage mechanism in the browser are shared between windows and tabs. When you use Selenium IDE, you have to always delete cookies (or localStorage) and remember about the necessity to clear this data between the tests.

## Solution to the problem provided by the BugBug

Despite the fact that the problem described above is simply burdensome, it also causes flaky tests. To prevent this, application tests in BugBug are by default performed separately with the use of Incognito mode in the browser. Thanks to that QA who builds the tests doesn’t have to remember about cookies, localStorage and other data sharing mechanisms in the browser. Tests are isolated regardless of whether you launch them in the browser or in the cloud.

![bb-blog-6-4.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_6_4_136c914e62.png)

## Launching tests in the cloud is impossible

Selenium IDE was created many years ago, when cloud and SaaS services weren’t so widespread as they are nowadays. As a result, Selenium IDE functions only as the browser ad-on and doesn’t offer testing in the cloud. Tests created with the use of Selenium IDE can be exported to the chosen programming language and then launched within your own infrastructure (or with the use of some commercial solution).


Solution to the problem provided by the BugBug

BugBug from the very beginning was designed as a tool that aims at supporting the whole testing process (end-to-end). It enables for:

- [recording and easy editing of the tests.](https://docs.bugbug.io/core-features/recording-the-tests)
- launching of the tests locally, within user’s browser, in order to verify the tests.
- planning and launching application tests in the cloud (through www interface as well as CLI tool).

Look in our previous post to see [10 features every test automation tool should have](https://new.bugbug.io/blog/10-features-every-test-automation-tool-should-have/).

Thanks to that you receive one, integrated tool that can be used for creation and launching of the tests as well.

![bb-blog-6-5.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_6_5_94ab9b819c.png)
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Lack of support for the Page Object Model (POM) pattern

Page Object Model (POM) is a verified design pattern for end-to-end tests, which enables you to freely re-use steps within the tests, thus simplifying its maintenance. This pattern bases on creating group of steps that represent pages of tested Internet application as so-called Page Object. Thanks to that after you create “Log in” Page Object you can use it multiple times – in each test that requires logging in. If the log in form changes, it suffices that you fix the test in one place – as a consequence all tests based on “Log in” Page Object would be changed accordingly.

Unfortunately, Selenium IDE doesn’t support creation of the tests based on the Page Object Model. Steps in each test are strictly assigned to it. When you have many tests scenarios that use the same steps, if one step stops working, you have to fix it separately in each test.

## Solution to the problem provided by the BugBug

BugBug was designed to support Page Object Model pattern from the very beginning. This tool enables you to freely group the steps in tests and use them as re-usable elements. What is more, a natural consequence of such an approach is the possibility of creating visualisation of the tests in one, coherent graph. Such presentation of all tests gives you clear information about which business paths within the project are covered with end-to-end tests.

![bb-blog-6-6.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_6_6_bf3d39ac25.png)

## Summary

![bb-blog-6-7-768x480.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_6_7_768x480_7b04bf2e6c.png)


large_bb_blog_6_23f3987e2a_a8876041ba.png

medium_bb_blog_6_23f3987e2a_a8876041ba.png

small_bb_blog_6_23f3987e2a_a8876041ba.png

thumbnail_bb_blog_6_23f3987e2a_a8876041ba.png

bb_blog_6_23f3987e2a_a8876041ba.png

Application Tests: BugBug vs Selenium IDE

application-tests-bug-bug-vs-selenium-ide

Automated testing became an indispensable part of the software development business. It is also given specific business objectives to attain. Which trends will dominate automated testing in 2021 and determine who will get the biggest market share?

The rapid development of the Agile and DevOps methodology integrated automated testing into Agile (which also means accelerated) process of the code generation. One of the direct consequences of such a change was so called shift-left testing, which means moving the testing to the earlier phase of software development – it can be even gathering of the business requirements. Before “tha Agile era” testing could start only when the final effects of the developers’ work were available. It resulted in the higher costs of the maintenance and bug-fixing (because some of them were overseen in the earlier phases of the work). Not to mention huge losses of the company’s image and outflow of the customers disappointed with the product. It therefore comes as no surprise that the executive IT management surveyed in “The World Quality Report 2019-2020” recognised “contribution to business growth and business outcomes” as the most important objective for testing and QA in 2019:

Chart 1. Answers of the executive IT management concerning objectives for testing and QA in 2019:

![bb-blog-5-1.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_5_1_1081b97858.png)
Source: The World Quality Report 2019-2020

However, testing in 2013 (when Agile started to gain in popularity) and now are two different worlds. What will contribute to increasing business results after Agile became an indispensable methodology of work in the software development business?
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Automatization of the new generation

In recent years, the software testing market has been experiencing a real boom and – according to the latest analysis – it is only the beginning. As stated in the Techavio report “Software Testing Services Market by Product, Geography, and End-user – Forecast and Analysis 2020-2024”, it is expected to grow at an even faster pace – with CAGR at the level of 12,62%. Read more about business consequences of this phenomenon. The necessary element of this process is development of the automated tests, which supports changes taking place thanks to the implementation of the Agile and DevOps methodology. Currently, the tools which offer only simple functions such as recording the tests performed on the website or in the app, are insufficient. To keep up with the rapid changes in the development environment there is a need of the software which will enable for automatization of the most actions taken by the testers. Additionally, such a tool should be easy to handle for the person without any programming skills and offer the feature of quick identification of the most bug-prone parts of the code. Check out 10 characteristics that the new generation testing automation tool should offer. Automated testing ceased to be only the tool which supports testers in their work – it became an indispensable element in the end-to-end testing process.

## Artificial intelligence (AI) and machine learning (ML)

Although they became very popular and catchy slogans, the newest Techavio report “Software Testing Services Market by Product, Geography, and End-user – Forecast and Analysis 2020-2024” confirms that the testing sector has just started making use the benefits which stem from this technologies. The results are encouraging, and the forecasts concerning the pace of development of the testing market (according to the TechWiz its value in 2025 could reach 190,6 billion USD) confirm its great potential. As we read in the Techavio report, implementation of the artificial intelligence in the testing process is crucial in striving for the smart testing, which means ensuring maximum effectiveness of the testing from the earliest stages of the code creation. What is important, QA specialists and testers who will be introducing the artificial intelligence in the company should receive appropriate training – it is necessary to fully benefit from the possibilities provided by this technology. Companies which will be first to discover such a need would gain a huge competitive advantage. The experts quoted in “The World Quality Report 2019-2020” indicate the complementary role of machine learning in the process of enhancing quality of the testing with the utilisation of the AI. How could it happen? As stated in the report, “As organizations grow accustomed to machine learning, they will increasingly understand its distinction from artificial intelligence. They will see that in order for AI testing to be effective, it needs access to the right data – and machine learning can provide this, by processing records in volume, thereby helping to identify and optimize test cases”.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Big Data technology

It is another shining example how testing is intrinsically linked with the latest trends in the world of the software and new technologies, as well as with the e-commerce market. Big data is used in the development of the programmes for an automated testing (i.e. with the use of the ML described above), although the data sets also require testing and continuous monitoring. Big online shops or the software for health systems are great example here – such a huge data conglomerates require testing on each phase: introduction, processing, migration, performance and speed. Along with the progress of digitisation process, which concerns each line of business, the demand for such services will be growing.

## New challenge – internet of things

“The World Quality Report 2019-2020” mentions quick development of the testing in IoT in the following industries: car, energy and telecommunication. The latter would face a great challenge in the coming years: consequences of the 5G technology implementation. As piszą Darren Coupland (Sogeti) and Mandan Sundaraju (Capgemini) write, “This will create a new quality assurance (QA) dynamics. All these new use cases will need to be validated end to end. How so? Because the increase of internet of things (IoT) developments implicit in 5G has implications not just for IT applications, but also for the physical devices themselves. For example, it’s not just the app managing the traffic light that needs to be tested: it’s also the traffic light sensor itself”. Test coverage of the smart devices interconnected with the applications became a necessity in the times of the rapid expansion of the IoT market. As the Testing Whiz reports, in 2016 its worth was estimated for 6,4 billion USD, in 2020 – for over 20 billion USD.

## Blockchain technology as a new business model

Blockchain solutions are being used increasingly with regard to the processing and protection of the data. The report “5 Blockchain Trends for 2020”, prepared by Deloitte, reflects its growing popularity and scope of use:

Illustration 1. Conclusions for the coming year with regard to use of the blockchain technology in the business.

![bb-blog-5-2.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_5_2_09dd6a8b48.png)

In the coming 12 months implementation of the blockchain technology is planned to be increased in the following sectors:

- technology, media and telecommunication (from 45 to 49 pct.)
- energy (from 37 to 43 pct.)
- industry (from 40 to 43 pct.)
- life sciences and health care (from 36 to 41 pct.)
- finance (from 33 to 38 pct.)
- professional services (from 24 to 33 pct.)
- industrial and construction services (from 32 to 33 pct.).
- 
Testing plays crucial role in the blockchain-based products, because it monitors its security level and effectiveness of data-gathering. In these fields there is no room for error.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## The increased significance of the security testing

The statistics presented in “The World Quality Report 2019-2020” confirm this trend. The survey respondents indicated that matters of security and risks are the most important for the IT strategy adapted by the company. The security testing scale in the cloud computing environment increased from 42 to 57 pct., what reflects development of the securities and the way such tests are performed, as well as adaptation of this line of automated testing to the fast pace of work in Agile methodology, because testing in the cloud enables for quicker implementation of the changes and reaction to them. In order to ensure the maximum coverage of security testing, the authors of “The World Quality Report 2019-2020” recommend introducing it on the earlier phases of the software development and carry it out with the tools for automated testing. What is even more interesting, the level of automation in security testing is surprisingly low – it discharges only 13 pct. from this kind of tests. However, if you look at the weighting attached to the particular aspects of security in the process of the software development, the increased significance of security testing seems inevitable:

Chart 3. Ranking the importance of certain aspects of secure development strategies.

![bb-blog-5-3.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_5_3_36f89419ef.png)

## Performance engineering as an essential mind-set and way of working

The time when automated testing and software development consisted only of delivering the specific solutions, and when each team had been working on its task separately from the other, can be described as the programming stone age. Nowadays the measure of success is creation of the product that all teams had been working on together. All people involved in the project (business line, project managers, developers, QA, testers) from the very beginning get acquainted with the business requirements and the needs of the end-user. They ask questions and talk about possible solutions. Thanks to such a workflow it is possible to implement many changes at an early stage, which prevents from the irreversible (or highly costly) damages that can occur after the deployment. In this way the performance engineering perfectly dovetails into the Agile objectives, because it postulates to look at the product from the meta-level and requires all teams to closely cooperate with each other. The effects are astonishing: the products that were created in this approach have a great market value in terms of the software, hardware, security, UX, effectiveness and performance.

large_bb_blog_5_5592be0c31_93a6f3e3c3.png

medium_bb_blog_5_5592be0c31_93a6f3e3c3.png

small_bb_blog_5_5592be0c31_93a6f3e3c3.png

thumbnail_bb_blog_5_5592be0c31_93a6f3e3c3.png

bb_blog_5_5592be0c31_93a6f3e3c3.png

7 Trends in Automated Testing in 2021

7-trends-in-automated-testing-that-will-dominate-in-2021

There are many test automation tools available on the market, but there is still a need for the “appropriate” ones. What does it mean? What features should the testing software have to meet the real needs of testing teams?

In the [World Quality Report 2019-2020 study](https://www.capgemini.com/pl-pl/raporty/world-quality-report-2019-20/) conducted by Capgemini, questions were asked about the greatest challenges related to achieving the level of test automation desired by testers and QA. It turns out that since 2018 the percentage of respondents who say that “They do not have the right testing software” (42 percent) has not changed. More than a third of them said they use too many automation tools. There are many voices on blogs and internet forums, which the software available on the market often endorses with the words: “Cool by design, just a pity that it doesn’t work” or “Why do I have to bother with functions from the previous era? We’ve previously mentioned some of these features in our post about testing. So what should not be missing from a tool of the 21st century?
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-


![bb-7-1.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_7_1_ddd248eaf2.png)

## Reusing the same steps in different tests

This postulate will be understood by anyone who recorded 150 test scenarios, which differed only in a few nuances in the final stages, but each time required a login path, registration or any other repetitive activities. This is a pure waste of time, unnecessary frustration and a burden on the team’s efficiency. A tool adequate to the needs should provide a module that allows the use of the same step (e.g. logging into the system) in various scenarios, without the need to record it each time. Such functionality has another additional benefit – in the event of an error in any of the steps, its repair will be visible in each test scenario where the step was used.

## Free edition of already recorded tests

It is also a problem for testers who use tools to record test scenarios. In the case of iterations, which are the order of the day in teams working in Agile methodology, it is necessary to re-record the test scenario from start to finish. However, there are several tools on the market that allow you to make changes without having to repeat the entire procedure from the beginning. A useful function is also “overwriting” steps to already existing scenarios.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-


## Lack of coding skills should not be an obstacle to the free use of the testing software

Many companies probably remember the pursuit of automation engineers, who were supposed to be a dream come true about test creativity and developer efficiency. Unfortunately, such people are real “specimens” on the market, and in times of increased demand for testing services, programming skills are not as important as the right approach and experience. The test automation market should also follow this trend and propose tools with built-in modules that previously required knowledge of programming languages, such as the Page Object Pattern described in point 1.

## Testing software: possibility to edit the code of test scenarios

The fact that a given tool can be used without programming skills does not mean that it should not allow interference in the code of test scenarios. Despite the most sincere intentions, the creators of any tool are not able to predict all the situations that the testers will face, so the possibility of editing the code of the scenarios prepared with a given tool should be indisputable.

## Applying appropriate conditions for the recorded scenarios

Test automation tools that can be safely called dinosaurs require the user to enter a pause between individual steps or have an automatically set waiting time between moving from one stage to the next. Intelligent tools record page reload or add conditions that allow you to proceed to the next step. It all happens automatically – without having to manually set the appropriate parameters after each step in each test scenario.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## The ability to use the testing software from any browser and in the cloud

[SaaS](https://www.oracle.com/pl/applications/what-is-saas/) solutions are valued for their flexibility and efficiency. Their use, however, does not exclude even more far-reaching facilities in the form of the possibility of launching a given tool from any web browser. Thanks to this, the entire testing process is incomparably faster and easier – you do not have to wait, for example, for all the reports in the cloud to load, and you can start running a given test scenario right away.

## Automatic reports

The tester should immediately be informed about the types of errors and their areas of occurrence, and should be able to sort by test scenario type / functionality / error type.

## Access to the bug map

The bug map is a functionality offered by the most modern test automation tools. Thanks to it, it is possible to precisely locate those areas of the code that can generate the most errors, which is very useful, among others. for regression testing. It replaces tedious exploratory tests of the entire product and allows you to focus on those areas that generate the greatest risk before the next implementation.

## Working in the CI/CD model

The increasing popularity of Agile and DevOps methodologies has imposed a fast pace of work not only on programmers – also testers should be able to quickly adapt to changes and maximize their efficiency. A test automation tool tailored to these needs should enable easy integration with any system via API and, consequently, quick test launch. Parallel testing should also be a standard.

## UI and UX design

Looking at test automation tools from 10 years ago, one can get the impression that they were created with the assumption that an aesthetic and useful interface is intended only for the end customer, not for the person who has to provide/test it. Fortunately, over time, the vendors of this software saw the business value of UX design in their own projects. The easier it is to navigate and the more intuitive the test tool is, the greater the efficiency of testing. One would like to say – the tester is also a human! Fortunately, more and more producers do not ignore this rule anymore.


large_bb_blog_4_ad6d70e9b2_c672b9a3d0.png

medium_bb_blog_4_ad6d70e9b2_c672b9a3d0.png

small_bb_blog_4_ad6d70e9b2_c672b9a3d0.png

thumbnail_bb_blog_4_ad6d70e9b2_c672b9a3d0.png

bb_blog_4_ad6d70e9b2_c672b9a3d0.png

10 Features Every Test Automation Tool Should Have

10-features-every-test-automation-tool-should-have

One often hears an opinion that role of the tester in the IT project is undervalued or marginalised. That developers treat him as the person who at all costs wants to criticise the code. Some projects managers complain on the delays connected with the amount of time that testing requires. These are – to a large extent – damaging stereotypes, which come from the times when role of the tester only started to develop. How does it look in the mature IT team?

## Role of the tester in the project

Phrase “in the project” is key here. Tester is not an island in the most distant part of the office. It is a person who actively participates in the meetings of the whole team, which consist of developers, analytics, project manager and product owner. Depending on the specifics of the work that needs to be done, in the same group you can also find graphic designer, ux designer and other roles that are in demand. Tester stays in contact with all these people and communicates with them on the daily basis; he also takes part in most of the meetings. An exception is so-called independent tester, hired to test application that has already been created. He is purposely “protected” from contacting the business team so that he can keep fresh perspective. In that way the team can obtain suggestions concerning the way the product works from the person who doesn’t know the requirements according to which it was created. Sometimes such a job is done by the whole team of independent testers. In this article we will focus on the work of the tester in the IT project employed in the software development company, who from the very beginning participates in the creation of the software. In this case very significant for the way the tester’s role is structured is methodology of the work that particular IT team embraced.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Role of the tester in the scrum

[Scrum](https://www.scrum.org/resources/what-is-scrum), i.e. the so-called Agile approach to project management, is currently one of the most popular and frequently used methodologies in the modern IT teams. Its opposite is so-called waterfall. Simplistically, it aims at planning the work of IT team (which should effect in the product ready to use by the customer) so that from the very beginning each phase of work is clearly defined, without possibility of implementing major changes. In effect tester obtains product ready to go, already after the implementation phase. Scrum in the Agile approach divides work in the project into smaller phases (so called sprints), so that a product is created “in parts”. It enables i.e. for modification of requirements formulated in the beginning, when work on the product just started, and quick reaction to mistakes/bugs can be identified later. For tester the most obvious consequence of this approach is that he starts working not on the already created product, but on its part – i.e. specific functionality, which developers commited in sprint.

![bb-blog-3-1.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_3_1_42ba0a462d.png)

## Role of the tester in the IT project – what are his tasks?

What are the specific tasks assigned to tester? These are the very basic ones:

- writing the test scenarios,
- performing the tests according to the scenarios designed earlier,
- creating bug reports (and adding them to the backlog),
- preparation of the testing documentation,
- if automated tests are the case – writing them.

It would appear that these tasks could be easily performed by one person alone and our previous claim, that the teamwork is crucial for the tester, was highly exaggerated. Nothing could be more wrong. Of course, each company sets its own rules and has different approach as to how tester’s work should be organised. Although our long-term experience shows that the more testers are included in the work of the whole team, the better for the product that is created in this way. In the scrum testers get acquainted with the product documentation and closely cooperate with analysts, who gather requirements for the application from the client and present the way it should work. Sometimes already at this stage tester discovers a mistake or lack of precision in the documentation, which could later affect the way product is created.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Tester in the project – renaissance man?

A little bit. A good tester will not only study diligently the technical documentation, but also conduct thorough market research (if he is not a specialist in his branch). Thanks to that he has wide knowledge about state-of-the art technological solutions and he can suggest viable changes concerning product design or broadly understood UI/UX design. It can happen during direct talks with developers and UX designers or 15-minute meetings of the whole team (characteristic to scrum), when each member of the team gives update on his work.

Based on his professional knowledge or bugs identified in the particular phase tester can inspire the product owner as well as developers to act. Contrary to prevailing stereotypes, developers often appreciate testers’ suggestions, because they enable them to objectively assess the work already done and take on a new perspective on solving the problem. These remarks are different than standard code review, which focuses more on the technical issues and is performed by another developer. Offered by tester approach: “how should it work” and “in this part this functionality can perform better, because later it generates errors such as…”, is also very important in programmer’s work. Such proactive, focused on finding new solutions attitude is required in projects conducted in scrum.

## Role of the tester in the project – why his time is so valuable?

In the Agile approach there is a popular saying: „Fail quickly. Fail often. Fail cheap”. This methodology aims at quick bug identification, what in a broader perspective enables for delivering a high class product. Its maintenance would not generate additional costs because all potential risks had been identified and addressed when product was created. That is why role of the tester is crucial here. The most frequently used types of tests in this job are:

## Exploratory tests

Exploratory tests mean testing on “living organism”, without sufficient documentation. In this phase you get acquainted with the application in the testing environment. It is rather starting point for creation of the suitable testing scenarios, in which your knowledge and experience play very important role. That is why novices are almost never engaged in these tasks. The undoubted advantage of exploratory tests is that they offer plenty of potential for detecting bugs that were overseen while creating requirements for the product and new user stories.

## Regression tests

They are performed after each deployment. They shall check whether after the implementation of the new functionality the whole application (including solutions added earlier) works properly. This group of tests also includes smoke testing (assessment if main functionalities of the application work seamlessly after the implementation) and sanity testing (tests performed after the application had been debugged). This type of tests has plenty of potential for wasting testers’ time, therefore it can be easily replaced with automated tests. Thanks to them tester in the IT project can focus on creating new user stories and searching for yet undiscovered bugs instead of rather tiring research of the “old” parts of the code. Check out first Polish tool for automated tests – BugBug

## System acceptance tests (SAT)

System acceptance tests it is a real cherry on the cake in tester’s work. Its aim is not discovering the bugs, but confirmation that product that has been created functions perfectly and in accordance with client’s requirements.

## Summary

As you can see, in a well-planned project work tester cannot be absent. His role is very important – there is a saying in the scrum that every member of the team is a developer, and it is not without a reason! It means that each person from the team shares equal responsibility for delivering the product perfectly adapted to the assumptions. And without the tester it is simply unattainable!

large_bb_blog_3_ff17ffebc0_d15e561502.png

medium_bb_blog_3_ff17ffebc0_d15e561502.png

small_bb_blog_3_ff17ffebc0_d15e561502.png

thumbnail_bb_blog_3_ff17ffebc0_d15e561502.png

bb_blog_3_ff17ffebc0_d15e561502.png

Role of The Tester in The IT Project

role-of-the-tester-in-the-it-project-what-does-it-entail

Software testing industry has no choice – a new era is coming and it will determine development of the whole branch and its products such as web applications testing software. This new trend will also positively impact the management of IT departments. 2021 can be a breakout year in this respect.

For several years we have been witnessing a growing disproportion between development of project management (including programming) and the situation of testers in the IT industry. The latter are often excluded from the benefits that Agile, DevOps and CI/CD entail. It does not mean that testers do not work in these methodologies or that they are not part of the teams that implement them. According to the report „State of the Agile”, published in 2019, testing and web applications testing was placed at the top of the activities which are managed this way:

![bb-blog-2-1.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_2_1_5f1b995952.png)

Within 13 years Agile from enthusiastically received novelty has become a dominating style of IT project management. In 2019 it was used in 97% of the surveyed businesses. DevOps technology was combined with Agile (or it was intended in the next 12 months) in 73% companies. Among benefits that Agile implementation brought they mentioned, among others, acceleration of software delivery, enhanced ability to manage changing priorities and increased productivity:

![bb-blog-2-2.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_2_2_6630bd8462.png)

If you ask testers about the consequences of Agile implementation, they would probably agree with the above mentioned benefits concerning management of the workflow. However, in terms of their responsibilities, conclusions would not be so encouraging. And it is not the fault of Agile itself – it is a systemic problem, which was only exposed by this particular methodology.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## How changes in the IT industry influenced the situation of testers?

They caused them to have much more work with the limited resources. Increased productivity of programmers provided testers with much more code to check, which makes web applications testing longer. Concurrently, their staff as well as software tools resources have not changed. It is also widely known that tester/QA’s positions are significantly less occupied than developers’, what was confirmed by StackOverflow survey from 2019, illustrating employment in the IT sector:

![bb-blog-2-3.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_2_3_fa7dae83da.png)

Year by year the number of employed as testers/QA increased by 1,1%. It is not much in comparison with robust growth of the programmers job market. Unfortunately, this situation has a negative impact on the whole IT sector, which suffers from the lack of adequate test coverage known as “testing gap”. It was first described by Jason Arbon in 2017 in the article AI for software testing”. He pointed out that the complexity of code and new products grows exponentially, but the increase of test coverage grows linearly.

![bb-blog-2-4.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_2_4_02c5d2ecb0.png)

Source: Jason Arbon

In practice it means lack of adequate test coverage of newly implemented products or their selective testing (often with the use of exploratory tests). For some of the services/applications it could result in disappearance from the market or at least cause severe image losses. That was in the case of Uber company, which created an app for automatic car driving. Undetected bug cost the life of an USA citizen, what sparked a huge media storm.

Web application testing is starting to be set aside. According to the research conducted in the United Kingdom by Diffblue, as much as 42% developers resign from writing tests for the sake of faster product implementation. Experts from Softwaretestinggenius calculated that direct costs of testing constitute as much as 25% of the whole project budget. Indirect costs, including consequences of undetected bugs, double this figure!
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Better web application testing = better quality products. How to do it?

Invest in appropriate tools, which will take the burden off the testers and enable them to optimise their work. The good news is that internationally things are quite busy. In Techavio report “Software Testing Services Market by Product, Geography, and End-user – Forecast and Analysis 2020-2024” experts anticipate that testing industry will grow 12,62% per year. The lead in terms of pace of development should take Asian countries, South America and Australia:

![bb-blog-2-5.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_2_5_35f6065999.png)

Source: Techavio.com

Interestingly enough, North America should be responsible for 41% of growth in the whole sector. Its main driver would be the mobile app market, which for the sake of constant introduction of the new features and rapidly changing user requirements undergo continuous changes. This phenomenon is also visible in Poland, where the scale of mobile devices use is constantly increasing:

![bb-blog-2-6.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_2_6_4ecc0a5f6d.png)

## New trends in the testing industry – what quality would they bring?

We observe an increase in the amount of code provided for testing, as well as in demand for mobile products (not only – websites and e-commerce services are also thriving). Till now the common response to these challenges were automated tests. Although the tools that provide them are indispensable in the tester’s work, unfortunately many of them do not always correspond to rapidly changing customers’ expectations. Some of them were created several years ago and were a huge help in less dynamic circumstances – good examples could be commonly available in such software functions of recording tests. In a dynamically changing Agile environment, where new functions are often added with each sprint (or once established ones are modified), older tools do not enable for easy change of testing parameters. In practice it comes down to the necessity of recording each step from scratch, what loses the purpose of automation, that is diminishing the amount of work that has to be done manually…
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## New trend no. 1: Page Object Pattern without programming

Page Object Pattern is a notion well known by test programmers. Very briefly, it allows to group elements in separate classes so that the change in one of them does not impact remaining parts of the website. An example can be a log-in page, where particular fields (e.g login, password, “log-in” button) constitute distinct components. Thanks to that in the case of the malfunction in any of them it is possible to quickly implement necessary adjustments without interference in the whole code of the website.

New tools for test automation would enable the implementation of solutions such as Page Object Pattern without necessity of programming. Each element of the website (e.g already mentioned “log-in” button) would be available as a separate graphic element, which can be freely utilized according to the needs of different tests. Referring to the log-in website: if the test scenario includes it, it could be quickly added using drag-and-drop function from the main panel. Such a solution has one big advantage: if any of the elements breaks down, it could be easily fixed in all scenarios at once just by implementing changes in one place, because update is made in all tests that this particular element was used. Hence we can officially announce the end of an era when tests had to be recorded from scratch each time errors occurred in any of their elements.

## New trend no.2: possibility of editing once recorded tests

Complete freedom and maximum speed are the wave of the future in creation and editing of tests. Till now modification of the already created scenario of automated tests was possible only after the test was recorded once again from the beginning after the end. New generation tools would enable not only for editing particular elements of the test that has already been recorded, but also for adding new parts to it at any time.

## New trend no.3: great UX/UI design

It is only a matter of time when we will reminisce about interfaces of the “old” programmes for test automation with the same tenderness as one that accompanied transition from Pegasus to Playstation. UX and UI design should not be overlooked in tools for people, whose task is to ensure the best experience for the end-user! This paradox is indeed an old reality: for several years testers have been working on programmes, which graphic design epitomises trends from the last decade… It also influences the quality of their work and it is great news that there are tools on the market that aim at changing this situation.

## New trend no.4: launching highly-specialised tests from the web browser

Cloud solution does not exclude fast access to the tool from the web browser – this motto would guide authors of state-of-the art programs for test automation. Tester does not have to acquire advanced knowledge about programming nor technical skills of administrators: installation of the web browser plugin should suffice for effective work. The same applies to test launching: new generation tools would enable its start, test recording and its instant modification exclusively from the web browser. Testers no longer have to wait for test launch and reports from the cloud – they can act immediately at the minimum technical requirements.
->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## New trend no. 5: real, not fake, reliability and stability

There are many tools that promise a lot, but in practice are disappointing and give testers a feeling of wasted time. Users that felt let down wrote several articles about such tools – here is an example». The future belongs to these test automation tools, which will give testers feeling of control and freedom in terms of taking action, concurrently delivering what they have promised in specification and marketing materials.

![bb-blog-2-7.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_blog_2_7_6bd4ef461b.png)


Our app is a [modern software tool for testers and software developers](https://bugbug.io/) that allows recording, editing and running reliable end-to-end tests for web applications.





large_bb_blog_2_68c7cb0029_9b87020ac0.png

medium_bb_blog_2_68c7cb0029_9b87020ac0.png

small_bb_blog_2_68c7cb0029_9b87020ac0.png

thumbnail_bb_blog_2_68c7cb0029_9b87020ac0.png

bb_blog_2_68c7cb0029_9b87020ac0.png

New Era in Testing Industry – Trends in 2021

new-era-in-testing-industry-which-trends-will-dominate-in-2021

Blog about test automation

Features

Pricing

Roadmap

Integrations

Case studies

Privacy policy

Terms of service

About us

Careers

Book a demo

Contact

Get more tips and product related content. Zero spam.

Don't miss any updates

Automate web app testing easier than ever. Without excessive costs. Faster than coding. Free forever.

End-to-end testing made simple! BugBug is a new, more intuitive tool for test automation of web apps. Get all the benefits of test automation without hiring new people or infrastructure changes.

BugBug.io | Intuitive and reliable test automation for startups

large_opengraph_image.png

medium_opengraph_image.png

small_opengraph_image.png

thumbnail_opengraph_image.png

opengraph_image.png

Updates

Guides to automation

[TABLE_OF_CONTENTS]

Compatibility testing is non-functional testing, which means it focuses on such aspects as the reliability and usability of software applications. Thanks to focusing on the compatibility of the software, you can make sure that your app will work as expected on different hardware and software configurations.

You can say that there’s software compatibility when various modules and components of software work together and exchange information to produce expected results that satisfy the user of the software. In other words, if an app works with other apps, systems, and hardware doing what it was created for, it’s compatible with them.

## Software compatibility testing is important, but what is its purpose?

As a part of non-functional software testing, compatibility testing is a method that allows you to check if an application or software works correctly with different software and on various hardware configurations. The goal of compatibility testing is to ensure that there will be no problems when your app runs on a specific device, platform, or together with other apps. An incompatibility issues will result in bugs and problems that you can detect thanks to testing and fix early in the process.

## Key objectives of compatibility testing process

- The key objectives of performing a successful compatibility testing process are:

- Checking if the software is compatible across various platforms, devices, operating systems, or hardware configurations.

- Finding problems and fixing them before the software is released.

- Improving user experience since more users with different configurations can use an app that has good compatibility.


->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Types of compatibility testing

There are two main kinds of compatibility testing: backward and forward compatibility testing.

### Backward compatibility testing

It's when you check if your app works on older hardware or previous versions of operating systems (the latter is often referred to as operating system compatibility).

### Forward compatibility testing

It’s the process opposite to that of backward compatibility testing as it consists in ensuring that your app works correctly on new platforms and hardware.

Also, we can distinguish more specific subtypes of compatibility testing like the ones discussed below.

**1. Browser compatibility testing**

Making sure that your website or web app works correctly on various browsers is highly important given how many browsers there are. It usually involves checking the layout and features on such popular web browsers as Chrome, Edge, Safari, and Firefox.

**2. Network compatibility testing**

Most apps today use networks and connectivity to function properly. Even if your software doesn’t require an internet connection to run, some features, such as updates may be unavailable if the app isn’t connected to the internet. For this reason, it’s essential to check if your app is compatible with different network configurations and different conditions, for example, low download/upload speeds or latency issues.

**3. Device compatibility testing**

People will use your app on such devices as phones, tablets, and notebooks. Different devices have different operating systems, hardware configurations, and screens. If you offer your app for many types of devices, it’s vital to make sure that you have dedicated versions of your app that have been thoroughly tested on each platform.

**4. Mobile compatibility testing**

This kind of compatibility testing concentrates on mobile devices. As mobility is highly important for modern users, you should make it a priority too.

**5. Software compatibility testing**

Software interactions are not uncommon. For example, two different antivirus applications won’t get along too well. You should check if your software is compatible with other popular apps that people may regularly use.

**6. Version compatibility testing**

Apps get updated frequently these days. It’s important to know that after an update, all the features of your app will still be working. You’ll need to check, for example, libraries, app components, and other elements that might be affected by updates.

**7. Database compatibility testing**

As applications often store their data in databases, you’ll have to make sure that your software works well with various databases. The testing focuses on checking how your app handles queries and how it interacts with different databases.

->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Key components of compatibility testing

### Test environment setup

It’s important to make your test environment mimic that of production. To do that, you have to make sure that your hardware, software, and data are identical or at least similar to those used in the production environment.

### Test case design and execution

You’ll need to prepare a set of tests to check the compatibility of your software. First of all, you will need to list elements that you’ll have to test. Secondly, you’ll need to establish what the prerequisites for testing are. In other words, you’ll have to determine such conditions as hardware and software configurations. Finally, you’ll prepare the test cases for each defined testing condition. Once you’ve completed these steps, you’re ready for test execution which involves reporting, tracking, and managing the detected bugs as well as retesting and reporting after you’ve finalized the test execution stage.

### Test coverage considerations

Determining what test coverage should be is vital as it helps to make sure that you can identify all the compatibility problems and find solutions for them. It involves establishing what the target configuration will be (including hardware and software), specifying the requirements that need to be met, and understanding the software architecture and its implementation (because the way software was designed and implemented may lead to compatibility issues).

### Compatibility test automation

You can (and should!) use automation tools that will allow you to create, schedule, and run automated test tasks for you. Such an approach will give you:

- greater speed of testing since you can have tests running on many platforms at the same time.

- higher efficiency and accuracy because taking out the human factor allows for consistent and comprehensive execution of test cases.

- generating savings as not having to rely on manual testers can significantly reduce costs.

## Steps to follow if you want to perform compatibility testing

Once you've decided to perform compatibility testing, you can follow these steps:

1. Determine what the designated platform for your app is. 
2. Get your hands on the required hardware, operating system, and any software related to the designated platform that will be needed for testing your app.
3. Set up your app and configure it.
4. Run it on the designated platform and test how the app works.
5. Find, record, and report any issues with compatibility that you encounter.


## Example of compatibility testing

Imagine that a software company has built a Windows app. They will need to find out how their app behaves on different versions of Windows, for example Windows 11 or Windows 10, as well as on Windows computers with different configurations. That’s why they’ll have to test the app for compatibility. Also, the company will need to test the app under various conditions which includes compatibility testing in multiple network configurations or with different amounts of data that the app will have to handle.

->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Benefits of compatibility testing for QA teams

### Ensuring software functionality across multiple platforms and environments

The main goal of compatibility testing is to make sure that your applications works on various platforms, configurations, and under different conditions. The rule here is simple: the better the compatibility of your app, the more users will be using it.

### Mitigating risks associated with incompatibilities

Compatibility testing can help reduce risks of compatibility-related issues. Thanks to such testing, you can identify risks early before they turn into real issues for your users.

### Enhancing user experience and customer satisfaction

High compatibility of your product improves the satisfaction of your customers. Given how many users with different configurations there are, software that has a high compatibility level will satisfy more people and positively affect the image of your software development team and company.

### Supporting product scalability and market reach

Quality Assurance specialists can use compatibility testing to ensure that their software works correctly on various platforms and under different usage. And if the app can handle more data, bigger workloads, and a growing user base, it means that their product shows good scalability. It also results in a better market reach as more compatible products appeal to users of different devices and platforms so the company can reach a wider audience.



## Best practices to follow when compatibility testing is performed

### Comprehensive test planning and strategy development

By focusing on test planning and strategy, QA teams can effectively test their software for various compatibility issues. A good test strategy goes a long way and will help you avoid dealing with frustrated users who experience compatibility problems.

### Testing early and often

The sooner you start testing, the more compatibility issues you’re likely to identify and address. Test early and test often as it increases your chances of finding compatibility issues in the most bizarre configurations and scenarios that your creative users can come up with.

### Prioritizing most critical issues

First things first. Make the compatibility issues that are the most common and affect the greatest number of your users your top priority. You won’t be able to fix every tiny problem, that’s why it’s important to focus on compatibility scenarios that really matter. If you find some time after fixing your top compatibility priorities, you can always move on to other issues.

### Continuous monitoring and reporting of compatibility issues

Be vigilant and be on the lookout for any compatibility problems by establishing a good monitoring process. Monitor and report issues as soon as you spot them. Sometimes such a process will help you catch an issue before it’s noticed during regular testing.

## Tools for compatibility testing

When choosing a good compatibility testing tool, you should focus on what devices and browsers a specific solution supports as well as features that it offers, including testing methods or report generation.

### Overview of popular compatibility testing tools

When it comes to compatibility testing, you have a plenty of great tools at your disposal. Some good examples include:

**BrowserStack** - a cloud-based solution that offers cross-browser testing capabilities.

**LambdaTest** - another cloud-based platform that provides parallel testing and mobile testing features.

**TestComplete** - a commercial solution that you can use to test web apps as well as mobile and desktop applications.

->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Conclusion

Testers should dedicate their time to compatibility testing because that way, they can make sure that their software will work seamlessly on multiple different devices and platforms. Early detection of compatibility issues can help fix them before the new release hits the production environment and users start submitting support tickets. In other words, in the long run, compatibility testing can positively affect the company’s image and user experience.

## Key takeaways and recommendations for effective compatibility testing

The most important things that QA specialists and testers should remember about compatibility testing is that testing should be done often and early in the development process. Always test on multiple different configurations and platforms to detect as many compatibility issues as possible. Document and report all problems and keep on monitoring for compatibility problems all the time.

## Stay updated with emerging technologies in the field

New software versions and devices enter the market every day. As a tester, you should keep up with all tech novelties and approach from the compatibility standpoint. It’s important because many of your users may be early adopters of new technologies. They will also be the first ones to point out any compatibility issues, so create a good compatibility testing strategy, test the application that your team's been developing, and stay ahead of any compatibility problems!



small_Test plan template (5).png

thumbnail_Test plan template (5).png

Test plan template (5).png

What is Compatibility Testing?

what-is-compatibility-testing

Software developer currently working as a tech writer and PM.  
[linkedin.com/in/marcin-%C5%82ojewski-a4191518/](https://www.linkedin.com/in/marcin-%C5%82ojewski-a4191518/)

large_DSC04042-Edit-3.jpg

medium_DSC04042-Edit-3.jpg

small_DSC04042-Edit-3.jpg

thumbnail_DSC04042-Edit-3.jpg

DSC04042-Edit-3.jpg

Marcin Łojewski

[TABLE_OF_CONTENTS]

Recently we have covered the test plan and we did quite a good job doing it. The document itself covers the testing process quite thoroughly. We agreed that the core of the test plan are the test cases and test suites. Now let’s shift our focus a bit more on the test cases and test scenarios and as a bonus we will come back to the test suites for a moment or two. 

Both test cases and test scenarios are crucial components of the testing process. Unfortunately it is not uncommon that they are not defined and understood properly.  Also it happens that they are confused with each other. The ability to set them apart is very important for proper test execution. Each tester, QA, test manager should have this knowledge. We think a high-level understanding would be beneficial even for the business people as well. We will try to be professional but not too technical in this article so hop on board.

## Test scenario

Test scenario shows a specific use case of a given functionality. It can be written in a non technical way as it describes an expected (positive and negative) result of a high level action. What is also significant for a test scenario, is that it might touch multiple layers of your software. If we were to create a smooth definition, we would aim for something like the following.

**A test scenario is a described pattern of a positive or negative action performed by the software’s user.**

Remember our article on [test plans](https://bugbug.io/blog/software-testing/how-to-create-a-test-plan/)? Let’s use the same example app to create an example of a test scenario. 

*“Only an authenticated user can see the salary on a job posting subpage”.* 

This is a great example, because one simple sentence describes triggering multiple functionalities. This test scenario contains a basic action that the user may perform on the web application. There are multiple processes and actions involved. 

What does the user see instead of the salary? If the user is not logged in, does he/she see the login button or link? Does the authentication work properly? Finally, when the user does log in after moving from the job posting subpage, is he/she redirected back to the same subpage after authentication? 

We can go on and on about that one, but hopefully you get the point now. 

There is a few additional key information here. 

- Test scenarios can not be automated and are not really reusable. They cover multiple aspects of your software and may include many variables. 

- A test scenario may be prepared by a technical as well as non-technical person. Usually the business people will tell what the app should do, and then the developers will have to know how to achieve it. It is the same in testing.

- Test scenario covers the end to end functionality of the software that needs to be tested.

- Remember that test scenarios may come from outside your testing team, it is common that some scenarios are derived from use cases that happen after the app is complete. The final users are great in finding ways of "breaking" your app. Ways that you would have never thought of. Best practice alert! If it is sound from the business perspective - foresee a beta test period for your app.


Can you perform software testing just based on a test scenario? No, you need to be more thorough. That is why you need something more detailed. You need a...

## Test case

A test case lets the tester know how to test a given feature of your app. We have to emphasise the singular here. The rule of thumb is one feature - one test case. Test cases are derived from test scenarios. It will usually include some input and expected result. Most test cases are written by and for a technical person, so expect more programmers’ vocabulary than it was in the test scenario. Our definition of a test case follows:

**A test case is a set of instructions, inputs and expected outcomes that is needed to validate the proper functionality of one software feature.**

Some technical knowledge and understanding the subject matter of your software are necessary to write test cases. As stated in the definition, we do not only need to describe what needs to be tested. We also need to know what is the data we want to use and what is the expected outcome.

Let’s jump right in and try to produce a test case from the test scenario above.

*Test case #1 - verify if the salary is hidden in a job post*

*Actions:*

*- Go to “/ads/job/2” url*

*- Scroll to div with id = “salary”*

*- Expected outcome is “Please log in to see full details” with “log in” being a link to “/login” url*

*- Failure condition is “$100 per week”*

*- Report any different outcome*

As you can see there are a few different elements that make a test case. The case ID - just for clarity. The case name or title if you will - a brief description of what is being tested. Last, but not least there are the test steps for the test engineer.  

Such test cases are easy to reflect in test automation tools. Some of them, like BugBug, will even enable you to create many test cases with using little to no code with their drag and drop functionalities. 

->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## The difference between Test case and Test scenario in software application testing

Trying to compare a test case and a test scenario is like trying to compare a book and a page. One could exist without the other but you have to agree that one page will never give you the whole context, right? It is the same for test scenario vs test case recognition.  

In software testing it is quite tricky to find actual similarities between scenarios and cases. They both serve a testing purpose, have a designed scope and purpose. The key is not to confuse them. A testing scenario describes user behaviour and may (should actually) be transformed into a list of technically defined single test cases.

Let's focus on the key differences to have a better understanding what a test scenario and test case is.

|                                            **Test scenario**                                           |                                    **Test case**                                    |
|:------------------------------------------------------------------------------------------------------:|:-----------------------------------------------------------------------------------:|
| Everyone related to the project can write test scenarios                                               | Technical personnel is responsible for creating test cases  and performing the test |
| A test scenario covers end-to-end behaviour of the user  what can go across multiple functionalities   | Test case contains one single functionality to be tested                            |
| Is created with no possibility of reuse or automation;  includes many variables and is not a procedure | Is reusable and easily adaptable for test automation                                |
| Informs what needs to be tested                                                                        | Informs how to perform every test                                                   |
| Strategically overviews how the users will be using  the software                                      | Gives some structure to the testing process                                         |



If we were to simplify the matter as much as we can, remember this. A test scenario is basically a set of test cases. There can be one or many test cases for a single test scenario. 

![Test scenario 1.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/Test_scenario_1_94473c7c69.png)

->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## How to write Test cases and Test scenarios?

After the first few paragraphs we are sure that you are a person clearly understanding what a test case and a test scenario is. Creating test scenarios is easy for people with a high level overview of the software whereas test cases are easier for people with more experience in the software testing field. Whichever description suits you more, it is crucial to stick to the how / what division. 

You should not overthink while creating a test scenario. Take the easiest approach possible and become the user for a moment. Think of what you would like to do in your app and then write it down. It should be that easy. Try not to consider (and describe) what different functionalities would your scenario trigger. This is for the test cases to check.

When you are creating test cases for each scenario, your job will be a lot more thorough. We suggest the "from the general to the particular" approach. 

Once you have the test scenario, try thinking about what functionalities it triggers and list them down. Afterwards analyze how those functionalities should and should not behave under the circumstances given in the scenario. Then provide or mock the data that need to be used in the testing effort. Last but not least, define the positive and negative outcome of each test. 

For starters try using our template from this article. We do encourage you to experiment and adapt such templates for your testing environment. Remember that creating test cases is a one-time job, an investment if you will. They are the core of test automation and are easily reusable throughout the testing process. 

->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Test case vs Test scenario - summary

At the very beginning we promised adding the test suite into the equation. Thanks for sticking around for that one. In our last article we described the test suite as a set of test cases. Here we do the same for a test scenario. There is a key difference though. 

A test suite is a set of test cases relevant to each functionality and is an artificial entity that helps to manage the testing process. 
Whereas a test scenario can cover multiple functionalities and is an effect of natural user actions performed in the app. 

They both cover multiple test cases, but a test suite can be automated whereas test scenario can not.

We hope we were able to convince you that test scenario and test case are two completely different beings used during the testing of an application. The scenario focuses more on the "what" and the case focuses on the "how". Remember that test cases are derived from test scenarios and not the other way around. From the good practice perspective it is wise to encourage your users to beta test as they have much more creative ideas on how to break your app. 




small_Test plan template (4).png

thumbnail_Test plan template (4).png

Test plan template (4).png

Test Case vs Test Scenario: Compare, Contrast and How to 

test-case-vs-test-scenario

[TABLE_OF_CONTENTS]

We recently went through the whole theory on the purpose of such document. We hopefully proved to each tester that such a document is more than a list of features to be tested. A good plan vastly reduces the risks associated with the whole process. It is time to present you with our sample test plan document. In the following article you can read our test plan example as well as get a sample template so you can write a similar one on your own. 

Before we do that, we need an example app, so welcome do BestAdPortal! (disclaimer - I found no such portal so I'm calling "dibs" on the name). 

From software development standpoint it is a most basic app, that does the following:

- user account functionalities (create, store, password reset, authentication, limiting access to given pages)
- ad related functionalities (CRUD)
- internal message system with email notifications
- billing functionalities 

The list is just an example, we can focus our tests on.




## Sample test plan

### Test scope and objectives

This is the place where you put the comprehensiveness of the testing effort. In our case the test approach might be as follows.


*In a few sentences we were able to describe what we are going to test, and why we limit the testing efforts. On top of that let's move to the identification of the major testing goals.*

*We would consider the test deliverables as complete if all of the below occur:*

*- All CRUD operations on the User can be performed flawlessly*

*- The User authentication process is functional*

*- All user access levels are functional*

*- All CRUD operations on the Ad can be performed flawlessly*

*- The internal message system is functional*

*- The message system cooperates with external email tool*

*- The billing is done properly (i.e. no double billing occurs during the testing effort)*

->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-



### Test environment

As you might remember from the last article - [how to create a test plan](https://bugbug.io/blog/software-testing/how-to-create-a-test-plan/), this is the place to describe the resources that will be used to test the designated app. We first describe the general info in bullets and then present the selected tool as well as other information on how and where does the testing activity take place.

*To perform testing activities the requirements are as follows:*

*- A test automation tool*

*- Designated communication channels: email address and Slack channel plus access to Jira and GIT*

*- Implementing the testing tool to our CD/CI pipeline*

*- Separate server space and a test environment setup accordingly to the CD/CI pipeline so the latest released app version is in place*

*- Dummy data creation functionality in place, at least 10 users (2 admins and 8 clients) and at least 50 ads created*

*The decision was made to use a low-code or no-code test automation tool. As we have no tester per say in the team, this is the best decision from the business perspective. After thorough research we decided to choose BugBug as it has low entry requirements, is easily integrated with communication clients as well as CD/CI pipelines.*

Providing the test environment allows a full understanding on what testing resource is needed to perform each part of testing services.  


### Test strategy and approach

We have already described the testing scope, objective and the necessary tools. It is time to let the recipients know what human resources are we going to utilize and what would be the high-level approach to their work.  Remember that it is not yet the time to define the schedule of testing. This chapter is also a good place to describe a high level situation of the app if it was not stated before. You can never foresee the changes in the team and what could be missed in the onboarding process. 

*In order to successfully complete the testing goals listed above, we need to consider our situation first. Given the agile approach to software delivery and MVP status we have decided that the testing efforts should be first and foremost iterative and highly automated. Each test milestone will cover the functionality provided in the latest development sprint.*

*The testing team will consist of the following:*

*- John Doe - test manager - major testing tasks and estimation*

*- Jane Doe - tester 1 - test execution, collecting reports for bugs encountered during the testing process*

*- Jeremy Doe - tester 2 - test execution and updating test scenarios*

*- Julia Doe - communication between the testing and the development team, assistant test project manager.*

*All of the above will be involved in testing for 20 hours per week.*

Remember that the business and finances people also must approve this plan. This is why the example covers also information that helps with the estimation of the time required. 

->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-



### Test cases and test suites

The core of the document. This is where you write the test scripts that will be executed. The software backlog is something that will support the test suites and cases for you. Given that we have chosen the iterative approach it will be relatively easy to pull the functionalities from the milestones identified in the software planning. The following also allows you to define any additional test milestones. 

| ID | Test suite          | Test case                           | Description                                                                                                                                      |
|----|---------------------|-------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------|
| 1  | User creation       | Proper data in user creation form   | Insert proper and valid dummy data into the registration form. Check if the user was created correctly.                                          |
| 2  |                     | Invalid data in user creation form  | Insert invalid dummy data into each field of the registration form. Check if the user is prompted about the mistake and if the user was created. |
| 3  |                     | Post creation behaviour             | Check if the user is redirected to the profile page after successful creation                                                                    |
| 4  | User authentication | Proper data in the user login form  | Insert proper and valid dummy data into the login form. Check if the user was authenticated correctly.                                           |
| 5  |                     | Invalid data in the user login form | Insert invalid dummy data into each field of the login form. Check if the user is prompted about the mistake and if the user was created.        |
| 6  |                     | Check credentials for a new user.   | Check if a new user without admin rights can access the admin panel page.                                                                        |




This is just a brief, high level example to make it easier to create a test plan. Test cases and suites might not be put into a table for instance. The crucial part is - it has to reflect your needs and requirements. Maybe you need to place a column for test data, or just an "additional information" column will do just fine? Be creative in using this example. 




### Test execution schedule

This part of the test management has to consider the software project schedule as well. One thing you might reduce your effort with, is supplementing the table above with a "sprint number" column. That way you end up with a highly readable to do list. If you choose the more descriptive approach, try something like the following.

*The testing will be performed on a similar schedule to the one the application is being designed. After each iteration is released to the relevant environment (at the end of each sprint), the test team will test the designated groups of features. As each of the people involved in the test phase is available part time, test items might require increased managerial attention. As of now there is little possibility to estimate the time required for each case to be conducted. This is mostly because the team is not yet onboarded to the chosen tool.*

Remember that a good test plan foresees changes. Also note there is some flexibility in the schedule for each testing task, since you will deliver those on sprint basis. There is no need to plan the actions in high detail.


->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-


### Defect reporting and tracking

As we have already planned the whole testing process, the final touch would be to take care of the “what if..” scenarios. Yes, the final purpose of the test plan is to find actual bugs in your software. The final part of the document should then outline the course of action after a bug is found. Remember, that proper setting up automated processes here is an investment that will easily and quickly pay off. Imagine sending out a hundred emails weekly just to initiate the fixing process.

*Thanks to multiple integration opportunities from the chosen tool we are able to notify the key people from both development and testing teams. To reduce unnecessary email communication, the reports on started and passed tests will be sent only via the designated Slack channel.*

*If a bug occurs, the following actions will be automatically undertaken:*

*- A message will be sent via the designated Slack channel*

*- An email will be sent to the Test manager and to the development teams’ PM*

*- A Jira ticket will be created with the description of the test case and error log*

*- A GIT branch will be created. It will be linked in the Jira ticket mentioned above*

*Such a flow will be efficient for the bug fixing process.*

Do note that not every test management tool allows you to easily integrate such functionalities, so choose wisely. In the test plan template you will be able to download, you can also find a flow chart for defect reporting.




## Sample test plan document

Here is one especially for you. After clicking the link below you can download sample test plan. If you are not the test manager, send it to someone responsible for providing the test documentation.  It contains the cases described above but put into one easy to read document. 


[Test Plan Example](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/Bug_Bug_TEST_PLAN_example_20b66d9113.pdf)




## Software test plan template 

We are not yet tired of giving away gifts. A sample test plan template will enable you to document the procedures for your app and meet the delivery date. And at the end of the day, what does it do? After reading the last article you should already know. It saves you money! Successful delivery of test items might and will reduce the man hours spent on bug fixing. Our template is universal so it will cover every field of software testing. 

[Test Plan Template](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/Bug_Bug_TEST_PLAN_template_3f4dd12d86.docx)




If you feel that this article does not consist enough information on how to create a test plan on your own, you are right. We created a separate article that includes much more knowledge. Check it out [here](https://bugbug.io/blog/software-testing/how-to-create-a-test-plan/).




small_Test plan template.png

thumbnail_Test plan template.png

Test plan template.png

Test Plan Template For Test Automation Process

test-plan-template

For many software development teams creating any sort of plan sounds dull and boring. Creating a plan for the testing process sounds.. Well… Pretty much Hermione Granger-ish. That is definitely not the case. Remember that the whole effort that you put into testing is there for a very important business reason - to save you time and money. Creating a test plan is the first step to achieve this goal.

**But how do you prepare a test plan for software testing?**



## What is a test plan document?

Stating the obvious - a test plan is a document describing the testing process of your web application. There is more into that though. This is a crucial document. It outlines the approach, objectives, scope, and resources required for testing a web application. It serves as a roadmap, guiding the entire testing effort and ensuring that all necessary activities are executed.

Creating it, is like answering to the “wh- questions” about the process:

- What will be tested 
- Why it will be tested
- When it will be tested 
- And how it will be tested (I always wondered why “how” is on the “wh- questions” list, but anyway)

A well-crafted test plan includes details such as the test objectives, tools, schedule, and roles and responsibilities of the testing team. It would be beneficial if It also identifies the test levels, entry and exit criteria, and the types of testing to be performed.

There are two important features of a good test plan. First - keep it a live document. Don’t set it in stone from the very beginning of the process. We all know that the only constant thing in software development is change. The test plan needs to react to those changes. Second - use the test plan. It is there for a reason. It will make the web application testing easier and more efficient. The worst thing you can do about it is to complete it and put it in a drawer. By doing so, you just wasted a lot of time and effort.




## What is the importance of a test plan anyway?

Well imagine going for a long hike without a map (optional North American sport parallel - imagine playing football without a playbook) - will work somehow, but do you really foresee success by doing so? Not really, huh?

It is crucial for web application testing that all team members to understand the key aspects of it. Especially now, when we live in times of fast software and business development, IT teams often spread geographically across different languages and timezones and flat company structures when a startup CEO may also work as the PM or tech lead. We all need to be on the same page. Even literally. 

This map (or playbook if you will) is vital for everyone involved to know what will be expected of them during testing and what should the pass/fail test criteria be for the application. 

->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## When to create a test plan in software testing process?

Given what we have stated above, on the web app test plan being a live document, the answer would be - create and improve it constantly. When to start creating it, is a bit of a different topic.

The planning process depends on your situation and web development approach. Of course the test plan needs to be created prior to the first testing activity. You have the waterfall vs agile decision to make, which implicates not only the testing but the development as well. 

![Phases of Waterfall methodology](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/96588c07_0308_4689_915f_111b5eef1f14_1ee85a8819.png)

Waterfall gives you a bit more time to create the test plan, because the person who will actually create it may work parallelly to the development process. On the other hand there will not be much time left for modifying the plan after the tests start.

![Phases of Agile methodology](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/e8034c88_f92f_4f97_8f92_fa65b85594d2_5752e83cc8.png)

Agile approach is based on iteration which is also reflected in test planning. A few core parts of the plan need to be done right after the completion of the functional specification of the app. Those would be test plan objectives and scope, test environment and test strategy and approach. The rest (test case, test suite and test schedule) can be done in an iterative manner, basically side by side with the scrum masters’ backlog planning. For example if the first sprint of your web application creation aims to create the user authentication process, your test cases will include… yes, you are right - testing the user authentication process. 



## What are the crucial components of a test plan? 

You might get different answers to that question all over the web. If your team is experienced enough, the list of components may vary especially from project to project. The following list comes from our expertise and will be described more thoroughly below. 

In our opinion a good test plan has to include:

- Objectives and Scope
- Test Environment
- Test Strategy and Approach
- Test Cases and Test Suites
- Test Execution Schedule
- Defect Reporting and Tracking

 
## What should be placed in the test plan template?

**Objectives and scope** 


In this paragraph the creator needs to outline the specific goals the testing effort needs to fulfil plus the range of the tests themselves. It is wise to do a rather thorough description followed by a bullet point summary for readability. Also we recommend doing the positive / negative approach, meaning that first think and describe what you want to achieve, then reset and do the complete opposite - what are the limitations and boundaries and describe them as well. 

This should answer the “what” and “why”. Are we just testing the functional aspect of the app? If so, why are we not doing the security testing or the performance testing? There might be business reasoning behind that decision, for example we might have an external team being responsible for the security. 




**Test environment**

Remember our article on [the best testing tools in 2023](https://bugbug.io/blog/guides/testing-tools-for-web-application/)? This is where it comes in handy. In this chapter you need to describe all assets that will be used in the process. How many man-hours do you foresee using? Do you need any specific server / network / devices or maybe some fancy settings on those? And finally how are the tests going to be performed? Will your team code them by themselves? Or maybe you will use some no-code solution like BugBug?

This might sound less important from the testers’ standpoint, but trust me - it’s a must have from the business perspective since it enables “the money people” to do some cost estimations on the test process. 




**Test strategy and approach**

We have addressed the “what” and the “why”, it is time to address the “how” we need to test. The strategy part needs to take care of describing the overall approach and principles that will be followed during the tests. The key here is to make sure that all information is relevant to your specific project.

The test approach on the other hand describes the actual activities that will be done within the process. There are different testing methodologies and a brief description of the one(s) chosen needs to be fit here. Are you going [end-to-end](https://bugbug.io/blog/software-testing/what-is-end-to-end-testing/)? Do you require data-driven approach? Make sure you let all the team members know. Speaking of team members - it is wise to place the responsibilities description here, bringing us to a conclusion that we have another “wh-” question - who? 


->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

**Test cases and test suites**

This is the most crucial part of writing a test plan, because it covers the actual scope of testing. Single test case answers the question “what do I want to test?”, and the reply needs to be in singular. One test case covers one topic, but do note that it may be divided into a few separate scripts. For example one test case will cover the user login functionality, but separate scripts will cover logging in by using different web browsers. 

A test suite is a collection of test cases grouped for test execution purposes. Moving along with the example from above a test suite would cover the whole user authentication process, and logging in, password reset, logging out etc. would be separate test cases.




**Test execution schedule**

The schedule has to cover both the high-level and low-level planning of the test phase. The first defining moment comes with the decision on waterfall vs agile that gives you a basic idea on when the testing will happen. Is it going to be post-development or mid-development?  Remember that creating a schedule is not only putting the test procedure into a calendar, the harder part sometimes is to figure out in what order the testing will take place. 

For waterfall it is relatively easy since your whole test procedure takes place after the coding is done. You might consider what the testers are going to be doing during the development phase. For agile you have a bit more decisions to make, for example is there going to be a delay in testing? If so, how many sprints of a delay would you like to have. [Testing in agile environments](https://bugbug.io/blog/software-testing/agile-testing-organized-chaos-or-a-planned-way-of-improving-your-software/) deserves a completely different article since this is truly a different software testing life cycle.




**Defect reporting and tracking**

First of all do have a bug reporting and tracking system implemented, this is the foundation of your communication within the process. If you don’t have one yet, create one. Even if it is writing a post-it with a bug description and smacking it at someone’s desk. Fortunately we have more sophisticated methods of monitoring software defects.

There are multiple project management and ticketing systems available. BugBug enables integration with the most popular ones via Zapier. This will make life easy for the test manager, since the majority of communication will be automated and whenever a bug occurs, a ticket will be created, an e-mail sent or whatever you require.

![BugBug integration with Zapier](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/2d90e3ab_2727_4a1a_9eae_52d74916c8fc_79aac10fc3.png)


## How to write a good test plan?


**Define Test Plan Objectives and Scope**

The author needs to start creating a test plan by writing the objectives and scope. In majority of cases the objectives included in the test plan are basically stating the obvious - that we want to make sure that all our functionalities work, the app is secure and will withhold increased traffic if our business is a tremendous success.

The scope on the other hand requires a tad more attention. As an exercise try writing the scope as you would for a person, who does not work for you yet and has no clue whatsoever about your software. The scope of your testing needs to be relevant for your app from the business perspective but from the subject matter point of view as well. For example you will not require too much UI testing for a console application do you?

 ->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

**Identify the test environment**

After carefully analysing the market and choosing the best tool that suits your needs, you now need to reach out to people who take care of your network and servers. If there are any special requirements such as server structure, traffic limitations etc. those need to be put here since the test management strongly depends on those. 

One thing that is commonly missing in this chapter is the test data. Those need to be either prepared beforehand or you may end up using data automatically faked by some external solutions. Whichever route you would like to take, make sure you let the readers’ know. Remember that each software product will require different types and quantities data to start the test so make sure you plan it both time- and money-wise. 




 **Choose a Test Strategy and Approach**

A good place to start is choosing your goals. Those need to be relevant to the objectives and scope you defined earlier. Remember, that a good goal is a SMART goal. Then you move to the team and responsibilities. Define specific members of your team, or profiles if you need to hire some additional testers. After that just “drag and drop” different pieces of the testing cake to those people.

One of the most important strategic decisions comes next - what tests would you like to automate. Is the test automation tool relevant to your needs in that matter? The high level listing of “to be automated” aspects would be a good place to do some self-compliance. Last but not least comes the answer to the crucial question - when do we do [functional testing](https://bugbug.io/blog/software-testing/what-is-functional-testing-types-and-examples/). There is little point to define the test plan on security, UI etc if our app just does not do what it is supposed to.




**Develop Test Cases and Test Suites**

In theory the applications functional requirements are your best friend if you want to write a software test plan. Keep your fingers crossed that the requirements were created correctly and thoroughly. In such a case your work here is relatively easy even though it will be quite monotonous. Basically you create test cases by checking and adapting the whole list of functionalities, user actions, security and whatever falls into your test scope. Then after creating such a list, you divide it into test suites that cover different areas and groups of functionalities. 

Worse case scenario - your functional requirements are described on a very high level. In such case the test plan is typically a much more "live document" as one would desire. The test management process might be a bit harder, but this does not mean that it is not an effective test plan. You just have to come back to this part in a more iterative manner and implement changes to the test plan as soon as the development team completes a functionality. 




**Create test execution schedule** 

That is another part of the test plan that might be partially covered from a different source. If your team does agile development, you should have a backlog created in sprints. Nothing prevents you from using this backlog to your needs, there is no need to reinvent the wheel there. You end up having functional test deliverables just like that.

Other test scopes need to be covered here as well. Remember that a test plan is a detailed document that requires not only your knowledge and expertise, but lots and lots of inter- and intra-team communication. You have to understand for example if starting performance testing may happen only after completing the whole app, or are there any circumstances that will allow doing it sooner. There is no universal truth here, only project relevant stuff. Those are data, you have to collect and process on your own. If you never tried to create a test plan, you would have to learn how to write it. The first version of the test plan might be similar to a first pancake. It will be thrown away. Trust us, expertise, especially in scheduling the test plan comes with repetitions. 




**Define defect reporting and tracking mechanisms**

The main goal of a testing project is to report every test result. The dream is to have as few negative results as possible, but a comprehensive test plan (like the one we are describing here) needs to consider the “what if?” scenario.

In this final part you need to describe two things. First - which tools and integrations are needed for a proper bug reporting path. The idea if bugs are the only things worth reporting is also something to think about. Maybe it is a good thing to report the completion of a test phase as well. Next you write down who the information recipients should be. Use as much automation as possible. Thanks to multiple integrations a detected bug might immediately trigger an email to a bunch of recipients, a ticket or a task and even a creating a git branch for the issue to be resolved.


->[Automate your tests for free](https://app.bugbug.io/sign-up/){.markdown-cta}<-

## Executing a software test plan. How to work with changes to the test plan?

Ok, you have created a detailed document that outlines your plan for testing. It contains the success criteria for testing, describes many test cases and includes all steps to report bugs. And now what? Well, the testing obviously, but this is not the point here.  The key importance of a test plan in software testing is not to hide in the drawer. The test plan helps in all phases of software development process and all aspects of testing only if you use it properly. 

First things first. From the very beginning understand that even the best plan will need some changes and updates eventually. Every test plan is created with no possibility to foresee how many bugs the tests will uncover. Creating your test plan has to assume some time flexibility, both ways actually. Your test estimation will rarely be 100 percent accurate. Of course if your development team did a splendid job and there are virtually no bugs whatsoever, you need to make sure that your updated test plan contains it too. 

In addition to that, remember that the most important soft criteria for a test plan is readability. You need to make it easy to understand to all audiences. You are probably wondering why we put this into the “how to execute” part of our article. That's simple - all team members have to be aware that the test plan exists and how far we have progressed. Remember, they are the ones actually working with the plan, you have created. Without them, the test plan becomes just another document.  




-----------------------------------


We hope, that with this article we were able to emphasise the importance of test plan creation. There many types of test plans out there for you to check. If we were to suggest you one crucial thing it would be just to create one and do so as a team effort.

Make sure you check the next article, that will cover how do we at BugBug write the test plan. What are our steps to create a plan. It will include a template and an example as well! A good test project plan will make as happy as John Hannibal Smith always was.

![I love it when a plan comes together meme](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/7db975a4_659f_4a4a_9a0d_9b063aee1b40_e5f73ae706.png)



