This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Please note – This discussion is about an Open Beta
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.
Performance is based on measurements and projections using standard IBM benchmarksin a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
Mobile Quality automation fundamental to a DevOps LifecycleContinuously deliver high-quality mobile applications (HTML5, hybrid and native) and support multiple
mobile operating environments and devices with the simplicity of a single, shared code base
Systems ofInteraction
DevOps LifecycleOperations/ProductionDevelopment/TestCustomers Business Owners
Continuous Innovation, Feedback and Improvements
Ec
os
ys
tem
Be
st P
rac
tice
s
Plan and Measure Develop and Test Release and Deploy
Monitor and Optimize
IBM Mobile Quality Assurance
Worklight
Automate and orchestrate the delivery pipeline for IT infrastructure and the mobile app, reducing cycle times to respond faster to feedback
Judge mobile application quality and customer readiness across multiple dimensions, to deliver apps that better meet customer expectations
Just how long does it take to fill out a good bug/crash report? Bug details SHOULD include:•Device maker & model•OS & version•Carrier & connection speed•Battery life & resolution•Repro steps & screenshot
Before MQA:•Manually enter each piece of information•Risk of manual inaccuracy vs time for quality information•Crash detail may require IDE environment to produce (iOS)
•Assertion: 15 minutes per bug/crash report to gather this quality information
User simply shakes their device
1. IBM MQA is activated
2. Bug details are reported in structured manner to RTC
Crashes logged automatically!
Assertion: Estimated time savings nears 15 minutes per bug. Multiply this by how many bugs reported. (i.e. 100 bugs = 25 hours of time saved). This is reporting alone – quality analysis alone is time consuming!
1Tools and Technologies for MobileFirst Developers: http://www.ibm.com/developerworks/mobile/
23
Ways to get started with IBM MobileFirst
Take part in the IBM Mobile Quality Assurance open beta: http://ibm.co/174C6ug
Read the CTO Mobile Frontier Blog: https://www.ibm.com/developerworks/community/blogs/mobileblog
Our Next Session: IBM Mobile Quality Assurance Study Group Session 3: Connecting mobile app end-users and the developer environment, Nov 8, 2013 9:00AMhttps://events.na.collabserv.com/register.php?id=b6855e07bb&l=en-US
Further Study: Mobile Learning Circle (coming soon)Mobile Testing Product Usage Learning Roadmap (coming soon)