DEV Community: conectionist

It helps to distinguish between stories and tasks

conectionist — Fri, 26 Mar 2021 14:37:35 +0000

Introduction

Agile/Scrum teams using Jira often create a "story" for everything they work on (except bugs and improvements).
Tracking your work is not a bad practice, but not distinguishing between stories and tasks can be.

So what's the difference?

Stories contain changes that are visible to end-users.
(Most) tasks contain changes that not visible to end-users.

Examples

To make it a bit clearer, here are some examples of stories:

create installer
add login screen
add "Cancel" button
add application to OS startup

While not all changes are visual, they are all clearly visible to the end-user (ok, some users might be oblivious even to the most obvious graphical changes of an app, but that's a different story - pun intended!)

And here are some examples of tasks:

refactor login screen code
add documentation for IDE setup
research how to support 10k concurrent connections
integrate unit test framework
add third-party library to project

All of these tasks, when finalized, will have no impact on end-users. They don't know or care about unit tests, refactoring or third-party libraries. With or without them, the application/product is the same to end-users.

Ok, so what's the real benefit of this "separation"?

It's testability.
In Scrum teams, the Definition of Ready should (ideally) contain a checkbox that says "is this testable by QA?".
Also, the Definition of Done, should (ideally) contain a checkbox that says "has it been tested by QA?".

All stories can be tested by QA! Why? Because "Stories contain changes that are visible to end-users".
Can tasks be tested by QA? Not really. At least most of them can't. Why? Because "(Most) tasks contain changes that not visible to end-users".

"refactor login screen code" - Other than running a set of regression tests to make sure nothing was broken, there's not much QA can do to verify this. But then again, this wouldn't mean that they are testing this task alone, would it?
"add documentation for IDE setup" - Sure, QA can look at the documentation and actually try to do what was written there, but I would hardly call that QA testing.
"research how to support 10k concurrent connections" - QA can ask developers what the result of their research was, but this would not be QA testing.
"integrate unit test framework" - Other than making sure everything still compiles ok, there's not much QA could do. But again, this isn't QA testing. Or QA's job, for that matter.
"add third-party library" - Again, QA cannot test this specifically. Best case, they could run a set of automated regression tests to check that nothing was broken.

Conclusion

While it's easy to consider everything as a "story", it might help to distinguish between stories and tasks sometimes.

Let me know your thoughts!

Should blockers be part of the Definition of Done?

conectionist — Mon, 22 Jan 2018 12:19:53 +0000

In Scrum, there is something called the Definition of Done. It's basically a set of conditions which is used to objectively determine is a user story is done (in a sense that is understood by all parties).

Let's say that I've implemented a story, but upon testing the QA team finds one or more bugs that are critical (i.e. blockers).

Obviously that blockers will have to be fixed ASAP.
But can/should you consider that story done?
More specifically, should blockers be part of the definiton of done?

Also, what if it's not a blocker (just a P2 or lower)?

All answers are welcome, but I'd especially appreciate those coming from people who actually have experience with Scrum.

Thanks.

Why code coverage is not a reliable metric

conectionist — Sat, 13 Jan 2018 20:22:57 +0000

I often hear statements like "Let's increase code coverage" or "What's our code coverage?" (mostly from managers). And I think to myself "Oh, boy...".

Not because I don't like unit tests or think they're useless. On the contrary. I think unit tests are very important and useful.

What I'm against is using code coverage as a metric. Because it can mean nothing. And it usually doesn't.

Let me explain why

Consider the following class that validates and email address:

class EmailValidator
{
    public bool ValidateEmail(string email)
    {
        // just for demo purposes
        // I know it's not a very good email regex :P
        return new RegEx("[a-zA-Z0-9_]+[@][a-z]+[.]com").matches(email);
    }
}

And a class used for unit testing the email validator:

class EmailValidatorTest
{
    void TestValidEmail()
    {
        Assert.IsTrue(EmailValidator.ValidateEmail("someone@email.com"));
    }
}

What's my code coverage?

Well, I only have one class with one method. And my unit test goes though that code. That means my entire "codebase" is covered. Yay! 100% coverage!
That means my code is bullet-proof, right? WRONG!

Why? Because my regex, although not very complex, covers a lot scenarios.
I've only written a unit test for small letters.
I haven't written unit tests for emails that are comprised of:

empty string
caps
numbers
underscore
alphanumeric characters
combinations of the above (and there are plenty)

So, what's my REAL coverage? I would say less than 15%.

What about real life?

I'm not saying code coverage is always unreliable. But it only works as expected for simple cases. Like the following:

bool IsEven(int n)
{
    if(n%2 == 0)
        return true;
    else
        return false;
}

Two unit tests for this code will give 100% coverage and that's actually all the unit tests you need for this.

But you don't have code like this in real life. From my experience, less than 5% of any codebase has code that's dead simple like this.

Most of the time, you use third party libraries that have classes/functions like the regex I used above. Even though I only wrote one line, there are a bunch of if/else statements hiding behind that.

Conclusion

What I disagree with isn't code coverage per se. That actually helps the developer to visualize the areas in which s/he hasn't written any unit tests at all.

The problem is most people don't understand that
high code coverage ≠ code reliability.

You can have >95% code coverage and your application can be unacceptably buggy (I've actually witnessed this myself).