183 stories
·
0 followers

Further hardening glibc malloc() against single byte overflows

1 Share
Comments
Read the whole story
karlosmid
4 days ago
reply
Zagreb
Share this story
Delete

Don't Leave Coredumps on Web Servers

1 Share
Comments
Read the whole story
karlosmid
4 days ago
reply
Zagreb
Share this story
Delete

Blame Charles Mochet

1 Share

The standards of your industry and our culture were set a long time ago. So long ago that we often forget why... we forget and then we fail to change them.

In 1934, the rules of bike racing were changed to ban recumbent bicycles. And that rule has stood for more than 80 years, because Charles Mochet made the mistake of giving his faster, safer bike to a cyclist who wasn't respected. To preserve the status of existing riders who had paid their dues, the governing bodies banned the bike forever.

All of those riders are now dead, but the rule persists.

Cars have two headlights because horse-drawn carriages had two lanterns. Of course you couldn't put a lantern in the middle, that's where the horse goes. Now, it's easy to make a bar of light, one that illuminates from edge to edge.

And jobs used to be done by men, because statistically, it's easier to find people who can lift heavy objects among the males in the population. But now, most lifting isn't heavy, it requires insight and care instead.

What else is still stuck? 

       
Read the whole story
karlosmid
4 days ago
reply
Zagreb
Share this story
Delete

A professional stumbler

2 Shares

Leo's working hard to do something he's never done before. He's just turned one, and he doesn't know how to walk (yet).

There are no really useful books or videos on how to walk. It's something he has to figure out on his own. But instead of waiting on the couch until the day he's ready to proudly strut across the room, he's there, on the floor, every day, trying it out.

He's already discovered a hundred ways that don't work, and stumbled countless times.

But he persists.

I don't know about you, but this is precisely the way I learned how to walk as well.

In fact, it's the way I learned how to do just about everything important. By doing it.

       
Read the whole story
karlosmid
4 days ago
reply
Zagreb
Share this story
Delete

Leading Indicators in Unit Testing Implementation, Part II

1 Share
This series deals with the implementation of a unit testing process in a team or across multiple teams in an organization. Posts in the series include:
Goals Outcomes Leading Indicators I
Leading Indicators II

Part I was HUGE! Now, let’s look at broken builds. We want to see a decrease in their number over time.

This may sound a bit strange. Our CI is supposed to tell us if the build breaks, that’s its job. Isn’t having more of them a good thing?

Unsurprisingly, the answer is “it depends”.

As we want the earliest feedback, the answer is “yes, of course”, the CI system serves us well. However, if we don’t see a decrease in broken builds, that may mean the CI process is not working effectively. We should investigate.

CI PI

Let’s trace the steps leading to failing builds and see if we can improve our process.

Are all the tests passing locally? If not, we’re integrating code that fails tests into the trunk. If tests are not run locally, when they run in CI builds, they will probably fail too. That’s a big no-no. We may even find out the tests are not even run locally, and we’d want to improve on these behaviors.

If tests do run and pass locally before they are committed, there might be another problem. That may point to issues of isolation. If they pass locally, tests that depends on available resources in the local environments, find them there. But at the CI stage, they don’t and fail. More broken builds, indicate the team has not learned how to write isolated tests yet.

There might even be a bigger issue lurking.

Trust and accelerate feedback

We want to trust them on the CI environment, but since they “work on our machine” and not on the CI, these tests just got a  trust downgrade. This can have a weird counter effect on our way of running them.

Since results we trust run on the CI, and local runs are creating confusing results, we may stop running tests locally at all, and run them instead on the CI server making sure they run correctly there. When we do that, we make our feedback cycle longer, but more importantly, we risk the tests failing for the right reason, but holding the rest of the team hostage until they are fixed.

To get the right feedback early, we need to get back to running tests locally.

We want to increase the number of isolated tests, so they can be run locally, and can be trusted to fail on the CI server. Isolated unit or integration tests failing before committing is the first line of defense.

Then, we want to be able to run the non-isolated tests either locally or in a clean environment as we can manage. The point is to not commit code until we trust it. This may require changing available environments, modifying the tests to ensure cleanliness, pre-commit integration or any combination of those.

Can you believe all these improvement opportunities come from a single indicator? The deeper we dig, and more questions we ask, we can find opportunities for improving the process as a whole.

We’re not done yet.

Read the whole story
karlosmid
4 days ago
reply
Zagreb
Share this story
Delete

Nordic testing days - closing it all up

1 Share

So, second day of NTD 2017... The scary part where I get to speak. At least, it was directly after the keynote, so I would have most of my day worry-free. 
Fiona Charles's keynote raised an important matter - As testers we should be responsible for our ethics - both towards the company that hires us, but more importantly, to the public that our product affect, and to ourselves. In a perfect world, everyone would be doing the right thing, so there will be no ethical dilemmas. Sadly, our world is not perfect, and we are asked to lie, or help in covering up information, or take part in a product that we think is morally inappropriate (my personal "no way I'll work there" include gambling sites, porn and most ad-services). In such cases, we have to know when to say "no". "No" to lying. "No" to deception. Also, it is very important to know that there are levels of saying that no. Most of the times, this no should be voiced internally - Letting the product owner know that the tests indicate a very high risk in releasing the software, asking again if we are comfortable with *this* business decision, going over your manager's head to make sure your concerns are not ignored irresponsibly, even resigning when you think the company is acting immorally (but not illegally) . Sometimes, when there's something more serious is on the line, it means that we should notify external entities - turn the external auditor's attention to the flaw that might cause a safety-critical component to malfunction, anonymously tipping the police when acts of fraud are being sanctioned by the CEO,  or even going to the media to reveal how irresponsibly the company is handling their user data despite all warnings and attempts to fix this. 
My main takeaway from this talk is that it's always easy to know what is the right thing for others to do. Especially in retrospect. Knowing the right thing to do yourself, and having the courage to do so - is not always that simple. Let's hope we won't face such dilemmas ourselves. 

Then, after the break, there was my talk. Was I nervous? yes. I think it went well, and some of the questions I got at the end indicated that my message had indeed reached at least some of the audience (my message, in short - threat modeling is very much like testing, so go and do that. 

After that, I could enjoy the rest of the conference worry-free, and went on to listen to some very good talks (such as Carly Dyson's talk on her insights from being a consultant, Melissa Marshall's thoughts about integration tests or Gwen Diagram's talk on logging and monitoring). 

Finally, was the closing keynote. Usually, I really like the keynotes - where you get great speakers with ideas that are inspiring and thought provoking. This one, sadly, was neither. The speaker, Kristjan Korjus, showed us a really interesting product - a robot that is meant to facilitate "last mile delivery" and make delivery a lot less expensive. It is, to borrow the Cynefin terminology, a very complex situation, and thus probably the most interesting situation, when the way forward is by probing fast and learning in retrospect, so I'm assuming that any of the directions there could have made out a great keynote that will give people something to take home except "oh, look, a cute robot". Instead, we got something that looked a lot like a sales pitch, and I'm not even sure who is supposed to buy what. 

Anyway, after the keynote and thanking the amazing conference team for their magnificent work we've moved to a nice bar for the after-party, where we got to say goodbye to those flying soon after the conference ends, and chat a bit more over dinner with those that were staying another night.
Yes, naturally we met a bit more with people at a(nother) pub for some more chats and fun. 

The last day where I could say it was still a bit conference-y was when we met the next morning for breakfast and final goodbyes. I then went with Sven for a day-trip in the countryside (where I took the picture you can see above). A really nice way to take a slow cooldown from a conference. 

So, all in all - it was a great conference. A lot to consider, great experiences and even greater people. If you are making a list of conferences you want to attend, this one should be very high on your list. 

Read the whole story
karlosmid
8 days ago
reply
Zagreb
Share this story
Delete
Next Page of Stories