Quality Assurance Testing rules for submitter

10 maja 2019 Jarek Kowalewski

There are multiple types of testing, such as Quality Acceptance Testing, User Acceptance Testing, Operational Acceptance Testing, Alpha and Beta Testing etc. In this post I’m focusing on the Quality Acceptance Testing.

Jarek Kowalewski. Backend developer at Visuality. Involved in creating and maintaining web applications in Ruby on Rails. Fan of process automation in IT, systematics and organization of creating code. He likes to get to know new technologies (focuses mainly on databases, both SQL and NoSQL) but also happy to vacuum up old cartridges and cassettes. Privately, passionate about fast motorcycles and contrasting the tastes of musical neighbors with an electric guitar.

Spis treści

What is QAT?

QAT (Quality Assurance Testing) is, in general terms, the verification performed by the supplier on the product or service under development. It certifies its quality in accordance with some specified requirements in the test plan derived from the agreed scope of work. QAT does not need to test the web product’s usability in relation to consumer experience. The main goal of whole QAT process is to prepare product to UAT phase, which is, in general, testing with product owner/client and preparations for product deployment.

QAT process

QAT process may be handled using such concepts like Git Flow and Feature Flow. Those concepts are described in links attached below:

Basically, flow of those concepts is fairly easy. For each feature/bug/fix in a project, its developer creates a separate branch, which branches out from the main (usually development) branch of the project. When the development process is finished, the developer creates a pull request, which is a request for merging their code with the main branch. Other project developers should check the developer’s code and accept it or propose fixes, which the creator should apply to their code. The final stage is merging of the branch, after it was accepted.

During the process, both sides (submitter and reviewer) should stick to some rules which are applied to it.

QAT rules for submitter

When the developer reports a new pull request that will be checked by other developers, they should be consistent with the rules that are specified below.

One PR-one feature – Avoid adding things from other tasks/fixes. If possible, split into smaller ones. Reading thousands of added lines is tiring, causes lose of focus for the subsequent reviewer. In general, the reviewer shouldn’t spend more than one hour straight on checking someone’s code.
Self-check – Even though you might expect your code to be high quality, you could still miss some parts just because of absence of mind. Basically, the submitter should also check their code, as should the reviewer, according to the reviewer rules.
Before creating a pull request, remember to check names of functions, variables and classes. Pay attention to readability of the code — indentations and spaces. Remember about tests — depends on the type of tasks you are working on — should those be integration or unit, or maybe both. If the task is really complex, you can try to add them to a separated pull request. Obviously — test your feature on your localhost. Remember to update environment variables in application.yml.example (or any other setting file in project) and app.json if there are review apps.
Naming PRs – Name of the PR should have a specified format. It should contain PID of project name from JIRA with a number of tasks and clear title of PR (the best would be covered with the feature name)

Naming commits – Names of commits should be clear for the reviewer. Concise names are essential. Good practice is to use word of action that was done (fixed, added, changed etc.). Commits may be described in a more technical way, for example „Added ‚where’ conditions to payments query in payment.rb file” or in a functional way — „Fixed position of payment submit button on payment site”. In general, if there is a need for more descriptive commits, which requires body, you should follow this link:
https://chris.beams.io/posts/git-commit/
Description and checklist – Description can be set in general for every PR, with possibility of customizing, if it is necessary (what actually is this PR about, some unusual solutions used etc.). Usually you should base work on this tutorial, but for every project there might be specific things. Also, it is good to have a basic checklist of what has been done (tested on localhost, with review app, new tests, new feature, added environment variables etc.).

Noticing teammates – Inform your teammates that PR has been created. It is possible to connect Slack with Github to do so, but a friendly reminder might still be helpful.

PR importance – Try to judge if your PR is important and/or complex. If those changes are crucial for application maybe your PR needs more than one reviewer. You can also require a review from a specific collaborator.
CI and Code Climate – Remember to check if tests passed through CI, if they did not, fix them. Also take care of Code Climate notes, some of them may be easy to fix (length of lines) or cause vulnerability of the system (SQL injection).

QAT rules for reviewers

Ask and communicate – The first rule is to ask about everything you are not sure — connected task, description, comments, code structure, tests. Misunderstandings may cost you a lot.
Value of PRs – Do not treat pull requests as necessary evil. It is also a huge part of the project, so pay attention and spend some time on checking it properly. Do not accept every PR simultaneously after a brief check. Remember, that seniority doesn’t prevent from making mistakes. A person who approved PR is also responsible for code which he or she accepted.
Check PR’s info – Read the description of PR. Check the task, which is connected to the pull request in JIRA. Check subtasks, descriptions and comments, if you are not familiar with them. Understanding the bug/feature/issue is a must in effective verification of code.
Test application – If you are not sure what part of application is fixed/feature is added, test previous and current version on your localhost. You can also test it in review apps, if such a feature is available in you project.
Code verification – Read the code carefully. Pay attention to details:

1. Focus on the code structure(naming, spaces, indentations, line lengths, size of methods, assignments etc.)

2. Check if logic of the code is properly designed according to the feature.

3. Tests coverage with integration and unit tests. Some places need a more careful testing than other (eg. payments). The sheer existence of tests in pull request doesn’t provide safety.

4. Pay attention to possible edge cases.

5. Environments variables in application.yml.example or any other setting file. Also remember about app.json, if there is a review app feature.

6. Admin settings, if such exist in project

7. Feature flags

8. Database migrations (especially data manipulations)

9. Changes in schema.rb

10. Analyze influence on performance of application backend, efficiency of database queries, memory consumption

11. Try also not only to investigate what has been changed, but also what has not been changed.

CI and Code Climate – As well as the submitter, the reviewer should check if tests passed through CI and take a look at alerts in the Code Climate. If they find issues that must be fixed, they should inform the submitter. Important things:

1. Critical issues (SQL injection, vulnerable old gems, unprotected redirects, other security issues)

2. Code readability (Size of methods, classes and modules, length of lines, spacing, Ruby hash notation etc)

3. Duplication, redundation of code

Comments and change requests – Leave comments in moot cases. Try to suggest/propose better (in your opinion) solutions, not to force them, be polite. Discuss with the submitter about unclear/obscure things. If changes are crucial from the perspective of the reviewer, request for applying them. Sometimes comments might be just a good piece of advice, but should not prevent the code from merging.
Pair programming – In specific and difficult cases during checking PR, there might be necessity of pair programming. Try to ask the submitter and/or other team members to check and discuss together ambiguous parts. Another point of view may make things clearer and fix them faster. For example, if there is a part of frontend code, and you are mainly a backend developer or, basically, you are not familiar with specific technology, you should ask someone for help who is more experienced. It will make such a review much easier.
Acceptance – After PR is discussed and fixed by the submitter, check applied fixes and discuss them again if necessary. When the whole process is finished, pull requests can be accepted and then merged by its submitter.

What is the point?

The point of the QAT process is, as I mentioned before, having product ready to UAT phase.In details, we provide product with good code quality, which is free from bugs, it fulfills business goals, according to documentation and primary ideas of the client. All these steps listed above, should be an essence of QAT. If you keep to the quality rules, further testing with client will be definitely less painful.

Zobacz też