When Does A QA Begin QA?

July 22, 2015

On Saturday, Aug. 1, I'll be speaking at SQLSaturday Baton Rouge on "What is Quality Assurance? What is the business value of Quality Assurance?" (Side note: If you're looking for a great professional development event, I encourage you to attend! It's free and has more than 40 sessions for executives, IT managers and for everyone in IT). This topic, in general, is becoming much more popular as more customers are trying to understand what QA is and where does it fit in with IT projects.

 

So, "When Does a QA Begin QA?" Throughout my Quality Analyst career, I've always found it easier to be on a project when it first begins.  Starting early more than outweighs a QA's effectiveness vs. being injected into a project near the end of development. Why?

Cons of QA being introduced late into the Software Development Lifecycle (SDLC):

  1. Knowledge transfer takes an inordinate amount of time.  The longer it takes to convey information, the slower the overall development-testing process takes. Being put on a project mid-to-late causes more questions than would arise if put on the team early due to lack of specifics in one location or another.  It's like an interrogation game from QA to developers or QA to the Business Analyst/Project Manager to identify the scope of work.  
    1. Cycling people on and off of projects causes confusion and knowledge dependencies too.  It's best to keep the same teams, if possible, to also avoid project delays.
  2. QA will likely not know the team before hand and getting to know the team, client expectations and overall project can take time. Sometimes there is a language gap between a QA (team) and a Development (team).  Team members, involved early in a project (like developers and PM) may not transfer knowledge appropriately to the QA (team), causing testing delays.  Having a good and cohesive team is always helpful for a productive group to help make processes be more seamless. 
    1. For more about the language gap between QA and Dev, please check out my post about defining the word "Done" early during a project
      https://spot.sparkhound.com/kms/blog/Lists/Posts/Post.aspx?ID=284
  1. When brought in, at the end of a project (Testing Phase), there will not be enough time to fix all of the bugs deemed important by QA.  Bug Severity 1's and 2's will be the highest priority.  I've seen far too many bug severity 3's not get corrected due to set project go-live dates, creating a less than desired user experience.
    1. Example Severity 3 Bug:
      1. User accesses a page in an application that has required fields
      2. User skips the first required field while reviewing the entire page form
      3. User, then, fills in all remaining required fields
      4. User goes back to the top of the page to fill in the first required field, after having entered all valid data for the latter fields
      5. All originally entered fields vanish because first field completed last
        1. This bug isn't a crash or a hang, but it would be extremely aggravating to an end user.
  2. The overall quality of the application has an extremely high risk of not being as easy to learn or user-friendly as it could be just having been built based on the requirements/design alone.
  3. Core functionality bugs are usually harder to find simply because so much code has been stacked on top of them, digging deeply enough to find it can be difficult.  If QA is involved early in the SDLC, core functionality bugs are extremely less likely are extremely less likely to occur.
    Example:
    1. Imagine a delete function that is supposed to remove all required data and allow the user to "clear" a page and start over.
    2. Now, imagine there are dozens of pages that have different sets of required fields depending on what type of page you're viewing.
    3. After testing for weeks, QA finally discovers there is a specific type of page that has a single required field that does not delete correctly. 
    4. This bug may be skipped entirely OR it could fixed by developers and must be re-tested by QA.
  4. Sometimes, QA is blamed for missing something or hearing "Didn't you see this…" Like anyone not involved in a project/initiative kick-off meeting, if the QA isn't involved in the development planning kick-off, communication of outcomes and deliverables get watered down and sometimes lost all together.  
  5. Bugs, found by the client or customer that uses the application after the application is live, can be up-to 100x more expensive to fix than if caught earlier during the development life cycle. Please visit here for more information about this. http://www.isixsigma.com/industries/software-it/defect-prevention-reducing-costs-and-enhancing-quality/
  6. A company's reputation for producing quality applications can suffer.

    Pros of using QA early in the Software Development Lifecycle (SDLC) 

QA needs to be part of the team from the beginning – with one goal in mind: exceed customer expectations, deliver the project on time, and present them with an awesome application.

  1. QA can help research during the planning phase of production (the very first phase in the SDLC).
    1. During Planning, QA can help look into market trends to help assist in the design plans or QA can assess the competition to see where our company can beat the competition (cheaper, faster, better mentality)
    2. QA can assist in planning for the future's market if the project lends itself to that type of group. (i.e., beta testing the newest PC operating system to get prepared for the next-big Windows phone update)
  2. QA can analyze the design documentation and find bugs before code is written.  This results in less development risk and helps lower project costs vs. fixing bugs after code is written.
    1. Under the Waterfall Method QA can scrutinize and assess the entire design.  Once all concerns are remedied, then the design is signed-off by QA then Coding can begin.
    2. In an Agile methodology, there is most likely no design.  Instead, there are requirements, user stories and/or backlog items.  QA helps the team in writing and understanding user stories, requirements and/or backlog items so the transition from written-to-tested is a much more seamless process.  The fewer questions QA or the team has in regards to the requirements, the quicker and more effective QA can be.
  3. There is time to plan ahead on each milestone (Waterfall Method) or sprint (Agile Method).
    1. In the Agile Method, QA needs to begin at Sprint – 0. This is the planning, prioritization and User Story/Product Backlog setup stage. 
  4. There is more time to write test cases with test plans per milestone. 
    1. In the Waterfall methodology, test cases are written to show proof of what was covered to ensure product quality.  Test plans show what is to be tested for that milestone and possibly a timeline on when certain aspects will be tested by given the time frame of the milestone.
      1. If there is no time to write test cases, then it's harder to keep track of what was tested, who tested it, and what areas of the application have the least amount of testing done.
    2. In the Agile methodology, test cases aren't a necessary need in order to make the application of high-quality.  Quality comes from the entire team, not just QA; so the whole team tests the app.
  5. There is more time to fix less-severe bugs, ensuring higher quality and less risk for the overall application.
    1. Typically (optimistically), more severe issues are found earlier in the SDLC than later and the less severe are found further into the life cycle of the application.
  6. The company looks more credible being able to provide good quality products and will likely get more business from the customer or client we worked with.  Involving QA early can make your company appear strong by assuring the client/customer from the beginning that QA professionals are involved with their product.  Introducing the Quality Analyst to the client can also give the client more of a peice of mind knowing who's going to be keeping their investment stable, safe, and usable.
  7. Knowledge transfer is almost not even necessary from person-to-person if the same team stays together throughout the lifecycle of the project. 
  8. QA is able to help triage the bugs that are leftover prior to the release to inform the Project Manager what really needs to be fixed vs. what isn't mandatory (lower risk issues).

Overall, initiating QA earlier in the development life cycle of a project reduces your business risk and increases the value of your application investment. In addition, the application will be more user-friendly, require less short-term upgrades (version 1.2, 1.3…) and be a product your development team is excited to  present a client, end user or customer.

 

 

Interested in learning more about QA? Register to attend SQLSaturday BR on Saturday, Aug. 1. You can stop by our Sparkhound booth or attend my 60 minute session. Or just give us a shout by filling out our Contact Us form on Sparkhound.com. I'll be speaking at 12:15pm.  If you're interested in learning more about SQLSat, please visit:
http://sparkhound.com/Pages/SQLSaturday-BatonRouge.aspx

 

Information and material in our blog posts are provided "as is" with no warranties either expressed or implied. Each post is an individual expression of our Sparkies. Should you identify any such content that is harmful, malicious, sensitive or unnecessary, please contact marketing@sparkhound.com.

Meet Sparkhound

Review our capabilities and services, meet the leadership team, see our valued partnerships, and read about the hardware we've earned.

Learn How We Work

See how our Plan/Build/Run methodology drives real client success, and gain our team's perspectives on timely tech topics.

Engage With Us

Get in touch any of our offices, or checkout our open career positions and consider joining Sparkhound's dynamic team.