- This topic has 18 replies, 11 voices, and was last updated 9 years, 8 months ago by
.
-
Posts
-
Discussion about applying different ways of testing, like detailed scripting, global scripting, session based testing, bug hunts, test tours and pure exploratory testing, in agile project.
View the Webinar Recording & Slides HereThank you Jan Jaap, for your presentation and your personal note.
A question:
You remarked:”Don’t stick to the method handbook but choose the best way of testing for the given situation.”
Would you agree using a method does not necesarrily impact the way of testing, but the process of testing.
Hence, the (quite varying) “best way of testing” for various situations might very well fit within a given method?Thanks Jan Japp – Great presentation. I must admit, that 3/6 of the types of testing I wasn’t familiar with by name (global script, bug hunt, test tour) and will be looking at these a little more so I can apply. If you have any links that might be good for general review of all 6 types it would be appreciated. Overall though, enjoyable presentation.
Thanks for the presentation Jan,
Could you please give some more information/links on global scripting and test tours. I get the other methods but these 2 are a little hazy for me.
ThanksThank you for a great webinar, Jan Jaap. It was very insightful in the different ways to get better at what we do in a more effective way.
Thanks for the question Rene. It depends on the method. Some methods are flexible enough to support differnt ways of testing but I haven’t found one method that supports the whole continuem. So in my experience you need to know and be able to appy different methods to cover the complete continuem.
By the may, the process of testing and the way of testing are for me about the same things. Could you explain what in your opinion is the difference?Thank you Jan, Ireally enjoyed the webinar. What is the best way to find out the basics of Agile testing for newbies?
I am moving to introduce a change within my department, where I want my team to create Test Scenario that can be run within a round of exploratory testing, then these would be extended to more detailed scripts during actual System Testing. The Test Scenarios would then be the base for Regression Testing/Automation later in the cycle.
We are still running in an Waterfall/Little bit Agile way.
I feel this will increase coverage, and will identify issues earlier.
What are your options on this?
Thanks for giving proper names to what we’re already doing in my company! We do a combination of all those. I would just like to share though that creating our automated tests happens at the implementation stage (not during or after testing phases – certainly not in an “R&A” stage!). We’ve been doing this for around 2 years now. So it’s very possible to do this cycle and would highly recommend it. Automated tests should not be an afterthought or at the end of an Agile life cycle.
Thank you Paul, Allen and Tonje for your nice words, It is great to hear you enjoyed it. The best books on test tours is the book ‘Exploratory software testing’ by James Whittaker. Simply brillant, I read it twice and made my own variants of test tours. Please send me an email ([email protected]) if you want to have my variant of the tours.
There is not one single good source for global scripting. It is described in some books about detailed scripting. The essence is that you make a decision how detailed you scripts should be. If you want someone else to be able to execute your scripts you should really make them detailed bu means of steps in the scripts. If you are the one that execute the scripts yourself or someone with deep knowledge of the system these detailed steps are not nessesary. Giving the essence of the test case and leave out the steps works most of the time. I also have an example here which I can email you. My general advice is: ajust the level of detail of your scripts depending on who is going to execute them, how much time you have available and how much freedom you want to give the tester.Thank you Angela for the nice words! I would recommend the books Agile testing of Crispin and Gregory, Explore it by Hendrickson and Test Tours by Whittaker. And get your ISTQB (or TMap if your Dutch) Then look for a more experienced peer and spend about 10% of your time on trying new things and evaluating the things you did last week. This 10% on piloting an evaluating is the most important after you have basis knowledge of testing.
Success and NEVER stop learning!hi Nina. I’ve got no idea! There is to little information in your message to say samething ussefull. For instance: These test scenario’s sound a bit like what I call test charters. This brings a certain amount of freedom into testing. I don’t know whether the testers can handle this. We could discuss this if you want by means of skype. If you find this a good idea please send me an email ([email protected]). Of course you can also add more detail in this forum discussion.
Haha, Tanya, I recognise what you say with ‘giving proper names to what we’re already doing in my company’! I once ‘invented’ a new way of testing for a particular project, we did not really give it a name. Later I found out others, who also ‘invented’ it, called it bug hunts. So yes, it is good to know how others call the way you work because then you can share experiences.
You are right about the test automation thing. I didn’t mention BDD, TDD, Cucumber etc. So much to tell, so little time. But I agree that when you can use automation during preparation/execution you should use it!Thanks for giving proper names to what we’re already doing in my company! We do a combination of all those. I would just like to share though that creating our automated tests happens at the implementation stage (not during or after testing phases – certainly not in an “R&A” stage!). We’ve been doing this for around 2 years now. So it’s very possible to do this cycle and would highly recommend it. Automated tests should not be an afterthought or at the end of an Agile life cycle.
My company has the same practice – automated tests are done during the sprint, and sufficient automation is part of our definition of done. We aim to do agile development so that our code is really of releasable quality at the end of each sprint. For us done means that the user story never has to be touched again. To release all we need to do is run our automated regression test set, if that passes do a short manual check and hit the release button. Top support a frequent release schedule automated tests have to be implemented in the story.
My company has the same practice – automated tests are done during the sprint, and sufficient automation is part of our definition of done. We aim to do agile development so that our code is really of releasable quality at the end of each sprint. For us done means that the user story never has to be touched again. To release all we need to do is run our automated regression test set, if that passes do a short manual check and hit the release button. Top support a frequent release schedule automated tests have to be implemented in the story.
Exactly! That’s how it’s supposed to be 🙂 Automation testing is not something to “use”. It’s part of the development process.
Hi everyone,
You can view the webinar recording & slides here 😀
Sounds pretty mature Stephanie, way to go! Not every project has that in place. Do you have any manual testing during the sprint? I usually see a combination of manual and automated.
Yes there is a combination of manual and automated during the sprint. This comment was only about when automated is done.
Thanks for the presentation Jan,
Could you please give some more information/links on global scripting and test tours. I get the other methods but these 2 are a little hazy for me.
ThanksSame here. I actually never heard about global testing. Also the main difference between SBT and Exploratory Testing is that SBT is using a charter besides ET is just using on start point test, right ?
Also at my company we are doing all automated test within the sprint.
I am curious about documentation. What if the project doesn´t give you the chance to automated due to software architecture constraints. Is the tester then in the charge to create a persitent test plan or should he stop the development process to make it possible to make automated test ? I met that a lot in other projects.
My approach so far is to implement the automated checks first in my sprint via the Acceptance Criteria and after that I create 2-3 charters for the end of the sprint to test the complete feature. My test also should then switch to green. Actually I am always using this approach since the last month and it went pretty well. But I am looking for improvements. Any suggestions ?
Thanks for your talk.
- You must be logged in to reply to this topic.