Here at YOOX NET-A-PORTER, we think that testing is an important part of a modern development process. As a new starter in a team working on Scala APIs that provide up-to-date shipping options information, I wanted to write about ideas we’ve discussed on how we write test code. Writing good test code can be as much of a skill as writing good application code, and our team have been looking at tools and frameworks to help us with writing the most readable, reliable and efficient test code that we can.
The 6th London Software Developer in Test Gathering will be held at THE NET-A-PORTER GROUP offices on Thursday 6th March, between 7:00pm and 9:00pm.
There will be three talks, as well as the opportunity to discuss the latest technology and topics affecting developers in test.
Or is it?
It’s not so much the act of estimation that’s the issue. We accept that estimation can be a useful tool to help teams gain a shared understanding of a work item, and to break work down. It’s what we do with those estimates afterwards that matters. Other than the value to the team, the most common reason for doing any estimation is in an attempt to be predictable: we want to be predictable so that we can budget for projects, and provide our stakeholders with some understanding of the progress of those projects.
There are many misconceptions in the software industry regarding both Manual Testing and Automated Testing. Some people believe that Automated Testing is the bee’s knees and exists as a replacement for Manual Testing. Others believe that Manual Testing is a simple set of step by step tasks that anyone can run through to check an expected output, and that it’s dying out.
The truth is that both are very important and necessary; they go hand in hand and complement each other. The bottom line is that in order to produce the highest quality app, you should have a strong manual testing element in place alongside utilising an automated framework.
So let us start by explaining a little bit about Automated Testing…
The NET-A-PORTER Group is running a free Agile discussion evening in west London on Wednesday, August 14th, between 6:30pm and 9:30pm.
Topics will include:
- The perfect Scrum board
- Agile and testing
- Strategic planning and Agile
- Cross-functional teams
- Splitting stories
- Agile at the enterprise level
Come along and meet Agile practitioners from the NET-A-PORTER Group and many other companies, participate in discussions around a number of vital topics in Agile project management, and enjoy the hospitality of our striking London offices.
Note that this is not an introductory session; you will need at least a basic understanding of Agile/Scrum practices to benefit from this evening.
Update: The event sold out within hours, but you can still sign up to the waiting list if you’d like to attend.
Running retrospectives can be hard work. The outcome can be affected by the dynamics of the group, how controversial the topic of the retro is, and work pressures external to the session. Here are some rules that I’ve found useful when planning and running retrospective sessions.
What does your ideal agile board look like? Simple: one that dispenses Krispy Kreme doughnuts and coffee for free. Unfortunately, the recent meeting of the London Agile Discussion Group considered more process-driven matters around how a good agile board should look.
The original plan was to discuss each other’s boards, but we decided that this was too problematic due to everyone’s implementation being tailored to their own circumstances: some don’t code review, some have separate testing and UAT instances, some use e-boards, et cetera.