If you are familiar with Nike and their different quotes, you have probably heard this one: “if you’re a human, you’re a tester”. Do you agree with that? Because I do. Every day is a day of testing – testing new shampoo, new diet plan, new cosmetics… And this list goes on forever. Today I will just focus on something I genuinely love – testing food, uh… I mean software.
This article contains the following parts:
- Environments
- Statuses diagram
- Correctly added bug and bug fix
Environments
If you are just starting out a new project, remember that it should have the environments mentioned below:
- Local Dev
- Local Test
- Test branch rev.x.x
- DEV
- TEST
- UAT
- Pre-production/Stage
- Production/Live
If your product is not production-ready yet, you can forget about Pre-production/Stage and Production/Live.
But don’t use just one testing environment – the best practice is the “one task, one branch rule”, which is also the most expensive one. This rule states that every new task or bug has its branch, in which a separate testing environment has been set up.
Always remember to make sure that every commit is connected with a particular task.
This solution has its disadvantages, as every solution does. You can’t make every task independent because tasks are often connected. And that’s the first issue, because you can’t easily separate them.
The second issue is connected with the need to have an additional connection with the integration of another system. But this can be avoided by creating mock-up data.
As a tester, you should have individual access to environments such as DEV test and UAT, and so does every developer.
Statuses diagram
Colours indicate where a given task is.
Every new task or bug has “new ” status (or “unconfirmed” if there are people responsible for confirmation at the company). This status will change to one of these three options:
- Rejected/duplicated – this shows up if it’s not an error, a package has been rejected, or a similar error has already been reported
- Waiting for confirmation – this shows up if an error path is not detailed enough or if we don’t have all the requirements. In other words, it shows up if we don’t have enough details
- Open/Waiting for Dev – this shows up if the task has been or is about to be assigned to a particular developer. Only tasks that have “unconfirmed” status may not have an assigned developer
Other statuses:
- In development – the coding process is about to begin
- Code review needed – when the coding process is finished
- Could not reproduce – when the developer can’t reproduce the error, then this task or bug is given back to a tester
- Resolved – when all of the development work is done
- Ready for testing – in the queue of tasks for a tester
- Testing – this means that the task is currently being checked
- Verified – this means that the task is verified and ready for UAT tests
- Reopen – if there is any problem with a task, it comes back to the developer with this status
- Waiting for UAT – a queue of tasks that need to be verified in the acceptance environment
- Closed – the task has successfully passed UAT tests
- Rejected in UAT – this means that the task has been rejected after UAT tests
UAT tests are not enough. Every task should always go to an internal tester before going to the developer. Running retests in a testing environment will prove if the error exists or not. By the same token, the tester becomes a shield between the programmer and the client. The tester can also help the developer by adding comments or additional instructions.
More significant and more comprehensive projects often require the client’s contribution in adding a new task or bug. Sometimes clients may want to have an active role in adding new features or providing a list of things to improve before developers start their work.
There is one more good practice – you, as the tester, should review new tasks to detect misleading or unclear requirements early.
Correctly added bug and bug fix
There are many programs which help you to do your daily work. You’ll be grateful if the particular program can be adapted to agile methodologies like JIRA or Team Foundation Server (TFS). The management system should be configured in a way in which no required fields will be missed.
Required fields:
- Status: New or Unconfirmed (by default)
- Summary: the title should be distinctive, so it is easily recognisable among other bugs on the list
- Comments: at the beginning, it should contain a short error description, and then a detailed step-by-step scenario, actual result and expected result
- Attachments: an attachment should include as much information as possible (“a picture is worth a thousand words” rule)
- Environment: the environment where the bug has been found
- Revision no: revision number
- Priority
- Assigned to
- Reported date
- Modified date
- Reported by
- Modified by
Additional fields:
- Estimate
- Due date
- Product
- Component
- CC
- Keywords
- Depend on
- Block
For sure, developers know that every part of the development process is equally important… Do they? That’s a rhetorical question, but sometimes the end of their work is an overlooked issue. When handing over a task to the tester, the programmer usually just gives the revision number in a comment. And that’s a mistake, because he should add such information as:
- The scenario he used to verify that the code he wrote is working according to requirements
- The environment in which this task has been checked. Usually, it’s on the developer’s local machine, but sometimes it’s a different environment if it needs integration with another system
- Additional data, i.e. data set used to check the specific task
Read more in another Dominik’s article about how to become a software tester here.
