Episode 03 of This Is the QA Podcast is live! The Nerdery’s quality assurance podcast is written, produced and recorded by our acclaimed quality assurance team each month. Did you miss our first two episodes? Listen here.
Episode 02 of This Is the QA Podcast is here! The Nerdery’s quality assurance podcast is written, produced and recorded by our acclaimed QA team each month. Did you miss Episode 01? Listen here.
We’re excited to announce the debut of This Is the QA Podcast — the premier Quality Assurance podcast — written, produced and recorded by The Nerdery’s acclaimed QA team each month.
Continue reading This Is the QA Podcast: Episode 01
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.
“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.”
It’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
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.
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.
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
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.
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.
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.