How I Test

What do I do?

Help the development team deliver the right software, faster – the software that the Stakeholders & Customers want

Help to specify acceptance criteria with Stakeholders to identify when the development of software is done

Provide feedback to stakeholders on the current state of the software under development

Identify potential risks with the software, either in the software itself or in related documentation, whilst the software is still being developed.

Provide input into design implementation

Provide input into functionality implementation

Develop automated regression checks with Programmers – these are at all levels of the technology stack

How do I do it?

Get involved with the development of the software as early as possible

Have close liaisons with both Programmers & Stakeholders in order to catch any changes to requirements to ensure we are developing the right software

Keep the feedback loop as short as possible

Deliver relevant information in a timely manner so that the Stakeholders can make informed decisions – Its not up to me which defects prevent software from being released!

What ideas in the testing community do I agree with?

Agile development makes far more sense to me than Waterfall development

This said “Agile” should be an adverb, not a noun – I want to be agile, as in flexible & open to change.

A Tester shouldn’t be tied to test cases, nor should they be fully ad-hoc

Exploratory does not mean ad-hoc – testing still requires structure & documentation

Testers should be able to develop (a bit) – to support automated regression checks

Developers should be able to test – automated checks in Test Driven Development (TDD)

Developers are really Programmers

Testers + Programmers = Developers on a software development team – we just fulfil different development roles

Tester & Programmers work concurrently on the sw – frequent feedback loops on testable tasks between Testers & Programmers help to find defects on the Programmers local machine immediately, as opposed to n hours later when the committed code finally gets into Test environment

Even though Testers & Programmers work together, Testers still have their independence and awareness of the state of the sw for stakeholders

Testers are outward facing, e.g. test the software from a User perspective
Developers are inward facing, e.g. test & develop the functionality of the software with regards to the requirements

We (the Development Team) are all responsible for the quality of the software & delivering the right software – software that the Stakeholders & Customers actually want.

What ideas in the testing community do I disagree with?

Testers are not QA – I don’t make the rules & processes, I only provide the information to let others make them. Testers are part of the QA process, not the QA process in its entirety

Testers lose their independence if they are too close to the code – In some cases I can understand this concern, but for most testers, the more code aware they are, the more informed they are. Feedback (inc. defects) is more meaningful & thus multiple loops can be avoided. Testing which requires distance from the code, such as usability testing, often isn’t as involved as the functionality testing and as such could be performed by someone outside of the test team, such as a BA, or the Business/Customer themselves

All tests can be automated, and there is no need for manual testing – this is more of a battle I’m having with Programmers at the moment – A Programmer feels that their code is covered by tests which incorporate the full stack – why do Testers need to see it in a browser? Its only when we find a critical integration defect in the Test environment after the code has been through the pipeline that Programmers realise why we still need manual tests.


I’m not sure this encompasses everything I believe in, but its a lot more than I’ve ever put down on paper before.

So, if I try to summarise my testing ideology, it might go a little something like this :

“I work with Stakeholders & Programmers to develop & deliver the right software & provide feedback to stakeholders as to the current state of the software.
I achieve this through several testing methodologies, including manual testing & automated regression checks, to ensure value is continually added to the software.
I am not only aware of the required functionality, but also the impact of the functionality for the intended Users of the software”

My current views & opinions on my self learning & software testing in general can be found on my blog