In a time where DevOps culture demands “everything as code”, from infrastructure to monitoring, its about time we took “testing as code” seriously.
First of all, I’m a big fan of test-driven design (TDD) and unit testing, but I’m not just talking about unit testing here. We already know unit testing should always done by a unit testing software framework, (usually) written before the code, and is always written in code.
Beyond this type of functional testing, you venture into feature testing. Testing the integration layers, and end to end testing, probably manually. With automation as the goal, you really want to focus on how you approach testing and give some consistency across it all.
There’s a number of principles and practices that lend support to the idea of this “testing as code” approach, including continuous integration, automation over documentation, automated testing, version control and infrastructure as code. Ultimately, it’s about making testing less painful.Read More »
By now you’ve probably seen this image, with waterfall on the left, and continuous operations on the right, it’s an evolution.
I’ve always thought that evolution was a great way to describe the software delivery journey of a company or team. Evolution is not about one person, it’s not about the first person being smart enough to discover fire. It’s about continuous improvement.
It’s about values and attitudes, ideas and behaviours. It’s a way of thinking, a way of doing and a way of being. Culture, paradigms and philosophy. Practicing as well as preaching. It’s about taking the best experiences and sharing those with others. That’s how we evolve.
There’s an Indian story about six blindfolded men who are trying to understand what an elephant is. One man just feels the trunk and thinks the elephant is a snake. The rest feel different parts and think that it’s a fan, rope, spear, wall, tree.
The same can be true for us in software engineering. Often we find that we’re talking about the same thing but from a different perspective. Perhaps from a technological point of view (infrastructure, development or testing). Perhaps from a different methodology (Agile, Lean or Continuous Delivery). However they are all talking about the same thing.Read More »
Back in February 2016, I went to PHP UK Conference. One of the points resonated with me, so I wrote down the following:
“We need a compromise strategy - even if our strategy is to do nothing, write it down, agree on it. (see PSR-9 and PSR-10)”
PSR is PHP Standards Recommendations. PSR-9 is a draft recommendation on the subject of security advisories and PSR-10 is a draft recommendation on the security reporting process. Having a compromise strategy is in direct response to PSR-9 and PSR-10 existing. Read More »
The agile manifesto talks about “people over process”. As someone who is often very process-driven, I know that the right process will produce the right results, and the importance it plays in effectively delivering software. What I really wanted to understand is what is meant by “people over process”.
As I move away from developer towards a more management role, I knew things would change.
I knew it would mean creating presentations, more time in workflow software like Jira, status reports, urgent emails and not so urgent emails, being responsible for workflows and processes, planning work, scheduling and attending meetings.Read More »
We now live in a time of version control, git and github. If you work in software development you should be familiar with “pull requests”.
A pull request is a way for people to contribute to your code repository.
But that’s not all, it’s also an opportunity to review your peers code.
Peer review – an activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities – is one of the most powerful software quality tools available. Peer review methods include inspections, walkthroughs, peer deskchecks, and other similar activities. After experiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them.
Code reviews are really important and will actually help make your team more efficient.
Peer code reviews are the single biggest thing you can do to improve your code - Jeff Atwood
There’s a few tools you’ll want under your belt if you’re going to review other people’s code.Read More »
subscribe via RSS