Showing posts from February, 2010

Automation testing using the Agile Methodology is one of the biggest challenges in organizations. Part 1

The questions I usually ask are:
1.What should I automate in the application?
2.How much of the project/application should I automate?
3.When should I start to automate the project?
4.Where should I put most of my automation resources?

Automating early and especially often in the project reaps the greatest rewards. We usually try to create the easiest of the automation's which usually falls on the developers to create unit tests. Working with the developers can be difficult at times because the mind set (sometimes) with developers is “QA tests the application and I build it”. Now teaming up QA and Dev is actually the best of both worlds. Both team members can play off each other’s strengths and fill the gap on the weaknesses.
Plus developers can run these test on their own box (or development environment) so issues can be found early which means time and money savings for the project. Automating unit tests produces immediate feedback to the developers. Increasing your velocity…

Additional Suggestions to Get Your Agile Testing Off On The Right Foot, Part 2

This is in addition to the previous posting on “6 Quick Suggestions to Get Your Agile Testing Off On The Right Foot”. Getting good requirements will require you to have to ask questions. You will need to ask questions that will garner involvement from the team members because if you don’t get them involved you will not receive questions that will assist you in testing. Questioning of the business/owners/users will engage people and provoke interaction within the entire team. When asking your questions you must “make no assumptions” use context-free questioning like

“What problems are you trying to solve with this project?”
“What problems might this solution create?”
“How does this work?”
“How might it be different?” if we proceeded with this project

You will be presently surprised on the answers you receive and of the ones you were not anticipating.

These are broad perspective questions which will illicit necessary information and can be used for any project effort. The key is to …

6 Quick Suggestions to Get Your Agile Testing Off On The Right Foot

From the Agile Manifesto
“Individuals and interactions over processes and tools”
“Working software over comprehensive documentation”
“Customer collaboration over contract negotiation”
“Responding to change over following a plan”

When Agile succeeds I believe it is because testing has been front and center in the development process. By adding QA into the development process by working with them (dev) defining and building unit tests (when applicable) creates extremely orderly code. Before coding for the new application development works on unit tests creating programming code rather than mounds of documents which was the case with the Waterfall Methodology. Here are a few suggestions that come to mind when starting an agile project.

1. QA will try, but we simply will not find all of the bugs, software has become increasingly complex. QA’s job should be to improve the software helping to produce a better product and know that working software is the primary measure of progress.

Gathering Requirements in the Agile Environment, don't make it a game of “Gotcha”

As a team we must find ways to set and meet goals, rather than focusing on mistakes (bugs). There are many challenges when it comes to requirements, testing and development for an Agile team and for me it is always been first and foremost “Requirements”. Agile does not use the traditional style business requirements or functional specification documents, instead we use small cards (or in our case the wiki) which details ONE feature. We would conduct more meetings down the road to hash out additional details about the feature with collaborative meetings and discussions. I have a few ideas that I have used to gather the requirements so I can build the high level User Stories. First and foremost ASK QUESTIONS!
Ask the business “what do you need to accomplish”.
• What are you goals for the change in the application of the creation of the application?
Ask a user of the system “what do you need to accomplish your goals”. Remember is you can’t state the benefit then you might not need…

Testing (Regression ) in an Agile Environment Part 2

Regression testing the code gains significant importance in this type of methodology (agile). Since each 2 week a sprint of code is being developed and released on the back of the previous weeks code regression testing takes a starring role. The QA team testing will have to test both of the newly added code and that the previously released code to verify it still works as expected. We found that automated testing is good, but time constraints would also hamper our efforts to create scripts that give us a “warm and fuzzy” on the code coverage. There are a few good tools out there that are open source; we were a small company so it was open source or nothing. The development would like to use JUnit, we would also use Mozilla’s Selenium automated tool. Since we had shorter iterations we had code ready to test almost immediately, so we would perform several levels of testing on new code.
Developers would run automated unit tests to test functions, methods and interactions with ot…

Testing in an Agile Methodology Environment Part 1

A quick overview with my experience with the Agile Methodology of Development, it focuses on an iterative method of development and delivery to the business.
Developers and end users communicate closely while the software is built, and a working piece of software is delivered in a short span (we used every 2 weeks) of time.
The key I found was to deliver working software quickly to the business with minimum features and then add features after you receive feedback from the business.
The delivery time-lines (again it was 2 weeks each) are short and new code is added and built on the previous build.
Coming from a waterfall based methodology before learning the Agile method created a whole set of challenges for me and the testing team.

We found that the testing can done more effectively in short turn-around times, by people who know the system and its objectives very well so we would pair up QA with developers. We also had our Business Analysts for the business completing so…

Ping Me Already, SEO Tricks Part 2

So I am still adding a few more tricks to my web properties and again I thought that I would share them with you. I am using blogger because it’s so easy, and these tricks can be used in other blogger applications but I will use Blogger as the test case since I am most familiar with this application.

1. Optimize all of your URL Structure’s: When you post to your blog Blogger will pick up the first few words of the posing title and use that to create your post URL. Ok let’s give this a try, I type in the post title “Agile Testing for Projects” publish the post, then exam the URL structure on the bottom of the page, it reads NOW edit that post and put in more relevant keywords and add to the post title (Agile Project Management) publish it and you still see
So put the relevant keywords in first, then re-edit it and…

Itsy Bitsy Spider, Some SEO Tips

First off this blog will not be entirely about Agile, it’s more inclusive. It will include lessons I have learned, education I am currently undertaking, and past experiences on projects (data management, search storage, cloud computing) in a multitude of different team roles (QA, BA Scrum Master). I am performing SEO on my web properties so I thought I would share some of my experiences. First off don’t design your site specifically for search engines and not the users of your site. You want users NOT just visitors so be careful not to over engineer and over optimize your site. Don’t hurt your user experience and don’t design for the short term it will bite you later.

1. Don’t try to use the popular keywords such as “agile” “quality assurance”, instead add a word before or after the keyword such as “using agile” or “testing quality assurance”. Popular keywords are a better then an extremely popular keyword that you will index at a lower position like number 100.
2. Remember …

Product Backlog Estimates

So at the beginning of the Agile project you are going to have to provide some high-level estimates so you can get an idea of the size of your backlog items you will have to plan for. For me this is always a tuff and exciting portion of the project kickoff. Tuff that estimating something that is a “concept” and Exciting to get involved in creating a new application

This is very important because it helps in the decision about priorities and what you should put on your plate first. Also you will be able to get an idea of what features are likely to be worthwhile, and from the business side it will give you an estimate of how big the team will be.

You are saying about now “I don’t know much about all the items on the backlog” what are the features, tasks to build the features and how do I implement them”??

The approach I have used before is to use a range of unit numbers from 1-20 indicating size. You can begin the estimation process just after you have completed your list of user-…

Agile Use Case’s

So as you know I have worked as a Business Analyst, Quality Assurance Manager and a Scrum Master on a variety of projects. I thought I would speak today about use case creation and show you some of my examples (above) of my work. We tried to create our cases and all of our documentation on a wiki so we could have seamless collaboration between team members and the wiki provided us with an easy technology solution. We use the Use Case in the Agile Methodology to capture functional requirements. The cases capture the functional requirements of the system and or systems you will be developing, enhancing or repairing (bug fixes). You will need a representative set of use cases, covering the entire major
goals of the users and business owners. The cases are multifaceted because the architecture team uses the cases to design the components, operations/methods for the application. Test team members and also business owners will also use the cases for validation walking through diagrams…

Six Sigma and Agile

I am just about the take my final exam from Expert Rating for the Six Sigma green belt program. The class has been very good and very in depth with lots of takeaways for future projects. Having experience in the Agile methodology and the “speed” of the processes I am wondering how the Six Sigma method would perform in a small quick to market software shop. The one thing that I wished I had and or had the chance to use would have been “dashboards” they talk a lot about them in Six Sigma but what I would have done with one for the agile projects I worked on. I have been doing a little investigation on some open source software and found some good sites. I always try to find open source applications first because I know that the implementation of Agile can sometimes scare management and they already don’t want to spend money on another methodology that they are not that comfortable with from the start. Not all management is apprehensive of the methodology but it can be daunting to…

New Blog on a Not So New Subject, Agile

I have been using the Agile Methodology for 3 years in a small technology company with great results. Our time to market, bug issues and resource allocations have all been reduced. I have worked in the IT field in a few different capacities (Business Analyst, QA Manager and Scrum Master) and feel that the Agile Method of software development is the most efficient way to develop and deploy applications. This blog will be a running commentary on what I learn, what I think works and does not, and any other thing that I encounter while learning, growing and implementing solutions to every day issues.