DEV Community: Ania

QA to dev

Ania — Wed, 09 Mar 2022 22:22:59 +0000

It's been a while since I wrote something here.. lots has changed.

I used to be a QA.

I'm a dev now.

Transition is still going on, in my head and skills. In IT there is no such thing as successful stagnation. You have to keep on going, or you'll be left behind. That can be scary, but brings exciting opportunities. You can reinvent yourself, learn, grow, shift roles, move between jobs.

Talking to people that would like to make a career switch I often hear that it is all so overwhelming. All the myths of the genius dev, sitting at the computer on his own, away from people... that's not how most devs are, and it's not how you have to be to land a job in IT.

Being a QA is to be observant, understanding, inquisitive, always looking for loopholes.

Being a DEV is to keep a lot of moving parts in your head, looking for best+fastest solutions, working hard and being helpful.

Actually, you can switch the definitions around and they will still be true. Working in different technical roles in IT requires similar skills, with more emphasis on a particular technical part or a specific angle of looking at a given challenge.

There is place for all different types of people, different backgrounds and forte. You are welcome to join, there is space.

Do(n't) test your own code!

Ania — Wed, 01 Apr 2020 14:37:17 +0000

So... you know you should write unit tests (generally). You know, you should make sure your stuff works before you push, needing often some functional testing as well (I hope, although I should know better than to count on everyone doing this...).

But...

Why would you? You KNOW it's working, right? You tested it, right?
Wrong. You checked a few cases. "Isn't that the same?" Nope... well, kind of, but nope.

What's the difference

When you run your function with an argument you know should pass, that is a happy path check. To me, it becomes a test, when you intentionally picked that value, when you know why this and not that value is worth checking. In a test like this (we can talk about other test approaches in another post) you should first write down what EXPECTED RESULT for it is.

To test or not to test

Test, obvi, but... don't just check some cases, think about what values, what steps and what effects you are checking for. Make the testing intentional. After a short while, you will see that it takes as much time than just choosing random values, but it makes a difference that you find issues before anyone else can see you introduced them... because you will eliminate them before they get a chance to notice!

How to test your code

Just write down a list of tests (or go TDD on it) that you'll run:

<tested_function> - <precondition> - <tested_value> - <expected_result>

<precondition> also called "initial conditions" or "setup". All the things you need in place to be even able to start testing.
<tested_value> usually the one thing you are testing in a given test case.
<expected_result> is a return value or a side effect of the function(ality) when run with the <test-value> passed to it.

Choose test values based on your knowledge of the intended range of values for the function. There are two basic techniques to define values for testing and they work together pretty well: Boundary Values Analysis and Equivalence Partitioning. Worth reading about them, they might seem very simple (the theory actually is) but their usage goes beyond number ranges.

Knowing those two basic techniques will go a long way towards improving your testing abilities.

Now, why NOT to test

Or rather "why my testing is not enough"? Well, in a great majority of cases, unfortunately, people are too focused on making their code work in an intended way, so they become narrow-sighted and don't even realize what possible issues they should be watching out for. That's where TDD, BDD, etc. get useful because when you define the expected result/behavior BEFOREHAND, you don't have the narrow sightedness yet and can analyze all sorts of possible scenarios. Negatives? You can't predict many changes and details that come up while already working on your code, but that's ok :)

Word about QAs and testers

Even if you become a great tester yourself, making sure you have a nice set of tests on different levels (see Test Pyramid) and your code is so clean, Uncle Bob would be proud, you will still need someone else's eyes on it. It doesn't have to be a professional tester or QA (although great if it is), but at least someone else than you, someone who is not afraid to say:

"You think I can't find any bugs? Hold my beer".

Shortly about.. criticism, code reviews, comments

Ania — Tue, 04 Feb 2020 13:46:53 +0000

You wrote some code, you're about to push.. wait a sec, please.

Working together

Most of the time developers work in teams. There is a lot of collaboration, hopefully, appreciation of the effort and, also hopefully, criticism. Yes, criticism. It should NOT be about making comments on someone's ability to do their job. It should NOT be directed at a person at all. It's about the shared code, making sure everyone understands how to work with it, how to make modifications when needed. It's about the trust that the code will do its job and not fail easily.

Hello, my name is...

When you name your variables, files, write commit messages, name tests, state your point in a meeting, writing a bug report... think about this: you are working in a team and the goal is for what you create to work in a bigger context.

Once you write your code, take a break, then read through it without going through how exactly it works.. think about:

Would it make sense for other people in your team? You know your colleagues, think of what kind of changes they usually ask for, what are their usual comments and aim for cleaning up the code in such a way that it will not require updates you know they will request.
Are the variables, functions, class names, etc. clear and accurate? Are you naming things by what they are/do?
Are you following conventions the team agreed to?
Think of what you would be commenting on when reading through another person's code.
Be critical of your own work.

Let's all be nice

As for commenting on other people's work, stay away from a passive-aggressive tone, which creeps in at times. Read your comments before submitting them. Be clear, be concise, be polite. Write about the changes in code you propose and explain why, shortly. Be open to discussion about your comments.

It's not about you

One thing I want to make clear. None of the criticism coming from others or yourself(!) is to make you feel bad, it is about getting the code in a state where it will work well for the client, the end-users, and make your colleagues happy and efficient when working with it. They WILL appreciate it and you for it.

Even if you feel a particular comment is directed at you, think if it should. Then ignore the personal part of it, think if there is something actionable and useful about it. Use that part. Only then you can decide to ask politely for the person to comment on the code, not you. But that's a topic for another time...

Author's note:

Let's practice positive critic here :)

I gave myself about 30 minutes to write it and then another few minutes to correct it, so that I don't keep procrastinating on my first post!