|---Module:text|Size:Small---|
Getting into Agile
Many people wonder – is it even possible to build a successful project without significant effort from multiple QA teams, going through all the waterfall project phases that we have embraced over the years?
Personally, I had my doubts. Challenging projects have very demanding development and QA phases and it seems almost impossible to deliver high-quality software without these very long journeys.
It all changed when I first started learning about Agile methodology and culture. It’s all very dynamic - you need to move fast, test every day, release often and make your customer happy with their product.
Personal experience
For me, it all started around July 2018, when I was challenged to start working with automation on a newly created Agile Squad. I had only three 3 days of training on the Automation Framework, so it was going to be highly demanding for sure. However, looking back, I could not be happier with the challenge I embraced.
|---Module:text|Color:Red|Size:Small---|
The Agile way of doing things
|---Module:text|Size:Small---|
Having a previous experience with the Waterfall methodology, the first few weeks felt odd. It takes some time to sink into Agile values and principles. The four main values from the Agile Manifesto are to prioritise:
- Individuals & Interactions over Processes & Tools;
- Customer Collaboration over Contract Negotiation;
- Working Software over Comprehensive documentation;
- Responding to Change over Following a plan.
The one that I find most related to Quality Assurance (QA) is to prefer working software over comprehensive documentation. Often, we end up in pointing out where small changes are needed to make our work closer to perfect. Agile allows us to do that and more.
|---Module:text|Color:Red|Size:Small---|
How do we deliver?
|---Module:text|Size:Small---|
“Deliver small wins faster”. The project is setup to have two-week long sprints. The main goal is to add value to our client with a high-quality shippable product increment at the end of those two weeks. Throughout each sprint we have several key moments, crucial for the success of our current and future deliveries:
- Daily Scrum – 15-minute meeting to talk about the progress on current user stories (if there are any blockers on progress; if there aren’t, how is it progressing);
- Backlog Estimation – meeting with the team to size and debate backlog user stories;
- Sprint Review & Retrospective – formal meeting with all the stakeholders to discuss what went well in the sprint and what could be improved in following sprints;
- Sprint Planning – decide which user stories from the backlog are promoted to the next sprint - Who will develop them and what testing is required.
My personal favourite is the Backlog Estimation meeting. As Quality Assurance Engineers we have the opportunity to raise risk & concerns that usually are not debated during the design process. The chance of design defects/gaps is reduced by doing this meeting, as we usually have more insight into the end-to-end process than just the small improvement being estimated.
|---Module:text|Color:Red|Size:Small---|
How do we test our code?
|---Module:text|Size:Small---|
It’s part of the Definition of Done of each user story to have automated tests for each feature being delivered. I’m using Celfocus Automated Testing Framework to develop these tests. I usually start the week by accessing the user stories planned to be developed during the sprint and estimate what effort it will take to automate the test cases required (or if automation is necessary at all).
Once this is done, I start by designing my test cases using the gherkin language. It helps to have most of the design work ready when the code is delivered to the environment. After that it’s smooth sailing (most of the time, at least) – mapping the required elements, designing the methods and it’s good to go.
Another part of testing, that is being done by developers themselves, is unit testing. This prevents code builds from completing if any of these static code analysis tests fail from the get-go. Another great step in improving our overall code Quality.
|---Module:text|Size:Small---|
Final Remarks
Despite the challenges, this is and continues to be a very good challenge for me. I’m amazed by how good agile work with digital improvements projects and I feel I still have much to learn.
