This post may come across as rambling, but its more of an avenue for me to dump the contents of my brain as I try & work things out.
As you may be aware, i’m on a journey to become a better Tester. I haven’t blogged recently as I’ve been busy at home & at work and this has really impacted my ability to study properly.
This said, I am gradually working through “Head First Java” in my lunch hours & studying for the ISTQB Advanced cert at home – i’m just not progressing as quickly as I’d hoped down that route (nb – my views on accreditation & certification are changing as my journey of enlightenment continues, but I’ll discuss this another post)
I have been following key figures in both the testing & development community on Twitter & they have been providing links to some really useful & insightful articles, blogs & podcasts. I have been absorbing these in the spare few minutes I get and I have found out something about me – After 11 years in software testing, I don’t really have a testing ideology!
This really came to the surface when I retweeted a comment from Michael Bolton & several of my followers started having a discussion around it. I found it really hard to formulate an adequate response as to why I had retweeted that particular comment. I did eventually come up with a response, but I felt it was a cop out, & it certainly killed the conversation.
So now I feel its time for me to assimilate what I know about testing, what I feel my role within a Test team involves & ultimately come up with a snappy paragraph that summarizes my testing ideology (to add to my CV)
This idea came from reading an article on what a good tester CV looks like on Eric Jacobsons “Test this blog“, one of the comments from which mentioned a new thread had been started on www.softwaretestingclub.com
I’m not sure where to start, so i’m going to give myself some headings & go from there…
What do I do?
How do I do it?
What ideas in the testing community do I agree with
What ideas in the testing community do I disagree with
What do I do?
- Provide feedback to stakeholders on the current state of the sw under test
- Identify potential risks with the software, either in the sw itself, or in related documentation
- Provide input into design implementation
- Provide input into functionality implementation
- Develop automated regression checks with Programmers – these are at all levels of the stack
- Get involved with the development of the sw as early as possible
- 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 sw from being released!
What ideas in the testing community do I agree with?
- Agile development makes far more sense to me than Waterfall development
- 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 – in terms of automated checks in Test Driven Development (TDD)
- Developers are really Programmers
- Testers + Programmers = Developers on a sw 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 sw from a User perspective
- Developers are inward facing, e.g. test & develop the functionality of the sw with regards to the requirements
- 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 Programmers to develop & deliver software according to stakeholders requirements & 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”
Thanks to @Griff0Jones @michaelbolton @grahamgzl @marick for making me sit down & do this – it was definitely called for!