12

I am somewhat a newbie with 2 years of experience in Java backend developing and I want to hone my skills in backend Java developing.

But now my manager and team is asking to work on automation web testing using Selenium, even though it is Java programming, it has little to nothing to do with backend developing.

I am not sure whether I should do it or not. And I am afraid I may be bogged down into testing eventually, which I want to avoid. My role is now not yet clear in my company profile, it just says associate junior software engineer, it neither says tester or developer, so I am afraid if I start working on this which may take 3-6 months.

I will be working less and learning less on the Java backend developing like APIs, Microservices, DevOps and working more on Selenium and writing automated test cases and eventually maybe given the role of tester. What should I do?

0

12 Answers 12

136

Before I jump in to an answer, background about me: I've been coding for 30 years, 20 professionally in startups, and have been in roles everywhere from myself as a solo engineer to the head of a big engineering team. I don't know everything, but I can assure you the following is decently well-informed.

Quite frankly, the entire attitude with which this question has been asked is a major red flag to me.

First and foremost, sometimes we all have to do things at work that aren't exactly the most exciting, aligned with our career objectives, or that we might not want to do at all. That's why you're getting paid to do these things. It's also very much a part of the whole "being a team player" thing — someone has to do this task, and your manager has decided that putting you on it is the best way for your team as a whole to meet its goals.

This is how the world works: sometimes we have to make sacrifices and do things outside of our comfort zone for the benefit of a larger group. This is teamwork.

Secondly, I will grant you that writing tests isn't necessarily my first choice either. Writing them can be pretty boring and tedious; you're not exactly solving the hard and interesting problems. But that doesn't make them any less important or useful. If you write good tests, your teammates (or even a future you) will certainly appreciate your efforts if when they catch a mistake in development and prevent a bug from going to production.

Thirdly, you could (should) look at this as an opportunity: your boss wants to pay you to learn how to use Selenium and write tests. Along the way, you'll have the opportunity to learn about how the things you're testing work. Presumably they know that you don't have any experience in this area, so expectations will be low.

Use this as a chance to knock it out of the park — learn the tool, figure out how to write good tests (whether by researching online and/or asking your teammates), and turn in quality work relatively quickly. This will impress your colleagues, and doing this repeatedly over time will make them want to trust you with the more exciting and challenging stuff as you prove your abilities. Plus, you'll have some great material to discuss the next time you're in an interview and are asked about your experience with testing.

Finally, from the way you've written your question, it sounds like you view testing as something that's beneath you. It's absolutely not. Writing tests is as much a part of a software engineer's job as writing the code being tested. A good tester is worth their weight in gold. An engineer who can't be bothered to write tests, especially when asked to? Well… they won't be on my team for very long.

This doesn't mean you have to specialize in testing or spend lots of time doing it, but you absolutely should understand how the tools work, and be able to use them when needed. Indeed, if you're a good engineer, it's very unlikely that you'd find yourself moved in to a testing role, since your engineering skills are more valuable than doing testing alone.

(There's only two reasons I'd want to move someone into a pure testing role: because they wanted the role and asked me to move, or if they were good at testing but repeatedly showed they didn't have the skills to be a good engineer.)

So you have two choices:

  1. Take the assignment with enthusiasm and do a good job even though it's not your first pick. Your team will appreciate your willingness to be flexible, and if you do well, you'll earn the chance to work on more critical (and therefore interesting) projects in the future.
  2. Push back and try to get out of the work. This will likely earn you a reputation as someone who is both difficult to work with and not a team player, which is a severe career-limiting move. The answer will likely still be "we need you to do this", which leaves you with both a damaged reputation and still needing to do the work — you can't just refuse to do it and expect to remain employed.
2
  • Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on The Workplace Meta, or in The Workplace Chat. Comments continuing discussion may be removed.
    – motosubatsu
    Commented Jun 20 at 16:47
  • Writing tests is a normal part of software development and as you mention. It's not weird to spend part of a sprint adding tests, to add them as you go, or even to add them all at the end of a phase. But OP says they will be assigned tests for 3-6 months. That sounds to me like it is beyond the scope of what a normal dev would encounter, which leads me to believe that they might be right to think that the company may want to raise OP as a test engineer.
    – Mars
    Commented Jun 21 at 7:10
63

With a username like "FullStack", somewhere in your career embracing testing needs to be included. It is your choice where and when - to a certain point.

To be clear, backend or any-end developing includes testing. Developing without testing is just throwing code over the wall, letting it be someone's problem.

These people are doing you a favor by asking you to learn how to automate testing.

Career growth is an important decision on your part. Decisions like this are not left to random internet people.

It comes down to several points. How quickly do you want to learn this area? Do you like this company? Do you see a growth path at this company?

To a young person, 2 years seems like forever. It isn't.

Having an plan to for career growth, including trying out different areas, being seen as a team player, etc. usually helps long term.

Good luck, let us know what you decide.

3
  • 2
    There is also the possibility that there is no testing yet at all and asking to set up everything that automated webtests in Selenium are working correctly in the build process, not to set up the tests themself
    – Zibelas
    Commented Jun 19 at 5:37
  • @Zibelas THAT part I don't think would be left to a rank junior, but rather done by a medior or senior engineer, possibly a contractor brought in specially for the job.
    – jwenting
    Commented Jun 20 at 14:59
  • 1
    @jwenting I dunno... I would let a junior engineer that I wanted to promote setup/create a system that he is an expert in. So that I can use his expertise in the XYZ system to argue his case for promotion with upper management...
    – Questor
    Commented Jun 20 at 18:23
8

If I would think like you, my job title would be FoxPro for MS-DOS programmer. This what I have started with around 1993, which is 31 years ago.

You have little experience, but you are afraid what your "job description" is. Why do you think that people will write Java Microservices APIs forever? For example I used Vaadin and my team boosted productivity compared to a Java Microservice / JS frontend approach. We actually were successful in replacing a product written with Java Spring Microservices, Angular JS and a bunch of other "glue" technologies.

Maybe your manager thinks you are QA material, not development material. A manager that is not a former engineer uses "cues" to make such decisions, as opposite to facts, therefore the judgement may be good or wrong.

Why are you afraid to work in testing? I have worked in testing. I wasn't testing web applications, but an application for mobile network planners. The application was working with a hardware that was in development, so I had to write some kind of emulator for the hardware. After doing that, I've been put on the same level with development. Testing is not an easy task, if you really want to do it seriously.

So what I would do it get a Java book, get your Selenium docker running, and start writing tests. Your work will get you to:

  1. Java and Selenium - Obviously
  2. Devops - you will need to manage services / databases / containers to create the conditions of the test and observe the test effects. obviously in an automated fashion.
  3. Product management - you will have to understand what your product is doing, what is supposed to do and what are the challenges in developing it.
  4. Project management - you will observe delivery schedule and planning. Well made tests are developed ahead of the product (called Test Driven Development).
  5. GUI design. Since you define yourself as a backend developer, GUI design is a good addition to your skills.
7

Your #1 job as a software engineer is to deliver code that works. There's no better way to know if code works than having a well-designed suite of automated tests that can be run before, during, and after changes (and during CI) to ensure the correctness, completeness, and stability of your code.

The best software engineers I know embrace test-driven development, an approach in which you write tests before you write code. If you have a suite of tests that accurately reflect the acceptance criteria for your assignment, you can use the tests to monitor your progress (you'll know when you're done!), and when you or someone else comes back to the same code months from now to fix bugs or make other changes, they can use the tests to make sure the new changes don't cause a regression.

Every developer needs to know how to test their own and others' code. I wish I had learned these techniques earlier as a developer. You should think of this as an opportunity to learn.

2
  • 2
    From my perspective as an amateur programmer and a professional software/hardware tester, it's critical that software is written in such a way that not only does it meet requirements, but it's also able to be tested properly and as completely as possible. By knowing and understanding how the testing side of the software development process works, it will help you understand how to write your code in such a way that's easier to test, whether with unit tests, or with full-scope tests of the product you're working on.
    – Milwrdfan
    Commented Jun 20 at 20:00
  • 1
    By writing more testable code, it will help find bugs more quickly, which will lead to faster bug resolution turnaround and an overall faster development process. The sooner bugs are found in the development process, the less overall cost and rework required overall in your projects.
    – Milwrdfan
    Commented Jun 20 at 20:00
5

I would communicate it to your manager exactly how you did here and then do what you are asked to do.

Then you should at least get some feedback, if your wishes align with the future plans of your manager/company for you.

Your best chance is to work together with your manager, rather than against him, because that usually turns out bad.

If the company plans for you to go more into testing and you don't like that, you need to consider finding a new company that aligns with your plans.

2
  • I would communicate it to your manager exactly how you did here - horrendously bad advice that will likely get him fired given the unprofessional way he expressed himself.
    – deep64blue
    Commented Jun 20 at 13:28
  • Imo any decent manager that receives this feedback from his subordinate, will work together with them to achieve their goal or at least clarify what the long term goal for the employee is. Not sure why you would get fired for saying "My job is not going in the direction I want it to go, what can we do?"
    – kirbby
    Commented Jul 17 at 8:39
4

Who wants to be a "one trick pony"?

The field is very, very diverse, and changes almost daily...

One can pay and study nights and weekends for "bootcamp" qualifications, or one can get-down-to-business and upskill on the company's dollar, adding another arrow to one's quiver at their expense.

You'll get value out of any assignment in proportion to the effort you put into it.

"The proof is in the pudding." Are you really as dextrous and capable as you imagine yourself to be?

Or, thank them for their time and start scanning the want-ads for your dream stream...

Best wishes, either way.

2
  • 1
    Agree totally with learning on-the-job. Once you know a tool well, you get so much faster with it. My company even provides Udemy courses so we can learn tools in our downtime.
    – qwr
    Commented Jun 20 at 18:13
  • 1
    I spend most of my free time on the computer, too :P
    – qwr
    Commented Jun 20 at 21:40
3

I largely agree with all but one of the existing answers: Do what your boss has told you to do.

But in addition, I would say:

After a while, re-assess how good you are at it, and how much you like/hate it. Talk to your boss then and let him know your feelings (in a business-like manner.)

If you are still asked to carry on, and you really don't like it, then find a job where the role is more focussed on what you like. But be aware that you will probably have to make some other compromise in that case, if you are even able to find one immediately - the more experience you have the easier it will be, and it sounds like you don't have much so far...

2

I am also a junior developer with only 2 years of experience and my advice would be to do it, for multiple reasons. First of all, are you really going to tell your boss no? How do you think that is going to go over? You might as well look for a new job if that is the case. I don't think anyone has the right to turn down an assignment at the job you are getting paid to do, least of all a junior developer.

Secondly, 3 months working on one project isn't that long, especially considering that the entire length of your career is only 2 years. I find it very naïve to assume that working on a valuable side project for 3 - 6 months will completely upend the rest of career. I'm sorry, but that is ridiculous.

Thirdly, and most importantly, you are being given an opportunity to widen your skill base which is critical. I volunteer for every opportunity I can to learn something new, do something new, or contribute in a new way. The wider your skill set, the more valuable you are.

The company I work for does not have developers who are only writing tests, so I am not familiar with the concept of being pigeon-holed in that regard, but I highly doubt your company would want to force you into a position that you are not interested in. Again, where would be the value in that? You would probably quit, and it is more expensive to hire someone new then retain an existing employee.

Understanding how to test your code properly makes you a better developer. If you are writing tests for code written by multiple people, or even just one, you will undoubtedly sharpen your development skills. The majority of what I have learned in the last 2 years has been from reading other peoples code, picking it apart, and trying to understand things I haven't seen before. Maybe this is what your boss intends for you.

Overall, it is unlikely you are going to work for this company for the next 30+ years, or however long your career will be. Your next job may not have dedicated testers, and the fact that you have so much experience writing automated tests in selenium may be what separates you apart from another applicant.

1

How comfortable are you with Java backend? How is your code received?

With a couple of years of experience, you should be not describing yourself as a beginner and in turn be able to mentor others. So perhaps this is an effort, by the team, to increase your value.

I'd have a very frank discussion with the manager. Why are you being asked to assume this role? Perhaps they are asking you to do it because no one else wants to and you are the junior person. In this case, I would ask to be assigned to this role for a limited time.

If the answer is because your skills as a backend developer are lacking, well then you have a choice. What can you do to improve your skills in this area?

You may not have a choice in the matter, and this is what the company needs and they tagged you to do it. So do it for a year. It will be time to move on in a year or so anyway. At three years' experience you should have a much nicer title and a salary to match.

1

I think this question needs a more nuanced answer. You have certainly gotten the two extremes: suck it up and do the work or cut and run. Company and team culture plays a big role in this as well, which you don't elaborate on in your question, so here is how I would approach this situation.

Since you are new to the company, don't assume good intent or bad intent. You mention that your role at the company has not been defined yet. Perhaps this is a good opportunity to get that definition. Talk to your manager and ask what they envision for your role, and if automated testing is the primary focus. You don't need to mention your distaste for the work, or where you want to take your career. The goal of this conversation should be to get more information about your role at this company and the team culture so you can assess for yourself whether this job is a good fit.

Once you have more information, you can make the judgement: do you "suck it up and do the work" or do you "cut and run"?

0

Try to find the lemonade within the citrus fruit. I had to write tests for a program producing technical documents. At first, it seemed REALLY boring -- until I tried it and failed gloriously at the beginning. Simply make an art out of it:

You will develop a certain sense to modularize your tests -- a rather valuable property to ease debugging. Writing tests taught me how to use my program literally in minutes, not in days and made bad usability HURT. For free, you will learn to easily write minimal proofs of concepts (incredible precious to communicate bugs such that they are solved fast!)

Good tests are fast -- so execute them concurrently. And woooushh you will have the opportunity to happily dive into advanced concurrent topics like Concurrent Maps, lockless programming and so on. As someone with a vivid interest in research after leaving the university, this was wonderful. One lesson I learned the time-consuming way: Try to minimize file writes on (slooow) virtual disks.

Fast tests also means: instantly to interpret. Use simple green and red colors. When you need half of the day to assess whether your 40-page document is correct, you will not execute your tests often and get bored. This is a great opportunity to get ideas for meaningful error messages from a user perspective (not ,"NullPointerException on array xy", but "No contract with ID abc found. Did you forgot to call setReporting() (Searched reporting: 2022QA2)?").

Get acquainted with the new features which the current version of your testing tool (Selenium) offers. Perhaps parametrized tests or test suites, ...

Optimize your workflow. Git can be used with an OpenPGP key. Write Javadocs. Use hooks. (You may even force your collegues to only commit without syntax errors and failing tests!) Train to write helpful commit messages. Try to modernize your toolset, e. g. by requesting a newer software version. Be kind and helpful and you will find open ears. In this way, you will become responsible for the technical infrastructure -- an area outside of Selenium testing.

GUI testing has its own interesting sujets -- user interactions while executing a long calculation (concurrent programming -- bugs due to serial instead of parallel execution lead to really annoyed users which cannot believe they have to wait multiple seconds for their high-range PC!), how to test on text being outside of the currently visible range, different screen sizes and operating systems, static analysis (papers concerning symbolic execution!), ...

Some days you will be mentally emerged into a specific bug, but on the other days try to work on multiple different issues to prevent boreness.

Seeing tests means discovering inconsistent program behaviour. So you are intensely prepared to work at interface standards, documentation, process documentations, ...

Note that tests do not solely exist to being written, executed one time correctly and becoming useless, but to prevent unwanted side effects during programming and as such, secure the reached quality niveau.

And last but not least: Every company has tickets which someone somehow should do in a distant future if one will have the time and more colleagues -- after the second coming of the lord. Here, you may raise your hand for things like quality control of another colleague's solution, tidy-up-tasks, ... In this way, you will get tasks outside of the testing realm.

Good luck!

-13

I am afraid if I start working on this which may take 3-6 months ...

the answer couldn't be simpler,

Don't do it.

There's nothing more to it.

It is inconceivable that, in software, you would do 6 months on a field you are not interested in.

In software you are and will be instantly pigeonholed based on your experience.

You must guard your experience reputation as if it means everything, which it does.

Sure, the market is down from a year or two ago, but you can still easily get a new job if needs be.


Note that I don't know and don't care about the specific fields you mention. It could be that, in fact, "Selenium" (or whatever it is) is a highly lucrative field. That's not relevant to the core of the question. In software, given that you don't want to be seen as an X worker, you must never, ever work in X.

16
  • 11
    This answer makes it sound like it would be impossible to switch subfields in developer jobs. But on the contrary, I have found it to be easy and often even mandatory, as technologies progress and needs of companies change. Besides, there are a lot of ways to phrase experience in CV to match the position you seek.
    – jpa
    Commented Jun 19 at 14:21
  • 8
    Not only does it make it sound like switching subfields is impossible, it also makes it sound like having developers write tests is necessarily outside of their subfield.
    – eques
    Commented Jun 19 at 22:07
  • 9
    This answer is absolute garbage. To "never be known to have written tests" is to "never be a developer ever again"
    – Brondahl
    Commented Jun 19 at 22:31
  • 8
    I'm afraid the premise of this answer does not account for the skillset that a contemporary software engineer is expected to have — especially if someone wants to be considered a "full stack developer." I'm not sure what your experience is with software development, but not wanting to do automated testing is for a software engineer like a plumber not wanting to test for leaks. Commented Jun 20 at 2:13
  • 5
    As someone involved in hiring, I'm looking for people who are adaptable - I don't know what tech they will need to work on 5 years from now, it might not even exist yet, so I value people who are hungry to learn. Every company I've worked for in the last two decades has had the same view. Clinging to your favourite is a good way to get stuck on dead-end legacy projects. Commented Jun 20 at 7:10

Not the answer you're looking for? Browse other questions tagged .