Work Breakdown Structure (WBS)

Work Breakdown Structure (WBS) is an estimation tool in the project manager's arsenal. Using this method, the project's scope is broken down into manageable tasks by creating a work breakdown structure (WBS). In other words, a WBS is a deliverable-oriented hierarchy of the work that must be performed to accomplish the objectives of and create the deliverables for the project.

The principle behind the WBS is simple - a complex task may be subdivided into smaller tasks until you reach a level where further subdivision is not possible. At this level of subdivision, estimation of time to accomplish the task and cost to do so would be easier than at higher levels.

The WBS decomposes the project work into manageable pieces (work packages) that can be assigned to individuals. This helps define the responsibilities for the team members and is the starting point for building the schedule. Decomposition is a technique for subdividing the project deliverables into smaller, manageable tasks called work packages. The WBS is a hierarchical structure with work packages at the lowest level of each branch. Based on their complexity, different deliverables can have different levels of decomposition. Each component in the WBS hierarchy, including work packages, is assigned a unique identifier called a code of account identifier. These identifiers can then be used in estimating costs, scheduling, and assigning resources.

The WBS covers the entire scope of the project. If a task is not included in the WBS, it will not be done as a part of the project. The WBS is a good way to portray the scope of a project. A question that crops up while creating a WBS is – when do you stop the decomposition ? It is suggested that you stop when you reach a level where you can estimate the time and cost for doing the work at the desired level of accuracy or else the work itself will take the time that is equivalent to the smallest unit of time you intend to schedule.

The WBS links the entire project and portrays scope graphically. It enables resource assignments, estimation of time and cost to be prepared and provides inputs to the schedule and budget planning.

Function Point Analysis overview

-->

One of the more popular software estimation methods is the Function Point Analysis (FPA) method by Allan Albrecht at IBM. Here's a high level overview. FPA helps measure the size of a software application based on the functions expected to be delivered. Measuring size of the software helps us derive other important metrics such as schedule, effort, cost, quality metrics, productivity, etc. The output of FPA is a count expressed in terms of function point (FP). The size measured via FPA is independent of the technology used to develop the software.

A function point is an unit of business functionality delivered through the software being measured. If an application has 100 function points, it denotes that an equivalent number of business functions (100 in this case) are being delivered to the user. The FPA method relies on five operational attributes for sizing any software application – External Inputs (EI), External Output (EO), External Query (EQ), Internal Logic Files (ILF) and External Interface File (EIF). The FPA method defines an additional set of fourteen General System Characteristics (GSC) which in turn defines the complexity of the application being measured.

The International Function Point Users Group (IFPUG) was formed to promote and encourage the effective management of application software development and maintenance activities through the use of Function Point Analysis and other software measurement techniques. IFPUG maintains a standard Function Point Counting Practices Manual (CPM), established FPs as an International Standards Organization (ISO) standard, and offers professional FP certifications.

Steps in performing FPA include -

• Defining the boundary of the application - consists of the internal files and logic, while the five attributes listed earlier which interact with the internal files remain outside the boundary
• Counting the data functions (ILF, EIF) - ILF and EIF are further defined in terms of complexity as Low, Average and High and map to a constant function point count (For ILF, FP counts are 7, 10 and 15 and for EIF, FP counts are 5, 7 and 10 for Low, Average and High respectively). Refer IFPUG tables for complexity levels and to assign point values for each countable function
• Counting the transaction functions (EI, EO, EQ) -as with the data functions, each transaction function may be defined as Low, Average or High complexity and maps to a constant function point count (For EI, FP counts are 3 ,4 and 6; for EO, FP counts are 4, 5 and 7 and for EQ, FP counts are 3, 4 and 6 for Low, Average and High respectively). Refer IFPUG tables for complexity levels and to assign point values for each countable function
• The FP count arrived at from the above two activities (counting data and transaction functions) is called as Unadjusted Function Points (UFP)
• Compute the Value Adjustment Factor (VAF) and apply to the UFP to get the Adjusted Function Points (AFP)
• The GSC, mentioned earlier, represent the technical attributes of the software being measured and may be specified in terms of their degree of impact on a scale of 0 to 5 (0 implying no impact and 5 implying maximum impact)
• The Total Degree of Influence (TDI) is the sum of the impact values for the 14 GSCs. If the TDI = 0 (meaning that all 14 GSCs have no impact), then the VAF is 0.65; if the TDI = 70 (meaning that all 14 GSCs have maximum impact), then the VAF is 1.35. There is a variation of 0.70 between the two extreme VAF values. [VAF = (TDI * 0.01) + 0.65]
• VAF is used to re-calibrate the UFP and compute the final AFP count [AFP = UFP * VAF]

The Test Architect: Strategic Technical Leadership in Quality Engineering

A test architect is not a senior tester with a bigger title. A strong test architect is a strategic technical leader who designs how an organization creates confidence in software change.

Testing careers often split into two visible paths: people leadership and technical leadership. The management path is easy to recognize because organizations already understand managers, reporting lines, budgets, and staffing. The technical path in quality is less consistently defined. That is why the test architect role matters.

A test architect operates at the level where product risk, engineering architecture, automation strategy, delivery process, and production quality intersect. The role is not about owning every test case or approving every release. It is about shaping the quality system so teams can move faster without losing trust.

What A Test Architect Really Owns

The test architect owns the technical integrity of the testing approach across products, platforms, and teams. That includes functional and non-functional quality, testability, automation architecture, test data, environments, observability, release evidence, and continuous improvement.

• Quality strategy: defining how the organization will evaluate risk, confidence, and readiness.
• Test architecture: deciding which risks belong at unit, component, API, contract, integration, UI, exploratory, performance, security, and production-monitoring levels.
• Automation design: building frameworks and standards that produce fast, reliable, maintainable feedback.
• Technical influence: participating in architecture and design reviews to ensure systems are testable, observable, and recoverable.
• Engineering coaching: helping developers, testers, product owners, and leaders understand what quality evidence is needed and why.

The Role Is Not People Management, But It Is Leadership

A test architect may not directly manage people, but the role absolutely requires leadership. Influence without authority is one of the defining challenges. A good architect can guide teams without turning every conversation into a process mandate. They persuade through technical clarity, useful standards, strong examples, and calm risk communication.

The best test architects are credible with developers because they understand design, APIs, data, automation, failure modes, and debugging. They are credible with product leaders because they can translate technical risk into customer and business impact. They are credible with QA teams because they improve the craft rather than merely demand more output.

Skills That Separate A Test Architect From A Senior Tester

• Systems thinking: seeing quality as the result of product decisions, architecture, code, data, environments, pipelines, and production behavior.
• Risk modeling: identifying where failure would hurt users, revenue, compliance, operations, or trust.
• Automation economics: understanding signal, speed, reliability, diagnosis cost, and maintenance cost.
• Non-functional depth: knowing enough about performance, security, accessibility, reliability, and data quality to ask strong questions and shape evidence.
• Communication: explaining quality risk differently to engineers, executives, product owners, and customers.

Where The Test Architect Adds The Most Value

The highest-value work happens before testing becomes a bottleneck. A test architect should be involved when systems are being designed, not only when they are ready to be validated. They should influence API contracts, event schemas, logging, traceability, error handling, test data design, deployment controls, and rollback expectations.

In a modern delivery organization, the test architect also connects pre-release testing with production learning. Test strategy should not end when a release goes live. Observability, service-level objectives, incident analysis, and escaped-defect reviews are all part of the quality feedback loop.

A Practical Operating Model

• Define a product-specific quality model.
• Map risks to the cheapest reliable evidence source.
• Set automation standards that developers and testers both trust.
• Create testability and observability expectations for new architecture.
• Review escaped defects for systemic improvement, not blame.
• Develop QA talent toward deeper technical leadership.

The test architect is one of the most important roles in a mature quality organization. Done well, the role prevents QA from becoming a downstream inspection function and turns quality engineering into a strategic technical capability.

Test Closure: How to End a Test Cycle Without Losing the Learning

Test closure is not just the administrative end of a test cycle. It is the point where the team converts testing activity into release evidence and learning.

A weak closure process says tests are done. A strong closure process explains what was learned, what risk remains, and what should improve next time.

What closure should include

• Scope tested and scope not tested.
• Quality risks covered and risks still open.
• Defect status, severity patterns, and deferred issues.
• Environment, data, and dependency limitations.
• Automation results, exploratory findings, and non-functional evidence.
• Recommendations for release, rollback, monitoring, or follow-up.

Why it matters

Release decisions often happen under pressure. A clear closure summary helps leaders understand whether they are accepting a well-understood risk or guessing.

It also protects organizational memory. Future teams can learn why certain areas were risky, what was hard to test, and where investment is needed.

The quality engineering mindset

Test closure should feed the next cycle. If every release has environment delays, data gaps, unclear ownership, or repeated defect classes, closure should make those patterns visible.

The end of testing should improve the beginning of the next release.

How to use this in practice

A useful way to apply this topic is to take one active feature or release and map the concept to real risk. Identify what could fail, who would be affected, what evidence already exists, and what evidence is still missing.

The point is to turn test closure: how to end a test cycle without losing the learning from a definition into a working habit. Good QA practice changes how teams review requirements, choose tests, interpret failures, and explain release confidence.

IEEE 829 Test Plan

A popular template for Test Plan preparation is the format specified by the IEEE 829 standard for Software Test Documentation.

Before we look at the contents of the template, we should bear in mind that templates are broad guidelines which should not lead to users of the template to stop thinking and focus on just filling up the blanks in the template document. While using the template, one should understand the organization's requirements and evaluate if the template fits your specific requirements or needs any modifications. Sticking to the stock template may result in some information which needs to be captured being left out.

With that short note, lets look at the template itself. The IEE 829 Test plan template includes
the following sections.

• Test plan identifier : A unique name by which the test plan may be identified and may include version information
  
• Introduction : Summary of the test plan, including type of testing, level of testing (master test plan, component test plan, unit test plan ...), any references to other documents, scope of testing and so on
  
• Test items : The artifacts that will be tested
• Features to be tested : The features or items of the specification that will be tested
• Features not to be tested : The features or items part of the specification that will not be tested
• Approach : Addresses “how” the testing will be performed
• Item pass/fail criteria : This could be viewed as the criteria for completion of testing per this plan.
• Suspension criteria and resumption requirements : List the criterion for pausing or resumption of testing
• Test deliverables : The artifacts created by the testing team that will be delivered as per this plan. Examples include - test cases, test design specifications, output from tools, test reports, etc.
• Testing tasks : The testing tasks involved, their dependencies if any, time they will take and resource requirements
• Environmental needs : List needs such as hardware, software and other environmental requirements for testing
• Responsibilities : List the people responsible for the various parts of the plan
• Staffing and training needs : The people & skill sets needed to carry out the test activities
• Schedule : List the schedule dates when testing will take place. A safe bet is to tie the schedule to the development schedule in a relative manner without listing hard dates since slippages upstream in development will mean that testing slips correspondingly. Hard dates would result in any development slippages causing compression of testing time.
• Risks and contingencies : Identify the risks, likelihood and impact as well as possible mitigation steps
• Approvals : Sign-off by the stakeholders denoting agreement

For a more detailed look at the IEEE 829 Test plan, view this comprehensive article - http://www.techmanageronline.com/2010/02/ieee-std-829-software-test-plan-ieee.html 

***

Liked this entry? Join my community of professional testers to receive fresh updates by email. Use this link to add your email address to the community. Rest assured, I will neither spam nor share your email address with anyone else. Your email id will remain confidential. Subscriptions are handled by Google's FeedBurner service.

Test Strategy: The Quality Engineering Blueprint

A test strategy is the blueprint for how an organization creates confidence in software. It should connect risk, evidence, ownership, automation, environments, data, and release decisions.

Some teams treat test strategy as a document created because a process requires it. Others skip it entirely and rely on execution momentum: pick up the build, run tests, file defects, repeat. Both approaches miss the point.

A useful test strategy answers a senior question: how will we know whether this product or release is good enough to trust?

What A Test Strategy Should Clarify

• Quality objectives: what quality means for this product, customer base, and business context.
• Risk model: where failure would create meaningful harm.
• Test levels: what belongs in unit, component, API, contract, integration, UI, exploratory, performance, security, accessibility, and production monitoring.
• Automation approach: what will be automated, at which level, and with what reliability expectations.
• Data and environments: what controlled test data and stable environments are required.
• Metrics and reporting: which signals help decisions and which vanity metrics should be avoided.
• Release confidence: how evidence, known issues, and residual risk will be communicated.

Strategy Is Not A Template

The common failure is to confuse strategy with a reusable format. A template may help, but strategy requires judgment. A payment platform, healthcare workflow, analytics dashboard, and marketing website need different risk models. The same generic test strategy cannot serve all of them well.

A good strategy also changes as the system changes. Architecture, customer usage, defect history, regulatory obligations, production incidents, and team capability should all influence the strategy over time.

Risk Comes First

Testing everything equally is not strategy. It is lack of prioritization. A strong test strategy makes tradeoffs visible. It explains which risks require deep evidence, which risks can be sampled, which risks are monitored after release, and which risks are consciously accepted.

This is where QA earns leadership credibility. The strategic QA conversation is not "how many test cases are left?" It is "which release risks remain uncovered, how serious are they, and what options do we have?"

What Makes A Strategy Executable

A strategy must translate into action. If it does not influence backlog refinement, automation investment, exploratory charters, CI/CD checks, test data tooling, environment ownership, release readiness, or incident learning, it is only documentation.

Test strategy is not bureaucracy. It is the technical and organizational plan for producing trustworthy evidence. Without it, testing becomes activity. With it, testing becomes decision support.

Testing based on analysis of Quality Risks

is an approach to testing wherein risks identified along with the level associated with each risk is used to plan testing. This blog post gives an overview of testing based on analysis of risks and their levels plus a look at an informal method of performing the analysis.

To begin, we look at what constitutes a risk. The definition states that risk is the possibility of a negative or undesirable event or outcome. From a testing perspective, we are concerned with two categories of risks. The first category is the Quality risk that affects the product, such as potential defects in the product that cause it crash, lose data, etc. The second category of risk is the Project risk that relates to management of the project and includes items such as inadequate resourcing, insufficient time to test, late binding features, etc.

Our focus here is on the Quality risks. Risks once identified, need to be classified and ordered according to their risk level. A risk level signifies the importance of a risk as defined by its likelihood of occurrence and business impact. Risk level can be expressed as high, medium, low or in terms of a number. Risk levels help in determining the extent of testing to be performed against the particular risk. You would naturally want to focus the greater part of your test efforts on those areas that have the higher levels of risk. As testing progresses risks are re-assessed and reports will appraise stakeholders in terms of residual risk.

Identification and analysis of risks can happen at each phase – requirements, design, development. It may also be viewed as a form of review to determine what the product might do that it should not be doing. Informal techniques of risk analysis may be performed for most projects that do not require heavy weight formal techniques of assessment. These require much lesser commitment of time and effort and also need little documentation. Here, stakeholder inputs based on their knowledge of requirements and experience, any historical information and checklists of risks are used to identify and classify risks. Since inputs from stakeholders is important, getting the right folks to participate is key so that risks are rightly identified and risk levels correctly assessed.

A Thousand Tests Can Still Mean Zero Meaningful Coverage

A large number of tests can create a comforting illusion. A team may have hundreds or thousands of automated checks and still miss the risks that matter most.

Coverage is meaningful only when it is connected to product behavior, failure modes, user impact, and release decisions.

The coverage illusion

Counting tests is easy. Understanding what they prove is harder. A suite may repeat the same happy path in many variations while ignoring permissions, data integrity, error handling, concurrency, migration, accessibility, or operational risk.

This is how teams end up with a large suite and weak confidence.

Better coverage questions

• Which critical user journeys are protected?
• Which business rules are checked at the cheapest reliable level?
• Which integrations and failure modes have evidence?
• Which defects escaped despite existing tests?
• Which areas are intentionally untested and why?

The senior QA standard

A test portfolio should be reviewed like an investment portfolio. Keep tests that provide signal. Improve tests that are hard to diagnose. Retire tests that duplicate cheaper evidence or create noise.

A thousand tests are valuable only when they buy real confidence.

How to apply this to an automation portfolio

The practical next step is to review one automation suite and ask whether each check still earns its cost. A useful automated test should protect a real decision, fail for a meaningful reason, and help the team diagnose the likely cause quickly.

This topic becomes useful when it changes automation investment. Retire low-signal checks, move expensive UI checks down the stack where possible, and keep human testing focused on discovery, ambiguity, and product judgment.

Using FMEA In Quality Engineering: Turning Failure Modes Into Test Strategy

Failure Modes and Effects Analysis is valuable in software quality when it is used as a practical risk-thinking tool, not as a paperwork exercise.

Quality teams often talk about risk-based testing, but many test strategies still start with features, screens, or requirement sections. FMEA forces a stronger question: how can this system fail, what would the effect be, how likely is it, how easily can we detect it, and what should we do about it?

That framing is powerful because it moves quality upstream. Instead of waiting for defects to appear during test execution, the team anticipates failure modes while requirements, design, architecture, and implementation decisions are still changeable.

What FMEA Means In Software

In software, a failure mode is a way the product, service, workflow, data path, integration, or operational process can fail. The effect is the consequence of that failure for the user, business, system, or operation.

For example, in a payment system, a failure mode might be duplicate authorization after a timeout. The effect might be double charging, customer distrust, support escalation, financial reconciliation effort, and regulatory exposure. That is much more useful than simply saying "payment failed."

The Three Ratings That Matter

• Severity: How serious is the effect if the failure occurs?
• Occurrence: How likely is this failure mode based on design complexity, history, change size, dependencies, or known weaknesses?
• Detection: How likely are we to detect the failure before it harms users?

The traditional Risk Priority Number multiplies severity, occurrence, and detection. The exact scoring method matters less than the quality of the conversation. If a team debates severity, likelihood, and detectability honestly, it will usually produce a better test strategy than a generic regression checklist.

Where FMEA Fits In Quality Engineering

FMEA is most useful for high-risk workflows, safety-critical logic, data migrations, financial transactions, integrations, security-sensitive features, compliance-heavy systems, and distributed workflows where partial failure is common.

It is also useful when a team has recurring escaped defects. Instead of adding one more regression test for the last defect, FMEA helps identify the broader failure class and the missing prevention or detection mechanism.

Practical Inputs For Software FMEA

• Production incidents and escaped defects.
• Customer support issues and complaint patterns.
• Architecture diagrams and dependency maps.
• Security threat models and abuse cases.
• Static analysis, code churn, and complexity data.
• Known test data and environment limitations.
• Operational telemetry: logs, metrics, traces, alerts, and SLOs.

How FMEA Improves Testing

A strong FMEA changes the test plan. High-severity, high-occurrence, low-detectability risks should receive the strongest evidence. That may mean API tests, contract tests, exploratory charters, data reconciliation, fault injection, performance tests, security tests, observability checks, or rollout controls.

For example, if a background job can process the same event twice, the response should not be a UI regression test. The response should include idempotency checks, duplicate-message tests, logs with correlation IDs, and reconciliation alerts.

Common Mistakes

• Running FMEA as a one-time meeting and never connecting it to test design.
• Letting only QA score the risks without product, engineering, security, operations, and support input.
• Scoring everything as high risk, which destroys prioritization.
• Ignoring detectability and recoverability.
• Failing to update the analysis after incidents or design changes.

FMEA is not valuable because it produces a table. It is valuable because it makes failure concrete. Senior quality engineers use it to turn vague concern into targeted prevention, detection, and recovery strategy.

Cost Of Exposure: The Economics Behind Risk-Based Testing

Cost of exposure helps QA leaders explain testing as an economic decision: spend effort where the expected cost of failure justifies stronger evidence.

Risk-based testing is often discussed qualitatively: high, medium, low. Cost of exposure adds an economic lens. It asks what a risk is expected to cost if it occurs and how much it is reasonable to spend reducing that risk.

The Basic Idea

At its simplest, cost of exposure is:

Expected exposure = likelihood of occurrence x impact of occurrence

If a failure is likely and expensive, the team should invest more in prevention, detection, and recovery. If a failure is unlikely and low impact, exhaustive testing may not be economically sensible.

Why This Matters For Testing

Testing capacity is limited. Teams cannot test every condition with equal intensity. Cost of exposure helps prioritize effort by making the economics explicit. It also helps explain QA tradeoffs to business stakeholders in language they understand.

For example, a typo on an internal admin page and a duplicate payment defect should not receive the same level of test investment. The second has higher customer, financial, support, and trust exposure.

What Counts As Cost

• Customer impact and support effort.
• Revenue loss or incorrect billing.
• Operational disruption.
• Compliance or legal exposure.
• Brand and trust damage.
• Engineering rework and incident response cost.
• Opportunity cost from delayed delivery or diverted teams.

Limits Of The Technique

Cost estimates are imperfect. Some impacts are hard to quantify, especially trust, reputation, safety, and regulatory consequences. The method should not be used as a false-precision exercise. It is a decision aid, not a mathematical guarantee.

It is also not appropriate to ignore critical failures just because the probability appears low. Low-probability, high-impact risks may still require serious controls.

How To Use It Practically

• Identify major quality risks for the release or product area.
• Estimate likelihood using change size, complexity, history, dependencies, and detectability.
• Estimate impact across customer, business, operational, legal, and engineering dimensions.
• Choose testing and release controls proportionate to exposure.
• Review production defects to improve future estimates.

Cost of exposure gives QA a strategic language. It moves the conversation from "how much testing do we want?" to "which risks are worth reducing, and what evidence is economically justified?"

Testing in an Agile world

There are a few areas to watch out for while pursuing an Incremental or Iterative model. For the purpose of this blog post, here are some of them. These are from experiences using a specific model – Scrum.

Incremental or Iterative models of development such as agile, have a fairly common theme – delivering an integrated, working system earlier in the life-cycle than would be possible when following a sequential model. The catch here being that only a part of the functionality and features would be available in the delivered builds and incremental addition of functions happen in chunks or increments. While having integrated and working systems available for testing early on does seem like a good idea, there are some areas to look out for.

The load on testing tends to increase after the first chunk or increment. The testing team is usually called upon to perform dual roles - help with on-going incremental testing (pair/buddy testing along with development counterparts as part of an agile team) while also ensuring that the entire integrated system is thoroughly tested too. After the first increment, testing team has to ensure that full regression test cycle is executed to test all features and functionality delivered in the previous increments. These regression tests (on the previous increment's deliverable) are executed by the team while also working in parallel to help with the on-going incremental test efforts for new features being developed in the current increment.

Scope for regressions increase. Typically in incremental development projects, the important & usually complex features and functionality are addressed at the start / initial increments. It is important to ensure that these priority functionality are not broken in subsequent increments. Given the nature of incremental development efforts, invasive changes to the code base often times necessitating changes that have wider impact cannot be ruled out and can be expected. In such a scenario, each new increment introduces a fair degree of changed and new code which increases the risk of regression.

Overlap of tasks across increments and bug handling – as discussed in earlier points, while the testing team is busy working on testing the last increment, development and others are working on developing for the current and subsequent increments. There is overlap of activities across increments. One of the challenges here is when testing finds many defects that need to be addressed by development. However, given that development has already begun work on the current increment based on their plans and information available at the start of the current increment, such new bug fix activity tends to get pushed out to subsequent increments (unless the defect is of a stopper nature). Also, work can quickly pile up on the plate of development if testing finds many bugs to be addressed. This would necessitate re-planning and even in some instances having to cut back on some features to accommodate bug fixes. For the testing team, bugs that are not show stoppers but still important, may get addressed much later on in the cycle. The amount of work to be done by the testing team (including verifying the fixes, checking regressions, etc) can easily build up nearing the end of the release cycle and requires active monitoring, planning and control.

Of course, the above are not barriers to adopting an incremental model and can be handled and managed while working closely with all constituents involved in the project or product development and delivery.

***

Liked this entry? Join my community of professional testers to receive fresh updates by email. Use this link to add your email address to the community. Rest assured, I will neither spam nor share your email address with anyone else. Your email id will remain confidential. Subscriptions are handled by Google's FeedBurner service.

QA is not Testing (QA vs QC)

QA, QC, Testing – more often used inter-changeably and generally meant to imply "Testing".

Lets get our facts straight - QA is not Testing; QC is not only about Testing; Testing is QC.
More explanation follow.

Quality Control (QC) - is oriented towards detecting defects and correction of these defects. QC works on the product rather than the process of producing the product. QC involves a set of tasks carried out to evaluate the product that has been developed. QC is normally the responsibility of the testing team and is considered to be a line function. Although testing is a QC activity, it is not the only type of QC activity. QC includes any activity that examines products to determine if they meet their requirements. Examples of QC activities apart from testing – inspections, reviews, walk-throughs of work products like requirements, designs, code and documentation.

Quality Assurance (QA) - is oriented towards defect prevention and focuses on the process by which the product or application is built. QA involves a set of tasks to ensure that the development process is adequate to produce a system that meets its requirements. QA activities include reviewing design activities, setting standards to be followed in coding and such other process requirements aimed at ensuring that a quality product is built. QA ensures that the process is well defined and looks at methodology and standards development. QA is performed through the life cycle of the product and applies to all involved in developing the product. QA is normally considered to be a staff function. QA looks at items such as identifying areas for improvements in current methods and processes being followed, making processes effective, ensuring consistency in the way these are followed and so on. While QC evaluates the product, QA evaluates the activities involved in creating the product.

Errors - Human vs Automation

Test automation is only as good as the human testers who created it. Test automation can help minimize chances of human error in situations that require human testers to perform repetitive and mundane activities. However, any errors that creep into an automation suite tend to be magnified many times more than a human tester can achieve. Errors in automation suites are easy to miss and every time the suite is executed, tend to manifest itself. There have been many instances where errors in automation have gone unnoticed for a long while and things have seemed ok when there were issues lurking around. Few examples of errors include, logical errors in the automation, missing coverage of scenarios that are likely to have defects, hard coded data (or even results !), and such others which contribute to giving a false impression of normality.

As Paul Ehrlich said, "To err is human, but to really foul things up you need a computer”. Human testing does have it's share of errors, but these tend to be relatively easier to detect using simple examination of test reporting and documentation.

Test Automation should be treated just like any another full fledged Software development effort. Due diligence needs to be done to incorporate sound Software development practices. Extensive testing of the automated tests needs to be performed. Testing and verification of the automation suite is an on-going effort that needs to be factored in while planning for automation. Regular testing helps monitor for relevance of automated tests and detect any needed changes in accordance with any changes to the application being tested or environment.

One thing humans can do is think. Human testers automatically interpret system behaviors and evaluate results based on a diverse awareness of the system being tested, its operating environment, inter-dependencies, the context, potential for changes and so on. In many cases, human testers may not fully realize their ability to model program behavior and adapt to changes. Human testers can observe much more than what an automation suite can.

As the quote goes, “The question of whether computers can think is like the question of whether submarines can swim.”

Human testers have their share of shortcomings – automated systems can run tests faster, handle large volumes of data and interpret instructions quicker. Also, automated systems can better and more efficiently investigate internal system data such as execution threads, variables, program states, etc. Humans can get fatigued and lose focus especially when tasks become repetitive, take a long time or are mundane.

Will Automation Eliminate Manual Testers? No, But It Changes the Skill Bar

Test automation will not eliminate the need for human testers. It will eliminate some repetitive work and raise the expectations for what testers contribute.

The future belongs to QA professionals who combine testing judgment with enough technical fluency to work effectively in automated delivery environments.

What automation does well

Automation is excellent for repeatable checks with clear expected results. It can run quickly, consistently, and often. It protects regression confidence, supports CI/CD, and frees human attention from repetitive verification.

But automation does not decide what quality means, which risks matter, whether a workflow is confusing, or whether a product solves the right problem.

What humans still do better

• Explore ambiguous behavior and unexpected workflows.
• Judge usability, trust, and product fit.
• Investigate strange failures across systems and data.
• Communicate risk to people making decisions.
• Design better test ideas from context, not only from scripts.

The career implication

Manual-only execution is a shrinking career foundation. Human testing remains valuable, but testers need broader skills: APIs, data, logs, automation concepts, risk analysis, exploratory testing, and quality communication.

Automation does not remove testers. It removes the comfort of staying narrow.

How to apply this to an automation portfolio

The practical next step is to review one automation suite and ask whether each check still earns its cost. A useful automated test should protect a real decision, fail for a meaningful reason, and help the team diagnose the likely cause quickly.

This topic becomes useful when it changes automation investment. Retire low-signal checks, move expensive UI checks down the stack where possible, and keep human testing focused on discovery, ambiguity, and product judgment.

The Goal of Testing Is Better Decisions

The goal of testing is not to execute test cases, find the most defects, or prove that software is perfect. The goal is to provide evidence that helps people make better decisions about risk.

That shift in thinking changes how QA communicates value.

Testing creates information

A test result is useful when it reduces uncertainty. It may reveal a defect, confirm expected behavior, expose an unclear requirement, challenge an assumption, or show that more investigation is needed.

Pass and fail are not the only outputs. Confidence, uncertainty, coverage, and residual risk are also outputs.

The decisions testing supports

• Is the feature ready for broader use?
• Should the release proceed, pause, or change scope?
• Which defect should be fixed first?
• Where should automation investment go?
• Which product or architecture assumption needs reconsideration?

A better QA conversation

Instead of saying testing is complete, explain what evidence exists. Instead of reporting only defect counts, explain what risks remain. Instead of asking for more time generically, explain what decision the additional testing would improve.

Testing is valuable because decisions made with evidence are better than decisions made with hope.

How this shows up in QA leadership

A QA leader can use this idea to improve the quality conversation in a team. Instead of asking only whether testing is complete, ask what risk has been reduced, what evidence supports that claim, and what decision the team is now better able to make.

That is the difference between QA as activity tracking and QA as technical leadership. The strongest quality professionals make uncertainty visible in a way that helps people act.

Functional Specifications: How QA Turns Requirements Into Testable Evidence

A functional specification is useful only if it helps the team understand expected behavior well enough to build, test, and support it. Long documents are not automatically good specifications. Clear, testable expectations are.

QA plays an important role in turning specification language into evidence.

What QA should look for

• Ambiguous terms such as fast, easy, normal, or appropriate.
• Missing negative cases and error paths.
• Unclear data rules, defaults, and boundary values.
• Role, permission, and audit expectations.
• Integration behavior and dependency assumptions.
• Non-functional expectations such as performance, accessibility, security, and observability.

From specification to tests

Good testers translate functional statements into examples. They ask what input, role, data state, configuration, and environment are needed to prove the behavior. They also ask what should not happen.

This work often improves the specification before code is written. That is cheaper than finding ambiguity after implementation.

The quality standard

A specification should support shared understanding across product, engineering, QA, support, and operations. If it cannot be tested, it is not yet clear enough.

QA should not merely consume specifications. QA should make them sharper.

How to use this as a working habit

The practical value of this topic is in daily test design. Use it when reviewing a requirement, creating examples, selecting data, choosing boundaries, or explaining why a particular test matters.

Fundamentals are not junior concepts. Senior testers use them with more judgment: less ceremony where risk is low, more discipline where ambiguity, impact, or repeatability matter.

A useful habit is to ask what decision this concept supports. If the answer is unclear, the testing activity may need refinement. Good fundamentals should make the work sharper: clearer scope, better examples, stronger evidence, and more honest communication about what remains unknown.

Software Testing: Evidence, Risk, and Professional Judgment

Software testing is the disciplined investigation of software quality. It provides evidence about behavior, risk, and readiness so teams can make responsible decisions.

That definition is broader than executing scripts. Testing includes questioning requirements, designing experiments, exploring behavior, checking expected results, investigating failures, and communicating what the evidence means.

What testing contributes

Testing reveals defects, but its value is larger than defect discovery. It reduces uncertainty. It exposes assumptions. It helps teams understand whether software is fit for purpose, safe enough to release, usable enough for real people, and supportable in production.

Good testing also improves the engineering system. The defects and gaps found during testing should influence requirements, design, automation, observability, and release practices.

What professional testers do

• Understand the product, users, domain, and business risk.
• Choose test approaches based on the risk being investigated.
• Use automation for repeatable checks and human judgment for discovery.
• Write defects that help teams diagnose and decide.
• Communicate confidence and uncertainty clearly.

The modern QA view

Testing is not a phase at the end of development. It is a quality feedback capability that should operate from idea to production.

The best testers do not only ask whether the software works. They ask whether the organization has enough evidence to trust it.

How to use this in practice

A useful way to apply this topic is to take one active feature or release and map the concept to real risk. Identify what could fail, who would be affected, what evidence already exists, and what evidence is still missing.

The point is to turn software testing: evidence, risk, and professional judgment from a definition into a working habit. Good QA practice changes how teams review requirements, choose tests, interpret failures, and explain release confidence.