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.”
How do test professionals deal with developers who insist there are no defects in their code? I talked about this with a test professional I met at the STARWEST Conference in Anaheim last week. This situation has come up so often for her that she has figured out some good ways to work around it. Here is her advice for other test professionals struggling to get things right with devs who give them a hard time.
• Don’t get mad. It’s important to work effectively with developers otherwise you are hurting yourself. Devs don’t like it when you find a bug and they sometimes take it personally. Don’t retaliate by taking it personally, too.
• Don’t use the word “defect.” One developer told me he hates that word because it sounds so harsh. So we just decided to call them something else – we came up with word “bunnies.”
• Document the problem. Years ago I worked with a developer who always came back to me with “cannot reproduce” no matter what I found. When this happens, stay calm and document the problem in whatever tool you’re using in great detail. It’s was hard for her to refute the evidence.
• Get to know the devs you work with on a personal level. If you make an effort, you can always find some way to get along. We are all human beings. We are all on the same team.
by Jennifer Lent
Courage may be an unlikely topic to come up at a testing conference. But in a Lightning Strikes the Keynotes session at STARWEST, Bob Galen, of RGalen Consulting, talked about the ways in which courage should guide the work of test professionals.
- The courage to try new things. You might fail, but go for it anyway.
- The courage to slow down. Experiment with a different approach to a test project. It will slow you down in the short run but it might be more efficient for the long haul.
- The courage to listen to your customer. Be willing to make changes.
- The courage to engage in reality during retrospectives. Tell the truth – not want people want to hear.
- The courage to challenge silo thinking. Encourage “swarming” around tasks instead of going it alone.
- The courage to apply craftsmanship to everything you do.
- The courage to push back on leadership and negotiate. Under what conditions would you say no to a project?
- The courage to give yourself a break. Take some slack time to think.
- The courage to be totally transparent.
- The courage to change. Don’t be stuck in your ways.
- The courage to build quality into your work.
- The courage to trust your team, trust your leaders, trust yourself.
- The courage to allow others to shine. Give them the spotlight. It’s not about you.
- The courage to deliver courage in a graceful way so that you are effective. Courage needs grace.
by Jennifer Lent
At a breakfast at the STARWEST 2012 conference I met tester Laurie Lantgen, who works at a financial services firm in Sioux Falls, S.D. I asked her about the most challenging aspects of her job, and here’s what she told me:
“The most difficult situation I have dealt with in my 17 years as a tester was a project so huge, it was virtually unmanageable for one person. In addition to testing the code, I had to work with about a dozen business users the app had been developed for. My project manager wanted me to engage them to do some of the testing with me. In theory, usability testing is important, but this project was nowhere near ready for that. The code still had defects, and new requirements were being written and rewritten all the time. It was tough to get through — I worked a lot of hours. I reached the point where I stopped conducting sessions with the users and went back to working on my own. I told my manager that this is what I had to do. I mean, I’m the one who finds all the weird stuff.”
Lantgen finished the project successfully. But her story brings home some of the points Johanna Rothman made in her keynote address yesterday Becoming a Kick-*** Test Manager. Test managers shouldn’t put their people in unmanageable situations and they shouldn’t turn a blind eye when a project isn’t going well. Laurie Lantgen was savvy enough to find her own way out. But lots of people aren’t capable of doing that.
For more on Johanna Rothman’s keynote, see: Advice for test managers: How to develop, coach and lead your team
by Jennifer Lent
Frank Kim opened his STARWEST Conference session Security Testing: Think Like an Attacker by asking attendees how many of them were familiar with the concept of a cross-site scripting error. Virtually every hand in the room of 60 to 70 test professionals shot up. But when he asked how many had actually come across this security vulnerability during the testing process, only a handful said they had.
Kim, who is a curriculum lead for computer security training organization the SANS Institute, wasn’t surprised by the response. “Testers think about functionality. They focus on what an application should do,” he said. But hackers concentrate on getting an app to behave in ways that weren’t intended. These days, testers need to assume the hacker mindset as well, said Kim, founder of software security consultancy ThinkSec. “Make one big assumption,” he told attendees, “everyone using your website is evil.”
In the session, Kim demonstrated how a hacker uses cross-site scripting, SQL injections and cross-site request forgeries to steal user names and passwords, and even get an online bank customer to unknowingly transfer money of her account into the hacker’s. It was powerful to watch the demonstration, to see the actual code the hacker was sending to the application, and the data he was pulling out. One attendee asked whether virus protection software prevents these kinds of errors. Kim said no.
Kim noted the widespread availability of application security tools – open source and commercial – designed to scan code and flag these vulnerabilities. He likes the tools well enough, but he said when introducing people to the concept, it’s more effective to give a live demonstration of how a hacker works. “It easy for software and test professionals to dismiss the results from the tools.”
For me, this was one of most interesting sessions at the conference. And it raises a bunch of questions. Will application security testing become a key process for test organizations? Will it move into the mainstream? How do we make that happen? I am interested to see how this all shakes out.