Have a look at our ground breaking conference presentation here.
The post is the second part of the Unit test execution (part 1) blog post published in October 2016. This time we will explain how to run Python tests with coverage using a distributed architecture to ensure things don’t take too long! We will describe step by step how and what we set up to achieve this. But first of all lets quickly define what we mean by test coverage.
When we talk about Unit Tests we generally mean tests for individual units of source code as created as an outcome of Test Driven Development. But how can we apply this when we’re developing against areas of our code base that don’t have unit tests to start with, that is essentially Legacy code?
This post describes how we approached this problem in three phases.
Our teams are cross functional and fully responsible for the quality of the product they produce. We apply an end-to-end philosophy to our daily work, that is, we are responsible from user story creation through to ensuring that story is delivered, working and supported in production. Every team member will be involved in supporting the QA process.
With this in mind, what can we expect from the QA tribe? Why are QAs still important? If we have great developers that use automated tools to check their workflows, are focused on increasing the quality of their daily work and the company is aligned with a quality-first philosophy, then why do we need dedicated testers?