I’ll be Speaking at Agile 2009 with Mike Longin

We will be speaking this year about applying modern software development practices to UI automation. If your going to the conference be sure to check us out!

http://agile2009.agilealliance.org/node/91

Stand-ups

As we work toward in enhancing our agile practices, we(the team) took it upon ourselves to enhance the way we handle our stand ups. However this practice may not work for all teams, but as a team of larger size who works a lot in pairs and feature sets we thought these following things would be beneficial to the team organizing there day efficiently. 

1. New & Improved Daily Stand Up Routine
1. Impediments that stand in the way of moving forward addressed first
2. Story Work
1. New or Changed Stories
1. Meeting with Product Owner, Development, QA for new stories should be identified and take place (New Stories only)
2. Identify Story that Pair Programming Team is going to work on, and how they are going to begin
3. Identify the tester who is going to be building the test with requirements
2. In Progress Story
1. Identify the Pair Programming Team
2. Identify the tester who is going to be building the test with requirements, or running the tests
3. Any Impediments related to story
3. Stories that are completed from day before.(Finished)
1. Is it ready for PO to review the story/close
1. Deployed in an Integrated/Customer Level Environment
2. All Tests Pass
4. What was accomplished outside of Stories(and does it need a story)
1. Escalations
2. Large Meetings, Discussions, etc
5. Product Owner Update
1. Change of Directions, Escalations coming our way, etc

South Florida Code Camp

At South Florida Code Camp right now presenting with Mike Longin on SWAT at 9:50, and Applying Modern Software Development Practices to UI Automation at 11:10. When all is done, I will give an update on how it went and will attach the power points on our presentation.

Some links to check out in the mean time.

http://sourceforge.net/projects/swat/

http://www.fitnesse.org

as well as devxero.wordpress.com.

Updates will come after 1pm.

Update:

Both presentations went extremely well(minus the demo failure for presentation #2). I have uploaded the slides here.

An Introduction to UI web testing using SWAT

Applying modern software development techniques to UI testing

Thanks for everyone who attended our two presentations. It was great to meet everyone and we look forward to future presentations.

Contribute CS4

Testing out the new shared content system of Contribute CS4, for being CS4 seems a bit bared bones, but I can see the appeal for ease of user and content updating on simple blogs or php websites.

Team Dynamics, Don’t be afraid of Change

In the Agile world, adaptation and constant change may be something your use to, but experiencing those changes in the team itself may not. Most people fear change, and not in the sense that change is negative, but it is unknown, therefore comfort zones that have been established will no longer be applicable.

One of the biggest types of changes in a Development world is Team change. As the organization discovers its strengths and weakness it than has to begin adapting the structure to best support the overall mission(deliverable) of the org.

So this affects us, mostly with team level changes, whether that be gaining new members(new to org or transfer), loosing members(experienced team members), or changing leadership(reporting structure).

Now there is most likely many other scenarios that can affect teams besides personnel changes. This also may include environment(team rooms, employees going remote), project(moved to another project, project canceled), etc.

As a Scrum Master in an agile world it is your main responsibility to maintain team communication, quality and velocity. This breaks down to being able to make sure the team communicates with each other in order to meet the second goals of maintaining a quality product and delivering that quality at the highest quantity possible. 

For Example: Team A joins Team B, and looses Employee X to Team C.

The example above is a standard team combination with maybe an overlapping resource being moved to another team, possibly two scrum masters, architects, product analysts, two specialty testers, etc. Team A and Team B most likely have reached a comfort zone if they have been existing teams, and already know there team mates work habits, and are able to adapt to them to continue productive forward progress. However now that Team A and Team B have combined, they have now returned to the “New Kid in School” mentality as they are entering an environment in which some people know each other very well and some may not know each other at all.

In Agile Development it would be accepted that the new team, will be able to spend a sprint or two in learning the team dynamic, adapting to change and transferring knowledge. This is where the Scrum Master’s ability as a team facilitator can be the most useful.

Here is a few things that a Scrum Master can try to do to facilitate a smooth transition and make a positive change to the team.

• During meetings(reviews, stand up’s, planning’s, etc) ask everyone on the team, person by person there past team experiences and the things they liked about there old team and how they would like to see that applied to the new team dynamic.
• Like above, ask everyone one thing they have seen that they would like to see different and what they suggest to improve this on the new team.
• Humor, even thou humor may be considered inappropriate in all ventures its important that you make the atmosphere a comfortable one, whether its being a bit silly or humorous, laughter is the best medicine for a tense new environment.  Remember to keep it non offensive, as jokes which can alienate people are unacceptable.
• Make sure your workspace is conductive for team work(when possible). Sitting in cubicles doesn’t facilitate a team mentality and makes it hard for people to come up to you without the feeling that they are disturbing or even possibly annoying you by interruption. Especially as a Scrum Master you want to make yourself as accessible as possible so your co-workers can come to you with any questions, concerns or anything at all.
• Have a team outing. Some people just can’t open up at work, and doing something outside of the office is a great way to have fun, and enjoy things together as a team. Pick a few ideas or suggestions and have the team vote on a few of them and pick the top choice.
• Take the team to lunch and try to get everyone to sit next to someone they don’t know, sometimes just having someone to the left of you is all you need to start up a conversation and get to know some-one.
• As a Scrum Master, make sure you spend some 1 on 1 time with all members of the team to see how they are adapting to the new team dynamic , and by having a 1 on 1 they will feel more comfortable letting you know something that has been on there mind, whether it be concern of a suggestion for improvement.

These are just a few idea’s that I have tried and there is definitely more ways out there to make change a positive experience for everyone. Remember most importantly that no matter what everyone is equal and by treating team mates with respect and kindness will be more than enough to start off on the right foot.

Retrospective, Scrum Gold Mine or Fool’s Gold?

“Retrospective meetings are the heart of agile methodologies. Scrum teams follow this religiously at the end of each iteration. ” – Agile World

A Quick History on the Sprint Retrospective

“Retrospectives initially were not a part of Scrum at all. There was supposed to be a retrospective part during the sprint review. Over the time it evolved into two separate sections: Sprint Review focused on what and Sprint Retrospective focused on how.” – AgileSoftwareDevelopment.com

Iteration Retrospectives

“Iteration retrospectives are carried out at the end of the every iteration. The main goal is the daily habits improvement. By discussing of what went wrong, what went well team gets a chance to share the individual observations, aid daily problems and eventually grow as a constantly improving team. Not to loose the power of periodic retrospection it is very important for an iteration retrospective to result in a specific set of changes. Reviewing own work takes emotional energy and people would not be willing to invest it if it won’t result in a visible outcome.” – AgileSoftwareDevelopment.com

 

Through personal experience with Agile and using a Retrospective as a method to “tune up” team performance and how we as a team handle outside interactions, I have found a few key things to focus on that help improve the Retrospective Experience.

1. At the beginning of the Retrospective before diving into each independent story ask about any large issues that have been impeding the team. Any issues brought up at this time are most likely the main impediments the team has, as they are the freshest in memory of have left the sourest taste in the teams mouths.  Ex. Spikes due to support, Performance, Knowledge, Project Misdirection, etc.
2. After identifying any general impediments move on to the existing impediments from previous retrospectives to make sure that you have been making progress with them, and that they have been in affect removed, or if a continuous issue, forward progress is being made. This gives visibility and helps to insure that issues aren’t being raised and falling to the wayside.
3. After the General and Existing Impediments have been dealt with it is important that we now move on to story level impediments, which usually have a strong focus on process and learning through experience. Ex. How did this story go, and now that I know what I know, what could I have done to done this more efficiently or handle the issues that arose?
4. It is critical that after you have gone through the impediments that you prioritize them and select the top impediment in which you need to remove first out of the teams way. This is important as taking on too many impediments at once will leave you ineffective at clearing them in a timely manner. So focus on what has the most value for the team, and work your way down the list. It is absolutely critical that you remove at least the top impediment from the list to guarantee forward process.

An Introduction to SWAT 2.0

 SWAT or Simple Web Automation Toolkit is an open source web automation testing tool developed by software engineers and testers who work at Ultimate Software. Currently SWAT is used in-conjunction with Fitnesse Framework however it is not dependent on FITNESSE being installed, but currently formatting is based of Fitnesse Pipe formatting.

Here are some screen shots of the currently public version 2.0

 

 
Version 2.2 SWAT Recorder

 

Assertion Tool

 

SQL Assertion Tool

Great Co-Worker Software related Blogs

Check out fellow Scrum Master and Developer’s blog and a lead contributor to open source project SWAT

http://devxero.wordpress.com

Also check out Software Architect and Founder of DVDFriend.us technical blog

http://hamletcode.blogspot.com

Exploratory Testing – A Walk Through

“Exploratory Testing” Defined

An approach to software testing that emphasizes the personal freedom and responsibility of each tester to continually optimize the value of his work by treating learning, test design and test execution as mutually supportive activities that run in parallel throughout the project.”– Kaner, Bach. June 2007

No Preconceived Notions

“Testing is exploratory to the degree that you are not bound by preconceived ideas. Testing is scripted to the degree that you are bound to follow what has been designed in advance.” – James Bach

Don’t Do what you always do! Your pre-existing conditioning will dampen your testing efforts. Try to take the beaten path.

Exploratory Testing

• Is NOT “random testing”
• Is NOT “unstructured testing”
• Is NOT a technique, but an approach
• IS teachable, repeatable, and manageable
• IS the heart of excellent testing

Missing Requirements?

ET (Exploratory Testing) can be used as a great method for finding missing requirements.

The Difference between a bug and a missing requirement is that a bug is a requirement that is failing, and a missing requirement is one that was never defined.

Helps finds holes in requirements

ET Vs Automation

Automation is great for regression and existing tested functionality

ET is great for discovery and exploring “undocumented” features.

They both can co-exist. A healthy balance of both will increase quality, while a lack of either will decrease it.

Misdirection

Focusing a set test plan all the time may leave you too focused to notice what’s going on outside of the test plan.

• Are features not in the test plan behaving differently?
• I break out of a test plan, should I expect a certain result?
• Inattentional Blindness is a common problem regarding missed bugs.
• you get too used to your environment, you may miss the obvious.

Tester’s Investigative Tools

• Observation (5 senses)
• Interviews (stakeholders, programmers, designers)
• Screen shots, log files
• Project documentation
• Scenario modeling
• Hunches, inference, feelings
• Notebook
• Screen capture, keylogger, video capture, log watch
• Software programs Test automation
• Scripting language
• Monitoring tools
• sysinternals, perfmon, file monitors etc.
• Whiteboards, idea diagrams

Transition to ET Strategy

• Follow script
• Add variability
• change input values, or step sequences
• Stop part way through
• Stare out the window, take a break, and then interact with the first thing you see
• Has the time spent been valuable? Should I continue?
• Lose the script (but not the test purpose)

How do I apply to QA

• Use a recording tool like SWAT to record your exploratory testing for feedback, regression and future automation (if bugs/ missing requirements found)
• Assign a story/task for ET to account for time. Report on findings during stand ups to show value.
• Implement a team tester trade.
• Have someone not familiar with your page/features to test your product without test cases. Gives fresh eyes and promotes strong ET values.

Can Testers Make a Difference? A thought inspired by Google’s “Testing on the Toilet”.

One of my favorite presentations of the whole conference, happened on day 4 regarding Google’s “Testing on the Toilet” keynote. In the testing world this is a pretty popular story, but just in case you haven’t read about it already, here is a link to read.

The idea here is that anyone in an organization can make a difference. It is a common misconception that Testers are an after thought in the development process and only are there to reassure that “Quality” is a term lightly used and rarely influenced. But the real question to ask is, “Why is this so, and How can I(the tester) make a difference?”

Now not every corporate world is the same, so there is no sure fire way to guarantee your message will be heard, and quality will be enforced, practiced, or even noticed. However that does not mean it is not your responsibility to make a change. Here is a few idea’s that a tester can use to inspire ones self to make a difference.

• Start a Quality Control Group
  • Rally up the testers, developers, PO’s, Analysts, Marketing or anyone who believes your vision for Quality and wants to move forward to achieving something that everyone can be proud of, and start a forum, whether it be a weekly, month, after work, or on-line meeting where you can brainstorm as a Quality Focused Team to help improve the current process.
    • Internal Quality Group
      • This focuses on a group within the company, improving the specific processes and figuring out ways to apply this focus on Quality to your individual project/companies projects. This allows for more specific discussions to occur without violating any industry secrets or confidentiality agreements.
    • External Quality Group
      • This focuses on a group of fellow peers in your local/regionally area that get together and brainstorm on how to improve the industry/field as a whole without necessarily revealing any company kept secrets. This is a great way to see how your peers handle certain scenarios that you may of otherwise been unable to visualize due to the nature of your work environment.
• Let it be Heard!
  • Create a Blog
    • Create away for people to access and discuss your idea’s. Web 2.0 is a great way of communicating outside of your immediate area. Utilize these tools to put your thoughts into words and let the world contribute to your ideas.
  • Contribute to existing Forums, Blogs, and Communities
    • You don’t have to be a leader to make a difference. Contributions are what make up any and all changes. Just being apart of the discussion can stimulate new ideas and become a catalyst for change. This is a great opportunity to use existing forums to ask questions, give answers, and learn more about all varying types of topics and how they may relate to you.
  • Create a newsletter
    You may have idea’s that the rest of peers may not even be aware of. You may be a senior tester yet have no way to distribute your knowledge to the rest of the team/organization/ or even community. By creating a newsletter you can sum up some of your basic ideas and even use it as away to train. Start with a single page, outlining some new feature or test method, give an example on how to implement it, and then follow up with some commonly asked Q&A’s. Send it out to your peers and than ask around for feedback. Others may like to contribute, and in time your readers will become participants and a community will be formed.
    • “Inspired by Google” – Post in the bathroom, post it in the cafeteria, post it under the build status. Put it where it will be allowed and if its not allowed anywhere, make your case to management that these methods have been used, applied and found very successful.

Now go out and make a difference! And just remember don’t stop until you do, not every idea may be right for you, and it will take effort to see it through, but the end result will be a better way, and you will be the reason for it.