I started listing resources & guides

 I started listing resources & guides please add more!

Cheers.

• Exploratory Testing
  • Ministry of Testing ET Resources
  • Ministry of Testing Session Based Test Management Resources
  • 10 Ways To Do Exploratory Testing Badly
• Security Testing
  • OWASP Testing Guide
  • Low Hanging Fruit
  • Ministry of Testing Security Testing
• Tools
  • Fiddler
  • ZAProxy
  • Burp Suite
  • Charles
  • Firebug
  • Ministry of Testing Tools List
  • YSlow
  • AutoIt
  • Jmeter
• Ideas
  • 36 Days of Web Testing
  • Technical Web Testing 101
  • You Are Not Done Yet
  • The Little Black Book On Test Design
  • Software Quality Characteristics 1.1
  • Alternative Uses for Fiddler
  • 37 Sources for Test Ideas 1.0
  • Software Quality Characteristics Poster
  • Introduction to Test Strategy
  • Exploratory Test Design
  • What does a technical exploratory test session look like?
  • 77 Test Idea Triggers
  • How to chain HTTP Debug Proxies
  • No time left at the end of the sprint for proper testing
  • Onion Patch Strategy
  • 101 tactics for revolutionaries
• Automation
  • Models of Automation
    
  • Throw it Away
  • Selenium Simplified
  • Selenium HQ
  • Webdriver Google Group
  • Selenium Users Google Group
  • Junit
• Humour

• • Software Tester Reactions
  • DevOps Reactions
  • Cartoon Tester
  • Explaining Testing
  • QA Hates You
• Books
  • Ministry of Testing Ebooks List 
• Accessibility
  • Web Accessibility Testing Heuristics 
    
• Cheat Sheets
  • XPath, CSS, DOM and Selenium: The Rosetta Stone

• • Test Heuristics Cheat Sheet Data Type Attacks
  • Web Test Heuristics
  • Selenium 2 WebDriver Java API Cheat Sheets
• Responsive
  • Responsive Web Design Testing 10-Tools You Need to Know

I went to Mile High Agile 2013 and I liked it.

I went to Mile High Agile 2013 and I had a interesting time.

The Keynote was from Joe Justice who spread the word about Team Wikispeed: building a 100 MPG car using Agile & Lean methods
You get the drift of the talk from the title, it was great to see how far they've come using these methods and also how they are able to help others using the methods.

The Keynote was filmed but I don't know what happens with the recording, whether or not it's put online for public viewing.

Find out more about wikispeed.

I managed to catch Paul Rayner's DDD Workshop which I enjoyed.  I think it gave a good introduction and a few take aways to think about.

We worked through a exercise and we were working out our domain model.  I won't write down too much detail as I don't want to give it all away.

Paul's was the only session I managed to catch as I spent a lot of the day in the coaches clinic.

The coaches clinic is a great idea and the basic setup is that people can drop by a booth and book in some time with a coach to talk about about pretty much anything agile related.

Whether it is issues they are experiencing or things they are unsure of and so on.

I enjoyed the clinic and it was interesting to talk with people who needed help with some different areas.  I hope I was able to help with some things to take away and think about.

Some of the things we discussed ranged from whether or not to use Scrum or Kanban to how to get more out of Product Owners. 

While I didn't make many of the conference talks I definitely feel my time was well spent.

My thanks to Pete Behrens for inviting me to be a part of the clinic.

My own talk was at the end of the day and it was still a pretty full room which I was surprised about purely because usually some people have left by the last talk.

My talk was about Change and the Prezi is available.

I caught a glimpse of the feed back forms and it was a mixed bag which is pretty good, in my experience it's hard to have a talk that is going to reach everybody the same way.


I do wish that the people who didn't get much out of talks would offer more feedback.  It seemed like the people who got something out of the talk offered comments and the people who didn't just marked down a score and left it at that.
That makes it very hard to improve.

All in all a good day, had a lot of different conversations, hopefully gave some people some things to think about in both the clinic and my talk and met a lot of really dedicated people.

My thanks to agile Denver and all the volunteers for bringing me along for the ride.


After the conference I got to meet Lisa Crispin's donkeys , Ernst and Chester.

Matt Barcomb was also Lisa's guest and it was great to be able to spend time with Matt, Lisa, Bob (Lisa's husband) and Lisa and Bob's extended animal family.

It was great to meet Matt and I'm looking forward to his (and Jim Holmes's) session at Eurostar.

My thanks to Lisa and Bob for inviting us (my wife and me) over. They are fantastic hosts and we had a great time.

 Matt and Lisa

My wife Marisol

No time left at the end of the sprint for proper testing

In the Agile Testing Linkedin Grp the following was posted:

No time left at the end of the sprint for proper testing

Designers tend to add and change code until the end of a sprint, not leaving enough time to do all the agreed testing. At the start of a sprint, we assign rough time estimates to user stories, taking both design and test activities into account. Some tests are automated and run during the night.
However, other tests need manual preparation of data and partly manual execution and result analysis. There is also some amount of exploratory testing involved. During the sprint, there always seems to be a reason not to deliver yet to test: fixes, improvements and design updates. At the end of the sprint, little time is left for manual testing, far too less for running the tests, analyzing and repairing eventual bugs, retest and results logging.
What advise do you have for me, so that I can claim and really use a fair amount of the sprint time for testing?

With a follow up post of:

What I called 'delivery' is not a heavy weight process wall. It is just a oral notification in the team stand up meeting that some story is ready for test. Our way of working is pretty much in line with all points you mention: except for point 5. "Testing is a fair amount of the sprint if done well". I think 1 day left for testing out of a 2 week sprint is not this 'fair' amount. The pattern that I have to cope with is: several user stories are coded in parallel and they tend to be 'ready for test' all at the same time, that is: 1 day before sprint end. The tester is involved in functionality and architectural discussions during the sprint and prepares test data and test scripts, ready to 'push the button' when a story is ready.

My (currently unpublished) comment (with minor changes):

So, based on the info you've provided I'm going to make a bunch of suppositions along with ask a number of questions.

1. Is there a definition of 'done'? Does it include testing? If so, it seems like it's being ignored?
* If it is being ignored are there retrospectives held? What happens when this is brought up?
* Is the issue being recognised by the rest of the team?
* Is it being recognised and cared about?
* Are the powers that be aware?

2. Are the stories broken up into tasks? If so is it possible to test the tasks?

3. If what you are working on is broken up into (small) stories and setting aside the late adjustments there should be a constant stream of stories coming through, if not, has this been looked at? If so, what was the outcome?

4. Is it possible for team members to pair? IE testers and devs, ba's and testers, ba's and devs, etc.

5. Is there a visual representation of story process? Visible by everybody?

6. Is this way of working new to the team/company? Was there help making the transition? If there was, were they any good? Were any new people with more experience in this way of working hired?

7. Are you/the testers prepared to play hard ball? You can't possibly test a sprints worth of work in a day, so don't try.

8. How are the late adjustments getting into the story? They should be judged on value and as a team decided on whether or not they get into the sprint. Failing that then a story/stories can be dropped to allow for changes.

9. Is there a scrum master type role? Is he/she someone who has gone and gotten the CSM or are they experienced?
* Experience is very hard to judge, how is it done?

10. Is there a way to prepare test data through automation?

11. Is there any skill sets lacking in the team in general?

It doesn't seem like you have a testing issue, you have a team/culture/mindset issue.

I'd like to know what I've missed?

 

 

Tyrion Lannister - the agilist.

He is intelligent, witty and has skill for political manoeuvring. 


Because he is an outcast, he also has great sympathy for outcasts and the mistreated and helps them improve.

He is disliked by some and treated with respect by others.

He has lived and experienced all that life can offer him.

He has been on trial, adapted, worked out a solution and used only the appropiate tools to survive.

He meets hostiles and wins their support.

He adapts and adapts those around him.

He is adapt at bureaucracy.

He keeps his friends close and his enemies closer.

He learns strategy.

He learns from books, experience and people.

He is effective.

He is a surviver.

He is a leader.

He is agile.

agile schmagile

Am I the only one bored of 'agile'? It doesn't seem like it.  As far as I can see it's causing confusion and still has bureaucracy issues and can be a right pain in the behind.

There seems to be a number of issues , here are some I’ve picked up on.

1. agile as intent is great* but agile is not defined, there is no one concept, people have their own understanding and this can cause problems because people are trying to achieve different things

* So when I write that 'agile as intent is great' that's my understanding of agile, which probably differs to yours

2. People have pre-conceptions and stick to them

3. People have a cookie cutter approach

4. People try change without help.  It's extremely difficult for a group of people to change their ways, especially if they don't see why things need to change

5. People don't see the bigger picture, 'what am I doing is fine (at least I think it is) so I'm going to keep doing it this way, it's not my problem if there are issues with the team/project/organisation'.  People also try keep a hold of their corner

6. agile is not a silver bullet, agile will cause confusion and uncertainty, all change will and does

 7. There is a huge psychological factor to changing to agile, in all kinds of areas, trust, egos, a change of thinking, etc.  This needs to be taken into consideration. The change in thinking required to 'be agile' will not be for everyone

8. agile and/or change can take time, most people don't like change and uncertainty, people won't 'get it' at first and it can causes scepticism, stubbornness and resistance

9. agile is not about productivity, it's about improvement, productivity will happen by default when you improve

10. Scrum is not agile, it's a project management methodology

11. For most of the organisations that have success with agile it's been hard and took years to get there, realise this

13. There is no one way to 'be agile' it requires trial and error, things will go wrong, mistakes will be made, things will also go right and great improvements will be made

You need to realise this and be able to deal with both scenarios

14. Learn from what others have done and consider that it might not be quite right for you. IE 'that's not a user story, there is no xyx'.  Who cares? Does it work for you? Yes? Great, keeping doing it. No? Tweak it until it does.   If it doesn’t work, ditch it. By the book doesn't always work

15. People hold back because of uncertainty, fear and worry