A few years ago when we started to establish Divante, I was highly against offering separate jobs for “Software testers”. We strongly believed that software developers being a part of a real and an effective team should test the results of their work. A project manager should test the results of software developers but a dedicated tester?
It appeared strange to us. It seemed to me that it’s just the developers being lazy :) I think, because I like to test myself (and I still do it often), I was misled in judging the situation. At that time I thought that everyone is a tester.
Today, we employ 120 people and we couldn’t imagine our lives without testers; actual testers, who develop the software equally to the programmers. Our QA Department has been developing very dynamically; we have employed a number of new people. I’d like to share my observations on how to develop a QA Department and cooperation of testers with other departments of a company.
On the blog we have previously published many posts on maintaining quality – checklists, methods of project management etc. Now is the time to discuss the most fundamental issues – the role of Quality Assurance and the role of testers.
Who is a good tester?
From my experience, I can say that a good tester is a person who’s not satisfied with perfunctory answers and someone who’s very bright. A tester is constantly looking for the causes of a function working (or not). He/she tries to understand the mechanism and spot gaps. People who wish to be good testers should have a mindset of a test pilot. They risk using an unknown system and they can never predict what will happen. What’s certain is that there will be errors. Many errors which have to be spotted. Otherwise they will never be fixed.
Testers should not leave any “casualties” behind, i.e. they should record everything that arises their doubts. It’s always better to record more errors than less errors.
The role of a tester enables one to develop in various directions in the IT sector. I know people who, while being testers, have directed their career towards project management, software development or even business analysis.
This happens because all the jobs above require characteristics which a tester needs to present from day one, i.e. a good understanding of operation of the system which he/she tests.
What’s interesting, I didn’t notice that education or previous work experience is important for being a good tester :)
What types of tests are completed by a tester?
It depends. At Divante, our competencies are distributed – certain people are in charge of automatic tests (e.g. Selenium), performance tests (e.g. JMeter) while others are functional testers (who are responsible for checking the functions for compliance with the documents). Other people are in charge of preparing documentation for testing.
It all depends on the person’s profile and his/her interests. The principles of cooperation of a tester with other team members in each field are generally similar – let me explain that later on.
What does the working day of a tester look like?
Most likely it’s different in every company. At Divante, testers are members of the project team. Sometimes they’re employed full time and sometimes they participate in two projects simultaneously. A tester communicates a lot – he/she talks to the software developers, the technical leader and the project manager in order to obtain information necessary to perform the tests. If something doesn’t work, a tester asks why it doesn’t work and when it will start to work :)
If functional tests are performed, then the working day usually starts and ends with a web browser (we create e-Commerce) – in the Redmine system where errors are recorded. First, errors marked as “requiring tests” are verified (e.g. faults recorded earlier which were repaired) and their retests are completed (after which the errors may be closed).
Then the application itself is tested and new errors are recorded in Redmine – they are assigned to a project manager or directly to the software developers.
What’s the best way to record errors?
Generally, we describe as many details as possible which will enable the software developer to recreate and correct the error. To show you how it works in practice, we have prepared a brief sample table (thanks to Damian Kowalski – our Automation Test Engineer).
| Type of issue | Error – Bug |
| Prior to first entry, ask PM for the error recording type. | |
| Topic | [CART] – It is possible to purchase product items exceeding the stock. |
| In square brackets specify the area for service to which the record relates. Then include a brief description of the error. | |
| Description | In the cart, the user may place quantities of product items exceeding the shop stock and then correctly process the order. Block the possibility of increasing items in the cart Found/checked on test.divante pl Browser: Chrome 38 WIN. |
| The description should specify as many details as possible in relation to the record. Error solution suggestions would also be appreciated. If the entire error description is included in the topic, don’t be afraid of repeating it in the description. | |
| Description cont. | Scenario: Find the product which is out of stock e.g. <name of product> Add the maximum available quantity of the product items to the cart. Proceed to cart. Increase the quantity of product items in the cart by pressing “+”. Place the order. |
| In the case of more complex paths to the error a scenario in which a given error can be recreated is required. | |
| Status | New or Assigned. |
| New – if the tasks are assigned by another person. This will be information for that person that a task/error is awaiting assignment to the appropriate person. | |
| Assigned – if you know who is responsible for the part of the service where the defect occurred. | |
| Priority | Depending on the error. |
| Assigned to | PM or developer. |
| Files | screen.jpg |
| Try to attach a screenshot to each record. The tools above enable easy editing of screenshots and adding arrows, texts, figures etc. onto them. Quick screenshot tools can also be useful. |
What’s the role of a tester in a team?
The basic principles of work of a tester in the case of an implementation project – prepared by Tomek Widliński, Project Manager (thanks, Tomek!)
- The tester reads project assumptions.
- The tester receives records from the customer and completes an initial verification (if necessary, the tester asks for screenshots, web browser etc.). Only such a prepared and described ticket may be submitted to the software developer (the developer needs the information and the reproduced error in order to fix it).
- The tester is familiar with the project and is able to verify whether the tested function meets the assumptions specified in the documents.
- The tester must describe the tickets and provides screenshots (so that the point of error can be identified as quickly as possible).
- The tester ensures quality of the project and adopts a comprehensive approach – he/she does not ignore errors found in the course.
- At the project finalisation stage, the tester ensures that all errors in the platform have records in Remine.
- The tester knows which software developer is responsible for which parts of the system and assigns the tasks to the appropriate people
The tester is a part of the team and he/she should require: good organisation from the software developers or webmasters; business decisions from the PM (e.g. who should be assigned with the new function which is missing) or assistance in solving quality problems; explanations relating to the realised functions from the software developers, etc.
Published December 31, 2014
