Agile
now browsing by category
How long does it take to run your Regression Test Set?
I want to dedicate this blog to a specific problem that we have during this iteration.
This post is for people who have the same problem, therefore can benefit from it and get some ideas from what we are trying to do.
Our feedback time is giant (Too long to know if we broke anything after committing code). After performing a quick value stream map for the development task we found out that we take between 24h to 48h depending on commited time and working hours.
Scenario I = 48 hours
Commit at 9:00 AM
Automatic build ready to be tested at 00:00 AM
Results at 6:00 PM (It takes 18h to run all the test cases, at this time developers are out from office)
Developers are back at 9:00 AM
Scenario II = 24 hours
Commit at 06:00 PM
Automatic build ready to be tested at 00:00 AM
Results at 6:00 PM (It takes 18h to run all the test cases, developers are still at the office)
Currently the team has 2 Test Sets, first one for smoke testing, second Full regression test set; The smoke testing covers just the basic part, all new test cases for new features are added to the Full Regression test set.
New Approach:
The team decided to create a third test set called “Release Test Set”, this test set will contain the test cases for features developed during the ongoing release, this means, all the automated test cases created by the team during the iterations will end on this “Release Test Set”.
When the product is released all these test cases will be moved to the “Regression Test Set”. With this approach the team will save around 17h of waiting time.
We will continue to run the Regression Test Set on daily basis but this time the team has the possibility to get quicker feedback about their actions during the iteration.
I will keep you posted about the results…
Please comment ;);) And give me your ideas ;)
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Succeeding with Agile, Book Review
This weekend I did read a book and I wanted to share my opinion about some issues in this blog. The book is called “Succeeding with agile” from Mike Cohn.
The book does not bring anything spectacular if you are familiar with Agile but it will give you some fresh ideas about several topics.
Below are the chapters that i found interesting.
Chapter IV describes useful tips how to spread good Agile practices inside the company; one way to achieve this is using improvement communities.
Chapter VI is in my opinion the most interesting chapter. The author dedicates a full chapter to the topic of “Overcoming Resistance”. He explains what kind of people most probably will be against the change, what kind of resistance they will show and simple tools to transform them into no resistors.
Chapter IX defines five topics to achieve technical excellence. Test driven development, Refactoring, Collective ownership, Continuous integration and Pair programming.
Chapter X talks about the team structure; this chapter is extremely interesting, it shows how teams should be assembled and present several studies showing how size of the team affects the productivity.
Chapter XIII gives an overview how to organize the product backlog and how to write good “user stories” with the respective acceptance criteria.
Chapter XVIII touches on a quite common topic nowadays: how to use apply Agile with distributed teams.
Chapter XIX presents situations where Agile needs to coexist with other approaches, for example CMMI or ISO9001. This chapter shows that several approaches can coexist.
Chapter XX describes very important topic; Agile methodologies cannot be implemented thinking only about development, the rest of the departments need to embrace the change, otherwise all the transformation will fail.
The book ends with a great chapter (Chapter XI) that presents some tools to evaluate the maturity of Agile in Team/Organization.
Hope this can be useful for you guys.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Is Localization delaying your product release?
I want to dedicate this post to a problem that I encounter several times.
- Did it ever happen to you that localization is the last thing to be done on the project?
- Was the release of your project delayed because of localization issues?
- Did your product go live just in English because there was no time to localize it?
In most of the projects localization is still done in “waterfall” mode, all the development is performed without thinking about it. Localization team is involved at a very late stage of the development cycle.
What impact does it have on the product?
In my opinion there are several problems related to it:
1) First it’s almost sure that the product will not be released on time. The team needs to wait for all localization so that the product can be released. Most of the times when the localization is done at the very end the GUI is not taken into account in order to support other languages than English. When the product includes other languages than English, several issues arise that needs to be solved.
2) Linguistic quality will be affected, localization and its testing will be performed in hurry. To perform localization testing GUI specs are needed. Most of the times at the end of the development GUI specs do change so much that no one has the latest version anymore, this will provoke many of the strings not being tested anymore.
As a final outcome, the localization cost will increase in order to correct all the defects inserted during the process. I am sure there are many more problems related to this but I wanted to highlight what are the most critical ones.
How can we improve this situation?
Based on my experience I believe these issues can be drastically reduced if localization is part of the development interactions.
What to change to make this happen?
The first thing to be changed is the people’s mind set. Localization is something that needs to be thought of since the beginning of the development.
The development team (usually called Scrum Team in Scrum World) should always contain a responsible person from the localization department. Developers should prepare the software in a way where resources files are used instead of “hard coded” strings.
The GUI specialist should work closely with the localization team in order to make sure that all the GUI is designed in a way that localization part will not have any big issues. Other languages than English usually take on average 20-30% more space, preparing the GUI for these situations will avoid many truncations issues.
Having localization part of the sprint, allowing localization test cases to be done and updated at the same time as the GUI changes allows the localization team to update the test cases immediately or even source files avoiding futures errors in the process. The projects I have participated it was normal to have test cases or source files out of date because there was not a clear conversation between GUI/development team and localization team.
For last a good way to make localization part of the development is to include it as part of the Definition of Done. A story is just completed when is fully localized. My experience shows that is difficult to include testing inside of the sprint. A possible way is to perform the testing within the next sprint when all the stories are done and fully integrated.
Resuming:
- Strings are created by the responsible person
- GUI personal needs to design the GUI taking into consideration other languages than English that will take 20-30% more space on average
- Developers work directly with resources files
- Localization department can localize the strings during the sprint
- Localization department can create localization testing cases based on the GUI specs for the stories being implemented during that sprint
- When the localization is ready, the resources files are included in the build
- Localization testing is performed in the next sprint
As a result, at the end of the sprint we will have:
- Software localized
- Localization test cases created
- Localization testing can start in the next sprint
This will help to reduce all the problems mentioned in the beginning of this post.
Do you think this is helpful?
Do you have any ideas?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
D5 Creation