Archive by Author

The purpose of the Software Tester is to develop test cases and apply testing methods and tools to thoroughly test the Direct Axis products. The Software Tester contributes to a collaborative culture in the Product Development area working with the Software Development teams to ensure development targets and measures are achieved.

– Relevant Tertiary Education and Testing Certification is beneficial
– IT Qualification, relevant tertiary degree or Diploma

– At least 5 years experience in a Software Testing
– Experience with MS Office Products (Word, Excel, Outlook)
– Strong Experience on SQL and XML and the ability to write statements in these languages
– Experience in Automated Testing tools e.g. QTP, Selenium etc. (2 years experience)
– Understanding and experience in Agile software development frameworks (at least 1 year’s experience)

– Ability to structure personal work efforts to ensure maximum productivity is achieved under guidance of the team lead
– Demonstrated analytical and problem solving skills
– Understanding of software testing approaches, methodologies and frameworks
– Excellent written and oral communication and presentation skills. Must be able to communicate effectively with key resources in the project.
– Must work well under pressure and changing priorities
– Flexibility to work in a changing, fast-paced environment
– Good communication skills, written and spoken
– Great team player
– Willingness to work outside primary capacity

Duties and roles:
– Responsible for quality aspects of software development including risk analysis, test development and test execution (formal and informal).
– Appropriately apply the latest techniques in test automation; e.g., data-driven testing, keyword driven
– Develop and implement test case methodologies and processes
– Find issues in the product and work with the development team to resolve them as soon as possible
– Work with the development team to resolve any issues that arise out of the testing process
– Participate in the release process to ensure that solutions meet business requirements.
– Document test results and report on software defects
– Contribute to the implementation of software quality assurance best practices
– To identify and define opportunities for improvement, measurements for those improvements and the implementation and roll out process to ensure that overall quality standards are met or exceeded
– To provide assistance with Release Management in planning and co-ordinating testing activities, with the rest of the test team, to ensure successful deployment of all releases to the QA environment.
– Seek to continuously improve software quality, testing tools and testing processes

We are committed to the principles of Employment Equity.

Should you meet the above requirements, please visit our website on to apply.
blackjack online free game

Nigel Basel shared the lessons he has learned doing Test Driven Development (TDD) for the last 8 years.

The stats show that TDD is still a minority sport with the average results polling in at 35% or so. Nigel mentioned that for a solid, quality base you needed TDD, refactoring and Continuous Integration (CI) to co-exist and none of these independently will result in a high quality codebase. For Nigel the best results come about from the creation and running of acceptance tests and unit tests in a tight cycle.

The usual way of developing by writing the code first and then hitting debugger is error prone and TDD offers an escape from this tedious cycle by encouraging developers to instead make it fail, make it work and then make it better through the cycle of getting failing tests to pass and then refactoring the code.

A good test should capture the business functionality not whether a certain algorithm works.

TDD is an aid to helping you get there, its not a replacement for classic design skills such as SOLID or DRY. It’s also no substitute for thinking!

With TDD the design of the system is captured in runnable form.

Some people do not use TDD because they think it will take too much time. Empirical evidence suggests TDD actually takes a similar amount of time. Writing tests first focus you on the task at hand. It also helps you recover from distractions much quicker as a failing test will be an instant reminder of what you have left to do. Much more time is spent fixing defects found post development. In Nigel’s own experience of product development TDD has saved him a huge amount of time.

Defect density is lower using TDD but TDD is really more about design than testing. You end up with low coupled and highly cohesive software.

When estimating effort for functionality ensure you cover the effort of writing your tests together with the code.

Nigel mentions Mike Feather’s assertion that code without tests is legacy code. The best approach, Nigel suggests is to use Mike Feather’s concept of Test Coverings when tackling legacy code that does not have unit tests. The goal is to detect changes to the current system in order to make it safe to refactor and extend. Most Test Coverings would be integration tests rather than unit tests.

Tests need continual buy-in from the development team or the tests ‘grow mould’ as the system changes but the tests lag behind.

For User Interface (UI) tests timing is a big factor. While coded UI tests are possible they are often brittle.

There are upfront costs to TDD but the benefits far outweigh the costs. Nigel suggests those new to TDD start small as TDD is about one test at a time. A great way of introducing TDD is to try it on a greenfield project or even a tool that you are building that will interact with the system. Find the testing framework that is right for you. A refactoring tool will also make life a lot easier as it takes a lot of the pain out of the refactoring process. The right toolset will really speed things up. And if you really want to speed things up Nigel recommends coming along to the next code retreat!

Often developers will shy away from TDD because the extra work will only reap benefits in the future. But Nigel thinks the benefits are worth it. And the benefits aren’t all technical, it will also improve the developers quality of life with days being full of instant gratification. The steps of writing a test, seeing it fail and then making it work instill confidence in the developer for the quality of code, however Nigel points out they need to be the right tests! Another thing to bear in mind that there is nothing too small to test, TDDing your code will always be worth it.

Refactoring isn’t just for the code itself, its also for the tests. Tests are also a great form of documentation especially when it comes to providing documentation for APIs.TDD has simple rules but applying them in the real world is not easy. Focus on the test first, not the code. For Nigel a good unit test is readable, quick to run, cohesive, documents usage and its results are deterministic.

I’m not sure if TDD is like teenage sex but everyone should be doing it, TDD that is.
internett spill

October Event: Growing Agile Coaches

Sponsored by:

Where: Allan Gray Portswood office in the Presentation Room on the third floor. You can download a map here. Everyone parking in the Portswood parking area will have to pay for their own parking tickets. There is also parking available in Beach road.

When: 7 Oct, 6PM

Topic: Growing Agile Coaches – a facilitated discussion

Building on an open space session at the South Africa Scrum Gathering, Peter Hundermark and Karen Greaves, will facilitate a further discussion on how we can effectively grow agile coaches and ScrumMasters in our community.

If you are a ScrumMaster who has realised that implementing Scrum is hard, an internal or external agile coach who would like to improve your facilitation, or an agile manager responsible for helping ScrumMasters grow their skills, this forum is for you.

Peter and Karen will each provide their own views on what coaching is about, and some of the techniques they have used to grow their own skills. They will then facilitate a group discussion to discuss different ways to grow agile coaches.

During the course of the evening you will all assist with making some decisions about how we take this forward in practice, and take the first steps towards establishing a way you can personally benefit.

To help us with catering for this event please sign up here.

Open Space Notes

The SG10ZA Open Space Notes (small) are accessible from this link.

Thank you to all participants and conveners for making the Open Space such a success

SG10ZA Gallery

A heartfelt thank you to all delegates at the recent South Africa Scrum Gathering 2010. Your participation and contribution are what made this such a successful event. Below are some pictures of the event
[flickr-gallery mode=”search” tags=”sgza”]

SUGSA aeroplane factory photos

Some pictures from the July SUGSA Event; a lesson in the benefits of limiting work-in-progress

Posted via email from sugsa’s posterous

Technical Debt

When: 3 June 2010, 6PM

Venue: Allan Gray Portswood office in the Presentation Room on the third floor. You can download a map here. Everyone parking in the Portswood parking area will have to pay for their own parking tickets. There is also parking available in Beach road.

Cost: Free

Sign up for this exciting event here.

Topic: Turning Technical Debt into a Reasonable Cost for Software

Most people like the predictable nature of time-boxed delivery of software. However, a situation that I see far too often is that the box starts feeling tighter as the software grows bigger. Sure, you can get a bigger box, but that feels like going up a trouser size. Often the decision is to “chunk up” the software and roll out more teams. Great, but the volume has not changed; it’s just spread out. It’s now costing more than before. It’s actually worse. Each chunk is simultaneously growing inside it’s own box. Better get a few more trousers that are one size up.

Yes, some people call it technical debt. I just call it broken software, and broken things left alone cause more problems. The simple truth is that overweight software costs money. In this session, we explore what it means to establish a reasonable cost of software, and what it takes to keep it at a reasonable level. Note that the names of classes, variables and namespaces have been altered to avoid association with those that are lying in various version control repositories many, many commits ago.

About the Speaker

Aslam Khan has spent more than half his life creating software. He still believes the truth is in the code that gets executed, but that belief is soberly balanced by his other core perspective that people write code for others. As a software master at factor10, Aslam spends his time helping teams build software better, while having fun doing it, and making worthwhile friendships. He is also an editor for the architecture community at You can read his blog at

Aslam Khan

Slides for “Software Testing – How has agile changed the game?”

Slides from the “Software Testing – How has agile changed the game? with Karen Greaves” are available for download here.

Agile Testing

When: 6 May 2010, 6PM

Venue: Allan Gray Portswood office in the Presentation Room on the third floor. You can download a map here. Everyone parking in the Portswood parking area will have to pay for their own parking tickets. There is also parking available in Beach road.

Cost: Free

Sign up for this exciting event here.

Topic: Software Testing – How has agile changed the game?

Karen goes back to the core of why we test and what we know about testing from research data. She will explorer the implications of agile software development on testing: what has to change in our approach to testing in an agile environment; and what can we still use from traditional testing techniques. She will cover some automation tips, defect tracking, test reporting and finally some technical things testers really need to understand.

About the Speaker

Karen started out her career as a Software Tester for Microsoft on Windows 2000. She learned a great deal about testing in this complex environment with about 3000 people working on a single product. She was fortunate enough to be trained in testing fundamentals by Cem Kaner. It’s 10 years later and Karen been working with agile teams for 5 years, she is still passionate about testing and as a Scrum Coach is interested in how the discipline of testing has been affected by agile.


This event’s catering is kindly sponsored by Hetzner