Once upon a Time
Since the origin of Software Engineering in 1960, some people work out prototypes, design and develop the prototype, perform testing, demonstrate to stakeholders, and make a release for the end-users consumption.
Courtesy: Vintage Computers - https://flashbak.com
In the modern era of Software engineering, these roles are made more sophisticated, categorized, branched, and described. However, the fundamentals are kind of the same, as in:
A Developer(in many cases we call them as Programmer) is a person responsible for designing and implementing Solutions. A developer uses programming languages to develop Software Programs.
Not all the developers really take part in designing the solution. There could be other roles like an Architect who does it and another developer(or programmer) implement the solution.
A Tester is a person responsible for the Quality Assurance of the solution/product/service etc. They perform automated and manual tests to ensure the software created by developers is fit for purpose.
If there are any bugs(aka issues) that exist, they report those so that, those are removed(or fixed) within a solution/product before it gets deployed to the end customer(or user).
Being in Sync
There are really serious number of illustrations to make us believe that, a developer and tester can not be in sync. This may result in, misunderstanding, ego, your-thing-vs-my-thing, doing only my job kind of side effects.
My personal favorite is this one(old joke but, meaningful):
Where to be in Sync?
- Understanding the Requirements. The big What part of the whole story.
- Understanding the Persona. The important Who part of the story.
- Understanding the Use-cases and Scenarios. The line that connects the dots.
These are all very fundamental expectations from both developer and tester to understand and be on the same page so that, they can clearly call out together,
6 as '6' and 9 as '9' => when seen from same side.6 can be seen as '9' and 9 can be seen as '6' => when seen from opposite sides.
While the above understandings help developers and testers to be on the same page but, it is not enough. It is equally important to have focused and healthy conversations throughout the project for each of the issues found and to be fixed.
How frequently a situation like this can be seen
Common Problems and Patterns
I have seen many common problems and patterns across many projects which can be avoided easily to gain better synchronizations and results. Here are a few that, I feel are the major contributors to the problem. I am sure, there will be more.
Issue Tracking Tools are the best way to communicate and manage an issue(aka a bug) life-cycle. Each decision taken to conclude must be documented in the tool. However, this shouldn't be the only mode of communication between a developer and tester. There is an easy and parallel one, is to Talk.
Discuss => Conclude => Move-On
Take a sidebar after your daily stand-up update, talk to each other to realize the gaps, and move on. Let's not bloat the issue tracking tool just because, you are not on the same page. Save energy, Save time. Please note to update the tool with the conclusion reached.
Not Sharing the Test-Cases in advance
Usually, a Tester writes various positive and negative test cases that are derived from the understanding of the Use-Cases and the solution of the problem at hand. I have seen that testers usually do an excellent job in writing, managing, maintaining, and executing the test-cases. However, I have seen a lack of sharing them in advance.
If developers and testers are aware of some common test-cases related to a feature in advance, it will reduce the chances for issues and bugs coming out of the test. Either a tester share or a developer proactively looks into those test-cases or they set up a meeting to go through, the result will be in saving time, fewer bugs, and early release.
Quantity wins over Quality
I have to open 3 issues per day, at least 20 per week, and around 230 in this release! I will feel like a winner if I could get there and most importantly, my boss is going to be happy! Sounds familiar?
A fake feeling
As a Tester, if any of us have got this feeling, it is the time to retrospect and come out of it. Quality matters the most than the target, number whatever set by you or your manager. You are not making the product better just by creating some bugs that no one is willing to fix as they are not important at all. Let's focus back on Quality as Testers are for Quality Assurance.
Testers are going to Test it anyway
I am just done with my coding and made a git push. It is going to work for sure. Testers are going to test it anyway! I can fix it as and when issues are reported.
This thought is not so welcoming. As a developer, we need to write and execute unit tests, test out the piece of code impact we are going to commit. Besides, it is perfectly fine to notify the tester of what has been committed with little more details than your commit message. Remember the importance of Being on the same page?
Automation? Who owns that?
Test automation is a very important part of the overall Testing strategy of a product. But who owns it? Testers? Specially skilled professionals? Developers? Who?
Confused?
In my opinion, it is the entire team. Developers can take part in building the automation needs like framework, execution strategy, code, etc. Testers use, maintain it over the releases. Automation is 2X the code. As we write more source code, automation code has to be modified, enhanced, and made better.
Teams within a Team
Developer, Tester is the roles created because of required skill-sets and job expectations. A scrum team usually combines people from both of these roles. Roles can be many, but the feeling of the team must be, ONE.
In Team, developers and testers shouldn't have physiological boundaries between them based on the roles. They belong to one team with the Common End Goal.
Conclusion: Seeing the End Goal Together
Over time, the role definitions of Developer and Tester are changing. We have been seeing various types of developer roles like front-end, back-end, full-stack, and many more. Similarly in testing, manual, automation, performance, etc.
We have been seeing the emerging need for a completely new role definition called, SDET which stands for Software Development Engineer in Test (or Software Design Engineer in Test). If you dive deeper into SDET, it is much more than the usual Developer and Tester role.
To conclude, the moral of the story is, come out of your own definition of a traditional Developer and Tester. Own up the entire solution/product. See the end goal and expectations together to align your motive, plan, and skill accordingly.
Even if your organization structure demands you to be separate, no one can stop you from being in sync and be a highly collaborative team.
With that thought, that's all from this story. Please like/share the post if it was useful. I would love to hear from you on your experiences as well.
How about that? ☝️☝️☝️☝️☝️☝️
