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”
