A QA tester’s mission is the most responsible one on the project, because he’s the person that the website’s quality depends on. Today, there is also another special mission for one of our quality assurance testers. We asked him to tell us about the QA testing process. So here is the first-hand information, which is always valuable;)
Make yourself comfortable and read about this:
QA testing process stages
Site study
The QA testing process begins with a site study. We literally push all the buttons, fill in all the forms, open all the links to check if the site no obvious errors. In addition, we use specific analyzers to check the site for broken links or problems with JS styles, as well as to assess its overall performance.
If the site involves registration, we register and see whether the system behaves as expected (we expect a confirmation email or an email with one-time password/login for the personal account). If nothing happens, then we may have found the problem. Next, we see how the site looks in an anonymous browser window (and check whether it’s the same as in the non-anonymous one). If there is a difference, we need to determine the reason (the difference may be is supposed to be there).
Usually, a lot of bugs can be found already at this stage of studying the site, for example, if we open the site on a mobile phone or a browser like Internet Explorer.
Depending on the particular case, there is a list of other actions we can take to further study the website, too.
Collecting the information from client (specs, development reports, mock-ups, etc.)
For future work, it is important to determine the type and scale of the project — for example, it can be an online store with this or that amount of products, categories, pages, languages, etc.
To check whether the site meets the client’s requirements, we have to know them. For this purpose, we study the technical docs provided by the client — these can be mock-ups, specs (technical specifications), etc. The more detailed the documentation is, the more accurate the result will be. If the documentation is absent, we communicate with the customer and create it in process.
It is very important to obtain all possible accesses to the website (login/password to the SuperAdmin profile, SSH access to the server, root access on the server, VPN access (if any), the backup database etc). All this information is necessary for the accurate assessment of how much work needs to be done.
Test planning and estimation according to the previous experience
After examining the site, the available documentation and customer’s requirements, we plan all we need to do and roughly estimate how long it will take. Based on our previous experience, we give a rough estimate of hours per person or (how many hours are needed for the job, if it is done by one tester).
For example, we write that the purchasing will be tested for 50 hours, functional translation functionality will be tested for 100 hours. Remember that the estimate is rough, because we do not yet know what tools and what types of testing will be used (automatic or manual), how many test environments will be available to us and how many people will be involved in the testing process.
By submitting this rough estimate to the customer, we specify some of the issues that may arise will surely arise in the estimation process. For example, the customer may need testing in all browsers, or only in a few that are important to him. Constantly communicating with the customer, we can save considerable time and money. Given all the above information collected, we can provide a more exact estimate.
Testing environment, Testing tools, Resource allocation, Test schedule
Next, we decide on the test environment, i.e. where we will write our test cases: for example, in an Excel file, on paper by hand, on the wall of a cave, or, for example, in TestRails — a specialized system for registering test cases, which is very helpful in information structuring (especially if it there is a lot of it).
We decide so on any server test site, and whether it will be a locally deployed site or on a specialized test server, or whether we will test all changes at once on a live site (do not try this at home :))
Depending on the customer’s needs and budget, we choose the testing type. Testing can be manual or automated, or combined.
So depending on this type, we choose the appropriate tools. When we already have all this information, we can talk to the customer and determine how many people can be involved in the testing process.
Only now we make a schedule of when, what and in what order to test. At this stage, we can make rough working sprints.
Collecting information about development workflow
It should be noted that we are now discussing the workflow for cases where the site comes to us only for testing. Most of our projects are developed and supported by us. However, if the project arrives to us for testing only, and it was built or is still in the process of being built by other web developers, we need to collect the most complete information about the development environment and processes.
We study how the development process is (or was) organized. We communicate with the development team to organize the cooperative process. It is necessary for "integrating" into their workflow and, if possible, automating it — for example, setting up continuous integration (a development methodology that allows us to control the process at any stage by means of the partial automation of this process: build scripts, automatic reports, work automation with GIT) for better teamwork organizing.
Test design (Test data / Test script / Test case)
As an architect creates a website site structure and solves problem issues, a test designer (usually a senior tester) determines the structure of the testing process, — the detailed aspects of working with the project. This can be expressed and documented in the work plan, or through a check-list.
Or we just have a team meeting and solve problem issues that may arise will surely arise during our work, and document our decisions, so we prevent problems before they occur. Usually, at this stage we develop test cases — invent them, mark them with numbers, format them according to the rules, so all process participants can understand them.
Test execution === Finding bugs
Now it’s time to implement everything that has been designed and planned. We’ve come to the stage of performing our tests.
In the testing process, we find bugs. And bugs will be found, no matter how wonderful a project is — otherwise, testers haven’t been searching thoroughly enough.
Reporting to developers
Then we go to the bug tracker (e.g. Jira) and report the bug in the relevant task. If there was no task, we must create it and specify where exactly and what bug has been found and how it can be reproduced. The more detail the bug report includes, the better the developer will understand it. Here’s where screenshots, videos, and step-by-step descriptions work very well.
Fixing & Verifying & Closing
Once found, it should be fixed! The developer gets the bug report or a task in the bug tracker (or a carrier pigeon ;), reproduces the bug, finds the reason for it and makes the correction.
Then the developer sends the task back to the tester for checking. The tester must be strict but impartial and check everything thoroughly.
If the tester determines that the bug is fixed — great! The task is closed and everyone is happy. If not, it goes back to the developer. This process goes on until everything is perfect.
Test summary report
At the end of the work, we describe everything we have been doing, in a structured way. This can be in the form of worklogs, or, if it’s TestRails, in the form of test runs. The most important thing is to have the work thoroughly documented. It is necessary for our “heirs”, because, if the project is large and long, this information will certainly become useful to someone.
Automation of critical business functionality
If the project involves automation, primarily, only the critical business functionality is automated. For example, the process of buying and paying in an online store (we check if everything is working correctly, whether the money is properly withdrawn from the customer's bank card, etc.). Automation goes with the tools we defined in the paragraph about testing tools. If there is such a need, we involve additional resources and automate the website testing process entirely, or almost entirely. But usually it is not necessary, because it is expensive and time-consuming. We always try to optimize the process so as to not do unnecessary work and save the customer’s money.
Regression testing
It may seem to someone that testing is an easy, and in most cases, unnecessary process. However, it is an important stage of developing a high-quality product. Here at InternetDevels assurance testing services company, we pay close attention to all the details of the process. So, to ensure the site’s smooth work and catch potential bugs that might occur in the future (especially when some changes in the code are made), we must do regular regression testing (we run all available tests again and again ... and then repeat the process). This can be either running the previously created automated tests or manual testing. As part of regression testing, the same process work: Reporting to developers, Fixing, Verifying, Closing.
Happy End!
Read also: