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?
Most developers think about happy-path scenarios and bad usages that could cause application problems. Normally everything works fine, however, developers may not consider all use cases or how final users think, and this is where dedicated testers can help. A testers time should not be focused on happy-path cases. QAs should be building business knowledge, investigating special flows and being involved in every stage of the software development lifecycle to help all team members to take responsibility for quality.
Software Development Lifecycle
Last year, we changed our thinking from ‘testing to identify defects’ to ‘testing to avoid defects’ and this is how we do it during our Software Development Lifecycle:
During the Analysis phase, testers join Refinement Meetings with a high-level test plan that will enable developers to know what testers are going to look for later. This practice increases visibility and lets developers preempt possible bugs. The QA, applying ‘los 3 amigos’ philosophy (of BA, developer and tester) agrees the acceptance criteria with the product owner using their business knowledge and expertise. They discuss possible performance testing, stress testing, security gates or integration tests required with other external systems. The main QA function here is to ensure we have complete User Stories with an estimate of the effort to verify the development.
We believe that reviewing is one of the most successful ways to reduce bugs!
When developers start to work on a User Story, testers begin work in parallel, designing the quality gates such as unit tests with the developer, integration tests, GUI or manual tests. They also perform any additional security checks, performance testing, training, learning coffees, documentation or checking logs to monitor the new functionality that will be deployed later. We record screencasts to show that the acceptance criteria have been met and showcase this to product owners and stakeholder’s through demos or to final users through official communication.
Finally, to confirm that our story is ready for production, we create a pull request that activates all automated tests, including regression tests (we will discuss this in more detail in another post). Furthermore, the team leader or an assigned developer will review the code and a second set of testers will review the manual and automated tests completed. As a financially regulated company this fulfills all our audit trail requirements.
Projects and ticket are managed in JIRA. We use a project for each team, Kanban or Scrum custom workflows and dashboards to prepare our sprints and future releases.
Optimising the release process
While we aim to design out dependencies and remove merging as much as possible we nevertheless need to align some teams when resources are shared or simply because they will deploy code on the same day and need to be aware. To solve this, we created a tool on top of the JIRA API.
This is how Ebury ‘SECO’ was born.
SECO is used to manage releases and it gives the QA tribe visibility on how releases are progressing, which applications are going to be updated into production and any issues encountered. We also have a lovely view of the release calendar available to all teams within Ebury.
In summary, over the last 18 months we’ve moved from development and testing roles to a quality-first approach across the whole team, promoting full alignment between developers and testers in order to continually improve the quality of the product.
Any questions, please let me know!