|
What is the scope and future for Appium testing? I am planning to learn Appium TestNG framework, is it worth to learn ?
|
|
|
Would anybody know a simple way of integrating Zephyr into PowerBi? Bare in mind there is an Api called ZAPI(Zephyr API) The Zephyr Api: https://marketplace.atlassian.com/plugins/com.thed.zephyr.zapi/cloud/installation
Power BI: https://powerbi.microsoft.com/en-us/
Has anyone managed to actually integrate the api into Power BI? and if so how did you do it? The jira rest-api has been integrated but vital information based on test cycles is all missing.
Is there a free alternative to ZAPI to expose that data as well?
Thank you!
|
|
|
We're not Continuous Integration. What are we? I'm trying to figure out the proper terminology for our dev/test procedure.
1. The main master codebase in bitbucket.
2. Developers make their code changes (bug fixes, feature improvements) and create pull requests/feature branches that contain their code commits. They are not saved directly into master (so not CI). Each jira issue generally has one corresponding pull request.
3. QA uses Jenkins to deploy individual (or sometimes multile) pull requests on top of the master to our test environments (each QAer has their own test server). So, we are able test the addition of just one change at a time. We do full functional testing and any regression testing we think might be relevant.
4. After QA approves the change, we merge the pull request into the master. |
|
|
Quality processes in Continuous Integration/Deployment In traditional waterfall and agile processes we implement a test strategy to set expectations (and receive feedback) on approach for a release (multiple sprints of work) and test summary to capture results of the execution (functionl, security, and performance testing).
In a a CI/CD model when we have a 2 week sprint and plan to deploy every 2 weeks it seems a bit cumbersome to do a strategy and summary every 2 weeks. Ideally the summary could be pulled from an automation tool and produced to a dashboard so that should not be too bad.
Is there a different approach to the strategy?
Are there other quality tollgates (maybe a bad choice of words) that we should consider?
From a quality process audit perspective is there anything else to consider?
Any feedack appreciated.
-Jeff
|
|
|
10 Lessons Learned in Cross-Platform Development Building an app for a single platform is difficult, but designing, implementing, and testing an app targeting multiple operating system platforms can be next to impossible. The secret balances upfront design with customer feedback.
|
|
|
Shave Mobile Development Time and Cost with Xamarin
Slideshow
By shaving time and cost to build and maintain your app by half, Xamarin—a free, open source framework offered by Microsoft—can revolutionize your mobile application development. Most app development approaches result in building the app twice—once for iOS and once for Android—or...
|
Dave Todaro
|
|
Is Your Project Doomed from the Start?
Slideshow
When we think of planning, we often think about requirements planning. We get the initial features and functions down, and then see where agile takes us. Lisa Calkins claims that less than a third of software development projects are successful. Regarding this lack of success, process...
|
Lisa Calkins
|
|
Finding Efficiencies in Your Development Lifecycle
Slideshow
Many of us feel like we never have enough time to complete everything we want in a given sprint, cycle, or phase. Even though we can't add more hours to our day, we can add time by removing inefficiencies in our development lifecycle management approach. Melissa Tondi explores a number of...
|
Melissa Tondi
|
|
Test Coverage in the Age of Continuous Delivery Test coverage is a strategy to help us spend scarce testing time on the right priorities. When things were tested last, how much automation coverage we have, how often the customers use the feature, and how critical the feature is to application are all factors to consider. Here are some ideas for keeping quality high when you're transitioning to continuous delivery.
|
|
|
2017 Is a Pivotal Year for DevOps Customers expect real-time software updates. As DevOps becomes the engine for delivering business value, continuous innovation is needed. And this has to begin at the start of every project.
|
|