Software Testing

**Nowadays, the profession of a software tester has become a symbol of entering the IT world without elbow grease. Why can some people pull it off and some cannot? Is there a golden rule for securing a job as a tester? Let’s find out.**

A good software tester has not only undergone special training crowned by a respective diploma. If you want to do this job successfully, you will appreciate natural predispositions and skills that you can acquire single-handedly. You may wonder if pure skills will suffice. Well, it depends …

## Who can work as a software tester?

Speaking in most general terms: anyone. There are no age or “trade” limitations; for many people who want to branch out the profession of a tester marks the first step in a career in IT. Many candidates fall prey to a stereotype, thinking that this is a simple, easy and pleasant profession that anyone can practise. Here come the details that you need to be aware of if you are  contemplating the job of a tester. As it is the case with other professions, some predispositions are also welcome, not only personality-related. These predispositions include:

### Analytical thinking 
A good tester needs to be able to combine facts, view an application and its possible uses in the context of its product environment and to draw conclusions;

### Inquisitiveness


When, surfing the Internet, you ask questions like “why does it work this way?”, “I wonder why they used this solution”, you are on the right path. Even if people around you sometimes find your inquisitiveness irritating,  it will prove priceless in a tester’s work;

### Resilience to boredom

It comes in handy especially at the beginning of work as a manual tester, when you check how an application works and simply “click your way” through some software an unlimited number of times. A certain degree of repeatability is an inherent part of a tester’s job; 

### Openness to people 

Another stereotype worth debunking before stepping onto the path of software testing is an introvert hiding in his cubbyhole, a dead ringer of  a character from “IT Crowd”, avoiding people at all cost. The situation is quite the opposite! Yes, you spend some time on the testing itself but you need to communicate the results of your work to a developer, a project manager or an entire team. Sometimes you need to explain what is not working. Sometimes you need to ask why something is working the way it is ☺   This is not a job for people who would rather have their arm chopped off than talk to someone on the team.

### Creativity

It will come in handy on a higher level of advancement when you are responsible for creating testing scenarios. In some companies, testers cooperate closely with the entire project team and contribute to developing the assumptions behind a product which provides plenty of room for creativity.

The stereotype of a software tester has one “benefit”: people think that testers do not need to know programming. Yes and no – it all depends on your aspirations. 

## Do you want to be a manual tester?

At this stage,  you are typically in charge of “clicking your way” through an application and reporting possible errors. After several or over a dozen months of working as a tester you can also start to write scenarios and test cases. At this stage, in order to acquire new skills, you can also learn to make use of automation tools  or tools supporting manual testers. However, if you do not want to grow or learn the basis of a programming language – you hit the wall.   The same holds true for financial promotion – among testers, the manual ones are at the bottom of the pay brackets. 

## Do you want to be an automatic tester?

Knowing the basis of programming is imperative because in this job you write your own test-automatizing scripts and you fix possible operating errors. All the time, you supervise also the programmes’ operations and you enhance them, for example with new requirements that occurred in the process of creating a product. There is a reason why burnt-out developers or people who want to have a break in programming are good candidates for automatic testers. If you are literate in even one programming language (of course the more the better) you are good to go.

## How to start working as a programming tester

Ok, let’s assume that you remain firm in your decision to become a tester. You have all the predispositions and you want to grow in IT. Where do you start? Regular broadening of your horizons and self-learning are a must; it does not matter whether you  already know the job or are contemplating it. The Internet is a mine of knowledge; we recommend publications both in Polish and English  (there are many more materials in English). If you know some basis, you can apply right away for a manual testing internship programme. Junior positions are also within your reach – they are particularly attractive to people who branch out and cannot afford an unpaid or poorly paid internship. At the same time, you can try to take on single jobs on platforms like uTest – they will ensure an inflow of cash as well as experience, so valuable at the dawn of a professional career.

Read also: A manual tester: 10 reasons that make this job interesting

## Working as a software tester – with or without training?

As working in IT has become fashionable, training companies are flourishing. They offer not only trainings for developers but also testers. On the one hand, this is an interesting and developing option because a course poses an opportunity to acquire knowledge in a user-friendly way.  This is also a guarantee of regularity in learning which is of importance to less systematic people or ones having difficulties with self-motivation. On the other hand, a training is usually costly. Before you choose the school, take a good look of the market because some participants complain about the small number of practical classes and poor care on the part of the mentors. Whether you decide to embark on a  course or not, it is a good idea to find a mentor: a person who already works as a tester and who may lend a guiding hand in your search, recommend literature on the subject  or give you feedback on your work. Last but not least: even if you have the best teachers/mentors, without your determination and own work they will not be of great help. Acquisition of testing skills is, first and foremost,  a considerable effort and ensures regular enrichment of knowledge – a lot depends on you and your commitment.

## How to be an IT tester with a certificate

The schools mentioned here frequently offer their own diplomas but the market honours certificates issued by the International Software Testing Qualifications Board (ISTQB). While you can obtain certificates at any stage of professional development, a document on the basic level should be the first step to becoming a Certified Tester. If you are new to the industry, this item on your CV is bound to be welcome. On the other hand, some people are critical about the certificates and say that all you need to know as a tester can be learnt single-handedly.

## How to be a tester and earn real money 

This is a very important issue; after all, the time of poorly paid internship must come to an end. Big companies typically have a natural development and promotion path that you may follow after having worked for some time as an intern or an IT junior. However, continued development is key to promotion – if you are contemplating the position of an automatic tester, do not put off learning  programming. The more you know about testing and the industry the better your chances of becoming a QA (quality assurance) team member. It stands for a tester with considerable experience who is in charge of entire projects, also related to people management, writing testing scenarios, writing automatic tests and monitoring work within a project. Irrespective of the position you assume, when you work in IT you should know the methods of project management while words like “agile” and “waterfall” should definitely ring the bell. 

large_jak-zostac-testerem.png

medium_jak-zostac-testerem.png

small_jak-zostac-testerem.png

thumbnail_jak-zostac-testerem.png

jak-zostac-testerem.png

How you can become a software tester

how-you-can-become-a-software-tester

**It turns out that following the “golden rules” of testing does not always  bring about the desirable effects. Disregarding the rules can be equally disastrous as exemplified by companies and institutions that have become household names. One thing is for certain: software defects are expensive. Fortunately, there are ways to mitigate the damage.**

Imagine that, as a result of an defect in the medical care system,  the patients’ medical records which are the basis for writing out prescriptions, are not updated. As a result, physicians prescribe medications unsuitable for the reported ailments which may pose a threat to some people’s health or even lives. This is not a script of a science fiction film. This situation took place in 2018 in Europe’s second largest economy. What caused it? A bug in the system operating in National Health Service (NHS) in the United Kingdom. Back then, more than 10 thousand people received wrong prescriptions. Fortunately, adverse consequences for the health were not involved. It is difficult to evaluate the losses incurred by this type of defects because, on top of purely economic costs of rectifying these mistakes, the reputation-related consequences may be even more damaging (especially for companies from outside the public sector). **In the United States alone, the damage resulting from launching to the market poor quality  software was estimated in 2018 at $2.8 billion.**

## The results of testing defects

The trade experts are far from disregarding the importance of defects generated in the process of designing software. Following a survey carried out in 2019 by Micro Focus in the US,  it was possible to define how the three areas of software written by means of the Agile/DevOps methodologies: functional, performance- and security-related, affect the specific areas of a company’s operations. It was agreed that defects on all the three levels impact most a company’s revenues, brand reputation and have legal consequences.

![elements-contributing-to-negative-business-impacts.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/elements_contributing_to_negative_business_impacts_9e27ba5281.png)

Allegedly, the situation can be improved by the rapidly growing automatic testing market which (and this comes as a surprise) is also an area which poses considerable challenges to companies, as indicated in the latest “World Quality Report 2019-2020″:

![challenges-currently-faced-in-applying-testing-to-agile-developments.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/challenges_currently_faced_in_applying_testing_to_agile_developments_005725ae28.png)

The most typical challenges indicated in the survey included:

1. Lack of appropriate test environment and data.
2. Inability to apply test automation at appropriate levels.
3. Difficulty in identifying the right areas on which tests should focus.

Interestingly, testing was indicated as the biggest challenge accompanying actions aimed at preventing new defects in software:

![top-challenge-of-mitigating-defects.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/top_challenge_of_mitigating_defects_6c5a6e3a12.png)

Why is testing perceived as such a difficult task? This may stem either from lack of knowledge or inability to apply it. One solution is to audit the activities instigated in the company; the list below may prove useful.

## Poor testing strategies or how extra costs can be generated

**1. Underestimated testing scenarios.**

Testing scenarios should result from consultations held within the testing team working on the scenarios aligned with the previously collected business requirements. At the very early stage of talking with product owners, project managers and developers, detailed product documentation should be compiled. Together with other things, it will provide the basis for creating detailed action scenarios (the testers’ skills and experience play an important role, too). Ironically, a firm plan, implemented since the beginning of work on designing software in accordance with the shift-left testing idea (i.e. starting tests at the earliest stage of development) facilitates flexible adjustments to changes typical of the Agile approach. It is easier for testers to modify an existing plan than to work in chaos aggravated by subsequent sprints. A case in point is a small software company, described in a scientific work entitled  “’Good’ Organisational Reasons for ‘Bad’ Software Testing: An Ethnographic Study of Testing in a Small Software Company” by D. Martin, J. Rooksby, M. Rouncefield and I. Sommerville. For the benefit of the study, a company from the United Kingdom is referred to as W1REsys. It creates development environments which make it possible for customers to design mobile applications. W1REsys employs seven people including four software developers. Due to the lack of a dedicated team of testers, the requirements for new products or functionalities are laid down either with respect to the clients’ needs or ideas for the elements which potential new clients can find attractive. These ideas are provided by representatives of the marketing and sales departments while the scientists surveying the company decided that testing was based on suggestions of what needs to be tested rather than how to do it. Therefore, the automatic tests created in W1REsys are not a part of a structured plan and as such, they allow only selected functionalities to be developed. The ideas for enhancing them are originated also in the process of developers’ work; they result from discussions about the way the system is working. This approach incurs the risk of grave defects in production and, as the survey’s authors admit, these defects do occur  yet they are maintained on a level acceptable by the company.

**2. The testing process is not aligned with the way in which an organization operates.**

The example of W1REsys shows how important it is to adjust the principles of effective testing to an organisation’s capabilities. In larger companies which are in charge of complex projects, following the good practices guarantees success. In smaller companies, oftentimes coping with staff shortages, these rules need to be tailored to the employees’ actual capabilities. Otherwise, they will work under enormous pressure of time and frustration that they cannot accomplish all the goals towards which they have been working. As the Micro Focus research from 2019 suggests, the defects detected at the last stage of designing software (production) tend to be the most costly. This stems from research into both projects managed in Waterfall, now a less popular methodology, and Agile, a methodology enjoying great interest:

![effect-on-cost-by-development-stage-1024x523.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/effect_on_cost_by_development_stage_1024x523_09c6c9266d.png)

[According to Eric Elliot who has written an article on production defects for Medium.com](https://medium.com/javascript-scene/the-outrageous-cost-of-skipping-tdd-code-reviews-57887064c412), the cost of remedying a production defect can be 100 times higher than the cost of correcting it at the design stage, and 15 times higher that the cost of repair at the level of implementation.

Smaller companies, which cannot afford extended testing scenarios, should arrange their tasks from the most to the least important to a project. The mentioned software company W1REsys from the United Kingdom set a goal of testing the functionalities most frequently used by the clients. As a result, it can properly manage defects identified at the production stage. This is a good example of approaching  testing not like a way of excellent testing of the entire code which, in many cases, is simply impossible but rather, as a way of managing risk that can be mitigated when specific testing tasks are given priorities.

**3. Ignoring the importance of tests in the speed and efficiency of  mobile applications.**

As a result of focusing on functionality tests (working/not working), some teams ignore the importance of speed and efficiency tests. A survey conducted by Dimensional Research in 2015 informs about the actual costs of adopting this attitude. Users of mobile applications were asked for their opinions on the response time. As the diagram below shows, their expectations are very high with 2 seconds required for the optimum response time:

![how-fast-should-app-respond.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/how_fast_should_app_respond_0d7c860cce.png)

80% of the respondents admitted that in the case of problems with an application, they give it not more than three chances before they abandon it for the benefit of competitive solutions. Interestingly, in the process of choosing an application, the functionalities promised by the producers are as important as the reviews published by other users:

![which-of-the-following-most-influences-the-app-you-pick.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/which_of_the_following_most_influences_the_app_you_pick_76401d2bb5.png)

In 2017, Pinterest found out about the business benefits of rebuilding an application to make a faster and more responsive one; following its implementation, Pinterest enjoyed bigger revenues and traffic:

![comparing-old-mobile-web-to-new-mobile-web-1024x528.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/comparing_old_mobile_web_to_new_mobile_web_1024x528_6332cda00b.png)

**4. Giving up on Test Driven Development.**

This approach assumes designing automatic testing before works on writing the right code even commence. Of course, at the beginning the tests are failed; over time, as the subsequent lines of the code are written, at a certain stage they all end positive. As a result, the “trouble-free” section of the code grows; you can also think over and plan how the entire application works. Eric Elliot presented the following calculations as evidence of the  effectiveness of the method which daunts many IT managers due to the high costs involved at the initial stage of a project:

![source-medium.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/source_medium_e8b7b31c22.png)

In the fictitious example provided by Elliot, development without TDD was to cost 1,000 hours (the cost of maintaining the system excluded). TDD allowed to save 623 hours which is equivalent to a month of work of a team of four.

**5. Under- or overestimating automatic testing.**

The success of any testing team is based both on qualified employees and skilfully selected tools. Automatic testing significantly speeds up and fosters work thus releasing the testers who can focus on exploratory testing or a product analysis with respect to the users’ requirements or experience. Teams distrustful of automation tools or disappointed with older generation programmes may prefer manual tests. Frequently, this results in overloading the employees with work. They are also frustrated because they need to handle repetitive, mundane tasks. On the other hand, automatic testing cannot replace an employee who may come up with the right testing scenarios aligned with the business guidelines or even supplement them with suggestions of new and interesting functionalities. An optimum testing strategy helps to design the testers’ responsibilities to ensure that they can make the most of their automatic testing tools, at the same time taking advantage of the specific workers’ competence in carrying out manual exploratory testing.





large_zle-strategie-testowania.png

medium_zle-strategie-testowania.png

small_zle-strategie-testowania.png

thumbnail_zle-strategie-testowania.png

zle-strategie-testowania.png

Bad testing strategies or how to learn from other people’s mistakes and to minimise damage

bad-testing-strategies-or-how-to-learn-from-other-people-s-mistakes-and-to-minimise-damage

The work of a manual tester is not always as appreciated as it should be. Often, words like “testing” boil it down to (seemingly) boring activities following a scenario. This is a superficial opinion; check the 10 reasons why this profession can be recognised as surprisingly interesting:

**1. The job of a manual tester=creativity that many marketing guys could dream of.**

As a manual tester you get to know the product and create testing scenarios. This is the part of the work where you can unleash your creativity: you come up with the biggest possible number of ways in which the user can make use of your product and where an error can be detected. Even if you are a natural when it comes to looking for “weak points” in an application, you go beyond it and foresee the user’s behaviour and the operation of the entire software. Looking at the scenarios you have created, many people could say “there is no way this will happen!”. How about you? When your scenario shows an unexpected error, you simply flick an invisible speck of dust off your shoulder.

**2. Manual testing is heaven for an analytical mind.**

Analytical thinking and drawing conclusions will come in handy at every stage of your work: since the moment you get acquainted with the technical specification and the product’s application up to writing the mentioned scenarios. A good tester has the skill of inductive thinking i.e. drawing conclusions on the basis of pieces of information coupled with deductive thinking (from the general to the detailed). A tester’s role is not limited to checking how specific functionalities work; a tester also places them in a broader context – the product and its trade environment. Questions like “Is this the best solution? Does the design meet the standard? Can you simplify it?” are elements of daily work. A manual tester is not a person who follows the instructions blindly but rather, he/she creates them respecting the latest standards and sometimes even challenging them.

**3. A manual tester criticises as much as he/she likes.**

Did you dream as a child of being a literary, theatrical or film critic? Even if you did not, as a manual tester you have an opportunity to show the part of your personality that enjoys pinpointing mistakes and highlighting imperfections. There is more: in this job it will be more than welcome (with reference to the tested application, not your team mates, that is )!

**4. A manual tester stands for a “great communicator”.**

Did you know why Ronald Reagan was dubbed “the great communicator”? For his rhetoric skills in general and one talent in particular. It actually helped him to be elected president. In 1980, during a TV debate with Jimmy Carter, Reagan addressed all Americans directly and during his air time he looked straight into the camera, making an impression that he was speaking to each and every viewer individually. How does this connect with a tester’s responsibilities? As part of your work, you will also have many opportunities to look someone in the eye and say something  harsh, e.g. to show a code error to a developer or to ask a project manager for extra time for testing if the situation requires it. Rest assured that these will not always be nice conversations… It is good to know because many people perceive a tester as an individual who is knowledgeable about logs and only produces reports. However, this job requires a lot of interaction with people at various levels (especially when your company uses the scrum methodology) and here communication skills are much coveted. Assertiveness (ability to present your opinion without hurting other people’s feelings) is worth its weight in gold.

**5. Testing and… empathising.**

I do not mean only empathy with a developer who, following your remarks, needs to repair the bugs ;). As a tester, you empathise mainly with the user who will ultimately make use of the product you are testing. You try to best understand the user’s needs and train of thoughts. Your aim is to make the application as easy to handle as possible. This is yet another soft skill that you can use in your work.

**6. People keen on accuracy make good testers.**

If you are applying for a job of a manual tester, perfectionism will certainly be perceived as your strength during the job interview. Accuracy and care for the detail are prerequisites for being a tester; otherwise you might miss an important aspect of an application’s functioning. As a result of this omission, the company could lose its good reputation and considerable amounts of money. 

**7. As a manual tester you use your organisational skills.**

You do not have unlimited time for testing; in many cases, there is less time than you hope. Your planning skills and effective use of time come in handy. Time pressure is visible not only in Jira; it also affects the people managing a project.

**8. A manual tester’s continued growth.**

As a tester you need to keep up with the changing trends and technologies, also as part of your specialisation. There is no room for stoppages or boredom because every day, new information is disseminated, new courses and ideas originated. When implemented, sometimes they challenge the assumptions about reality. Every tester needs to know the product he/she handles and this is no mean feat: you need to know the rules of operation and find out the solutions offered by the competitors plus analyse in depth the technical documentation, trace the logs etc. A tester’s work requires regular updates.

**9. As a tester you are responsible for the product’s quality.**

By clicking on “Test passed” in Jira, you confirm that a specific functionality and, by extension, the entire product, meets the requirements. You are some sort of a quality controller and this is more than just checking if an application works as planned. As a result of your work, a product wins market trust while its effectiveness improves the corporate owner’s reliability.

**10. The position of a manual tester is the first step; there is always more**

Later on, you can branch out into automatic testing, QA or even programming. The more testing tools, technologies and programming languages you know the better. Consequently,  you strengthen your position on the job market. Your opportunities for growing, learning and enhancing your skills  are limitless.

large_dlaczego-praca-testera-moze-byc-ciekawa.png

medium_dlaczego-praca-testera-moze-byc-ciekawa.png

small_dlaczego-praca-testera-moze-byc-ciekawa.png

thumbnail_dlaczego-praca-testera-moze-byc-ciekawa.png

dlaczego-praca-testera-moze-byc-ciekawa.png

A manual tester: 10 reasons that make this job interesting

a-manual-tester-10-reasons-that-make-this-job-interesting

Analysts agree that in 2021 and the subsequent years, the software testing services market will flourish. How will that affect the entire IT industry? Which business areas will be most impacted by this growth? Will the effects be always positive?

The optimistic forecasts for the software testing services market are coming true as we speak. According to Marketsandmarkets research company which has produced its forecast on the basis of indicators from 2016, in 2017-2022 the value of this specific market will grow to $50.14 billion with the compound annual growth rate (CAGR) amounting to 13.5%.

In 2020, Technavio published its report on “Software testing services market by product, geography and end-user. Forecast and analysis 2020–2024”. According to the report, in the four years the market value of the software testing services market will grow by $ 81.73 million with the CAGR amounting to 12.62%:

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

The two above mentioned research companies also agree that North America will be the region with the biggest growth potential on the software testing services market. The related division of power has been illustrated by Marketsandmarkets in the following manner:

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

## The software testing services market

In an article for Medium.com, Astasia Myers published a diagram which shows the major dividing lines on the software testing services market. It also provides a picture of the growth potential of the market’s specific parts:

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

The fastest growing areas of the software testing services market include test automation (17%CAGR) and API testing (19%CAGR). Testing services have the smallest annual growth rate (13%CAGR) but enjoys the biggest value ($50 million).

## The possible business outcome of the processes

In order to foresee the outcome, the growing shares of the specific parts of the market need to be viewed from the perspective of the trends in software production. Here, the ever so popular DevOps and Agile methodologies play a significant role. The latter methodology was indicated in the latest report “State of the Agile 2019” as the most frequently applied in unit testing. Both methodologies enforce a quick rate of code development, at the same time placing strong emphasis on its quality and reliability. In order to ensure the best possible processes of monitoring quality and detecting errors in the resulting solutions, more and more often managers decide to automatize the work of testers and QA. This has been confirmed by the results of a survey carried out by Capgemini and published in “World Quality Report 2019-2020”:

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

The report’s authors draw attention to the fact that the need to increase work automation will involve increasingly advanced technologies for creating the right tools. Here, solutions based on AI and machine learning will have an important role to play.

Which solutions are the most popular among managers who want to streamline and accelerate tests in the DevOps and Agile environment? In a questionnaire developed by Capgemini, tools for automated tests were indicated most frequently. They were followed by the BDD (behaviour-driven development) which should not come as a surprise in the light of its benefits in solving complicated business problems and making decisions about the types of tests which are best for a specific situation:

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

The above chart shows also a third trend which has lately gained in popularity as the Agile – CI/CD methodology is developing. In the testing context it is continuous testing i.e. continued exchange of feedback between teams of developers and testers. It is possible on condition that a majority of the software testing processes are automatized. Only then the code quality can be effectively and sufficiently quickly checked.

These benefits have been appreciated in the IT industry for several years as presented below in a cross-cutting summary of the biggest benefits of automatizing the process of software testing. Every year, their value grows. Interestingly, in 2019 managers indicated better control and transparency of the supervised processes as the most appreciated value added resulting from automation:

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

## The financial outcomes of the changes in the software testing services market

The development of automation tools has also decreased the costs of testing as evidenced by the summary below:

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

How was it possible to substantially decrease testing-related costs? The report provides information about employing:

- solutions for cloud testing which lower the costs, at the same time increasing the effectiveness and flexibility of the teams involved
- virtualization,
- Agile and DevOps methodologies,
- automation,
- shift-right testing i.e. testing is performed shortly before a solution goes live. Of course this does not exclude agile methodologies or code review in sprints, preferred by Agile.



large_bb-8-0.png

medium_bb-8-0.png

small_bb-8-0.png

thumbnail_bb-8-0.png

bb-8-0.png

The software testing services market and the business outcomes of its growth in 2021

the-software-testing-services-market-and-the-business-outcomes-of-its-growth-in-2021

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.

## 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)

## 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.png

medium_bb-7-0.png

small_bb-7-0.png

thumbnail_bb-7-0.png

bb-7-0.png

Want to introduce automated tests in your organization? Here are 5 challenges that you have to face

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.

## 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.

## 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.

## 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)

## 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.png

medium_bb-blog-6.png

small_bb-blog-6.png

thumbnail_bb-blog-6.png

bb-blog-6.png

Application tests, BugBug vs Selenium IDE

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

Blog about test automation

Features

Pricing

Roadmap

Case studies

Privacy policy

Terms of service

About us

Book a demo

Contact

Get more tips and product related content. Zero spam.

Don't miss any updates

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_Open Graph 1200x630 3.png

medium_Open Graph 1200x630 3.png

small_Open Graph 1200x630 3.png

thumbnail_Open Graph 1200x630 3.png

Open Graph 1200x630 3.png

Updates

Test Automation Expert and Test Architect. He is a seasoned tester who can’t stay long in one place. He is looking for perfection and a place to challenge his skills.  He gathered experience working for different companies with different working models, From small to big corporations, From Products via In-house development to software house. Thanks to that he has a wide perspective on testing quality and delivering value.\

[linkedin.com/in/wyrodek/](https://linkedin.com/in/wyrodek/){ref="nofollow"}

large_https://i0.wp.com/wyrodek.pl/wp-content/uploads/2017/01/T1A0194.jpg

medium_https://i0.wp.com/wyrodek.pl/wp-content/uploads/2017/01/T1A0194.jpg

small_https://i0.wp.com/wyrodek.pl/wp-content/uploads/2017/01/T1A0194.jpg

thumbnail_https://i0.wp.com/wyrodek.pl/wp-content/uploads/2017/01/T1A0194.jpg

https://i0.wp.com/wyrodek.pl/wp-content/uploads/2017/01/T1A0194.jpg

Maciej Wyrodek

Testing can be difficult, it is hard to master, there are many questions and many issues we can face with each new feature, each new story. Every day, testers need to decide what to test, how to test, what to automate, and what risks to accept. These decisions are hard and require a lot of experience. Fortunately, there are techniques, heuristics, and models which can help with planning tests. One of the oldest and still very useful techniques is **Agile Testing Quadrants** (**ATQ**). it is a simple table that helps us select the tools we need to use, depending on the required outcome. In this article, we will look into the history of Agile Testing Quadrants, their uses, and limitations. We will also discuss the attempts at modernizing it.

![Agile-Testing-Quadrants](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/Agile_Testing_Quadrants_4b2d044860.png)

[TABLE_OF_CONTENTS]


## Agile Testing Quadrants or Agile Testing Matrix?

First, we need to clear one thing: as with everything in IT, even this simple table needs to have many names! Chances are that you will come across it as an Agile Matrix, Testing Matrix, Testing Quadrants, or Agile quadrants. All of them refer to the same thing. The only exception is the Agile Testing Matrix which may refer to both Agile Testing Quadrants and its precursor the Named Agile Testing Matrix. 

![Testing matrix](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/test_matrix_00ac277513.jpg)


## The Story of Matrix

When speaking about **Testing in Agile**, there is probably not a single more important person to its development than [Lisa Crispin](https://lisacrispin.com/) and [Janet Gregory](https://janetgregory.ca/). Their book, [Agile Testing](https://www.goodreads.com/book/show/5341009-agile-testing), has helped many testers. [Testing Pyramid ](https://bugbug.io/blog/software-testing/testing-pyramid-a-successful-approach-to-test-automation/) was born while [Mike Cohn](https://twitter.com/mikewcohn) tried to explain the nuances of automation to Lisa’s team (*Experience of Test Automation - chapter 1 Section 1.3.*) Agile Testing Book played a key role in the popularization of Agile Testing Quadrants, where the creation of ATQ is often misattributed to this wonderful duo. As Lisa Crispin explained in [her blog](https://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/) - they improved on the older concept by [Brian Marick](http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2) - an Agile Testing Matrix created as part of his blog series presenting his vision of testing in Agile. So Agile Testing Quadrants have almost 20- year-long history and they are still one of the best models used for testing.

## The Usefulness of Agile Testing Quadrants

Agile Testing Quadrants have two axes which split the matrix into 4 quadrants. Both axes pose the same questions, namely **What is the goal of your testing?** The major difference between the two axes is the flavor of the question: the horizontal axis asks what is currently more important: helping the team to deliver faster or ensuring that the product is as good as possible? the vertical axis asks if we are concentrating on the aspects of technology, ensuring that everything is working well, or are we looking from the perspective of business and customers, making sure that our program is worth using? Obtaining both answers points to one of the Quadrants with a list of useful examples. This can be a little confusing, so let’s look at some of the examples.

### Example 1: E-commerce shop

Let’s say we have e-commerce shop development that is going nicely. However, there is one enormous risk on the horizon, namely quite a lot of features, each tested separately so no one is sure how they will work in the real world. The team believes that the standard paths will work. However, no one is sure what kind of edge cases will come from the real world.

Looking at our matrix we can see that problem is definitely business-facing - we don’t know what the user will do. We also need to make sure that our product will handle it, ergo - Critique Product.
Looking at it we land in Q3  where we have propositions of the following techniques:
 - Exploratory Testing
 - Scenarios
 - Usability Testing
 - User Acceptance Testing (UAT)
 - Alpha/Beta Testing.

So our goal is to find edge cases. Looking at the list, all the techniques could prove helpful. But some may require too much investment so late in the developments (Scenarios). Some are a poor fit for an e-commerce shop (alpha/beta testing, UAT). Which leaves us with Usability Testing and Exploratory testing.
ATQ is not an extensive matrix, it contains only examples of techniques rather than a complete list. For example, a different technique that could help is [Dogfooding](https://en.wikipedia.org/wiki/Eating_your_own_dog_food) where company employees themselves use a product to satisfy their everyday needs.

### Example 2: Messaging App

A company has made a very successful messaging app, but now they are facing the problem of success. Their small app, designed for a small community, is gaining popularity fast. The team feels that the app is not ready for all this attention. The situation is clear - from a business perspective, everything works well enough. The risk is technology, and again the problem lies in the critique of a product. This leads us to Q4 where we have, among others, *Performance* and *Security* testing. There is no doubt that we will need both. Lots of users mean a load on an application and nothing will kill its momentum like failing servers. Security is also important. Attention also attracts bad actors who will try to exploit the system.

### Example 3: Early Development.

The team suffers a problem of poor quality code. In the case of some features, developers are reluctant to fix a familiar bug because of the high risk of breaking something else. One glance at the ATQ shows that we need something to support the development and its technology which leads us straight to Q1. Both Unit Test and Component Test would improve team productivity and code quality.

The above example may give a wrong impression that Agile Testing Quadrants are used to select one and only one tool. **THIS IS NOT TRUE**: we can use ATQ for each goal of our testing, for each need, for each problem we are trying to address. However, trying to improve too much at once may lead to too much-wasted effort and no result. Concentrate on one subject at a time.

## Evolution

While the concept of AQT has changed little over the years, the techniques in each quadrant have evolved, for example: 

![Updated Agile Testing Quadrants](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/updated_atq_06346e83b7.jpg)

In [More Agile Testing](https://www.informit.com/articles/article.aspx?p=2253544), the author presented a new version with Micheal Hüttermann changes, with a circle of *Outside-in, Barrier-free, Collaborative in the middle of the quadrants*. The author believes that it will stretch beyond any quadrants. The main issue with this update is that it is a catchphrase and provides no information about the tools and techniques that may help.

![Agile Testing Quadrants next iteration](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/Agile_Testing_Quadrants_next_d74569f53c.jpg)

A few years back, [Lisa and Janet](https://agiletester.ca/applying-the-agile-testing-quadrants-to-continuous-delivery-and-devops-culture-part-1-working-towards-continuous-delivery/) also presented a version more in line with DevOps. This version adds a lot more techniques to each of the quadrants but also changes one side, from *Supporting Team to Guide Development*. While it may seem like a single name change, fortunately, the original name leads to many misunderstandings and the new label is much more descriptive. 

![RST Agile Testing Ecosystem 1.1](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bb_ATQ_1fb44a3b67.png)


Michael Bolton and James Bach have also made the [above version](https://www.slideshare.net/HcmcStc/the-new-agile-testing-quadrants-bringing-skilled-testers-and-developers-together-james-bach) which is compatible with Rapide Software Testing. Most of these updates are only fine-tuning, adding elements that their author thinks are better in this context. So which one to choose? It is the author’s opinion that the original version holds well? It is still relevant, because:

## It is just a model.

“All models are wrong, but some are useful” is an old aphorism attributed to George Box. And it is important to bear it in mind in the case of Test Pyramid, Agile Testing Quadrants, etc. Models are what they are: models which need to help us think about a problem. **They are not the golden rules that should be followed in the letter**. They provide us with a good way of tackling the problem. But it is up to the user to decide if a specific model will work for a specific problem.

## Summary

The **Agile Testing Quadrant** is a model which is nearly 20 years old. Owing to its simplicity, it is still relevant. It is a great tool for teams and testers who have a problem with choosing the right testing method. For junior testers, it is a great place to look into different tools and approaches, and for more advanced testers it will be an excellent aid in building or improving the testing process.

large_beetle-g2d0bd3bb5_1280.jpg

medium_beetle-g2d0bd3bb5_1280.jpg

small_beetle-g2d0bd3bb5_1280.jpg

thumbnail_beetle-g2d0bd3bb5_1280.jpg

beetle-g2d0bd3bb5_1280.jpg

Agile Testing Quadrants

agile-testing-quadrants

A self-taught software QA Engineer working at an IT start-up, Dominika has experience in
web testing. Currently, she is focusing on developing her test automation skills with Python.
Apart from programming, she likes to make pottery and cook vegetarian delicacies.\

[linkedin.com/in/dominika-nykiel](https://linkedin.com/in/dominika-nykiel){rel="nofollow"}

medium_https://media-exp1.licdn.com/dms/image/C5603AQH6NBuKQg3UWw/profile-displayphoto-shrink_800_800/0/1637439945009?e=1646265600&v=beta&t=IwBmGAWmNdXvprRNzsLB-PbwuPFXBTKFfTLP612yEuA

small_https://media-exp1.licdn.com/dms/image/C5603AQH6NBuKQg3UWw/profile-displayphoto-shrink_800_800/0/1637439945009?e=1646265600&v=beta&t=IwBmGAWmNdXvprRNzsLB-PbwuPFXBTKFfTLP612yEuA

thumbnail_https://media-exp1.licdn.com/dms/image/C5603AQH6NBuKQg3UWw/profile-displayphoto-shrink_800_800/0/1637439945009?e=1646265600&v=beta&t=IwBmGAWmNdXvprRNzsLB-PbwuPFXBTKFfTLP612yEuA

https://media-exp1.licdn.com/dms/image/C5603AQH6NBuKQg3UWw/profile-displayphoto-shrink_800_800/0/1637439945009?e=1646265600&v=beta&t=IwBmGAWmNdXvprRNzsLB-PbwuPFXBTKFfTLP612yEuA

Dominika Nykiel

An aspiring technical writer with an interest in testing and a knack for learning languages.
Former journalist, translator, and editor, whose work was published in several magazines. She
speaks French and Norwegian and is looking forward to learning Spanish.\

[linkedin.com/in/aleksandra-spilkowska](https://linkedin.com/in/aleksandra-spilkowska){rel="nofollow"}

large_a_spilkowska_cropped.jpg

medium_a_spilkowska_cropped.jpg

small_a_spilkowska_cropped.jpg

thumbnail_a_spilkowska_cropped.jpg

a_spilkowska_cropped.jpg

Aleksandra Spilkowska

Ask any QA Engineer worth their salt about their Chrome extensions - they probably have a bunch of them ready to go at all times. And for a good reason! They can come in handy when you need to edit a screenshot, clear a browser cache, or test a website’s performance. Saving some clicks and double-checking for hidden issues means that a QA’s everyday life is much easier, and it leaves more time to focus on spotting all the bugs before the final product is released. Get ready to pimp your browser with some of the most useful Chrome extensions for testers!

[TABLE_OF_CONTENTS]

## [Monosnap](https://chrome.google.com/webstore/detail/monosnap/lhgadannddhdpkfhfjjgcpdjhpmjhkfm){rel="nofollow"}

![Monosnap](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/monosnap_a19cbb03a1.png)

A reliable recorder is a must-have in your virtual toolbelt. While most recorders are programs, Monosnap is an extension so there are extra advantages, especially if you tend to switch between devices a lot. You can capture a GIF or a video, a selected area of the screen, and of course a fullscreen. There is also a set of basic editing features such as drawing, creating marks, highlighting details, or hiding sensitive data. No watermark in sight! Monosnap works with both Windows and iOS.

## [Clear cache](https://chrome.google.com/webstore/detail/clear-cache/cppjkneekbjaeellbfkmgnhonkkjfpdn?hl=en){rel="nofollow"}

![Clear Cache](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/clearcache_ec20bd645f.png)

It does just what the name promises: clears your cache and browsing data. What's the catch? There isn't any! You can do it all with a single click. This extension allows you to choose how much data you want to clear and from which domains you want the cookies removed. Neat!

## [Bug Magnet](https://chrome.google.com/webstore/detail/bug-magnet/efhedldbjahpgjcneebmbolkalbhckfi){rel="nofollow"}

![Bug Magnet](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/bugmagnet_115b949485.png)

For many, this is a go-to extension for exploratory testing. Will it do all the work for you? Unfortunately, the answer is no, but it sure helps a lot. This exploratory testing assistant will offer you access to common boundaries and edge cases. It works on input fields, text areas, content editable DIVs, and more. This means that you don’t need to rack your brain to think of an email, postcode, or address anymore, Following selection of the value, Bug Magnet fills in the field you need. It’s an open-source solution and you can customize it to your liking.

## [PerfectPixel](https://chrome.google.com/webstore/detail/perfectpixel-by-welldonec/dkaagdgjmgdmbnecmcefdhjekcoceebi){rel="nofollow"}

![Perfect Pixel](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/perfectpixel_6d7ba283bd.png)

This extension is very convenient for frontend testing, especially when there is a need to compare a website design with frontend changes. It adds a semi-transparent overlay over the top of the developed HTML to make it perfect - down to the last pixel. The position, size, and opacity level are no longer your enemies with this handy extension.

## [Web Developer](https://chrome.google.com/webstore/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm){rel="nofollow"}

![WebDeveloper](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/webdeveloper_827b9ef3f7.png)

The Swiss Army knife of web developing tools, this extension will equip your browser with a toolbar full of functional items. Cookies? Managed. Information? Anchored. Web elements? Highlighted. CSS? Edited. Forms? Populated. Of course, some tools work better than others, and you aren’t going to use all of them equally, just like with a real Swiss Army knife (fish scaler, anyone?) but it’s still a quite useful quality multitool.

## [Lighthouse](https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk?hl=en){rel="nofollow"}

![LightHouse](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/lighthouse_f51d97d7ce.png)

Yet another multi-use extension, it runs overall non-functional tests on websites. The metrics you can audit are performance, SEO, best practices, accessibility, PWA (Progressive Web Application). Lighthouse auto-generates a clear, simple report which lets you know how well your website performs for an average user. The audit will instantly highlight the areas that need improvement and will give you a general overview of the website’s functionality.  

## [Postman Interceptor](https://chrome.google.com/webstore/detail/postman-interceptor/aicmkgpgakddgnaphhhpliifpcfhicfo?hl=en){rel="nofollow"}

![Postman Interceptor](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/postman_interceptor_a0d0b62ce1.png)

Assuming you have heard of Postman (if you haven’t, [go check it out now](https://www.postman.com/){rel="nofollow"}!), you might be interested in further improving the workload with this practical extension. The Interceptor sends requests which use browser cookies to the Postman app without using a proxy. This is an advantage for testing APIs, as Interceptor makes it possible to send headers (typically restricted by Chrome).

## [SelectorsHub](https://chrome.google.com/webstore/detail/selectorshub-xpath-plugin/ndgimibanhlabgdgjcpbbndiehljcpfh){rel="nofollow"}

![SelectorsHub](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/selectors_hub_624439475b.png)

Whether you’re a seasoned tester or just starting your journey, this extension can be a worthy addition to your collection. SelectorsHub is easily the top-rated XPath & cssSelector plugin available now, and it lives up to the hype. It helps write and verify XPath and cssSelector in less than 5 seconds, auto-suggests attributes, text, etc. SelectorsHub not only supports the iframe and the SVG elements, it is also the only extension supporting shadowDOM (at least for now). And if you value a proper error message, you’ll get one for missing elements in the selectors. This impressive extension is indispensable not just in test automation but also to users of codeless, smart testing tools.

## Summary

That’s it! We hope you have enjoyed our pick. Of course, this list is in no way comprehensive, as new extensions are added to the Chrome web store all the time. While the choice might initially seem overwhelming, it is highly recommended to checkout various extensions and find the ones that suit your needs best. Hopefully, this article will be a good starting point for these explorations!


large_leaf-gfcaac0297_1280.jpg

medium_leaf-gfcaac0297_1280.jpg

small_leaf-gfcaac0297_1280.jpg

thumbnail_leaf-gfcaac0297_1280.jpg

leaf-gfcaac0297_1280.jpg

Best Chrome Extensions for Software Testers

best-chrome-extensions-for-software-testers

Professional Quality Evangelist, experienced in testing web and mobile applications.\

[linkedin.com/in/kinga-witko-b5bba659/](https://www.linkedin.com/in/kinga-witko-b5bba659/){ref="nofollow"}

thumbnail_https://pbs.twimg.com/profile_images/1410220490434744328/eqEl_DXL_400x400.jpg

https://pbs.twimg.com/profile_images/1410220490434744328/eqEl_DXL_400x400.jpg

Kinga Witko

As recent data show (https://gs.statcounter.com/browser-market-share), Chrome is the most used browser in the world, representing over 64% of the browser market.

The Chrome Developer Tools (DevTools for short) are a set of web authoring and debugging tools built into Google Chrome. The DevTools provide web developers with improved access to the internals of the browser and their web application. Did you know that they are quite useful for the Testers as well?

[TABLE_OF_CONTENTS]

## Give it a try in testing the web

There are multiple functions in which Dev Tools may support your testing, not only limited to:
- resizing (change user agents)
- screen rotation
- using Console: Debug JS – CSS, Logs
- network manipulation: Throttling, Performance
- security testing
- location change
- looking for elements (id)
- taking screenshots
- clearing cache
- test recording
- database checking (IndexedDB  - a transactional database system, like the SQL-based RDBMS)

## How to enter?
To open the developer console in Google Chrome, open the Chrome Menu in the upper-right-hand corner of the browser window and select **More Tools > Developer Tools**. 

![https://i.imgur.com/fIMFZgz.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/f_IMF_Zgz_bea99d61c0.png)

You can also take shortcuts:

**On Mac:** \
Command+Option+I 

**On Windows/Linux:** \
F12 or Control+Shift+ I


You can dock your DevTools window to the right of your viewport or at the bottom of the screen, depending on your preferences. By default, DevTools are docked to the right of your viewport. You can also dock to bottom, dock to left, or undock to DevTools to a separate bottom.

![https://i.imgur.com/13JgWaO.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/13_Jg_Wa_O_2e4ec2b59e.png)

It is possible to reorder the panels so they suit your needs best. Click and drag a panel tab to change its ordering. Your custom tab order persists across the DevTools sessions.


## How to start
Chrome DevTools can be used in web and mobile testing. Every Tester should take advantage of it because these tools are free and easily accessible. 
Here is a list of the most useful ideas for testing purposes. Maybe you'll come up with new ones?

### Resizing and Rotating
It is important to check the UI of your website on mobile browsers and multiple screen resolutions. For some people, it’s “Just the UI” testing but do remember that nowadays a lion’s share of the market (54.37%) belongs to mobile browsers ([stats here](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet)).

![Browser market stats](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/image7_6614995465.png)

Use the **Responsive** option in Chrome DevTools to make sure that a majority of different screen resolutions is covered.

You can select the desired resolution from the dropdown list of many different mobile devices to test against different screen sizes. DevTools tell us the screen dimensions of the device in the top menu as well. What is more, you are also able to rotate the screen. Screen rotation is a common cause of mobile bugs, as the mobile website layout changes when the screen is rotated, and page elements may need to reload. While it won't pretend to be the real device, it will give you a lot of hints on what other tests should be performed on your application.

![DevTools resizing and rotating](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/image6_02544f7f6a.png)

### Console - debug

Either a developer or a tester can debug a website on a mobile device.
In the JavaScript **Console** you can find all ranges of errors in the application.
As the complexity of JavaScript applications increases, developers need powerful debugging tools to help quickly discover the cause of an issue and fix it efficiently. The Chrome DevTools include several useful tools to make debugging JavaScript less painful.

![DevTools console](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/image9_aee0e7d98e.png)

### Network and Throttling
The **Network** option allows you to observe the order and time of loading elements. You are provided with insights into resources that are requested and downloaded over the network in real-time. It is of special importance in mobile testing as users expect mobile apps to work smoothly and fast.
1. Open DevTools (F12)
2. Click the ‘Network’ tab
3. Click the No Throttling dropdown
4. Select the type of connection you want to imitate
5. Reload the page to see the assets downloading at that connection speed.

The Network tab in Chrome DevTools has an option to faux throttle your network, so you can experience what your users might see visiting your website on 3G, Offline, or with your real speed connection. The **Throttling** option is also useful for visualizing how fonts are loaded. The lower the speed, the more end-user frustration on your website.

In this section, in the left upper corner, there is also a record button that allows you to preserve all the activities (logs) and compare them with other test results.

![DevTools network throttling](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/image8_9e4f1f589f.png)

### Elements
The Elements panel allows you to see everything in one DOM tree and fosters inspection and on-the-fly editing of DOM elements. It is also a useful option for automating tests.
You can always access this option for a specific element on the website:
1. Mouse-over the element (word, button, etc.)
2. Right-click on the mouse
3. Click Inspect

![DevTools Elements](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/image12_3c7cc49608.png)

In the Chrome DevTools panel, you’ll be directed to the very element in the DOM structure.
The **Elements** tab is extremely useful if you need to play around with CSS in your application. Sometimes you need to switch on and off some buttons/lists/checkboxes. It is possible in this section to select the desired elements in the DOM structure and edit them in the Styles sub-section. 

There is also a handy way of locating a node element in the DOM using a CSS selector. From the elements panel, use a keyboard shortcut (win: Ctrl+f, mac: Cmd+f) to open up the search input UI. Enter a CSS selector into the search input UI.

### Clear Site Data
Cache clearing is one of the activities that might be used daily in the testing exercise. Chrome DevTools can successfully help you out.
Press Control+Shift+P or Command+Shift+P (Mac) to open the Command Menu and then run the Clear Site Data command to clear all data related to the page, including Service workers, localStorage, sessionStorage, IndexedDB, Web SQL, Cookies, Cache, and Application Cache.
If you don't want to delete all site data, you can control what data are deleted from **Application >  Storage**.

![DevTools application storage](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/image10_3278490be8.png)

### Location
This is a fantastic functionality! It shows how to test an app that must work in different locations and presents a map for you - teleportation has not been invented yet! There is an option in DevTools that allows you to mimic location. The option is slightly hidden:
1. Open Dev Tools
2. Click the action bar in the top right corner of the screen
3. Select More Tools
4. Click Sensors

Now you can provide a website/application with your desired geo-coordinates and pretend you are there. Remember about reloading the page with every change to the coordinates.

![DevTools location](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/image11_d0b495da83.png)

### Performance monitor

In the same **More Tools** panel you can find the Performance Monitor. Use it to get a real-time view of various aspects of a page's load or runtime performance, including:
- CPU usage.
- JavaScript heap size.
- The total number of DOM nodes, JavaScript event listeners, documents, and frames on the page.
- Layouts and style recalculations per second.

There is also a separated **Performance** tab in the upper menu, which shows the Compute Intersections in the flame chart. These options can help you to identify the events and debug on its potential performance overheads.

![DevTools Performance](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/image13_7323c216c2.png)

### Screenshots
There are two ways of taking screenshots when working with DevTools:

**Screenshots of a portion of the viewport**

1. Click **Inspect** or press Command+Shift+C (Mac) or Control+Shift+C (Windows, Linux) to enter Inspect Element Mode.
2. Hold Command (Mac) or Control (Windows, Linux) and select the portion of the viewport if which you want to take a screenshot.
3. Release the mouse. DevTools downloads a screenshot of the selected portion.

**Screenshots of specific HTML nodes**

1. Select an element in the Elements tab
2. Open the Command menu
3. Start typing node and select Capture node screenshot. DevTools downloads a screenshot of the selected node.

## How to operate on mobile devices?
Last but not least, if you want to test the mobile option, it might be useful to know how to attach your device to Chrome DevTools.

1. Install the Chrome browser on your PC
2. Get hold of an Android smartphone
3. Find a USB cable to connect them
4. Plug your device in.
5. Type chrome://inspect in the Chrome browser.

On mobile devices, you can take advantage of Chrome Developer Tools in a very similar way to web testing. You can perform throttling, look for elements, or check the network connection. What is more, you are also able to check things in a database through Stetho (*debug bridge for Android applications*). 

If it doesn’t work right away - all you need to do is enable the developer options:
1. Open settings
2. Go to System> About phone>Version number
3. Tap on it 7 times (that’s right)

And there you go.
1. Open the developer options
2. Switch them on
3. Allow USB debugging

From now on the device should be visible in Chrome/inspect.
 
There is much more to Chrome DevTools - all you need is to explore the options. Each year, Chrome adds new functionalities to its extensions, including DevTools. The number of options expands and allows not only for better development but also better testing without multiple external tools or applications. For basic functional testing, Chrome DevTools is more than enough. They just require time to learn how to best use them and to benefit from all the resources they offer. 


large_weevil-g22fd4954a_1280.jpg

medium_weevil-g22fd4954a_1280.jpg

small_weevil-g22fd4954a_1280.jpg

thumbnail_weevil-g22fd4954a_1280.jpg

weevil-g22fd4954a_1280.jpg

Chrome DevTools introduction

chrome-dev-tools-introduction

[TABLE_OF_CONTENTS]

## Why Agile?

The word 'agile' became trendy years ago and the eagerness of using it in projects in organizations remains high even today.

We have Agile dev teams and Agile testers, Agile projects. Unfortunately, the term 'agile' has become a convenient replacement for lack of requirements, lack of documentation,  or, just basically,  a pure mess.

On the other hand, Agile means nothing more than a way of working well to reduce the cost of change and uncertainty.

## Traditional vs. Agile

Talking about methodologies is always good as it leads to spotting the difference between traditional - usually phased or gated (Waterfall) ways of making software,

![phased_or_gated](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/phased_or_gated_f4e60a9340.png)

as opposed to iterative, where every story is expanded, coded, and tested with a possible release after each iteration.

![agile.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/agile_4b0f766f35.png)

## The Agile change

Agile testing influences the whole process of making software, including:
- Whole Team Approach
- Coding and testing as a single process
- Feedback, collaboration
- TDD/ATDD practices
- Test-infected developers
- Better tools
- Better designed tests 

It also allows a tester to be an actual part of the team rather than a siloed unit in an organization. A tester is not a gatekeeper or quality police but he/she provides valuable input into each phase of development.

In real life, it means that an Agile tester takes part in all team meetings, provides the input, asks questions, is invited to pair programming sessions with developers, and takes the same responsibility for the code and product as any other member of the team. Of course, it requires from the Tester a larger skill set, great communications skills, and at least basic knowledge of coding and test automation.

## How to include testing?

There are many ways for extending Test Specialist responsibilities in an Agile team. They don’t necessarily include testing itself but also include a vast range of communication, presentation, and consultation activities.

### TDD
Traditional testing relies on ample documentation. Agile testing is an approach to a process that mimics the principles of agile software development, especially where:
- Testing is done more often,
- The whole team knows how and what to test, it is possible to share tasks
- Testing relies less on documentation and more on team member collaboration.

One of the great examples of how to include testing into an agile process is to start from Test-Driven Development. The TDD methodology is a software development process that emphasizes the need for good software quality. Traditionally, a developer has written the code, and then the testing department has examined it and reported bugs. Moreover, in TDD, it is the developers who write unit tests first before even writing any code that would complete a user story.

Of course, it is possible to pair in every task, so in most situations, it is possible for a developer to work together with a Quality Expert and think of possible test cases.

The tests initially fail until the developer writes a minimal sequencet of code to pass the tests. As the next step, the code is refactored to meet the quality requirements of the team.

It is possible to implement TDD into the Scrum or Kanban type of working. The point is to focus on testing and quality in general. Additionally, it makes testing more agile by moving most of the testing procedures to the early stages of the development lifecycle. When writing test scenarios at the beginning of each story, developers need to understand the requirements and cooperate with the other team members. This minimizes unnecessary code creation and also resolves any doubts at the beginning of the development cycle.

### Automate regression testing
Regression testing is yet another type of software testing to verify if the software, previously developed and tested, still performs correctly after changes or interface with other software. Changes may include software enhancements, patches, configuration changes, etc.

If regression testing in a software project is supposed to make any sense - it has to be performed as often as possible - at least on a sprint basis. Ideally - daily. Why? Because stable test suites would detect any unexpected system behaviors and react to a major change.

Small systems usually have checklists rather than test suites - large ones - even ‘monstrous’.
Deciding what should be automated is always tough because having automated test scripts may not be something that the team could present  to the customer. The question is rather: WHY would you want to automate anything?

The problem is that sometimes, automated suites are not reliable or trustworthy and the effort to keep them alive is quite hard. Test suites have to be regularly maintained and extended. Automation is great for this task but it is just another tool – not the purpose of the project.

Most importantly, even in the Agile environment, all tests need to be reviewed often and prioritized daily.

No one will benefit from extended long-running test suits. What is more, automated regression tests should be efficient and alert early in the development phase, to be of better quality and truly agile.

### Visualize testing activities
One of the great examples of working with a Scrum or Kanban board is to visualize all the tasks in the project, not only the developer’s ones.

It is a great idea for the team to select even small, repetitive manual test tasks as prospects for automation. All these ideas and tasks can be placed on a board and addressed accordingly. It doesn’t mean that a tester is responsible for doing it.

Besides, in cross-functional Agile teams, there is a great opportunity for the testers to learn more coding and test automation, and for the developers to pay more attention to code quality.

### Communicate
Irrespective if a project is handled in Scrum, Kanban, or another Agile manner – the key to success is (?) the communication in the team.

Also, there are useful respective tools which help  teams deliver faster and fight for better quality and efficiency. CI/CD build tools can be easily integrated with common tools for communication such as Slack, and can inform automatically that the build is done or if the build has failed. It can also be helpful in automated regression and getting the test result accessible to everyone.

### Avoid single used solutions
The responsible software development process requires planning and adjusting, not working “here and now” and then fixing production bugs. Single–used solutions in a code, in testing, unnecessary work done in the cutting-corners mode to satisfy the customer’s demands are the things that often  boomerang in the future.

When a manager  approaches you and asks for doing development quickly instead of properly – “because it’s Agile” – remember that this is nothing else but a start of technical debt.

Discuss, propose, think, but when you agree on a shortcut – for example skipping performance testing or postponing some exploratory sessions due to lack of time – be aware of the consequences in the future.

You’ll save some time now, but you’ll be in real trouble soon.

### Explore
As Elisabeth Hendrickson said in her book “Explore it!”:

 “No matter what your job title, you most likely find yourself testing regularly. Testing is an integral part of creating anything.”

This is so true in Agile. Exploratory testing is simultaneously designing and executing tests to learn about the system, and then using your insights from the last experiment to feed the next.

Exploratory testing involves scouting around areas that the net of other forms of testing doesn’t cover. A tester interacts with the implementation, designing, and executing tiny experiments in a rapid succession.

### Give and receive feedback
Every Agile Team uses feedback to improve. It does not matter whether feedback is provided daily or during longer sessions such as Retrospective or Planning. Testers are expert feedback providers, they usually have overall knowledge about the product and can advise at the beginning of brainstorming or at the end of the iteration to improve further work. Feedback lets the team make course corrections.

### Testing in Scrum
How to incorporate testing in Scrum? 
The Scrum Guide doesn't say anything about testing because it's "a framework for developing, delivering, and sustaining complex products". It transcends the type of product that the team is developing, and the types of testing that the team needs to do, or how testing fits into the process is different for producing different types of software products. It does not define a specific “Tester” role, as testing is the whole team’s responsibility.

Of course, there can be a person more focused on delivering high quality, measuring application performance or assuring application security, but this role is not defined by the book. It usually means that when a team decides to work according to Scrum Guide and at the same time, there is an organizatinal role of a “Software Tester” - an expectation might arise that this person should provide guidance for the entire team (or even organization) on how to test software most effectively and lead the others in the field.

## Summary
It is not the choice of a methodology or technology that limits us from raising the quality of the product or including test automation in a daily routine. It is rather a drive that comes from the team and helps everybody to get better at coding, testing, and taking care of the product.

The choice of the methodology is always a process, not a single decision. It requires work and effort from every team member, not only from the tester.

If you have anything to do with test management or quality assurance - this short exercise is great for practicing on a daily basis: start your working day from a short trip around different metrics - nightly builds, code coverage, cyclomatic complexity, etc. Try to explore and add a new flavor to the testing. Every day you can make an important discovery and improve the quality of your work.

