Continue reading: Breaking up the monolith at Discovery and enhancing subscription flexibility in one fell swoop

Breaking up the monolith at Discovery and enhancing subscription flexibility in one fell swoop

No developers were hurt in the making of this interview

Max – Tell me briefly what your team is up to @ Discovery?

I’m one member of a devteam which takes care of external API’s. We build services for streaming TV (OTT), for example user management, authentication, user entitlements and playback services.

We started this effort to enable a more flexible way to assign entitlements to users, for example through affiliates (like cable TV companies and mobile phone operators). Before, you had to be a subscriber at Discovery to be able to view any content. Being a direct subscriber is called the DTC model, ”Direct To Consumer”. But a large part of the business in some markets still comes from the so called “TV Everywhere” model where the customers come in via affiliates.

Continue reading
Continue reading: Readable Java system tests with good old JUnit

Readable Java system tests with good old JUnit

This article is the third in a series about system testing:

  1. Dockerized testing vs end-to-end testing
  2. How to setup Dockerized testing
  3. Readable Java system tests with good old JUnit

JUnit is poorly named. Given the name, people tend to think that it should only be used to write Java unit tests. And then people feel a bit hesitant about writing their integration tests with JUnit too. When they start with system tests, they often think they need another driver for their tests. Sure, maybe using another abstraction layer and a custom domain specific language (BDD), you can make the tests more readable for a non-programmer. That often comes at the cost of making the tests less readable for the programmers. And if we are honest, who’s going to read the tests the most? Perhaps just naming test classes and methods well and writing readable code can suffice?

Continue reading

Continue reading: How to setup Dockerized testing

How to setup Dockerized testing

This article is the second in a series about system testing:

  1. Dockerized testing vs end-to-end testing
  2. How to setup Dockerized testing
  3. Readable Java system tests with good old JUnit

You may want to read Dockerized testing vs end-to-end testing first.

How to setup Dockerized testing?

A prerequisite for running your tests against a dockerized environment is of course that the service you want to test is packaged as a Docker image. Also, all of the services which the System Under Test (SUT) depends on needs to be dockerized. If you don’t have that, your environment is not fully dockerized and you will suffer the consequences of having to test against external services.

If your SUT is packaged as a Docker image and has no dependencies on other services, you can just start it using “docker run” and run your tests against it. However, usually services have one or more dependencies to other services, such as its own database, a queue and perhaps a external RESTish service that returns nasty XML. You want each of these services in their own container. To spin up a bunch of docker containers, you can use docker-compose.

Continue reading

Continue reading: Dockerized testing vs end-to-end testing

Dockerized testing vs end-to-end testing

I recently rewrote the end-to-end tests for a service. This brought up the question of what we should test in the end-to-end (e2e) tests vs our Dockerized tests.

This article is the first in a series about system testing:

  1. Dockerized testing vs end-to-end testing
  2. How to setup Dockerized testing
  3. Readable Java system tests with good old JUnit

e2e tests vs dockerized tests

Since the original e2e tests were written, we (my team) have also introduced another type of tests. We call them “dockerized system tests”. These are similar to the e2e tests. They also test the connections between services in the system, and how the system works as a whole. One key difference between e2e tests and dockerized tests is that the dockerized tests do not test the system when it is deployed the way we deploy it in staging and production environments. Our dockerized tests bring up all services in a single machine, and we usually don’t set up redundancy, clustering, load balancers and such things.

Continue reading

Continue reading: Automated testing is never enough

Automated testing is never enough

In the pursuit to automate testing to create faster feedback loops and build quality in, some teams forget the value of manual testing. In my experience, without manual testing (as well) we are toast.

Continue reading

Continue reading: My Testing Philosophy

My Testing Philosophy

Testing is a topic covered with mysteries and misunderstandings. Some people believe that testing is simply a verification of a specification. Others rely on a false assumption that everything can be automated and there is no need involving test engineer into anything else than writing automated scripts. Many think that quality is a responsibility of only a few folks in the company and should not bother the rest.

My views are different to the ones stated above, as my expectations on testing are alike to other engineering disciplines, for example, programming.

On high level I am following 3 main principles:

  1. Testing is a creative activity.
  2. What can be automated should be automated.
  3. Quality is everyone’s responsibility.

Continue reading

Continue reading: Security Test-Driven Development – Spreading the STDD-virus

Security Test-Driven Development – Spreading the STDD-virus

Agile development with short release cycles have been here for a while now. Most of us want fast feedback loops and many even Continuous Delivery with changes in production software everyday. However, most of us also want secure software and the question is: Can security engineering keep up the pace? A fast feedback that your production website has been hacked is not so nice.

Security is a quality attribute of your software, just like performance. If you don’t want to be surprised by bad performance in production, what do you do? You test and design for it of course and you preferably do so continuously from the start.

In my experience, the same however cannot be said of security. It is very often relegated to a once a year penetration-test activity. Not really an agile way of working is it? Not a secure one either since untested software is released as often as everyday. There must be a better way of working which allows us to both work in an agile way and to verify security on the way.

In the security field people like Gary McGraw have long been advocating ways of “Building Security In”. The Microsoft MVP Troy Hunt also proposes that you should “Hack yourself first”, instead of just waiting for the pentesters. Shouldn’t it be possible to weave these security activities into the process the same way as it is possible with normal testing activities using TDD? Indeed I, as well others believe it is so. Let’s look at how small extensions to an agile process can work in this direction.

Extending Sprint planning to deal with security

To start off you must first know what the requirements are. In a normal agile project this is done by eliciting User Stories from the customer or the Product Owner.

Let’s take an example of an online e-Commerce site. A User Story might be “As a customer I want to be able to add a review of a product so that information about products can be shared between customers”.

This works very well for traditional functional requirements, but for non-functional requirements a little extra thought is needed. In the case of security requirements it is often useful to state a requirement in a scenario that should NOT happen. In our case we shall call these scenarios “Abuser Stories”. These stories are non-technical descriptions of bad things you want to make sure you avoid. An Abuser story for this site might be:

“An attacker uses the Review Product-function to spread malicious Javascript”. Another might be: “An attacker abuses the Review Product-function to gain unlimited access to the database”.
A Product Owner might not be able to come up with these stories himself, but might need the help of a security engineer to help him with finding these threat scenarios.

SecurityTesting
Continue reading

Continue reading: Developer Testing: Book Release Party

Developer Testing: Book Release Party

Developer Testing PartyLast Friday, we had a release party for my book, Developer Testing: Building Quality into Software, here at Crisp. Thanks everyone for coming! Apart from signing books, I did a short presentation and made some announcements. 

I started by talking about the process of writing the book (It’s available on Amazon, Adbris, and Bokus.) It took four years, but I did have some bumps along the road, like two kids :). For those of you who haven’t heard the story, here it goes: Large parts of the concept of developer testing were born during my time at the Swedish Postcode Lottery, where we were a brand new Scrum team working in a regulated industry. Since we had no testers on the team, and probably even more important, no traditions and rituals to adhere to, we self organised into automating all checking: at unit, integration, and end-to-end level to such a degree that we were confident about releasing, pretty much always.

Continue reading

Continue reading: Slides from Agile Testing Day Scandinavia

Slides from Agile Testing Day Scandinavia

In this talk I presented a simple 2D platformer written in Java/Groovy and how to use Spock to test it. I’ll make the source code available in a while. By the way, of you’re not using Spock yet, then start!

Continue reading
Continue reading: Think twice before logging

Think twice before logging

balloon_irrelevant

One property of legacy code is inflation by irrelevant logging statements. Not only does this increase the size of a bulging code base, I’d also argue that it’s dead wrong.

Quite recently I’ve had the honor of making acquaintance with a piece of code that looked roughly like this:

if (LOGGER.isLoggable(Level.FINEST)) {
    LOGGER.log(Level.FINEST, "foo is now", foo.getValue());
}
boolean result = doSomeActualWork(foo);
if (LOGGER.isLoggable(Level.FINER)) {
    LOGGER.exiting(this.getClass().getName(), "bar", result);
}

Continue reading

Continue reading: Slides from JDays

Slides from JDays

I talked about some overlooked (and quite new) features of JUnit at JDays in Gotherburg. My presentation was a tour that started with boring example tests, and then proceeded through parameterized tests, theory tests, and generative testing. At the end of this tour, I spoke about fundamental, yet again overlooked, testing techniques such as finding

Continue reading
Continue reading: A Decade of Agile, A – F

A Decade of Agile, A – F

A decade of agile boils down to theses simple fundamentals and steps for me. A. Ask: do you need to improve as an organization? Only go forward if your sincere answer is yes. Ask everyone: Do you want to improve? Same procedure. Make sure you will fail (and win) regularly by commitment (plan/hypotheses) and checkpoints.

Continue reading
Continue reading: About the Developer Profession #1: How Many Decisions Do You Make in Real Time?

About the Developer Profession #1: How Many Decisions Do You Make in Real Time?

In this series of articles, I’ll be discussing the developer profession from different angles. The common denominator is that all articles will, in one way or another, be about professionalism. This first article is about the different factors and decisions behind every single line of code.

Notes snd Equations

A while ago I spoke to a friend who is pretty much a professional singer. He explained singing to me in a very passionate way, saying that singing is like solving multiple parallel equations in real time. He told me that it’s quite obvious that every singer has to follow notes. What’s less obvious is that the singer also takes a multitude of micro decisions during every second of his/hers singing. He told me about tempo, intensity, interpretation of the composer, matching the expectations of the audience, synchronization with other singers, following the Kapellmeister, and a bunch of other factors. I was quite impressed.

A second later it struck me that this goes for programming as well, and I started to list all the equations a developer must solve while writing a single line of code. Here it is!

Continue reading

Continue reading: Alla mjukvaruprojekt borde ha en Kodkvast!

Alla mjukvaruprojekt borde ha en Kodkvast!

– “All kod är en skuld!”
– “Den bästa koden är den kod man inte skriver!”
– “Snabbaste sättet att få upp testtäckningen är att ta bort död kod!”

Jag tror att alla är överens om att det är bra att hålla sin kodbas så liten och kompakt som möjligt. Byggtider hålls korta, testsviter går fort att genomföra, driftsättningar går fort, statisk kodanalys går fort, nya teammedlemmar kommer snabbt in i koden, risken för buggar och sårbarheter hålls nere och så vidare. Kort sagt, man blir mer lättrörlig!

Så alla utvecklingsteam borde ägna tid åt att inte bara skriva ny kod, utan också att faktiskt städa efter sig. Men det är lättare sagt än gjort…
Continue reading

Continue reading: Slides från SAST Stockholm Q4: Tema agilt

Slides från SAST Stockholm Q4: Tema agilt

Igår hade jag äran att få gästa SAST Stockholm Q4, där jag fick hålla en presentation om utvecklartestning. Med handen på hjärtat, så blev det lite mycket information på få tidsenheter ibland. Dock brinner jag verkligen för ämnet och vill säga så mycket jag kan. Efter att ha checkat runt lite, gläds jag åt att

Continue reading
Continue reading: Test Strategy

Test Strategy

In september I had the great pleasure of speaking at the http://agileprague.com/ conference. It was the second time I attended and I was equally pleased with the event this year. Last time I just attended while my wife gave a talk, but this year I decided to share my thoughts on Test Driven Development. The talk was

Continue reading
Continue reading: Seminar “Will automation kill the tester?”

Seminar “Will automation kill the tester?”

Last Thursday I gave a two hour talk on Agile Testing, “Will automation kill the tester?”, for Dataföreningens network for test and requirements in Stockholm. I talked about testing in agile contexts, the agile tester, busted (and approved) some myths on agile testing, and gave examples – lots of them. How different companies, project and

Continue reading
Continue reading: Sources of bug list misuse

Sources of bug list misuse

Bug lists have the potential to consume a lot of your organizations effort. Bugs drive re prioritization, dispatching, reporting, followup –  even though they might be of one time nature and random occurrence. Whenever I encounter a huge bug list is to I ask which of these the organization will fix the upcoming release and

Continue reading
Continue reading: Every bug means two problems

Every bug means two problems

Finding a bug in your application actually means you have at least two kinds of problems: symptoms and process issues. To deal with quality in a sustainable way, you have to fix both!

Continue reading

Continue reading: Still not automating tests? Here’s why you should (again)!

Still not automating tests? Here’s why you should (again)!

The other day I read a blog by Uncle Bob. It more or less stated that no matter what situation you are in, writing automated tests will make you go faster. Ok, this is old news I thought, until I checked Uncle Bob’s tweets. A fair amount of people argued against this statement, and that surprised me!

Campfire
Join me at the campfire!

So I started thinking about why there still are fellow software developers that doesn’t believe in automated testing? Have they not seen them in action and understood what they are for? Please, gather around the campfire, and I will tell you one, just one, of my war stories, and then I will tell you why also you should write automated tests!

Continue reading

Continue reading: Where is that Red ‘Stop’ Button in Your Development Process?

Where is that Red ‘Stop’ Button in Your Development Process?

If you don’t dare to stop the line, continuous integration might be waste. Here is the second part of my three-part series on building the quality in on the SmartBear blog. In the first post of this series, I wrote about Toyoda Sakichi, the founder of the Toyota industries, who invented a loom that would

Continue reading
Continue reading: Stop the Line – Build Quality In with Incremental Compilation

Stop the Line – Build Quality In with Incremental Compilation

We in the software industry are still far behind when it comes to automated quality checks. Toyoda Sakichi for example invented the automated loom with stop the line capability almost 100 years ago. I write more about that in my first blog in a three-part series on building the quality in on the SmartBear blog.

Continue reading