I have known several SWET's over the years who really hate using xpath as element locators for looking up elements on web pages while using Selenium, and now for testing mobile applications we use Appium.
I have never really understood the hatred. I love XPath and use it instead of CSS for finding elements in web pages and mobile applications.
Using XPath is only as powerful as the tools that can translate it correctly and actually have tools that tell you what the xpath locator string is.
For mobile applications, Appium Inspector tool will give you the xpath locator to interact with UI elements.
For web applications, use FireBug as usually those xpath indicators work with Selenium.
And that's it. That is all you need to be the world's greatest, and most efficient automation test developer.
Use Xpath and prosper :)
Wednesday, November 27, 2013
Saturday, November 23, 2013
Be careful not to let personal relationships at work jeopardize product quality
I have seen personal/friendly relationships at work between QA and development, product management teams hurt product quality. How? The QA team members cover up any product quality risks for fear of damaging a work relationship.
The reason is that these relationships may, at times, introduce compromise and risk of product features and as a QA person.
Your responsibility is to the product and customer experience, not to make friends or protect future job references.
Be careful to manage your rapport with co-workers because, as a QA professional, you must ALWAYS represent the customer and expose and risk (process, design, etc) that has potential to be negative in any way.
The reason is that these relationships may, at times, introduce compromise and risk of product features and as a QA person.
Your responsibility is to the product and customer experience, not to make friends or protect future job references.
Be careful to manage your rapport with co-workers because, as a QA professional, you must ALWAYS represent the customer and expose and risk (process, design, etc) that has potential to be negative in any way.
Thursday, November 21, 2013
RIP Winamp
I just heard today that Winamp is going to shutdown.
That really sucks.
I think almost everyone I know first played ripped mp3's from their CD's (or pirated from Napster) using Winamp in 1999. I even made a few skins and published them and even got them rated by other users.
What a great, innovative product from Web 1.0. Probably the best one.
http://www.winamp.com/
Thanks to everyone that has ever been involved with this awesome product!
That really sucks.
I think almost everyone I know first played ripped mp3's from their CD's (or pirated from Napster) using Winamp in 1999. I even made a few skins and published them and even got them rated by other users.
What a great, innovative product from Web 1.0. Probably the best one.
http://www.winamp.com/
Thanks to everyone that has ever been involved with this awesome product!
Wednesday, October 30, 2013
iOS Mavericks and XCode 5.0.1 was Apple showing arrogance and dominance in the mobile app market
I am still amazed at how Apple has showed complete arrogance and disregard for it's developer base by releasing XCode 5.0.1 and Mavericks just a few weeks after iOS7/XCode 5.0 initial release with several major changes in the OS and testing/development tools that are not close to working the same way as with the previous release.
Apple should have just waited (and not released 3 weeks ago) and called last week's OS upgrade Mavericks 7.0 and XCode 5.0, because iOS 7.0.2 and XCode 5.0.1 are a lot different (especially the way Instruments and Authorization internally works) than would be expected in a "dot" or "point" release, which is usually slated for unseen bugs or security fixes which do not require disruption to the previous upgrade.
Apple must have calculated the disruption that happened earlier this week and basically said: we don't care, because we are Apple, and you have to react to whatever we decide is going to happen.
It is clear that this was a message from Apple to it's development community: mobile is where most of the new product development is happening and we own this space, and you will do what we say and we will let you know information when we want to, and you will just have to scramble and deal with the consequences.
It was either disorganization or total arrogance, but I doubt it was the former. Apple is too smart for that.
I offer my never-ending Thanks and Appreciation to all of the 3rd party testing and development products that have to deal with Apple's arrogance in order to assist their respective communities in supporting the development of excellent and innovative products that help to sell iPhones and iPads because user want/need that app.
Ironic.
Apple should have just waited (and not released 3 weeks ago) and called last week's OS upgrade Mavericks 7.0 and XCode 5.0, because iOS 7.0.2 and XCode 5.0.1 are a lot different (especially the way Instruments and Authorization internally works) than would be expected in a "dot" or "point" release, which is usually slated for unseen bugs or security fixes which do not require disruption to the previous upgrade.
Apple must have calculated the disruption that happened earlier this week and basically said: we don't care, because we are Apple, and you have to react to whatever we decide is going to happen.
It is clear that this was a message from Apple to it's development community: mobile is where most of the new product development is happening and we own this space, and you will do what we say and we will let you know information when we want to, and you will just have to scramble and deal with the consequences.
It was either disorganization or total arrogance, but I doubt it was the former. Apple is too smart for that.
I offer my never-ending Thanks and Appreciation to all of the 3rd party testing and development products that have to deal with Apple's arrogance in order to assist their respective communities in supporting the development of excellent and innovative products that help to sell iPhones and iPads because user want/need that app.
Ironic.
Tuesday, October 29, 2013
iOS Mavericks is a disaster for test automation developers
iOS 7 first update was disaster for us test automation developers.
Thanks Apple for, yet again, showing us test automation developers and software QA people how little you care about quality and testing of 3rd party apps depending on mobile technology stability.
Appium - broken
Instruments - broken (why ask permissions EVERY SINGLE TIME?)
It's amazing how a single "dot" release disrupted (and not in a positive way) every single test automation framework other than whatever weak, inferior test automation software was attempted in XCode 5.0.1 and Mavericks.
Thanks Apple for, yet again, showing us test automation developers and software QA people how little you care about quality and testing of 3rd party apps depending on mobile technology stability.
Appium - broken
Instruments - broken (why ask permissions EVERY SINGLE TIME?)
It's amazing how a single "dot" release disrupted (and not in a positive way) every single test automation framework other than whatever weak, inferior test automation software was attempted in XCode 5.0.1 and Mavericks.
Saturday, October 19, 2013
Appium - the game changer that mobile application automated testers have been waiting for.
A few months ago, I was introduced to Appium - an amazing mobile application testing tool for software testing professionals that have the incredible burden of being responsible for testing mostly Android and iOS mobile applications.
And I love it.
I think "love" is not an adequate word - It is what all software testing professionals have been waiting for for years: An easy-to-use, robust, powerful, silver bullet that allows me to rapidly create tests for mobile applications on any platform that I used to have to write (for iOS) Objective-C (which is really stupid) and Java activity proxy (which is slow and cumbersome) in the programming language that you choose.
In my case, I love Java. So...... I created an entire automated tests suite for iOS and Android mobile applications using, for the most part, the same codebase - in Java!
Follow this amazing project on twitter at @AppiumDevs. Thanks guys! Finally, someone got it right.
Buh-bye Objective-C. Buh-bye Calabash. We dont need you anymore, but thanks for playing :)
And I love it.
I think "love" is not an adequate word - It is what all software testing professionals have been waiting for for years: An easy-to-use, robust, powerful, silver bullet that allows me to rapidly create tests for mobile applications on any platform that I used to have to write (for iOS) Objective-C (which is really stupid) and Java activity proxy (which is slow and cumbersome) in the programming language that you choose.
In my case, I love Java. So...... I created an entire automated tests suite for iOS and Android mobile applications using, for the most part, the same codebase - in Java!
Follow this amazing project on twitter at @AppiumDevs. Thanks guys! Finally, someone got it right.
Buh-bye Objective-C. Buh-bye Calabash. We dont need you anymore, but thanks for playing :)
Monday, June 17, 2013
Using the Agile Process makes testing activities more difficult, not easier
One the innovative, great processes for reducing risk of achieving any goal, improving the efficiency of work teams, and reducing resource investment when business decisions change, and one being adopted en mass currently amongst companies that develop software is the Agile Process.
I love Agile process and believe it is absolutely the best way to develop software and protect business from over-investment (resources and time) and risk in a dramatically changing business climate.
However, the ideal (and most practiced) Agile sprints last 2 or 3 weeks. 10 - 15 working days. Some companies, especially SAAS companies, deliver the software to the production environment after each sprint. This is really great for the end customer; they get a new update of the product every 2-3 weeks and since the changes are "incremental", it helps reduce the massive changes in software functionality and user experience that used to accompany major software updates (does anyone recall their user experience going from Windows 2000 to Windows XP to Windows Vista or Windows 7 to Windows 8?).
The compressed timeframes, and dependency of the development resources to complete the new functionality or software changes greatly reduce the amount of time for testing activities. Testing resources have no control as to when the software changes get finished and ready to test. In most cases, testers have multiple stories to test in each sprint. This scenario creates testing schedule pressures. New changes must be tested, plus the regression testing.
In most cases, I have experienced that developers will not compete new functionality and be ready for testing into the testing environment until 50-70% of the entire sprint time duration.
This leaves 50-30% of sprint time for testing activities per story. 3 to 5 working days for a 10 day sprint duration possibly for testing each story implementation.
During this time, bugs may or may not be found. If they are, bug reports are created and assigned for fixing. Re-testing must be done for bugs fixed. Regression is run many times over again to verify the product is still working as expected. For large software development tasks, bug finding might be greater in occurrence.
Testing difficulty, and time to test, occurs between white and black box testing. The company needs to be aware of what impact this has on testing it's software in short time durations. Risk varies amongst functional goal to be implemented.
Using the Agile process for software development puts a lot of schedule pressure on the testing time to validate the Acceptance Criteria of the software for each story. This could be between 3-5 days. This is why so many companies (almost every company) are putting testing emphasis on automated testing to assist the team in testing-related activities. It is a wise choice, but the organization needs to realize the stress that the Agile process puts on testing activities and be sure to adequately provide testing resources to ensure acceptance criteria for new stories and successful regression testing is accomplished and all required tests to be run pass.
I love Agile process and believe it is absolutely the best way to develop software and protect business from over-investment (resources and time) and risk in a dramatically changing business climate.
However, the ideal (and most practiced) Agile sprints last 2 or 3 weeks. 10 - 15 working days. Some companies, especially SAAS companies, deliver the software to the production environment after each sprint. This is really great for the end customer; they get a new update of the product every 2-3 weeks and since the changes are "incremental", it helps reduce the massive changes in software functionality and user experience that used to accompany major software updates (does anyone recall their user experience going from Windows 2000 to Windows XP to Windows Vista or Windows 7 to Windows 8?).
The compressed timeframes, and dependency of the development resources to complete the new functionality or software changes greatly reduce the amount of time for testing activities. Testing resources have no control as to when the software changes get finished and ready to test. In most cases, testers have multiple stories to test in each sprint. This scenario creates testing schedule pressures. New changes must be tested, plus the regression testing.
In most cases, I have experienced that developers will not compete new functionality and be ready for testing into the testing environment until 50-70% of the entire sprint time duration.
This leaves 50-30% of sprint time for testing activities per story. 3 to 5 working days for a 10 day sprint duration possibly for testing each story implementation.
During this time, bugs may or may not be found. If they are, bug reports are created and assigned for fixing. Re-testing must be done for bugs fixed. Regression is run many times over again to verify the product is still working as expected. For large software development tasks, bug finding might be greater in occurrence.
Testing difficulty, and time to test, occurs between white and black box testing. The company needs to be aware of what impact this has on testing it's software in short time durations. Risk varies amongst functional goal to be implemented.
Using the Agile process for software development puts a lot of schedule pressure on the testing time to validate the Acceptance Criteria of the software for each story. This could be between 3-5 days. This is why so many companies (almost every company) are putting testing emphasis on automated testing to assist the team in testing-related activities. It is a wise choice, but the organization needs to realize the stress that the Agile process puts on testing activities and be sure to adequately provide testing resources to ensure acceptance criteria for new stories and successful regression testing is accomplished and all required tests to be run pass.
Subscribe to:
Posts (Atom)