Three steps to improve the quality of your development process in a startup

I’ve been working in the IT industry as a QA engineer since the start of my career. Sometimes, my position was just hands-on testing in a waterfall-like process; other times I worked closely with the developers to write all the automation needed before the feature was considered done. Every company offers a different approach on how to increase the quality of their product, and I’ve also seen companies trying the same thing with completely different results. But there is always something that kept being constant: when a company reaches enough user-mass or the codebase gets big enough, the conversation about ensuring quality gets more and more important. Speed and productivity matter less if you alienate the users with buggy releases, and your engineering team gets afraid of areas in your code which changes _always carry side effects_. That is the moment when the way of _just getting things done_ that has worked till now starts getting on the way of a healthy product. That’s the point when the organization thinks on increasing the QA headcount.

Currently, I’m facing this situation again, with the difference that I feel way more prepared. Of course, every company has a different way of working, but starting to be a veteran in the industry allows me to recognize common troupes and analyze the situation with frameworks which worked for me on previous cases. For some of these steps, I highly recommend finding a person who will bring the expertise on automation or testing principles in your team, but a lot of these steps can be performed without by anyone, especially if you already count with a Quality-crusader in your ranks. And that’s what I’m going to help you with right now, giving you an example of the steps you can take to start improving the quality of your product and processes by yourself.

Before starting, I would like to share the first step I take when joining a new startup, particularly if there’s not a defined Quality process in place. I always start finding the Quality Crusaders currently working with you, those bright knights who, regardless of their work title, push for a quality-first approach of working and cares about following best practices. I even ask for them during my interviews when considering a new job. Having allies who will share their view on how to improve the current situation is invaluable. So, find them, and involve them in these first steps!

Step one. Describe the development process.

Ok, so we are all making software here. And the process seems pretty straightforward, doesn’t it? Some people sit in a corner. They write some code. They push that code somewhere. And our users enjoy it. Pretty simple. So let’s add a little bit more flavor to it, shall we?

I like to start naming the different the different states that a task (bug fix, feature, etc.) goes through before our users enjoy it to pieces. Of course, this is more of a guideline than a cooking recipe, but I’ll describe an example as broad as possible so hopefully, you can get inspired. In this case, a task can come from a bug report, a new feature requested on some work that we want to do internally (tech debt, etc.). At some point, an engineer will pick it up and start working on it. It will land the codebase. It will be deployed to some testing environment. And finally, it’ll be in our user’s hands. So, without caring about actions and transitions, the states would be:

Coding – Code on the repository – Testing environment – Production

Now, let’s start the fun part. If we know that our code will go through these steps, how can we improve the quality adding actions or extra transitions?

Step two. How can we inject that quality?

This will drastically change depending on the previous experiences of your team, as well as what are they currently doing. Involve different people in this step, as they’ll offer valuable insight from their previous works of things that worked and didn’t. This is an example of what I’ve proposed in previous occasions. I usually include a short description of the different steps.

Copy of Quality Process

For instance, involving people with different expertise on a Design Document before starting to work on a feature has worked with great success for me. That document can take any shape, but having a little discussion on what is the problem that we’re trying to solve, where does it interact with other modules, what is the threshold needed to feel the implementation is good-enough helps A LOT to most engineers when working on it. Just having “what might go wrong” in the back of your head while you’re coding a solution can work wonders.

Another key element, apart from the description, is figuring out the owners of those actions. As I said, many don’t require any new technical expertise in your organization like Design Document, or Demo Testing where the developer runs through the solution with a peer or a product person to spot errors and understand how others verify that feature. Others really benefit from a specific skillset. That’s why, for instance, I took the ownership of working on the automation that will provide a smooth and reliable way to assess a solution. I’d work on building and improving the frameworks (Unit, Integration, End to end, Performance testing…), as well as working with the team so we can all embrace quality.

I also recommend that you don’t try to tackle all solutions at the same time. Set priorities, where can you get more bang for your buck, which skillsets do you already have, etc. All of these solutions will go through different cycles, and spending enough time and energy to set a nice foundation will help with the resistance that every organization faces when introducing change. Focus on feeling a constant momentum of change an improvement, instead of the speed of that change. Personally, the workplaces where I could focus on a steady pace, end up having a way more impactful change in the end.

Step three. Measuring the impact, reviewing and improving.

This is, in my experience, the hardest part. It’s really difficult to measure the impact of shifting to a quality-focused development process. Are you having more bugs because the engineers are working on a harder problem? Or did we get better at finding those bugs? As a quality engineer, part of my job is also finding ways to measure the impact of any change, so we can iterate through them and find a better approach. We all share a common goal: develop a product that will bring more value to our users, and doing it in an environment that we enjoy working at.

Spend some time profiling the process so you can get data on it. Sometimes, it’s as easy as holding periodical meetings where people discuss how it worked or didn’t work for them; or you can find entry points of measurements to take a data-driven decision. Be mindful of how hard this task is. If people feel that they would be reviewed by these metrics, they would be reluctant of iterating and embracing them. This is not about pointing fingers, but devising a way to improve the process for everyone.

As in most tasks I usually work on have more an internal impact than an external one, I like to measure my success on the perception of the codebase by our engineers. Of course, I hope that changes in frameworks and automation will impact the end user experience; but I like to focus on our team first. Examples on measurements that I use are: periodical surveys to the engineering team on how much they like working in our codebase, or how safe they feel when doing a refactor or change based on our automation; pairing with different developers so I can see how they work and their interactions with the frameworks; workshops on how to approach different bugs or problems; etc.

Another thing to be mindful of is that, at this stage in a startup, Quality is a buzzword used as an escape goat quite often. Most teams had to focus on quick and “dirty” deliveries on their first steps as an organization. When the conversation about Quality starts arising, it’s usually because that speed has started to produce difficult releases, and “the lack of a QA in your team” is frequently used as an excuse. Having people with different expertise always bring value, but it’s everyone’s responsibility in following the best possible practices to their knowledge, and voicing their complains about the current process. This situation can also create a toxic situation where, after hiring someone who that expertise, it’d be required from them to just fix everything.

Final notes

To wrap it up, I want to finish that this is not a magical tool that will increase your productivity and ensure the quality of your product by itself. This is a progressive change of mindset. It’s about changing how we work to spend more time on “how we can ensure and verify the solution”, and less on “how can we get done with this as soon as possible”. I personally believe (and I’m backed by plenty of evidence) that an increase of the efforts regarding quality will also bring speed on the long run, as it will require less of the VERY COSTLY redoing and fixing, that can also undermine the spirit of our engineer team.

If you’re starting to ask these questions in your organization: congratulations, you’re going through a change that your users will thank, and will produce less churn on your engineering team. But, I’m also really curious about your approach. What is the situation that brought you to start talking about Quality? What are the current solutions that your team is working with? Which are the points are you most struggling with?

The no-QA way

We’re still finding out sweet spot regarding Quality and there are always some developers that think no “formal tester” is needed in our process right now. This approach even gains more followers when you have an ex-Facebook in your team.

Don’t get me wrong, I never take the bait to jump yelling “You NEED me, this will be a MESS without me!”, mainly because I think this approach is as valid as any other if you focus on the right things, and meet some conditions. And I really enjoy discussing testing, especially when it allows me to understand my peers’ point of view.

So we started a conversation, but it didn’t lead to anything because we were just pointing the pointless parts of our current process, instead of really talking about how to make it work. Afterwards, I schedule some time on my calendar to sit in one of the meetings rooms and use the Whiteboard to clear my ideas. Would it be possible? What are we missing to get there? What would it offer us? How would it impact our team and process? Which are other solutions?

Then I felt way more ready to have that conversation again, but I decide it will improve with a broader audience, and sharing the questions in advance so everyone’s is better prepared. And, this time, I really enjoyed the chat. We still complained about what is currently failing, but we managed to come with tentative solutions. As well as some answers to the previous questions.

Let’s start with motivation. What would it offer us? The answer was almost unanimous: less friction in the process. As developers will be more autonomous and the QA layer is not going to be annoying, coders can focus on the code. It also carries some challenges, but we’ll talk about them later on. The goal is having a simpler and smoother process, and also, you don’t have to spend on QA itself. Win / win situation!

But, obviously, there are some requirements to get there. So, what are we missing to get there? First and more important, by far, is the culture of owning quality. If there won’t be a “quality gatekeeper”, everyone should be responsible for their deliverables quality as well as ensuring that everyone’s working on it. We’ve been moving towards that (as well as most of  the Agile testing approaches), but we’re not there yet and it’s really needed making this huge step.

This is especially tricky when you think about testing the “big picture”. It’s quite straight forward that when you deliver your solution, it should contain unit and functional automated tests verifying its behaviour. Hopefully, you have a culture regarding integration and component testing as well. But what about ensuring that the application works as a whole? Who will be responsible for that? Who will create, maintain and run those tests? What about the strange and complex cases that are almost impossible to automate? When and who should explore it?

One of the huge differences between the Facebook and our case is the amount of dogfooding that they do. We don’t have beta users, we don’t do canary releases, we don’t even use our tool that much internally. That’s one of the biggest challenges that we’d need to solve before taking this approach. It can be done, things like getting used to exploratory testing the application after when the development is done, but no developer is used to do it. One of the reasons why Quality Assistance keeps a testing expert available for the team is to help in this transition.

Then… how would it impact our team and process? Well, spreading out the responsibility about quality need some process changes, like defining some steps or techniques to review the solutions in pairs, not only reviewing the code and the tests. Get some understanding of the application that we’re building, and we need to play with it if we want to verify the changes. We’ll need more involvement with the product in order to find dependencies and better testable solutions from the beginning, although it will improve after the team gets better knowledge about it.

So, would it be possible? Well, one of the Agile principles I TRULY believe and share is “Fail fast, fail often”. As long as we timebox the try, set some retrospective meetings and are aware of the potential impacts; I think is stupid to answer the question instead of trying it out for a while, analysing and understanding the outcome afterwards. For sure, the first version won’t be the good one, but will teach us some tricks for the next one.

And which are the other solutions? I’m still keen on giving it a go, so it helps us identify what are we missing from the current approach and what we love from the change. But it’s always good keeping other solutions in mind. We can always go back to the old model of a QA wall where we throw everything, having someone to help us embracing quality and building tools to aim us (Quality Assistance), heavily invest in automation, or whatever pop your mind that might work.

There are thousands of different approaches to find Quality at Agile speed, and none of them works flawlessly. They neither work in every organisation. And I know a thing for sure: spending time and resources on finding a sweet spot for your process is always a good investment. Period.

Do you have experiences with a non-QA environment? I’d love to hear them!

May the force be with you,

Developer archetypes

During my career, I’ve encountered numerous and very diverse professionals, which is one of the best perks of teamworking: you have to try really hard to not learn something from the experience, because learning how NO to do things is even more important than learning the best way. Reacting differently is always a factor that will empower the team as it’ll allow a wider expertise. But, obviously, there are some behaviours which help to build teams, while others make it challenging.

As most of my working hours are between developers (right now I’m the only QA for 15 programmers), I want to focus today on describing the different developer archetypes regarding Quality I’ve found, as well as sharing some tricks I’ve learnt dealing with them. Let’s start!

The “testing is not needed” one, which have two branches: “I’ve never seen proper testing, so I don’t see value in it yet”, typically found on junior profiles or professionals coming from experiences where no one cared about good practices; and the “My code doesn’t need to be tested” which can be even found on really senior profiles. For me, the wisest tip is focusing on them as few as possible.

When they start seeing the results from the others and realising that they’re getting behind, that they’re less shining, is the time to offer yourself to help them as much as needed. Your job is to make their work look awesome, don’t forget the commitments!

The “I don’t have time for testing” one, typical from junior profiles as well. They know that writing automated tests is valuable because… Well, probably because they’ve read that somewhere, and they know people expect it from them. Most of the cases they think there’s no time because they don’t know how you make them, so it’s a daunting task. The best that you can do is showing how easy is to get value from the tests. Handle them a framework with an example, pair during their first implementation and support them at the beginning.

If you see they become needy (what happens way less than I thought), gradually stop giving them that much support, coming from time to time to ensure they don’t get stuck. I’ve found that sometimes spending time explaining how this new skill is needed is they want to step up their career at some point towards “one of the big names” is really helpful.

The “I’m too biased to test” one, especially when you start talking about approaches like Quality Assistance and making them autonomous sharing the testing responsibility. They’ve heard that a developer can’t test, he’s biased, and that’s the perfect excuse to not even try it. The most successful way I’ve found to deal with this is focusing on the keener to test team members, sit with them and teach some tricks and examples. They love solving puzzles, and breaking systems!

When those colleagues are motivated enough, convince them to pair with the “biased” developers so they can test the new features together. Seeing a peer testing their code will show them that it’s possible to do it, and realising that when they review the dev on test feature finding way fewer bugs… Well, data is more convincing than words. And shame, more convincing than anything.

The “So, how can I test…?” one. This is the dream. These developers know what testing achieve, they understand that delivering a solution doesn’t mean anything unless it’s a quality one, they see value in the automated tests and prefer being the ones finding their shit. After seeing them work, and enjoying the results of their effort (fewer errors on their developments); they get your trust and you can focus the efforts on the rest of the Archetypes.

That doesn’t mean all the work is done. We assume most companies aim to have these developers, and sometimes you’ll be blessed with loads of them in your project. Now you can start working on what they’ve hired you to do. You discuss with them to build more testable products, review their work, build additional tools, assist them on the hard-to-test features, and experiment with new approaches. This is the dream. And that’s why I’m spending all my effort right now to convince as many developers as possible.

I don’t want to finish without naming one of my favourite archetypes: the “then, what are we paying you for?”. At the beginning, I wanted to answer them in a similar way but… wasting energy won’t take you anywhere. That’s why I keep it simple now. “My job is to review you until you become autonomous. Then, they can make me redundant or I can start focusing on the interesting stuff: doing whatever it takes to increase the Quality of your deliverables”.

Have you encountered different developer types?

May the force be with you,


Quality Assistance: Lessons learned

This morning, during my 10 idea routine, I push myself to list techniques and activities that I’ve tried to change the Quality mindset around the company. You already know that we’ve been doing modelling some of the process following the Quality Assistance approach. I know that the outcome of these activities will drastically vary for each team, but hopefully knowing some experiences will help you try something similar. And, as Scott Berkun explained amazingly here, it’s more important to learn from the failures than to just share the final idea. And certainly writing this will help me remember some details. I don’t trust my memory that much…

I’ll try to give you as much background as possible, although reading about how the organisation is working now and how I’m facing it know may help. Now.. Let’s focus on some things I’ve tried!

Three amigos. This is a pretty standard activity, although we needed some twist mainly because of resource issues (just me as QA and one product owner). We started picking some complex tasks per sprint and trying a standard Three Amigos, although at some point we decided that the engineers should do the exercise of listing the scenarios before implementing a solution, leveraging our work to double check and enhance with some “edgy but important” ones.

QA demo. We do it after finishing the development of some sprint stories where me (or Product) showed in 10 minutes at their machine how users are most likely to run through it, as well as trying to break it. There’s no better way to understand how to test than looking someone testing (and trying you communicate the mental process). There are some developers that, after this, embraced some testing activities as they saw me enjoying it, although others are reluctant.

Defining metrics to understand the current status. Things like amount of errors in each version, times, grouping types of errors, clearing non-useful data or even finding ways to generate it (like replicating production load on testing environments). We’re all engineers here, and no matter how much you try: data wins discussions. That’s a fact. I don’t have any data to back it, but you have to believe me.

Testing hour. I can’t think that I have too much time to run many experiments, but one of the activities I love doing is setting voluntary exploratory testing sessions. I’ve done it mainly for big new releases, and I try to guide them to focus on a different aspect each time, although it gets wild most of the times. Unfortunately, we don’t do enough dogfooding, so this activity helps a lot spreading the knowledge about the tool and getting feedback. In my experience, teams that are usually siloed and less involved with the products are the ones enjoying it more, and giving you fresh feedback (R&D, Ops, etc.).

Getting involve with the community. We’re quite small, and I love allocating some time helping out the customer support guys giving not technical answers in the “I think I found a bug” section of our forum. It gives me loads of insight about what they care about, and some valuable examples to back my feedback. And they actually find some really weird bugs!

Proactively spying production. Gathering metrics, we’ve come around with some filters to get weird errors and behaviours, and we can use our tool to understand how the a user can get there. We’ve found edgy bugs because of it. We also use Inspectlet to understand how the users react to new features, helping us understanding further user cases and finding strange behaviours!

Participate in technical design meetings. I’m used to joining product meetings to help define some new features or make the product more resilient, but being involved in the technical discussion gives me more insight into the implementation and the challenges, and allow me to raise issues to ensure a more testable product (backdoors to easily reach some states, ways to inject failures, etc.)

Big picture testing. That every developer should care about testing it own slice is a fact, particularly in an organisation where there is only a QA. But testing integrations and “end to end” is usually something tedious that no one wants to deal with, but having a smoke verification before and after every release brings A LOT of value. That’s why I’ve taken the responsibility of building a “simple scenarios” big picture testing suite for both backend and frontend, serving me as valuable documentation as well. It’s the green light everyone needs before rolling a change.

Reviewing code (particularly tests). I wish I had more time to review more bits of code, but I usually just check some of the new stuff who I haven’t understand yet; and the code for the functional tests, especially the first batch of tests for a new feature. My main concern are readability, scalability and detecting flakiness. Avoiding integrations when possible (using static versions of webs vs live version), some random waits, retries policy that would masquerade problems, modularize for reusability…

Pair whenever possible. Ok, after all of this, I know I don’t have much time left. But, when I have, my first list is pairing as much as possible. It teaches me new technologies and ways to develop, I get some understanding about the solution, I can give early feedback and it bonds me with my colleagues. I’ll make a post about the benefits (and cons) I see in pairing soon!

And this, guys, are some activities I’m trying to infect the team with the love about Quality. Some of them may end as worthless, and many will be evolved and change, but right now I’m learning something new every time I do them. That sounds like enough reason to keep them for me!

May the force be with you,


Modernise your testing roles

Fortunately, the Testing industry is not only formed by Automation, Manual QA and QA Leads. Models are shifting (particularly due to Agile methodologies) and new approaches require new (and more interesting, in my opinion) roles. Here I’ll talk about some of these roles, either real examples and some theoretical ones.

  • Test jumper. Described my James Bach, is one solution for Testing in Agile methodologies. Its duties are supporting and supervising multiple Agile teams, ensuring that nothing blocks proper testing at speed. It’s all about aiding developers and testers to have whatever tool before they need it, helping to create testable products and raising testing concerns as soon as possible.
  • Software Engineer, Tools & Infrastructure. Google’s evolution of the Software Engineer in Test, this role focuses on tooling the Software Engineers to make their life easier. It’s a technical position and some of the tasks are described in this Reddit post, but it has been one of the trends in the recent time to replace testers with software engineers who focus on making testing easier.
  • Quality Assitance. As I described in this post, it’s the approach Atlassian took to deliver quality at Agile speed. The efforts are focused on empowering the developer and training him in testing tasks, so the majority of the tasks can be done really early on the development process. Other companies, like Spotify, are creating similar roles.
  • Automation toolsmith. Similar to Google’s approach and theorized by the Rapid Software Testing team, this role focuses on developing tools to unlock testers potential. They should work closely with the testers understanding what are going to be their needs in the future, and with the developers creating more testable products and learning the system to build those tools.

I am sure that they’re more cool Testing roles out there, and I’ll try to find them. I love seeing how is moving shifting our community, and learning how companies are trying to adapt testing to today’s needs.

Some honorable mentions are:


May the force be with you,


Retrospective: Hacking my time scheduling skills

One of the pieces of feedback I’ve reiteratively got from my managers is my difficulty to say no, as well as how easy is for me to focus on new challenges sometimes setting aside key pieces of our roadmap. I want to believe that I’ve made some progress on the subject, although there’s always room for improvement. I’m here to talk about one of the techniques which have been really successful in my case.

I’ve been trying several techniques during the past years. I’m in love with Pomodoro timers, but I find really hard implementing them in a team that’s not used to it. Also, I think they shine in heavily intellectual activities (such as programming or designing), but most of my daily activities involve meeting, pairing and discussing. I’ve kept the concept of taking some chilling out minutes after long periods of focused work. For example, I still use something similar when I’m coding or performing exploratory testing sessions (see how Rapid Software Testing applies chartering in Exploratory Testing).

The moment when everything changed was when my QA lead, among other colleagues, got redundant and I lost her help prioritizing and tracking or roadmap. So I needed to take even more seriously my time scheduling skills. I started applying the quadrant technique to my daily tasks, identifying their categories and their time c consumption. As I’ve explained before we were following the Quality Assistance approach, so the four categories I identified were:

  • Automation: All time spent writing testing frameworks, tools, and scripts. Also, all the effort maintaining our current builds, upgrading, etc.
  • Exploratory: Time to run through the new features, understanding our product and assessing the Quality. It also involves reporting and verifying.
  • Teaching: Working with my colleagues ensuring that everyone’s on the same page regarding quality. Meetings, redesigning something to make it more testable, reviewing their automated tests, pairing, etc.
  • Learning: As most of my daily practices are new to me, and we’re always looking for improvements, I spend a fair amount of time documenting myself, learning new methodologies and building prototypes.

As you may assume, it wouldn’t make any sense to have an even distribution of my time, but it helped me understanding where I spent most of my time, and aligning it to our goals. Different periods need different approaches and having the data help me realising if I need to change.

As I’ve already said, one of my top priorities right now is spending more time doing the tasks I enjoy the most (or the ones where I learn the most). These categories make it simple, allowing you to invest more time in other quadrants if you get stuck on activities that you hate.

Also, I have to admit that reading this post about a similar technique has helped me retune it to get more value or of it. This is an iterative tool which is helping me a lot understanding the time spent during my working hours. I highly recommend you to step up your time managing techniques, it makes my days way more productive, it helps with our goals and my days are funnier. Knowing what you love about your work allows you to invest more time on it.

May the force be with you,

Quality Assistance: Why we tried it

As I mentioned before, Quality Assistance is a testing methodology that focuses on empowering and support the developer on Testing tasks so the team can deliver at speed. In this post, I’m going to talk about the reasons why we tried this approach with our team, as well as some challenges we faced.

I joined the startup right after our QA lead did. It was in interesting timing, all the decisions regarding Quality were still pending. I was lucky that she counted on me for the change, and one of the approaches we wanted to try was Quality Assistance.

Why? Well, I think that the main three reasons were: resource limitation, we were only two to deal with every time, so traditional methodologies based on manual sign off or us automating every check was out of the table; we sincerely believe this is the step forward the industry needs, especially in Agile environments where speed is a key factor; and personally, I’m always willing to try something that would allow me to spend more time doing the activities I love of my role.

It wasn’t the only option we considered, but the one we wanted to try the most. As any other similar change we had a list of challenges to face in order to success in it, and some of them needed to be addressed before working on it.

As always, the first step was convincing the stakeholders. Luckily for me, most of this work were done by my manager, and they were really keen to try the change because they knew the previous approach wasn’t working and agree that Quality ownership should be shared in the team. But, if we want to really convince stakeholders we needed to start gathering metrics to show the results and start using facts as arguments instead of opinions or beliefs. It makes most conversations easier. We struggled on this and I believe if we had focused more on metrics, embracing Quality Assistance would have been smoother. Although I don’t have facts on that…

Convincing the developers at that stage was easy, but when we started to work together on what were the expectations and how we needed to change our way to work… Well, I can ensure you that it’ll take me a whole post talking about some clashes we had during the process. The lack of documentation made it more difficult. So far, it seems that only Atlassian is trying it, so we didn’t have many documentation or examples to show them, and most of the information was focused on QA practitioners out stakeholders. It is also an approach that requires high doses of customization as it depends on each team. We had to focus on a team by team solution, difficulting us to use one solution to convince other teams.

Personally, I also had the challenge of improving my exploratory testing techniques. Previously in my career, I just focused on automated checkings, tooling and performance testing. And this is a crucial part of quality assistance. It was an enlightening experience, learning a lot in such a small period of time, and helping me with the next challenge: thinking how to teach testing. To empower developers with the ability of testing you need to learn how to express all the tacit knowledge you’ve been building for years. It completely changes the perspective because every time I performed a testing task I was actively thinking what is happening inside my head and trying to translate it into words. Challenging for sure, but fun nevertheless.

These were the main walls we had to face before trying Quality Assistance on your organisation. On following posts, I’ll try to focus on different steps that we tried and what was their impact.

May the force be with you,

P.S. Feel free to use Quality Assistance category to visit the related posts!

Meet Quality Assistance

Quality Assistance is a shift in the Testing industry that focuses on empowering the developer with testing knowledge and guidance so the development process can enough Agile speed. The principal promoter of the change is Atlassian, although some other companies are starting to embrace a similar approach (like Spotify)

In this video, Penny Wyatt (Atlassian) beautifully explains why they decided to try Quality Assistance:

Personally, I’m in love with this way to introduce Quality in software projects. I learnt about this approach from my QA Lead and we tried some of the ideas in our startup, learning in the journey some of the challenges needed to embrace it. We learnt how to deal with different developer archetypes convincing them that our goal was empowering them, not procrastinate because we were sharing Quality’s responsibility.

Particularly, I love that I spent most of my time on activities I love doing with this approach, such as revisiting processes, breaking them down along with the product itself looking for dependencies and bottlenecks to focus on; pairing with the developers learning the technical details of the product while I show them the joy of the puzzle of Testing; spending sometimes automating tools, enhancing frameworks and improving automated tests… it was such a win-win situation for me when we embraced this approach!

Obviously, we also encountered walls and difficulties and realise that there is not a simple way to adapt this methodology without customization, iteration and a fair amount of time. Most of the challenges are related to the need to change how most of the people work, being particularly difficult if you find some reluctant to change developers.

It’s impossible to tackle down the details of this encouraging shift in one post. I’ve included some really interesting documentation that I recommend you to visit, as well as the promise to detail in further entries some of the aspects of the approach, and some experiences dealing with it.

For me, Quality Assistance convinced me that Testing is where I want to be. I spent a big percentage of my career thinking that Development is what I should be doing, but I enjoy way more the tester role from Quality Assistance than programmer’s one.

May the force be with you,