I can't stop laughing when I translated my recent post in english via Google.. enough commercials here's the translation.... (shout out for Jeric Cabuyao.. hahahah!)

Original Article Here


I was bored po nung sometimes take me to MRT. I am a regular mananakay the MRT, the heavy and jostle natitiis I was able to enter and get home early. Pero nung once you are bored I was. It is the late, more passengers and the long interval of the train. Is the Shaw Blvd. Station, a train passing in the middle, not the specific reason this is the minimum of all the passengers more south. Filled with too much platform, too many people in the decision together that we wag nalang mag MRT and bus nalang. Back me Ticketing station for a refund or pass because I used the incoming ticket. Laking surprise and irritation ko nung sabihin sakin ng nag bebenta the ticket with a reduction of the P10 appears to me same station. Boarding fee if daw hindi ako nag kakamali.

Sa tagal kong sumasakay the MRT just now I found it. No information on post with this kind of system. And another very unfair because it did not used or napakinabangan the fare. I think that should remove this extrang charges. Not just not pay napakinabangan.

Isa pa po, would increase the guard platform, only dadalawa and incorrect ratio of the number of passengers on the 2 guard. and marshals would have the peak hours to sasaway in the tutulakan and sisiksikan. yung mga naka uniform dun sa office nila dun much for leisure.

Thank you!

If you have complaints you can sort of email PGMA @ op.gov.ph

I just sent a message concerning MRT. Below is the transcript:


Madam President,

Ako po ay nainis nung minsan ay sumakay ako sa MRT. Ako ay isang regular na mananakay sa MRT, yung siksikan at tulakan ay natitiis ko para lang maka pasok at makauwi ng maaga. Pero nung isang beses po ay ako ay nainis. Ito ay bandang gabi na, madaming pasahero at matagal ang interval ng tren. Ito ay sa Shaw Blvd. Station, may dumaan na tren sa gitna, sa di tiyak na kadahilanan ay ito ay nag baba ng lahat ng pasahero pa south. Napuno ng sobra ang platform, sa sobrang daming tao ay ang pasya kaming magkakasama na wag nalang mag MRT at mag bus nalang. Bumalik ako sa ticketing station para humingi ng refund or pass dahil nagamit ko na ang ticket papasok. Laking gulat at inis ko nung sabihin sakin ng nag bebenta ng ticket na may bawas na P10 pag lalabas ako sa same station. Boarding fee daw ito kung hindi ako nag kakamali.

Sa tagal kong sumasakay sa MRT ngayon ko lang ito nalaman. Walang impormasyon na naka paskil na may ganitong klaseng sistema. At isa pa napaka unfair ito dahil hindi naman nagamit o napakinabangan ang pamasahe. Sa tingin ko dapat tanggalin na ang extrang singil na ito. Hindi naman makatarungan bayaran ang hindi napakinabangan.

Isa pa po, sana dagdagan ang guard sa platform, dadalawa lang ito at hindi tama sa ratio ng dami ng pasahero sa 2 guard. at magka marshals sana pag peak hours para mag sasaway sa mga nag tutulakan at nag sisiksikan. yung mga naka uniporme dun sa office ang dami nila dun parang walang ginagawa.

Maraming salamat po!

Posted on October 10, 2007 by msumrell

More and more companies are either switching to agile practices or talking about switching to them.  Agile development highlights high-quality software delivery and yet the testing community seems to be the most resistant to adopting agile.  Have the qualities that make us great software testers become our own worst enemy when it comes to adopting agile practices?

 

I recently attended the Agile2007 conference in Washington DC.  I went to almost all of the testing focused talks and tutorials and as the week wore on, I came to an interesting yet disturbing realization.  After listening to dozens of testers ask questions during presentations, I realized that Software Testers, QA analysts, QA engineers, or whatever your team calls them have become their own worst enemy.  What gives me the right to say this?  I am a software tester and have been one for over 10 years.  I know how testers think and why we are the way we are. 

Agile development is all the rage these days.  If your company isn’t currently trying it out in one way, shape, or form then chances are that someone is talking about it.  After attending several sessions at the agile conference (and talking to dozens of testers there), the testing community seems to be the one that is resisting agile practices the most!  What really shocks me about this is that we (the testers) have the most to gain from good agile practices!  Agile focuses on high quality.  So, why are we resisting this so much?   

Let’s start by taking a look into the mind of a tester.  Testing is not just a skill set, but it really is a way of thinking.  Some people would even go so far as to say it is a way of life.  We generally have a “guilty until proven innocent” mentality.  When we are given code to test, the first thing we want to do is to prove that it doesn’t work.  That is our job.  That is why we get a paycheck.  That is why we come to work every day.  We are hired and paid to break things.  So, it is no surprise that when a new process (Scrum, XP, etc) is introduced, our first inclination as testers is to “break” the process.  We start looking for all of the ways that the process will fail and try to find defects in it.  We immediately assume (whether we realize it or not) that we don’t trust that the process has really been unit tested well and it is therefore our job to find all of the issues and challenges with it.   

So, all of you testers out there, I challenge you to change your way of thinking for a few minutes.  Instead of immediately trying to “break” agile practices, I challenge you to first analyze the process you are using today and list out the defects with it.  Here is a quick list of the typical “defects” that testers complain about on software projects: 

1.     We are never invited to meetings early in the project to discuss requirements, design, etc.  We have no input into what is being built so we have a hard time creating test plans.

2.     By the time we start testing, the requirements have changed 10 times and no one has told us.  So, we have no idea what we are testing anymore and our test plans are not valid.

3.     We have no idea what development is doing when they are coding and code is “thrown over the wall” for us to test.

4.     We never have the amount of time we need to test.  If development delivers late, then we don’t get to push out our testing time.

5.     The code we get from developers is really hard to automate and is of poor quality.

6.     We feel the full burden of quality.  If we miss a bug, everyone will blame QA! 

How does agile solve these issues?  The beauty of agile development (when done correctly) is that it puts quality first every step of the way.  This sounds like a testers dream come true, doesn’t it? 

Let’s take a closer look at the 6 problems listed above and how good agile practices help solve these issues: 

1.     Agile is all about including the entire team in release planning, iteration planning, estimation, etc.  Testers are involved upfront and in every step of the way.  If priorities change, the entire team knows about it, including the testers.

2.     Agile promotes test first activities.  On good agile teams, the acceptance tests are written before development even starts.  The entire team sees the tests and agrees that they need to pass in order for that story to be considered “done.”   

3.     The tests are written first, so the testers always know what the developers are doing – they are writing code to make the tests pass!  The testers and developers are sitting side by side working as a team to ensure the tests are passing.  There are no walls on agile teams….just constant collaboration and communication.

4.     In agile teams, nothing is considered “done” until it has passed the acceptance tests.  Therefore, developers don’t talk about being “done” until the tests pass.  We don’t discuss design complete, coding complete, and testing complete.  Nothing is done until the tests pass and that is what matters.

5.     The developers know what the tests are before they start coding.  This encourages them to build code that can be automated easily.  Their focus is to build code that makes the tests pass.

6.     It the entire team’s responsibility to drive stories to completion with all tests passing.  The entire team carries the responsibility of producing high quality software. 

So, why do testers want agile to fail?  Why in the world would we want to stay in our waterfall world full of problems when there is clearly a better, higher quality way of building and delivering software?  What are we afraid of?  I think there are 4 main reasons that make testers resist a change to agile.  Fear, accountability, skill set, and the need to be right. 

Most testers out there are afraid of the unknown.  We may not like the delivery process we are currently in but it is comfortable and we know what to expect.  Moving into the “unknown” means a loss of control.  That isn’t a happy place for testers.  We tend to fall into the Type-A, control-freak side of the spectrum.  I know this because I am one.   

Our current waterfall process gives us something to blame when we miss bugs that go into production.  We can always say, “I didn’t have enough time” or “the requirements changed and I didn’t know it” or “I couldn’t automate the tests so we didn’t have time to run them more than once.”   

We are also comfortable with our current skill set, especially if we are manual testers.  Agile testing relies heavily on test automation to be successful.  Therefore, when teams start discussing a change to agile, we hesitate to get on board because we are scared that we won’t provide value on those teams with our current skill set.  When you think about this, it is really a double standard for developers and testers.  As technology changes, we expect our developers to learn new languages, architectures, etc.  Why should we as testers be allowed to stay stagnant in our technologies and skill set?  We should constantly work to increase our skill sets to match the changing needs of the software industry, too!  Testing on an agile team is very different then testing on a waterfall team, especially if all of your testing has been manual.  Adopting good agile practices may require new skills, tools, and techniques.  Instead of pushing back, I challenge you to look at this an opportunity to beef up your skill set and learn new things.  Get engaged!     

Testers do not like to be wrong.  It is our job to ensure that what we are testing is “right.”  I believe that many testers worry that if they start championing agile practices, they will be looked at as having been “wrong” with their former processes.  I argue that learning a new process or skill doesn’t mean that the old one was wrong.  That is just as crazy as saying that old development languages were “wrong” and everyone that used them were wrong.  In reality, we were all doing what we knew to be the best at that time.  Processes and technologies improve and evolve over time.  Testers need to embrace this as much as the development community does. 

As testers, we are champions of quality at our organizations.  If you are a tester that is currently resisting a change to agile practices, I ask you to take an honest look as to why.  If you can truly say that your process has no room for quality improvement, then I would love to hear what you are doing.  You must sleep very well at night J  If not, then push yourself out of your comfort zone and take that first step.  Stop trying to “break” agile and start practicing it.

Source: http://megansumrell.wordpress.com/2007/10/10/software-testers-have-we-become-our-own-worst-enemy/

Written by: Lisa Crispin
Wednesday, June 17, 2009 6:41 AM

Some leaders in the testing industry continue to maintain that test teams are “gatekeepers”, the watchguards for quality. This makes me sad. I’ve spent many years now in development organizations where everyone—programmers, architects, DBAs, system administrators, analysts, customers as well as testers—takes responsibility for quality. These teams have delivered software whose quality is many levels of magnitude beyond teams where the testers were the quality gatekeepers.

One argument I hear from people who advocate separate, “independent” test teams is that testers who work together with developers (especially those who report to the same manager as the programmers) are vulnerable to a programmer suggesting that their “minor” change (“It was just one line of code”) doesn’t warrant any testing. This implies that the programmers don’t care if they introduce defects into the software.

Crummy programmers influencing gullible testers isn’t an issue to be solved by separating them into different, siloed teams. What we need to do is: 1) hire people who care about doing a good job, and 2) give them the time and training they need to do a good job.  It’s not an organizational issue, it’s a management issue.

All the good testers I know are independent thinkers. If a programmer tells them, “I only changed one line of code, you don’t need to test anything,” they’ll analyze the situation and decide for themselves what testing is warranted. If there’s a time crunch, they’ll provide the customer with information about the risk of not doing all the testing they think is needed, and let the customer make the decision.

My independent streak doesn’t change when I report to the development manager instead of to the QA manager. There was a time when I was proud to be the “Quality Boss” and hold the keys to production. Back when I did that, the quality of the software we released was average at best, and our product wasn’t competitive. Seeing the results of the “whole team” approach to quality has convinced me that more collaboration and communication, not less, is the way to go.

Don’t worry about whether your test team is separate or not. If you’re a tester, get up now and go start talking to the programmers. See how you can help them. See how they can help you. If you’re a manager, start hiring the best people you possibly can, and start training the people you have to care about quality and learn how to deliver high-quality software.

Source:
http://blogs.stickyminds.com/Blogs/tabid/91/EntryId/93/Independent-Testers-Or-Independent-Thinkers.aspx

Hello! It has been a busy week at the office, not much time to blog about... Until today...

This is what you call or say "you don't see this everyday" kinda thing.

It was a beautiful Sunday morning, I slept well and when I checked the clock, I saw it's exactly 9am. So I decided to get up and eat breakfast. Just as I was going down the stairs, I saw strange faces in the kitchen area. Fortunately our helper showed up and asked if the strangers can come in to my bedroom to get the monkey. Yeah... a monkey... I was kinda not myself coz I just woke up but I just said "ano kamo?" (what did you say?) to her. She said, "there's a monkey at the kitchen and it's too high to reach, maybe they could get it at your room's terrace". (FYI: the kitchen is a "dirty kitchen" located at the back of the house. it's outside and just covered with grills). I immediately went to the upper floor to look down and I saw nothing. I went back down to tell them and they said, it's there at the corner. So I went into my room and moved the bed so I could open the window. When I went out to my room's terrace, I was surprise that there was indeed a monkey!. It was your average size monkey seen at the zoo's. It was kinda fierce coz it was cornered and confused. The handler/owner told me to get back and it might bite me when provoked. The handler has a long shaft with a rope at the end. I don't know what's it called but if you watch Crocodile Hunter, or Discovery, that's the thing they use to capture stray dogs or crocs. Anyways, to make the long story short, as athletic monkeys are. It just jumped and went to a different route.

We thought it was over until it came back and this time it's at the terrace at the 3rd floor. Fortunately I closed the door knowing that the monkey is still loose and it might get in the house and cause serious mess.

I quickly grabbed the camera and took some shots.





more here

As you can see it's surroundings are very open. It can roam around freely. And as of this writing, we don't have any updates if this monkey is caught or still loose.

I will keep our doors shut until this animal is confirmed captured. If you're wondering why we fly open our doors, well the doors are situated at the top floors, no one can just barge in there, the reason is to let air or wind if you may, to come in and circulate inside the house.

Just got home from Megamall today. I was with my officemate and we were surprised to see a lot of people wearing unusual clothes.. They were wearing costumes from anime shows. We thought it's just their way to have fun, but looking around the mall, there were a lot of them. It was like an invation of anime characters. My instinct told me that there's an event in SM Megatrade and I was right. We went to Megatrade and we saw that there's a toy convention on going and a mass of cosplayers are there. Sadly only a 3-4 cosplayers impressed me. The rest were "nice try".. I guess I was exposed to cosplayers in Japan and in other 1st world countries. Like the ones here http://www.flickr.com/search/?q=cosplay&w=all

I guess cosplay is young in the Philippines and I sure do hope we have more like this (events) in the future. Hey speaking of cosplay, I have some pics over at my flickr account (link somewhere in this journal hehe..) of cosplayers.. only 2 shots I think.. of young aspiring cosplayers... I admit they're good cosplayers for their young ages.

Till here..

Rabby

AKO mismo is about YOU… … making a stand and taking real action for the causes you believe in.

It's been a while since my last post. Why? because of work. It's been a roller coaster ride for a month now. We're handling tasks that is over the capacity of people working on the floor. I really don't know how did it became so chaotic at the office. I've been seeing lots of software bugs lately due to I guess the pressures of deadline. Hey us software QA's miss a lots of stuff too because they want results pronto. I myself has been restless for 2 straight weeks now. It's amazing I'm not sick at all. Although I already feel the fatigue, both physically and mentally.

I want to take a vacation, go to a spa or something, somewhere relaxing. I want to unwind. But I don't have the financial capability :( sad huh..? I work my @$$ off and still don't have enough left for my personal enjoyment. But there's something I am earning right now which nobody can take, and that's experience. YES experiencing the worse case and bad scenarios at the office and how people are resolving them teaches me, so that when-ever the same scenario comes to me, whether in the same company or in the future company I will be working to, I have the experience and knowledge on how to resolve them.

I had to give up my weekend because there's tons of stuff to do. It's better to finish them now than stress myself rushing to finish the documents later. I had to do it because I wasn't able to do it at the office the previous week coz the uncertainty of the things to be released next week. The constant change of the project schedules makes planning a week before impossible as of the moment.

So there you know what's up with me. (If ever you're asking/wondering)

Till next time, I hope the next blog about work is good news............


God Bless us ALL!!

-Rabby

by Sulit.com.ph (revx)

What do the words tester or QA engineer bring to mind? They're those people who think of ways to break the software, right? Isn't QA the team that comes in after the coding is done, to tell the programmers what they did wrong? It doesn't take all that much skill to be a tester; anyone could pound on a keyboard and check whether the software works, right?

Wrong. Think again.

In traditional projects, requirements are defined up front, usually by business analysts or product managers. Testers have learned to analyze each requirement—looking for completeness, ambiguity, correctness, and much more—so that they can write detailed test cases. However, development teams using this type of phased and gated methodology often tie the testers' hands, giving them no way to get requirements changed if they find contradictions or unclear specifications. By contrast, testers on agile teams get the opportunity to accommodate and embrace change. By observing how testers contribute value on agile projects, we can see how agile testing principles and practices may be applied, regardless of the development methodology being used. The key is making testers full partners with developers, giving them access to business experts, and involving them from the very beginning of each project.

Undervalued and Unappreciated

Testers often aren't used to their full potential. Their skill sets are underestimated and overlooked. Many testers have abilities, experience, and aptitude that make them useful throughout the software lifecycle. In agile projects, where testers have the opportunity to add value from the very beginning of the project, the many ways in which the testers contribute have become obvious. However, there's no reason that testers can't provide more value on any development team, regardless of the methodology used.

Testers have suffered a bad reputation over the years. Too many people fail to value testing, seeing testers as people who couldn't succeed as programmers, or unskilled workers who just bang away at the keyboard. As a result, testers are often paid less than programmers of equal experience and skill. What talented professional wants to work in an unappreciated job, for low pay? This attitude toward testers can become a self-fulfilling prophecy.

It's time for everyone to start seeing testers in a new light. By testing, we mean more than the traditional QA role. We don't mean just testing the end product. We also mean working closely with customers to clarify their needs, enhancing requirements with concrete examples of desired system behavior, challenging the status quo, acting as information providers to give feedback to the team throughout the development lifecycle, as well as helping the team with continual process improvement. Testers lead by example, focusing on business value. They encourage the team to adopt values and principles that promote quality.
 

The True Value of Testing

A skilled tester makes the effort to understand the customers' requirements fully; only then does he or she know how to work with the development team to make sure that those requirements are met. If your developers consistently delivered the right functionality at the right time, how much value would your business gain? If more software defects were found and fixed during development, rather than leaking out to production, how much money would your business save?

Testers can apply their strong analytical skills during planning sessions, asking questions about each piece of functionality. These questions often reveal hidden assumptions. Because testers work with the whole product and have a "big picture" view, they can look at impacts that a user story or feature might have on the rest of the system. Testers test the requirements—understanding what the business really wants, and looking for defects before they happen. Their questions prevent future misunderstandings and wasted resources. Their ability to clarify requirements helps the team make better implementation decisions. They help developers think about testability, focus on simplicity, and facilitate test automation with well-designed code.

At this point you might be thinking, "But we have analysts who write requirements." It's true that analysts make important contributions in understanding business needs. However, like the business experts themselves, your analysts may not know how to express those needs in a way that helps programmers to produce the right code. Because testers usually understand the technical aspects of implementing a new software feature, and know how to express business needs in terms of clear examples and tests, they're able to contribute better guidance for the developers than the analysts could provide.

Programmers know what code to write when they have examples illustrating the necessary functionality. These examples may start out as whiteboard drawings, spreadsheets, or paper prototypes. Testers know how to turn those examples into high-level acceptance tests. All of a sudden, we now know when a user story (or requirement) is done—at least for the happy path. Customers may know what they want, but too often they don't know how to express this information meaningfully. Testers can help customers to create acceptance tests that define the minimum quality criteria for each requirement.

Once testers take a user story or set of requirements and start to create more details around what they want to test, they can flesh out variations in time to identify changes or new requirements. A good exploratory tester challenges shared assumptions and finds issues that weren't even considered during planning or coding. When testers are treated as equal members of the team, they can bring up issues early, when it's still possible to make changes in the code

Whole-Team Commitment

Technical skills for the tester are often mis-defined as programming skills. Understanding programming terminology and basic programming skills will help any tester to communicate with the programmers. However, it's not absolutely necessary to know how to code, as long as the whole team is committed to completing all testing activities for each new piece of functionality. An open-minded attitude and a willingness to learn are the main skills that testers need to be productive development team members. With some training, and with time and support from the entire development team, any tester with the right attitude will learn the necessary practices and principles to keep the project on track.

What do we mean by this "whole team" commitment? Testers work with programmers to turn their test ideas into automated tests that become part of the regression test suite. The whole team becomes responsible for keeping the test suite "running green"; that is, keeping the tests passing. The regression suite (including all unit and functional tests) allows the team to refactor continually to keep the code clean and to minimize technical debt. Testers contribute their specialized skills for developing robust test cases, but the entire team gets involved with designing testable code, automating and executing tests. A team commitment to principles, values, and practices that promote quality will result in well-designed code and keep maintenance costs low. Good test coverage means that changes are easier and faster to implement.

Multiple Roles

Testers on any project—not just agile projects—can work with programmers and test new pieces of functionality as soon as those pieces become available. Pair testing with a programmer can be a shared learning experience. Testers work closely with programmers to understand some of the risks and complexity of each feature. By reviewing unit tests and their functionality with testers, programmers learn to write more effective unit tests that support stronger code design. In turn, testers learn what has been already tested, allowing them to concentrate on higher-level business-facing tests. This approach prevents duplicated effort and increases the team's efficiency.

Another role in which testers excel is that of information provider. On traditional projects, testers have learned how to look at test results and present the information to the stakeholders in an understandable format. When testers are treated as equal partners in the software development team, the testers can expand this skill to give continual feedback to the whole team—not just the project manager.

Project managers are generally the folks who report team progress to the stakeholders outside the project team. They rely heavily on metrics in order to tell them the story. This is another area where testers provide useful information. They're expert at producing feedback that gives everyone on both the technical and business teams a full picture of project progress. For example, testers can produce charts showing how many tests are written, how many are being executed, and how many are passing.

Collaboration comes naturally to testers, as they've always worked together to make sure that the product has been tested end to end. Let the testers expand this skill to include collaboration with programmers, customers, and the rest of the team. Collaboration is a skill worth sharing, and testers are in a great position to help teams learn. Of course, the whole development team collaborates with customers, but testers often spend the most time with them, helping customers learn how to write acceptance tests and understand the possibilities.

Time for a Change

Are you utilizing testers at their full potential, taking advantage of all the resources they have to offer? Start thinking about the additional activities they could perform. Where are you feeling the most software-related pain? Are your stakeholders unhappy that they aren't getting the functionality they wanted? Are deadlines missed because of last-minute corrections? Software professionals with good testing skills can help to address problems like these.

If your testers or QA professionals aren't actively participating throughout each project lifecycle, it's time to get them involved. If your testers lack the skills we've discussed here, but they're passionate about their work, enjoy collaborating, and are eager to grow professionally, give them time to learn, and provide them with training support. Get testers and programmers together, so testers can help programmers learn to love testing, and programmers can help testers to enhance their technical abilities. Leveraging the skills of your testing professionals will maximize the potential of the entire software development team. Discover the many valuable resources hidden in your QA team.

From: http://www.informit.com/articles/article.aspx?p=1322400