Once upon a Time
Since the origin of Software Engineering in 1960, there are people who work out prototypes, design and develop the prototype, perform testing, demonstrate to stake-holders and make a release for the end-user's consumption.
In the modern era of Software engineering, these roles are made more sophisticated, categorized, branched and described. However the fundamentals are kind of same, as in:
- A Developer(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) 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 into, 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 do they need 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'and9 as '9'=> when seen from same side. -
6 can be seen as '9'and9 can be seen as '6'=> when seen from opposite sides.
While 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.
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 few that, I feel are the major contributors to the problem. I am sure, there will be more.
Over Relying on Issue Tracking Tools
Issue Tracking Tools are the best way to communicate and manage an issue(aka bug) life-cycle. Each decisions taken to reach to a conclusion 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.
Take 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 write various positive and negative test cases that are derived from the understanding of the Use-Cases and the solution of the problem in 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 in 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 look into those test-cases or they setup a meeting to go through, the result will be in saving time, less 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?
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 on 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 overall Testing strategy of a product. But who owns it? Testers? Special skilled professionals? Developers? Who?
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 are the roles created because of required skill-sets and the job expectations. A scrum team usually combine people from both of these roles. Roles can be many, but the feeling of 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 the 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 of 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.
Top comments (2)
Thanks for the write up. I'm glad you took the conversation between individuals and landed on the quality any product delivery is on the backs of the team and not the difference in job titles.
Thanks Ken for the note!