The initial statement of Anko Tijman (@agiletesternl) in his talks was, that agile testing is about migitating the risk, therefor a test strategy should focus on risks in
- code
- interfaces
- requirements
- architecture
- business acceptance
The initial statement of Anko Tijman (@agiletesternl) in his talks was, that agile testing is about migitating the risk, therefor a test strategy should focus on risks in
The idea of writing a blog post like this was in my mind for quite a while already, but as too often, I was just procrastinating. Today I have been busy retesting (and closing) a lot of items from our defect tracking system (DTS) and started writing down the following items, as I stumbled upon them (and as they came to my mind as I remembered them from previous projects).
Of course I´m exaggerating a bit on some of the listed items, but all of them are real examples of what I´ve experienced in the past. 😉
So here it is, my (not-yet-complete) list of things to do, to make your bug report most useless for your team mates (none ordered):
Short notice: I will participate at the German Agile Testing and Exploratory (GATE) Workshop 2011 on October 1st & 2nd in Hamburg, Germany. My topics will be „Shared responsibility for quality vs. separate QA teams“.
Other guys participating so far: Markus Gärtner, Maik Nogens, Meike Mertsch, Eusebiu Blindu & Sven Finsterwalder.
More info available on the GATE homepage: www.gate-workshop.de.
I´m looking forward to have a productive weekend full of learning and insights with these guys!
Lately my colleague Maxence Bonhomme and I set up FitNesse to be used within several .NET projects which are all build on one Microsoft Team Foundation Server. Since it was quite some work to do we documented all the steps, and as it was an official work project, we published the documentation on the Agile Partner blog: Setting up FitNesse for Team Foundation Server.
For the records: I lately had the case that I wanted to read a symbol´s value within a FitNesse sub wiki page which I included within another site for the first time. In this special case the symbol doesn´t get interpreted as symbol by the FitNesse engine, but as a normal camel case´d string, so it gets represented as a link to another wiki page: E.g. when having an string like „LukeImYourFather“ and assuming that there´s no wikipage with that name, the rendered output of this will be LukeImYourFather? where the question mark links to a new empty wikipage.
To avoid this behaviour simply escape the symbol´s name (but not the ‚<<‚-prefix) the standard-FitNesse-way: !- -!
<<!-MyFitNesseSymbol-!
A quite new series of postings on the Software Testing Club´s Blog is asking for the communities answers on frequently asked questions among the testing world:
Our community holds the wisdom to frequently asked questions we constantly being asked again and again.
Help out some testers in need!
Answer one as many as you dare, you choose!
Selected responses will be published in the next issue of The Testing Planet.
Find my answers below:
On May 23rd, there was an event organised by the Luxembourg Testing Board, the topic was „Testing Tools“. One of the speakers was Stephane Louis who spoke about „Test Tools“ in general: He presented examples of different kind of test tools, and explained for what kind of tests to use that tool.
The other speaker was me, my topics was „Agile Test Tools“, here´s the abstract of the talk:
Still some kind of buzzword these days, „agile“ (and other related terms like „Scrum“ & „Lean“) are becoming more and more common used methodologies, you could say, that „agile has arrived in the mainstream“. But what is so different about agile software development? This presentation will try to give an answer at least for the subcategory of „Agile Testing Tools“.
The presentation will make visible the difference between testing in classical software development processes and in the agile (scrum) process. Main focus will be on how „the agile tester“ is beeing supported in his work by „Agile Test Tools“. According to different „mantras“ of agile software development like test-driven-development, acceptance-test-driven-development, behaviour-driven-development and others, several tools that support working according to these mantra will be presented and it will be explained how this tools work.
Concluding, the final essence of „Agile Test Tools“ will be presented and it will be discussed, how the agile tester is supported by this.
After that, it will be some room for questions & discussions with the audience.
The slides are available on Slideshare:
INVEST is an abbreviation, describing the attributes, a user story should have: Independent, Negotiable, Valuable, Estimable, Small, Testable.
For quite a while I´m thinking about a solution for following situation:
I have a lot of (old) scripts/ classes, which I created without unit tets (yes, shame on me, but by the time I´ve written them, I didn´t knew better, or didn´t had the time to do so, … the usual excuses).
Now I would like to add unit tests afterwards, to benefit from all the advantages they give to a programmer (find regression, give a safety net, etc.).
But I´m just too lazy to go all of my code and add unit test after unit test after unit test. Instead I would like to auto-generate them. At least the skeleton, like test classes & methods; so e.g. create a test method for every method used, create a test for every object that should be (not) accesible from the outside, etc.
I know that I will have to create the test logic by myself, so checking if a method returns the expected result (or not).
Before start coding a solution, I would like to know if there´s something existing like that already? If yes, I would appreciate any hints/ links/ articles etc., especially for Ruby, but Java and/ or C# would also be great.
Thx in advance!
I´m thinking about how to solve the following task: You´re joining an (agile) team as a tester and you´re the one being responsible to do the (automated) regression testing. No structured regression tests have been done before, (nearly) no tests (test cases, automated test scripts, etc.) are existing. What you have are the user stories + acceptance criteria from previous sprints and the (user-)documentation as far as it exists. Maybe some other docs too, but that´s not the point.
So it is your task to start regression testing for the old functionality as well as doing the testing for the stuff that is under development at the moment. Since development is ongoing, you somehow need to split up your time between this two main tasks, but how?
I see two possibilities:
Advantages
you learn about all the product´s feature from the very beginning
you know about the „development history“ of the product
regression test suite is build up as fast as possible
Advantages
tester is available for testing actual stuff under being under development right on from the start
tester is working as closely as he could(/should?) together with the team from the very beginning on.
Disadvantages for both proposals: Just invert the advantages of the other proposal. 😉
What should be done indepently from what solution is been chosen:
What do you think about this?
Did I miss a possibility or (dis)advantages of the explained possibilities?
[Update]
Interesting article on Starting Test Automation for a Legacy Project which is imho closely related to what I have written: You can’t start test automation without having a clear concept on how to start regression testing. The article gives some good ideas on how to start for both.