Making the Most of Your Quality Assurance (QA) Budget

One of the biggest constraints when setting out on a custom software development project is the budget. A project’s budget will ultimately determine how many hours your project team can work on the software, and the scope of the software’s features.

What many people don’t realize is that seemingly small decisions can have a huge impact on your project budget – and Quality Assurance (QA) is one area where this is especially true. So what do you do when you have a limited QA budget but want to keep your project on track?

Here are three things to consider when trying to maximize the impact of your QA budget.

Continue reading Making the Most of Your Quality Assurance (QA) Budget

What Owners Need to Know Before Rebuilding a Website or App

“The pressure is on and you need to decide whether you can move forward with [your current software] or if it’s more efficient to start over.”

bad-app-reviewsIt’s never fun to spend money and get less than you expected. Consider a business owner with a website or app that either needs emergency updates or long-due feature enhancements. Perhaps it was built without much concern for scalability or future feature-needs. Maybe its developer moved to Timbuktu before completion. Or worse, the app was live and users were peppering the App Store with 1 star reviews. Whatever the reason, the business owners and stakeholders are left wondering: “What are my options? How do I evaluate those options? Do I have to start from scratch? Will all my previous effort/time/money just go to waste?” Continue reading What Owners Need to Know Before Rebuilding a Website or App

Your Money is Buying More Than Just Software Testing, It’s Quality Assurance

If we were only concerned with testing software we would need to think of a different name for our Quality Assurance department. There isn’t anybody applying stickers on widgets from an assembly line stamped “Inspected by No. 2177.” We do things a bit differently here at The Nerdery and it’s earned us the respect of our partners by putting the right engineers on the right projects. The investment our partners make on Quality Assurance for their project ensures that they have smart people providing real solutions throughout their projects to save them time, reduce overall effort, and ensure project success.

Continue reading Your Money is Buying More Than Just Software Testing, It’s Quality Assurance

Minimum Viable Product and Quality Assurance

On a perfect project, everything would go exactly as planned. The client would clearly indicate exactly what they want and never change their mind. There would be no complications along the way to interfere with the schedule. My department, Quality Assurance (QA), would receive the completed project on time, all features would be clearly documented and only a handful of edge-case bugs would be found.

Perfect projects don’t exist. Fact of the matter is, regardless of the team’s skill, there’s never a guarantee of success. There may be scope creep, clients may change their minds, development complications may arise, deadlines may be missed and projects may fall behind. There are plenty of counters to all of these – more than I could ever hope to cover here. However, we’re here to talk about how QA’s minimum viable product can help get the project back on track.

Continue reading Minimum Viable Product and Quality Assurance

In an ocean of browsers and gadgets, support standards for web & mobile platforms are ephemeral

Programming, interactive media, and the web have come a long, long way. It’s humbling to realize nine years have passed since the Arduino introduced an affordable microcontroller to the public, or seven years since the original iPhone redefined our expectations of what a cell phone can be.

2014…another year of the internet, social media, home automation, video games, wearable tech, smart TVs, and multiple ecosystems of mobile applications running on a growing variety of phones and tablets. Maybe you’re developing an app or website or you know you need one…In an ocean of computers, browsers, and gadgets, how do you choose what to support? Support means testing and there’s simply too many options to test on every single phone, tablet, and browser.

Whether it be a website, native mobile application or web app, the environment you support defines the reach and intent of your presence online. Choosing the right platforms to support demonstrates a strong product vision, general technological awareness and long-term plan for the work. So, what is the right direction to aim? Continue reading In an ocean of browsers and gadgets, support standards for web & mobile platforms are ephemeral

Webinar: Mastering Interactive Development Lingo

Due to unfamiliar and sometimes confusing  language, interactive projects can end up costing more or take longer to complete than they were supposed to. One of the primary contributors to project delay is a result of what we like to call the “Miscommunication Tax.” In this webinar we took the opportunity to talk through some of the lingo that consistently lends itself to miscommunications during a development project. If you are selling interactive projects, working on interactive projects, or would like to hear what a user experience designer, a developer, and quality assurance engineer have to say about confusing terms and how to create clarity around them, you’ll want to tune in.

Bonus Content:

QA Myths: “I don’t need to test because QA will catch it.”

Having a dedicated group of testers can be an invaluable resource when you’re a developer. But having testers (or maybe even a full-blown quality assurance department) doesn’t mean that a developer should avoid executing tests. Developers should understand how to most effectively use their own time, as well as the time of the testers.

Unit tests are useful and so are “sanity checks”

There are plenty of other people discussing how – from a developer perspective – unit testing is as important as “going to the gym” so I won’t belabour the point. But as a quality assurance (QA) professional I have experienced a marked difference between code that has extensive unit tests and code that does not. That said, I’ve also noticed improved quality amongst developers that do functional sanity checks. These checks became such a good indication of a project’s readiness for QA that we instituted a series of quality gateways here at The Nerdery to encourage this behavior.

So, what’s a “functional sanity check?” Short answer: Use your application/code/system as if you were a user. This can be as simple as loading up a website in Internet Explorer 8 to see if it looks remotely close to the way it does in Chrome. This could also be a meeting of the development team where someone drives through the application and everyone else has the chance to catch, triage, and assign defects as the team discovers them. Performing the most basic functional integration tests eliminates the easy-to-find issues.

“Why bother?”

As a project prepares to enter its QA phase, I’ve heard some developers say “why should I bother finding all these tickets when QA is just going to test everything?” This attitude is dangerous because at first blush it seems to make sense. No one wants to duplicate effort or make a project drag on longer than necessary. But in reality, projects are neither faster nor cheaper when all test activities are left to QA.

I’ve seen these projects slow to a crawl in their QA cycle. Their issue databases become quickly bloated with issues that are low-hanging fruit and – with the deadline quickly approaching – the time that could have been spent on final polish is instead spent on making sure the whole project doesn’t fall apart. The team inevitably faces the unenviable choice of either prolonging development to add polish, or “finishing” the project without a full QA cycle.

From a QA Engineer’s perspective, these projects are a source of frustration. Spending your days writing defect tickets for “Site does not load in Chrome” or “User cannot login” or “Order form does not validate submissions” is like being a home inspector and being asked to sign off on a house that has no walls and is on fire.

Let’s all do what we do best

On the opposite end of the spectrum, projects that have passed all of our internal quality gateways and were built by developers that are passionate about quality tend to breeze through their QA cycle. They hit their deadlines and satisfy clients and users. These successes are the result of developer/QA partnerships where both groups can leverage their unique strengths.

In this scenario, developers have helped mop up the obvious issues by performing unit tests during development and basic sanity tests as integration occurs. From there, QA Engineers can focus on helping the development team double-check each and every requirement in each and every environment, and test the boundaries of the application. Good QA Engineers will vigorously push the application in ways the developers didn’t consider. And that is where the partnership flourishes.

Developers, remember, are focused on making the application work. That’s their job. And so, they are the most likely people to see their code work. In counterpoint, QA Engineers are focused on verifying that the application works. That may seem a small difference, but it’s why QA Engineers are good at finding unexpected variations and results outside the “happy path” that developers have worked hard to create.

This push and pull is invaluable to developing high-quality software but is only possible when QA Engineers are forced to be creative. And they can’t be creative if all their time is spent documenting “fish in a barrel” defects. When a developer has tested enough to feel confident that “QA won’t find anything,” a QA Engineer must leverage all her/his testing skills to verify everything works. This translates into a highly motivated and engaged QA Engineer who will work very hard to help a development team meet the goals of the client and/or users.

And thus, instead of QA being a safety net that developers use to avoid testing their own work, QA helps push developers – and their the applications – toward the best possible final result.

You Got Your UX in my QA

UXinQA2There is a fundamental relationship between user experience designers and quality assurance engineers, and I think it’s time to take that relationship to the next level. User Experience (UX) Designers and Quality Assurance (QA) Engineers are both deeply concerned about the user, and everyone wins when they talk to each other early and often.

My QA counterparts and I both want the websites we deliver to be usable. We want choices to be relevant. We want things to work. We want apps to make sense. We don’t want modal windows to prevent completion of integral tasks. In short, UX and QA both want to deliver a product that won’t leave the user cursing the heavens, having to force herself into a Zen-like contemplation of kittens in Christmas sweaters in order to quell the slow-burning rage that threatens to destroy her as she tries to perform simple tasks like transferring money to a savings account, buying tickets to a ballgame, or monitoring a sick parent’s medication schedule. UX designers are the experience architects and QA engineers are the building inspectors of the development lifecycle. UX figures out who we’re building for and why, analyzes user and business requirements, and incorporates it all with stakeholder vision and known constraints.  We then strive to design an experience that does no more and no less than what it needs to be. QA ensures that I, as a UX Designer, don’t make stupid blunders that will undermine my stakeholders’ goals and interfere with my users’ experience when all is said and done. Do developers help with this, too? Of course. And perhaps unsurprisingly, I also advocate for early and regular consultation between UX and development. But the type of value that QA can bring to a project when consulted early on goes beyond the type of specialized guidance and knowledge that even developers bring to the table.

To illustrate — if I’m designing a deck for my next-door neighbor who just moved his aging parents in, a QA engineer is the inspector that can inform me (before I’ve poured my footings) that even though I wouldn’t know by looking at it, the soil in my area is actually classified as a mixture of clay and sand, which means that diameter of my footings needs to be wider than it would in normal soil. This inspector might also point out that if my neighbor’s aging parents currently use power wheelchairs, or if they might need them in the future, it would be in my best interests to increase the diameter of the footings even further to accommodate the extra weight. And the inspector might lastly point out that with wheelchairs on the deck, I’ll need a ramp, and that the ramp ought to have a slope no greater than 9.5 degrees.

The most obvious software development analogue to that example is accessibility. Call it ADA compliance, 508 compliance or what have you; the point is that there are standards that you’re almost certainly not aware of for making sure that your application or website is usable for those with disabilities. But a good QA team has engineers that are steeped in those standards, and they know how those standards relate to every device you’ve targeted. Making changes to accommodate accessibility late in the game – or after your site is done – can be very costly, so why not have the conversation early on? Ditto that argument for data and application security. And ditto that argument for just plain old usability. Bring QA in for a quick consultation on your wireframes, and chances are you’re likely to save yourself some revisions.

As a designer, is it my job to think through use cases? Yes. Am I good at it? Yes. Am I able to consider every contingency of every scenario my project entails and implies? No. This is why a strong relationship between UX and QA is indispensable. UX Designers and QA Engineers have a similar mandate, but they fulfill it with different toolkits and from different perspectives. As one of my friends in QA puts it, “UX creates and QA destroys.” But we both do it for the same reason — we respect and love the user. QA engineers bring their extensive experience with devices, platforms, browsers, protocols and standards to bear on every project they touch. They are the brilliant generalists that throw our researched, prototyped, revised, and user-tested designs into the fiery furnace of the real world to see what burns and what doesn’t. Loop them in earlier, and you can avoid putting out fires later. So what does this collaboration look like? Here at The Nerdery we offer Embedded QA, in which QA is along for the entire ride on a project. We’ve seen tremendous success with this approach, but it carries some additional cost. The type of collaboration I’m talking about can be much leaner. It can be a conversation, or maybe two hours with an accessibility expert before you get into visual design to make sure your navigation scheme and color palette won’t set off red flags down the road. Build strong relationships up front with the folks that are responsible for signing off on your project down the road, and you’re guaranteed to save yourself time and headaches.






NerdCast #86: Making the Case for UX and QA Partnerships

In this episode of the NerdCast we discuss the crazy notion to bring Quality Assurance engineers into the usability testing process.  It’s not that much of a crazy notion the more Christopher Stephan and QA Engineer Alex Hofer talk throughout this discussion about bridging the gap between these two project activities concerned with quality control.

Host: Ryan Carlson

Guests: Christopher Stephan (UX) and Alex Hofer (QA)

Listen Now: Running Time: 0:22:11 / Subscribe on iTunes

Play

NerdCast #85: Targeted Cyber Crime – Discussing BlackPOS

On this episode of the NerdCast we interview security experts Chris Wade and Jason Herbst from the Nerdery QA team. We look at the malware that was used to target high profile retail companies in a massive case of stolen data. The software called BlackPOS is a brilliant piece of software and in another context is genius in its design. Hear more about how the malware works, what it can reportedly do based on security research firms, and what Jason and Chris think of our current state of security.

Host: Ryan Carlson (Tech Evangelist)

Guests: Chris Wade and Jason Herbst (QA Department)

Listen Now: Running Time: 0:23:13 / Subscribe on iTunes

Play