A week ago today, I sat in on a really interesting informational workshop. I learned all the basic pieces of building an incredibly simple mobile application. I write a good deal about mobile application development, but as yet, I hadn’t actually done any coding for a mobile app. I still don’t think I’ll stop writing about it and start doing it any time soon, but I do now have a much better appreciation and understanding of the practice of building mobile applications. The demonstration application we built was a simple HTML 5 app designed to run on multiple platforms – iOS, Android, and Windows Phone, for the most part. Continued »
This week it’s a quick wrap-up of recent content on SearchSoftwareQuality.com before I head out for the weekend. Jenn Lent shows us the places where automation falls short of the hype. Jan Stafford shows us a couple of Agile success stories. But first, let’s look at some of the things application security expert Dan Cornell has been up to. Continued »
This week I’m going to bring up a few things I got to see at Agile 2013 in Nashville last week that I should have written up while I was at the conference. These are the extra blog posts I planned last week but didn’t have time for, all rolled into one. I’ll write about Legos, asking questions, and bluegrass music. They all relate to Agile in one way or another.
Automated integration testing sort of presents us with a paradox. The problem is that automated testing makes the most sense for large organizations where there’s a lot of testing to be done; however, these big enterprises tend to have large, complicated development environments where it tends to be hard to build automated tests for integration. So, it’s not quite a catch 22, but it is rather inconvenient that the more an organization needs their integration testing automated, the harder it’s going to be automate it. A growing open source project might have found the trick to cutting the knot – if its name doesn’t get in the way too much. Continued »
It’s been a busy week and I’m itching to start the weekend, so this week’s post is going to be short, but I’ll make up for that with extra blog posts next week. I take off for Nashville in about forty-eight hours. This conference is going to be a real challenge to cover on my own, but it should be a really fun challenge. Plus, I’m looking forward to announcing some news from one of our application security experts. Continued »
My head is spinning this week. The summer seems to be rushing by in a blur. I’m gearing up for Agile2013 in Nashville Tennessee (August 5-9) and I’m torn between wishing I was leaving tonight and wishing I had an extra week to prepare. There’s so much excitement packed into one little week, I don’t know how I’ll keep up with it all. Continued »
I don’t think I’m the only one that gets a little bit turned around sometimes when I’m talking about Agile. It’s tough to quickly state what Agile is and how it affects software development teams on a day-to-day basis. Some teams focus on these aspects, concepts and practices, while others focus on those. Ideally, Agile should be a holistic effort, but I think in real life most companies that are trying an Agile approach are still focused on specific processes and might not see how those processes fit into the big picture.
I mean, I know the Agile manifesto: “People and communication over process and tools; working software over heavy documentation; customers over contracts; and responding to change over sticking to the plan.” Those are all set in my mind and so are the twelve guiding principles in the Agile manifesto. I won’t list all twelve, but I think “break down work into smaller components that can be completed quickly,” and “provide motivated individuals the environment and support they need and trust them to get the job done,” are two good ones.
But – even with a solid picture of what software development teams should be doing, I still get a little confused about how an Agile development team does those things. Continued »
I’ll be updating the blog at least once a week from here on in. You can expect a healthy dose advice and commentary each week as I relate news and tidbits that either didn’t make the cut at SearchSoftwareQuality.com or else just haven’t posted to the site yet. I’ll also keep you up to date on what’s happening here at SearchSoftwareQuality.com from week to week.
The big news right now is that there’s a new site editor in town, namely me –James Denman. Jenn Lent did a great job in her time at the helm and she left us on very good terms. In fact, she’s still writing a regular Quality Time column for us as well as occasional tips and news stories. While we’re sad that we’ll no longer work together every day, we’re still glad to have her as a regular contributor.
Lent’s last column was a real treat. She gave us a solid look at application portfolio management and how to get enterprise applications front and center for business as well as IT. She said too many organizations are lacking a clear view of what applications they have and what they do with them. If you look at building and facilities management, on the other hand, most businesses know exactly how many buildings they own and operate and have a pretty accurate estimate of the buildings’ market value. So the first step in APM, according to Lent and her sources, is to get a handle on what you’re working with, which is just exactly what the APM project management lead at the Port of San Diego recently experienced firsthand.
In other news – or I guess I should say tips – three other great ladies have graced the (web)pages of SearchSoftwareQuality.com with great stories lately. Yvette Francino (another former site editor here) gave us four tips on cloud testing tools focusing on risks and challenges, selecting the right services, choosing public or private clouds, and taking control of the service level agreement (SLA). Project and program management expert and author Johanna Rothman was good enough to lay out ways to stop multitasking and get projects to done. She outlined alternate project management styles including committing to one iteration at a time, committing to one feature at a time, or scheduling time specifically for dealing with interruptions and secondary projects. Last but not least, intrepid journalist Crystal Bedell brought us some easy ways to improve mobile application performance from sources like PerfTestPlus President and CTO Scott Barber.
That’s all I’ve got for this week, but rest assured there is much, much more to come. Until next time, keep leaving things better than you found them.
As the Android marketplace continues to grow at a rapid pace, Android developers face the problem of maintaining software quality while also meeting the time constraints for deployment. Electric Cloud, a DevOps optimization company, recently announced a partnership with mobile testing experts Wind River. This collaboration aims to ease the burden on Android developers by offering a solution that dramatically increases the speed of testing and deployment while upholding high quality standards.
In a recent conversation, Electric Cloud CEO Mike Maciag described how the company’s solutions accelerate the optimization process, and provide a framework to integrate disparate tools, as well as the reporting infrastructure needed to produce a cohesive view of the application.
Vice President of Product Marketing at Wind River, Ido Sarig, explained how Wind River has “reproduced reams and reams of log files that are very difficult to manually parse through. We’ve unified all those inside test management, providing you a single-click, single-point method to run tens of thousands of test cases and then consolidate all the test results and artifacts using a standard format in a single repository.”
Wind River has integrated its testing solutions with the Electric Cloud solution set, creating a seamless flow between development and testing processes. Maciag discussed the advantages of the partnership, explaining how Electric Cloud offers solutions that manage the complexity of the development lifecycle, while Wind River provides a homogeneous output of test data.
“The combination of the automation to deal with the complex matrix and the homogeneity brought by the Wind River test management suite takes a very complex environment, slows it down, makes it very simple and allows the process to move quickly,” Maciag said.
For related stories from SearchSoftwareQuality.com, see:
There is a tendency to want to plow through the requirements phase of an application development project, as in the sooner requirements are set, the sooner the coding, and then testing, can get underway. But the requirements process doesn’t proceed in a linear fashion, and nor should it, says business analyst Laura Brandenburg, founder of Clear Spring Business Analysis. “It’s a funny task. You go through the cycle quite a few times. You get closer and closer, but you’re not really done until you have a baseline spec.”
What makes the process nonlinear is that you are not actually “gathering” requirements—you are eliciting information that helps define an app’s features and functionality, says Brandenburg. Although the term “requirements gathering” still gets a lot of play, it isn’t really accurate, because “gathering” implies that requirements are sitting around fully formed just waiting for someone to pick them up. Elicitation, on the other hand, is a complex process of getting information from stakeholders, interviews, surveys and other sources, then analyzing and validating the information, says Brandenburg.
A good business analyst asks questions of stakeholders, listens actively, clarifies what she hears and works to get alignment among group members. When Brandenburg leads a group, she says things like: “I heard what you said. We have an idea on what we want. Now let’s see if we tear this apart.” This back and forth takes place before you actually write down a single requirement, she says. “When you are ready to write down the requirements, you are working from a shared understanding.”
Her requirements projects typically include business stakeholders and a project manager. As ideas begin to crystallize, Brandenburg brings a developer into the mix as well. Developers are most effective when they are willing to listen and understand the real problem we are trying to solve,” says Brandenburg. “You want to involve them in the creative part of the process. They are engaged, they offer options, helping me and the business understand that more things are possible.”