Testing Skills Every Software Engineer Should Master

At Brainhub, there is a rule that every programmer is also involved in testing. How do you assess this solution, and what does it mean to you?

Hubert: I think this is a good solution, and every programmer should participate in the testing process. It should start from unit tests of the methods and components through integration and e2e tests (after agreeing with the QA department).

In some projects, if we have testers actively writing automated tests, it may turn out that they will take care of the rest of the testing, but this does not mean that we should ignore it because we may be able to bring value to the testers.

Milosz: For me, it means extending the responsibility for quality to the whole team - we all work on the high quality of the delivered product. Shifting the testing burden for the entire development process helps reduce the number of bugs found during QA testing. Some bugs have been found and fixed earlier, which speeds up the team even more.

Tomasz: From my observations, this approach speeds up the process of delivering business value to the customer.

Thanks to the fact that programmers already check their work at the implementation stage, write new tests, and fix the current ones, more problems and defects are already set.

The implemented functionality rarely comes back from the testing stage for patches, and there is no need to retest it later. Besides, it reduces the technical debt in the form of many features not covered by automated tests. So that we can avoid long-lasting regression testing before releasing a new version and immediately know what does not work when implementing new functionalities.

It is also worth mentioning that early detection of defects reduces the cost and time of fixing them.‍

What does testing in a team look like from your perspective? 

Hubert: I have to start with the only correct answer for a programmer: 'It depends'. It depends on the project, and sometimes it may happen that it is not us but other stakeholders who have prepared the testing process, and we come into a 'ready-made’ environment. It does not mean that we no longer influence the process.

At Brainhub, we approach problems and projects as consultants, so we advise possible improvements from the very beginning.

Currently, I'm working on a well-established process in the project. However, the code we got was not of the best quality. We first suggested changes in the code to improve the application's performance to cover the essential parts with tests (unit, integration, e2e). In the previous process, after delivering a functionality, developers passed the test build to Quality Assurance, and they checked the requirements (0 unit tests or any other).

After a complete cycle, the testers checked everything from the beginning, and if it passed the verification, it was sent to production. Now, after our changes, the flow is a bit different.

We cover what we can as software developers with tests. It protects us at the code writing level as tests are checked on the pipeline every time.

And we document the requirements the same way. We also added e2e tests for the most important functionalities, such as logging.

We transferred them to the Quality Assurance department so that they do not have to check the logging manually anymore. Before the release, we perform these tests on the pipelines configured by us. Instead, testers can focus on more important things and use cases in the application.

Tomasz: I agree with what Hubert said. I would add that the testing process starts already at the requirements gathering stage. We make sure that the entire team knows the requirements and business needs and their collection process.

At this stage, we discuss with the customer what problems the new functionality may cause, where it conflicts with existing functions and how to solve these problems, e.g. through additional validation. Of course, we also test the newly implemented functionality, both manually and using automatic tests - so we do not repeat the same work several times. We have a sense of responsibility for the quality of the product. The team is aware of the benefits of this approach.

The certainty that the introduced changes do not spoil the existing functionalities. There are no more tedious testing periods before the release; code freezes, and we rarely get 'feedback', i.e. bugs found by the customer and end-users.

Milosz: I work currently on a small Brainhub project, so I have a different experience than the guys. We try to start the testing process by verifying the requirements and making sure they are clear and testable. If that part is missing, then ambiguities and tensions come out later. It is crucial to be aware that we are working on a system that achieves specific goals, not individual functionalities.

As a QA team, we participate in code reviews, which also gives us an insight into the changes and an opportunity to develop - it is worth taking advantage of this opportunity. We test new functionalities manually on feature branches and the test environment. Due to the growing number of functionalities and increasing scope of regressions, we aim to increase test automation.

Do you have a comparison of your company to how you test at other companies? Do you see any differences?

Hubert: Sure, I'll tell you a story. In one of my previous companies, there was no talk about testing. Unfortunately, I was a very inexperienced programmer and didn't have the power to bring in code testing. The only such process was manual testing by the QA department. Fun fact, our tester could test automatically. Still, the projects were so small and start-up that time was the most critical factor, and you had to deliver as fast as possible because every day of testing could, in their opinion, cause the company to fail and the funding to end.

In another case, the project was massive, but writing tests had to be 'smug' because if someone found out from the client's side, they would ask why we were wasting time and say that we could deliver something else in that time. One of the most important requirements was: 'You have to prove it ASAP'. The QA department in that project was on the customer side while being outsourced to another company. The funniest thing was that testers there were paid probably per problem (bug) found, and to earn money, they were putting even feature requests into Jira as bugs.

Currently, in Brainhub, I don't experience similar situations. As a rule, customers approach us as experts with whom we can discuss the process. If we reason the changes well, they get implemented and even when we don't have a tester in the project, there is space for us to test. At Brainhub, there is a solid focus on testing and, therefore, on maintaining quality simultaneously. Not at any cost because 100% coverage does not necessarily mean that we have a perfect application.

At Brainhub, there is a solid focus on testing and, therefore, on maintaining quality simultaneously.

Tomasz: Unfortunately, most of the experiences are such anti-patterns that show the wrong ways and, in the long run, the costly consequences of such an approach. I can tell a lot of stories here. In my first project, the process was typically a waterfall - a spec came in the mail (a few dozen pages), and the development team was locked with it for a few months. During this time, the QA team wrote down manual test cases, the development team came up with a branch, and finally, the team had to rewrite most of the test cases.

It was followed by a tedious process of testing, fixing, retesting, regression testing, and discussing the details of the requirements with the business analyst. Then a few weeks of merging with another team and the main branch, and then a lot of reimbursement after the release. It occurred that the customer wanted something else. We introduced automated tests and a more agile approach during several years of work, but there was a lot of resistance on the customer side.

The rigid separation of duties and division into development and QA teams created misunderstandings, conflicts and a lack of responsibility for what we deliver.

The organizations I worked for had many projects for different clients. Each approach was a mix of agile and flexibility of the management team, plus how much the team wanted to do things right and come together to change the world for the better. It was often possible to get the project off the ground by actively reducing technical debt, involving QA in the entire development process from requirements gathering to release and maintenance, and frequent customer contact to avoid assumptions and misunderstandings.

Milosz: I think almost every tester can share many anti-patterns encountered during their work. Testing in production, absolute lack of time allocated for testing, micromanagement by people without proper knowledge, and many others. Most of these stem from organizational characteristics (lack of flexibility, low testing priority) and customer attitudes (thinking testing is an unnecessary cost). I think that something is changing, and tests are becoming no less important part of the software development process. 

What do you need to know to become a software tester? What skills do you need?

Milosz: I think skills not directly related to testing are essential initially. Perceptiveness, assertiveness, inquisitiveness in researching topics and absolutely - computer proficiency. A beginning tester should know how websites, apps, mobile apps work, what good UX is, and generally have some idea about IT. Version control system skills (e.g. GIT), database skills (SQL), and knowledge of REST API seem to be a good start. Knowledge of ISTQB and agile software development methods will also come in handy. 

Tomasz: I agree with what Milosz said, and I would add that it's essential to be thorough, pay attention to detail, and be willing to understand the problem and the reasons that caused it, the so-called getting to the nitty-gritty. Next, you should be interested in how tests are approached in big companies like Google, Facebook. I recommend this repository: https://github.com/abhivaikar/howtheytest). It helps to understand the benefits of the agile approach and automation. It's vital to realize that we make software to solve someone's problem or help someone make big money. There is also almost always a user who will be happy with what we deliver or not. So it makes sense to work to keep that person's satisfaction in mind.

So, should a programmer perform the testing?

Hubert: Definitely yes, but not as much as a professional tester. A programmer should know how to test, understand the scenarios and requirements, write code tests, and know fundamental issues such as test pyramid, white/black box testing, etc. But he doesn't have to match an experienced tester and his skills.

Milosz: I think not the skills, but the approach is essential. The tester's approach certainly helps verify the delivered requirements (Why this and not that? Something is missing here?). And from here it is very close to a better product.

‍Tomasz: A programmer should, first of all, know why he is testing. As my colleagues mentioned - it is worth knowing the basics, test levels, equivalence partitioning, boundary value analysis, and combinatorial testing. Knowing these simple techniques allows you to write better and more precise unit tests. In an ideal world, QA does not take the team out of testing but only gives them opportunities and supports the team in improving the quality of delivered solutions. In line with the saying: 'Give someone a fish, and you feed him for a day. Teach him to fish, and you feed him for a lifetime.'

‍

Tomasz Grażyński Quality Assurance and Software Quality Engineer at Brainhub

He has been working with Quality Assurance issues for ten years. Still, he also managed to gain experience in areas related to team organization, business analysis, DevOps, new customers analysis and their needs, and programming in .NET and JavaScript. He appreciates the relaxed atmosphere, healthy attitude, team commitment, and taking responsibility at work. He chooses hiking and swimming for relaxation, but he also likes books, movies or a series.

‍

Hubert Stemplewski Full Stack Developer at Brainhub

He has been professionally involved in programming for five years, mainly front-end, but he doesn't have a specific field. Technologically he likes challenges, whether it's mobile, backend or blockchain. The most important subject for him is to match the technology to the problem. He wants to try new things, and although JavaScript is his fundamental language, he is always trying new solutions. He is interested in DevOps (CI/CD) and security topics. He likes to play squash, soccer and work out at the gym in his free time, but because physical activity is not everything, he also does not refuse a good TV series.

‍

Miłosz Sałata Quality Assurance in Brainhub

For over seven years, he has been professionally involved in software quality - widely understood testing, test automation in Python, and building processes to improve teamwork. He is focused on learning new tools and developing in CI/CD topics. Always appreciate the commitment, creativity, and holistic approach to a project. After work, he enjoys photography, weightlifting, rock climbing, and drone crashing.

‍

‍