This section is to instruct on when to test, how you should be formatting the bugs raised and guidelines for QA
When you are developing a project, the project might require commands to run and work correctly, these can range from simple set up commands to automatic updating commands, a list of these commands and a brief description of what these commands do will help QA move more smoothly and avoid raising unnecessary questions.
Some projects require certain data to have certain statuses and manipulation of the database to update systems and cause it may be required to force the system onto the next process. We would like these to be formed into commands if it is a complex task or a detailed outline of what is required to be completed and a description of when and why you would need to do this, QA should have minimum contact with database directly, this leads to user error. This will allow the tester to carry out complex tasks without directly modify the database or sensitive areas of the application.
Ensure that the ‘env.example’ is up to date and remove redundant keys that are no longer required.
For staging, we are following a multi-stage testing methodology to enable us to ensure that the customer is getting a bug free and fully functioning system. This will be a merge between ‘Agile’ and ‘Waterfall’ methodologies.
This stage is for the developers to test and ensure that there are no obvious bugs and that the code is working as expected before they create a PR (Pull Request). This will ensure that QA is not wasting time on obvious bugs that could have easily been spotted during development and be fixed them before the pull request is made.
At this stage the PR has been created and must adhere to the following criteria before being accepted. One check will be from a member of the development team to check over the code and to review the code itself to ensure it meets our internal standards. The other check will be from QA, that will test the code changes itself, ensure that it is working and there are no bugs in the relevant area(s). This is more of a ‘Spotlight Check’, focused testing around each change that has been made and near areas that could be affected by this change. No matter how small an issue might seem it must be reported and signed off before continuing. Once both parties have accepted the code we will then proceed to stage 3.
This area of testing is large end to end testing. We start by creating a new user, with a cleared database (as much as can be cleared). Testing will be used as if the customer was using the system, this would include all different user types such as: client, admin, worker. If a customer has a web application, mobile application, and any other applications then this process will be repeated for each one until QA is confident to say that the applications are working as expected.
This area of testing is large end to end testing. We start by creating a new user, with a cleared database (as much as can be cleared). Testing will be used as if the customer was using the system, this would include all different user types such as: client, admin, and/or worker. If a customer has a web application, mobile application, and any other application(s) then this process will be repeated for each application until QA is confident to say that the application(s) are working as expected. If any urgent issues are found they should be raised and created as hotfixes, if they are not urgent they should go into the development branch and start the testing process again (from stage 2).
Timing is a very important point in the merge between staging and production.
Test cycles are a collection of tests that need to be ran. Cycles should always be given a time frame and a time estimate to ensure that we are completing them in a timely manner and to enable management to organize work efficiently.
For stage 2, stage 3 and stage 4, a list of tests is required. This is to keep track of what needs to be tested and to ensure that all functionality is tested and to ensure we don’t do any unnecessary testing. The structure of the tests are as follows:
Each test requires a statuses once completed. The status are as follows:
When you find a bug, you will need to raise a bug on the ‘Jira Service Desk’. This bug will require multiple areas to be filled in, these are as Below:
When testing on
production we will require valid data and credentials. These should be stored in a ‘Google Docs’ document that the project lead/manager should have access to, these should be kept up to date. The document should contain data that you need or is helpful to have when you are testing the given project.