Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

Laying the Foundation for Africa's Software Testing Community

We both work as quality analysts at Thoughtworks Brazil (Porto Alegre office). It's been a year since we came to work at Thoughtworks Uganda (Kampala) and South Africa (Johannesburg)

Based on the professionals that we came into contact with since we arrived, the typical QA profile in Africa shows strong manual testing skills but limited technical experience. There is extensive knowledge of the traditional test frameworks, high value on documentation and a focus on the traditional methodology (distributed teams).  It's not common for testers to work closely with the development team. Also, there are few local communities for software testers, in which they could learn and strengthen new skills.

These were our main motivation to try and build a local QA community. In addition, it could attract more professionals and increase interest in software development practices.

The first action included a workshop for QAs in Kampala and the creation of the QA group in Johannesburg: QA in Braam.

Workshop "Understanding TDD and BDD" (Uganda)

We began by engaging students from Makerere University to familiarize them with skills required in the software development industry, as Thoughtworks Uganda was already doing for some time.


Our audience was made up of these students as well as some professionals from local organisations. There were also a good number of Thoughtworkers who volunteered as coaches and lent their laptops for the session.

The interesting part of the workshop was to show the life of a software developer and a software tester in a hands-on way.That was through a simple exercise about TDD (Test Driven Development) and BDD (Behaviour Driven Development) and how both practices work together within an Agile team.

We had two presentations as part of these exercises: the first one about TDD and the importance of using the test pyramid strategy; the second one about BDD fundamentals and patterns to write effective acceptance criteria. The goal of the exercise consisted on writing unit tests for the functionalities of a calculator using Java + JUnit, and on automating a search in an online store by implementing a basic BDD scenario in Cucumber + Gherkin.

QA in Braam (Johannesburg)

Following the success of Coded in Braam, we decided to create a similar event, but focused on software testing. At least once a month (on Saturdays), we have meetups with the local QA community, which is basically made up of professionals from local organisations.

QA Braam

The sessions are mainly about concepts and techniques regarding software testing. For example, we have discussed the new role of QAs in agile teams, different types of testing, basic concepts of Selenium IDE, pros and cons of having documentation and exploratory testing (which is a strong skill on QAs here). We have also started great discussions regarding test pyramid and presented an overview of BDD with some practical examples.

For those who want to be part of the community, you can join the meetup here.

Considering the feedback we have received so far in both events, the intention from now on is to have more technical sessions, even to put in practice some of the concepts we've discussed.

QA Braam

After our experience running these events, we believe that it's very important to build, nurture and grow the local QA community on the continent. That's a simple and effective way to ensure that all people involved have incentive to learn and become better professionals.

And based on the experiences we shared above, here's a list of actions items we consider crucial for a QA to become more technical and a good fit specially to work in agile teams:

  • Expose the QAs to many different contexts (green field projects, legacy code, experiences as consultants)

  • Coaches are always important, not only inside a project, but at an organisation level

  • As a community, we need to organise more specific sessions about good and relevant technologies

  • Expose the QAs to refactoring sessions inside the team, so that they can understand the advantages of having a clean and structured code

  • QAs should have incentive for learning and dedication beyond the working hours - some time at home to read an article is always interesting.

Special thanks We could have done a list of names to thank everyone who helped us with these initiatives. However, it would be a huge one and certainly we would forget some names. Either way, thank you very much!

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights