When you start working as a QA/Software Tester, you will find out that you need some tools to help you do your job right. I came to software testing while working as a Frontend Developer for a small start-up. We did not have much of a budget so we used only a couple of tools. However, working for a big corporate client like Volkswagen as I do now means using all different software testing tools. Over the last months, I have collected a few of those handy tools and tried them out. Each tool is good for something slightly different and it shows the complexity of software testing.
I prepared this list of software testing tools as an overview for people who want to change their career to software testing as well as for other Software Testers. I think I got them all. But please let me know in the comments below if I forget some. Also if you are one of the IT career shifters you can check out my article on how to do that here.
1) Jira
Jira is the number one project management/product ownership/bug reporting system in agile teams. It provides an amazing overview of tickets that the team will work on. The Product Owner moves the tickets from the backlog (sort of a to-do list), through refinement (to-do list in detail), to separate sprints (working on to-do list). Each ticket has a workflow included in it which shows who in the team is currently working on it (Developer, QA, Product Owner).
The successful fulfillment of the to-do list depends on how the Product Owner writes tickets. There are usually four types of tickets: epic, story, task, and bug. The epic gives a general idea of a bigger feature to be implemented (signup/login). It includes the business idea behind the feature, ie. what the company/client will get out of having this feature (the company will have logged-in users).
Then comes the story which is the epic broken into smaller pieces (authorization service). The story describes the smaller feature or part of it from the position of the user, i.e. what the user will do/achieve with this feature (user’s password will be authenticated). It is always good to give a broader business background and benefit hypothesis (what will the user get out of it – eg. nobody could sign up under their password) to the story so that the Developers working on it understand it well.
The task is even a smaller piece of the feature. It does not usually need to be refined as the story (meaning it does not need to be broken into more understandable pieces). And then there is the bug ticket which I as a QA write. It describes the steps on how to reproduce the bug and what the expected result should be. I usually add a screenshot, screen recording, or a gif to the ticket to make it as straightforward as possible.
If you have not worked with it yet, you can make your own little project in Jira and learn about it.
2) Developer tools in Chrome
When testing a web application, I always start testing it in Chrome browser. The main reason is the developer tools. I have the console open when I work through the features and watch if any red errors are coming up. It will usually tell me what is happening with the code. Another way to use the developer tools is open the network and refresh the website. Then watch the XHR to see what is being sent and received. Again, whatever is red will tell me where the error can be. If I change the speed to slow I can see how long it will take me to load the application.
I also use the dev tools to see the web application in responsive mode. I can check the layout for mobile, tablet, and all different sizes of computers. This is great when you need to make sure that certain elements are on the certain parts of the webpage.
There are other nifty little things that make my tester life easier, including tracking events, local storage, disabled cache, and sensors to set “my location”. However, that would be for another long article. The main thing is that using dev tools helps me to find the bugs and errors faster than any other browser and that counts!
If you want to learn more about Chrome developer tools you can check their documentation. And do not forgot to test in other browsers as well! 🙂
3) Git
When you have a team of Developers and Software Testers working on the same project you need to be able to have each of them work on a separate version of the project. Github and Gitlab allow just that. I work mainly with Github now but I have tried Gitlab before and it looks similar. Github (and Gitalb) is a platform that allows storing projects on the cloud. That means in case your laptop breaks down (hopefully never though!) the project is still there available. After you create your account on Github, you can clone (sort of download) the project from a certain repository onto your laptop. Then you make a new branch of the project and start working on it. Having your own branch will allow you to work on the project without destroying the main branch.
Github actions (and Gitlab continuous integration) allow for automation of the Developers’ and QAs’ steps. Usually, your DevOps builds pipelines to automate the build, test, and deployment to save your time. You can also use it to automate triaging and managing issues, releases, and collaboration with the user base. Everything you need to know about Github actions can be found here.
4) Postman
When you need to test how the Frontend (your browser) communicates with the Backend (the server/cloud) through REST APIs. In short, REST (REpresentational State Transfer) API is a path of communication that allows you to create, receive, update, or delete information though HTTP requests (that represent the state of the requested source). There are multiple HTTP request types. You can read about them here.
The main thing is that Postman let you test the communication path fairly quickly. You just choose method (POST, GET, DELETE etc.) and enter the API endpoint – url and it will show you what is happening with it.
5) Cypress
When you get good at manual testing and want to automate some or all of those steps, the easiest way is to use cypress. Yes, you will need to know some JavaScript for it. On the other hand, when you work in tech you should want to strive to learn at least one computer language. Not only will that provide you with more job and higher pay opportunities but also it seems polite to “speak” at least one language of your main coworker – laptop.
When you learn the basics of HTML, CSS, JS, then learning Cypress is quite straightforward, at least at the beginning. The main idea is that you use HTML selectors to find where exactly you are on the webpage and then give those selectors something to do. For example when you are testing a sign up form. You will get a selector for each input and then tell the computer to type something inside the input. After you do this for each input, you tell the computer to click the submit button (again based on a selector of the submit button).
When you get more into cypress it becomes a little bit more complicated but if you break it down into small pieces it will make sense. Anyways, if you are keen to check it out, here is a lot of information.
6) Redux dev tools Chrome extension
If you work with react and redux, it is always handy to download the Redux dev tools extension. It can help you to check what version of the application you are currently on. This comes in handy especially in situations where you are working on a big application that consists of a framework and smaller applications in it. I use it when I need to check whether there is a bug in the configuration of the application within a framework. Knowing configured version helps me to understand the problem better. And usually, the problem is a wrong version of the app.
7) Web developer Chrome extension
Another cool tool is the Web developer Chrome extension. It adds various tools to the browser. For example, I used it when I was checking that there are no duplicate ids on the page. It is also handy to check the HTMLP and CSS attributes and more. Here is to learn more.
8) Axe and Wave Chrome extension
When you work for a big corporation, having an accessible web application is one of the musts. That is why I started to use Axe and Wave Chrome extensions. These tools run through the website and generate a detailed report that will show me where the pain points are. Based on that I can easily write bug tickets and even include a screenshot of the report to point to the places on the web app that need specific attention.
9) Lighthouse Chrome extension
Another great app that helps me to do my work well and fast is the Lighthouse Chrome extension. It also generates a report but includes performance, accessibility, best practices, and SEO. I like the bigger picture I get from this tool and I do some recommendation to our client based on the report.
10) Grammarly Chrome extension
Last but not least is the Grammarly. While I am mainly testing whether the software is functional, I need to also make sure it looks good and has the right spelling. For that reason I use Grammarly Chrome/Firefox extension. I used only the free version as it gives me enough points to keep the web app readable and understandable.
So, I hope this will help you in your Software Tester journey. If you want to learn more about how to become a Software Tester without a tech degree read about it here.
And as always, please send me some comments below :-).
Comments are closed.