Code Quality, Code Coverage, And The Limits Of Developer-Centric Metrics

Code quality matters, but code-centric metrics cannot fully answer whether a product is ready for users. Quality engineering must connect code evidence with product risk and user value.

Developer practices such as coding standards, code review, static analysis, unit testing, automated debugging, and code coverage are important. They improve maintainability, prevent classes of defects, and create faster feedback. But they are not the whole quality story.

The Code Coverage Trap

Code coverage is useful when interpreted correctly. It can show which lines, branches, or paths were exercised by tests. It can also reveal areas that have no automated protection.

But code coverage does not prove that the right behavior was tested. It does not prove that requirements are correct, user workflows are usable, security controls are effective, performance is acceptable, data is accurate, or production failure will be diagnosable.

A team can increase coverage while adding weak assertions. That creates a comforting number without much decision value.

What Better Quality Evidence Looks Like

• Unit and component tests for deterministic business rules.
• API and contract tests for service behavior and compatibility.
• Exploratory testing for ambiguity, usability, and emergent behavior.
• Performance, security, accessibility, and data-quality checks where risk justifies them.
• Observability that helps teams detect and diagnose production issues.
• Release-readiness summaries that explain known risk and residual uncertainty.

Unit Testing Must Be Disciplined

Ad hoc unit testing is not enough. Developer-owned tests should be intentional, repeatable, automated, and meaningful. They should protect important logic and support safe refactoring. A weak unit test suite creates false confidence; a strong one allows the team to move faster.

Quality Is Broader Than Development Practice

Good development practices reduce defect creation. Good testing and quality engineering reduce uncertainty about product behavior. The two must work together. Developers should own quality in the code path, and QA should strengthen the evidence model across the system.

Code quality is essential, but user trust is larger than code. Senior QA leaders use code metrics as one signal in a broader quality system, not as the final answer.

Usability Testing of Software

Let us begin by taking a look at the term, usability. According to the Usability Professionals' Association, "Usability is an approach to product development that incorporates direct user feedback throughout the development cycle in order to reduce costs and create products and tools that meet user needs."

Usability testing provides the opportunity to receive feedback from the very people the application is meant for. And, the consequences of building something without getting user feedback is obvious to anyone who's in the industry ! Whilst planning for Usability Testing, its easy to constrain it to be more of a "Validation" type technique. Usability testing & the information gathered from the exercise, should serve to make informed design & development decisions right from the outset, thereby acting in a mainly "preventative" role. The idea in the case of Usability testing is to test early & test often. Usability testing lets the design and development teams identify problems before they are deeply entrenched. The earlier those problems are found and fixed, the less expensive the fixes are. As the project progresses, it becomes more and more difficult and expensive to make major design changes. The more you test and change based on what you learn, the more confident you can be that your application will meet your objectives and your users' needs when it is released.

An iterative process involving developing prototypes, testing it with users, analyzing the results, making needed changes based on the results and repeating the test, analysis and revision cycle is the recommended way to produce applications that are more usable (and acceptable) to users. We could also probably say that, in the initial stages of application development, users would be called to perform tests that are mainly "Exploratory" in nature. This feedback helps clarify direction for interface design, navigation, etc. In later stages, prior to release, "Validation" type usability tests are performed to validate that interfaces and design are "usable" and feedback from earlier stages have been incorporated.

The folks who should actually be doing Usability Testing (executing tests) should ideally not be anyone associated with the product or organization. A profile of potential subjects (folks who will perform Usability Tests) should be prepared that mimics end user attributes in as fairly and representative manner as is feasible. Based on this profile, subjects may be sourced from market research, temp or contracting agencies.

During Usability testing, representative users try to find information or use functionality on the web site / application, while observers watch, listen, and take notes. The purpose of a usability test is to identify areas where users struggle with the application and make recommendations for improvement.  The most likely goals in usability Testing or areas that are monitored and measured include, the Time (taken to accomplish specific scenarios or tasks), degree of Accuracy (covers inaccurate menu or navigation choices, errors and lack of clarity or misunderstandings), the Success (in accomplishing the set tasks wherein users are able to complete the scenario they were asked to perform using expected steps) and importantly, Satisfaction of the users (broken down and measured per area such as navigation, information search, etc.)

If you are developing an application, your product must allow users to do their tasks at least as quickly with as few errors and as much success and satisfaction as their current way of working. Ideally, it should let them be more quicker, more accurate, more successful, and more satisfied. Otherwise, there's little chance of customer delight.

Choosing the Right Type of Software Testing for the Risk

Different types of testing exist because software can fail in different ways. A system can calculate correctly but perform poorly. It can pass functional tests but expose private data. It can work in isolation but fail when integrated with another service.

A strong QA strategy begins by naming the risk, then choosing the test approach that can expose that risk with the best balance of speed, cost, and confidence.

Match the question to the method

If the question is whether a business rule is correct, unit, component, or API tests may provide fast evidence. If the question is whether a customer can complete a complete workflow, exploratory or end-to-end testing may be necessary. If the question is whether the system survives a traffic spike, a functional regression suite is the wrong tool.

This sounds obvious, but many teams still respond to every concern by adding more UI regression tests. That is usually expensive and slow.

Risk categories worth separating

• Functional risk: incorrect behavior against expected rules.
• Integration risk: failure at boundaries between services, systems, devices, or teams.
• Data risk: loss, corruption, inconsistency, privacy exposure, or migration error.
• Operational risk: performance, reliability, deployment, monitoring, and recovery gaps.
• User risk: confusion, accessibility barriers, and broken workflows.

The leadership habit

When a release is under pressure, ask which risk is still uncertain and what evidence would change the decision. That one question prevents testing from becoming generic activity.

Testing types are tools. Senior quality engineers choose them with intent.

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 choosing the right type of software testing for the risk from a definition into a working habit. Good QA practice changes how teams review requirements, choose tests, interpret failures, and explain release confidence.

Testing the Tests: How QA Teams Protect the Quality of Their Evidence

Tests can be wrong. They can pass when the product is broken, fail when the product is correct, check the wrong thing, rely on invalid data, or become obsolete after the product changes.

That is why serious QA teams test their tests. The credibility of a test suite depends on the quality of the evidence it produces.

The risks inside the test suite

A weak automated test can create false confidence. A flaky test can train the team to ignore failures. A manual test with vague expected results can produce inconsistent outcomes. A regression suite that never changes can protect yesterday's risks while missing today's architecture.

A test suite is not valuable because it is large. It is valuable when it produces trustworthy signal.

Ways to test the tests

• Review tests against current requirements, architecture, and defect history.
• Inject known failures and confirm the relevant tests fail for the right reason.
• Track false positives, false negatives, flaky behavior, and diagnosis time.
• Remove duplicate or low-signal checks that slow feedback without adding confidence.
• Keep test data and assertions realistic enough to expose meaningful failure.

The professional standard

A QA team should be able to defend its evidence. If a release decision depends on a test result, the team should know what the test actually proves, what it does not prove, and how reliable the signal is.

Testing the tests is not extra work. It is quality control for the quality process itself.

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.

Why Do We Test Software? Risk, Evidence, And Release Confidence

We test software to create trustworthy evidence about risk. Finding bugs matters, but testing is ultimately about helping teams make better decisions.

Software testing is often described as defect detection. That is true but incomplete. A tester may find defects, but the deeper value of testing is the information it provides about the state of the product, the risk of release, and the confidence the organization can reasonably have in the system.

Testing Reduces Uncertainty

Every meaningful software change creates uncertainty. Did we build the intended behavior? Did we break existing behavior? Will the system perform under expected load? Are permissions correct? Is data handled safely? Can users complete the workflow? Can support diagnose failure? Can we recover if production behaves differently from test?

Testing does not remove all uncertainty. No serious tester should claim that. What testing does is reduce uncertainty enough for responsible decisions.

Testing Supports Release Decisions

Release decisions require evidence. Product leaders need to know whether user workflows work. Engineering leaders need to know whether the system is stable and maintainable. Security teams need to know whether controls are effective. Operations teams need to know whether issues can be detected and recovered. Business leaders need to know whether residual risk is acceptable.

Testing connects those questions to evidence. That evidence may come from automated tests, exploratory testing, reviews, static analysis, performance testing, security testing, accessibility testing, data reconciliation, observability, and production monitoring.

Testing Is More Than Finding Bugs

Bug discovery is important, but it is not the only purpose of testing. Testing also:

• validates whether the product solves the right user problem;
• verifies conformance to functional and non-functional expectations;
• reveals gaps in requirements and assumptions;
• exposes design and integration risks;
• supports regulatory and contractual confidence;
• improves team learning about the system;
• helps prioritize release tradeoffs.

The Senior QA View

Senior quality professionals do not ask only "how many bugs did we find?" They ask better questions: which risks did we reduce, which risks remain, how strong is the evidence, what did we learn, and what should change upstream so this risk appears less often?

This is why testing must be connected to quality engineering. A test case is useful only if it produces meaningful signal. A defect report is useful only if it helps the team understand impact and act. A test strategy is useful only if it aligns effort with risk.

Testing And Business Value

Good testing protects more than code. It protects customer trust, revenue, operational stability, brand reputation, compliance posture, and the team's ability to change software safely. Poor testing is expensive not just because defects escape, but because teams make decisions with weak evidence.

We test because software decisions deserve evidence. The best testing does not merely say whether something passed or failed. It helps the organization understand whether it can trust the product, the release, and the engineering system behind it.

What is Software Testing ?

While embarking on the journey to learn Software Testing, the starting point is understanding its meaning. So, what is Software Testing ?

The IEEE definition states that testing is, "an activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component". According to Hetzel, "Software Testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results". Further, Myers states, "Software Testing is the process of executing a program or system with the intent of finding errors".

Software Testing involves an evaluation of the system or component. This evaluation is done to: a) see if the system does not perform what it is supposed to perform b) to see if it performs what it is not supposed to be performing

Given the above definitions, a question that gets asked is - What does testing prove ? Does testing prove the absence of defects ? The answer: Testing does not prove anything. Testing is not about proving the absence of defects. Testing helps reduce the risk perception associated with the system or component. Testing is about finding defects but not about finding all of the defects. This distinction is important to make.

Software Testing involves operating a system or component under controlled conditions, evaluating the results and checking if performance meets expectations. Testing is usually compared to the headlights of a car while driving on an unknown stretch in the dark. Testing brings to light critical information that enables better decision making. In the words of James Bach, testing is "organized skepticism", an inherent belief that things may not be as they seem; testing helps to reduce uncertainty about the state of the system or component and is usually thought of as the process of comparing the ambiguous to the invisible, so as to avoid the unthinkable happening to the unknown. On a lighter note, testing is considered to be a support function that enables developers to look good by finding their "mistakes" before anyone else does.

This is the part 1 of the series on Software Testing, from the ground up. Stay tuned for upcoming posts in this series.

Why do users find bugs that Software Testers miss ?

Here's a familiar scenario: Testers spend months or longer, testing a product. Once the product is released, users report bugs that were not found by the testing team. The obvious question that gets asked is - how did the testing team miss these issues ?

Listed below are some of the common reasons why users catch issues that the software testing team may have missed.

• The testing team has not tested in an environment that is similar to what the user uses. This could happen for a variety of factors. It could be due to a lack of awareness of the user environment or usage scenario. Where there is awareness of the user environment, it may be that the testing team did not have the time or bandwidth available to test with this scenario. Where there is awareness and time, it may be that the testing team could not replicate the scenario due to physical or logistical constraints such as availability of required hardware, software, peripherals, etc. While it is not possible to replicate every possible usage scenario, testing must consider the most possible or widely used cases.

• The steps that users followed differed from what the testing team followed. This can happen either when users follow a different set of steps than what the testing team may have followed or when the order of the steps followed differs. Even when the same set of steps are followed, if the ordering of the steps differ, it can have different consequences.

• The user entered a set of input data that was not covered during testing. This can occur for the simple reason that it is physically not possible to test every possible set of input data. When a product is deployed widely, the chances that some users somewhere will enter a set of values that was untested is likely. While designing tests, testers choose sets of input values to test with. Errors in making these choices can also contribute to user reported defects.

• The defect that users reported could come from code that was not tested. It could either be due to having released untested code or the existing set of tests did not exercise the piece of code where users found defects. The challenges encountered by the software testing team increases as our products become more complex.

Modern Test Planning: What IEEE 829 Still Teaches Quality Engineers

A test plan is not valuable because it follows a template. It is valuable when it creates shared understanding of scope, risk, evidence, responsibilities, constraints, and release confidence.

IEEE 829 gave the industry a structured vocabulary for software test documentation. Some of its document-heavy practices feel dated in Agile and DevOps environments, but the underlying planning discipline is still highly relevant. Modern teams should not copy old templates mechanically. They should preserve the thinking behind them.

The Real Purpose Of A Test Plan

A test plan is a decision document. It explains what the team intends to test, why those areas matter, how evidence will be produced, who owns the work, what constraints exist, and what risks remain.

When written well, a test plan prevents late misunderstanding. Product, engineering, QA, security, operations, and business stakeholders can see the testing strategy before execution begins. That matters because disagreement about quality scope is cheaper to resolve before the release is under pressure.

What Modern Test Plans Must Cover

• Quality objectives: what confidence means for this product or release.
• Scope and exclusions: what will be tested, what will not be tested, and why.
• Risk model: which failures would create user, business, operational, legal, or reputational impact.
• Evidence strategy: unit, component, API, contract, integration, UI, exploratory, performance, security, accessibility, data, and production signals.
• Environment and data: what test environments, data states, dependencies, and access are required.
• Responsibilities: who owns preparation, execution, automation, triage, release decisions, and residual risk.
• Readiness and exit criteria: what evidence is required before release and what exceptions require explicit acceptance.

The Shift From Documentation To Planning

The most common failure is confusing the document with the planning. A large test plan copied from a template can still be weak if it avoids hard tradeoffs. A short test plan can be excellent if it clearly explains risk and evidence.

In iterative delivery, the test plan may be a living artifact. It can exist as a lightweight strategy page, release checklist, risk register, test charter set, or quality dashboard. The format matters less than whether the team uses it to make better decisions.

What IEEE 829 Still Gets Right

IEEE 829 emphasized scope, approach, resources, schedule, responsibilities, test items, features to be tested, and risks requiring contingency planning. Those are still the right questions. The modern update is to include automation architecture, CI/CD quality gates, observability, rollback strategy, test data management, security, accessibility, performance, and production monitoring.

A Practical Modern Test Plan Structure

• Release or product context.
• Key quality risks and assumptions.
• Test levels and test types to be used.
• Automation and exploratory testing strategy.
• Non-functional test strategy.
• Environment, data, and dependency plan.
• Defect triage and risk communication approach.
• Release-readiness criteria and residual risk process.

Modern quality engineering does not need more ceremonial documents. It needs better planning. A strong test plan is the artifact that proves the team has thought seriously about risk before asking users to trust the software.

Fuzz Testing / Fuzzing as a Software Testing technique

Fuzzing or Fuzz testing is a method of testing applications by randomly altering or corrupting input data. The idea behind fuzz testing is to hit the application under test (AUT), with random corrupt (bad) data and observe how the system behaves. Fuzz testing can be done both manually and using automation. Automated fuzz tests tend to be more effective in unearthing issues based on the variety and range of data that may be supplied to the application. These automated fuzz tests may be used to send a regular barrage of garbage to the AUT. The emphasis on fuzz testing has increased due to the significance of security testing and tools available. Tests that are developed using reasoning and logic by human testers, would not usually find issues that a Fuzz test may reveal.

Fuzz testing is a simple technique but it can show important defects that need addressing. Corrupt data can cause applications to crash or behave unexpectedly. In the earlier days on some of the older operating systems, it was possible for application crashes due to corrupt data to bring down the computer system itself. The defects that are identified via fuzzing could be potential security holes if left unaddressed. The outline of steps to perform fuzz testing is listed below.

1. Gather the correct set of input data for your application
2. Change some or all parts of the input data with random or corrupt data
3. Pass this modified input data to your application and observe what happens

Fuzz testing may be performed manually to begin with, but for greater effectiveness, automated fuzzing is recommended. Fuzz testing requires a good deal of creative thinking. The steps listed above may seem simplistic, however once the initial defects are reported, developers will harden the application and introduce greater checks and verifications before accepting inputs. After this point, it can be harder (not impossible) to identify more defects. This is when testers need to exercise a greater degree of creativity to work-around these counter measures to break software. It is important to think like the hacker who will be looking to break the system.

Fuzz testing can quickly show up some of the "assumptions" that developers make. For example, when data is passed in as input, if a parameter is expected to accept a specific range of numbers, the program should be checking the input data to ensure that it matches with what is expected and not assume that the data is correct. Also, while working with files that have been created by the application under test, the application must verify the integrity and validity of the file before reading it again. Assuming that the files it created are valid is a potential security hole since an attacker can take advantage of this lapse and modify the file.

Fuzz testing is not a replacement for other more formal testing. When an application passes a fuzz test, it basically shows that the software can handle exceptions and incorrect inputs in a safe and sane manner. Fuzz testing is used to find defects and test an application's error-handling capabilities. Greater success with fuzz testing requires a detailed understanding of the application and related technologies being tested. If we are testing a protocol implementation or a specification, it helps to really know the protocol or specification. This knowledge can be used to come up with strategies to fuzz test in a way that can expose holes in the product. Fuzz testing demonstrates the existence of bugs and not the absence of it.

Software Testing - for whom do we test ?

Software Testers spend a significant part of their work lives, testing! How often do testers pause to think about the question - whom are we testing for ? The answer that managers would usually say is - stakeholders. That brings up the next set of questions - who is  a stakeholder and who are the stakeholders for testing ? A stakeholder is someone who has a stake or interest in the work that you do. The testing stakeholder also has an interest in the quality of the final work product. Stakeholders in testing may be broadly classified as internal and external stakeholders.

Some organizations view all stakeholders within the organization as "internal" while any stakeholders outside of the organization are considered as "external". In some other groups, anyone who is involved with the test effort - in terms of performing testing, leading or managing the test efforts are considered as "internal stakeholders" while all other stakeholders are considered to be "external". The list of who constitutes a stakeholder can vary across projects and organizations. Given below is a brief list of stakeholders for testing.

• Other testers in the group
• Test Managers and Test Leads, involved in managing and leading test efforts
• Architects and Designers, responsible for designing the product
• Implementors - the developers, development managers and leads involved with developing the product
• Product marketing folks, involved in determining the features for the product and are interested in the quality of implementation of these features
• Analysts, involved in determining the requirements for the product and the related quality attributes
• Program/Project Management folks, responsible for project planning, organizing and managing resources for successful completion of project objectives
• Customer Support folks, responsible for supporting customers and users of the product produced
• Sales folks, responsible for selling the software
• Executives / Senior Management of the organization, who run the organization
• Shareholders of the organization
• Users of the software
• Partners of the organization
• Vendors, who may supply components that are integrated with the product
• Customers, who pay for the software
• Community / Society, where the software product is being used
• Governmental authorities, who are interested in the software complying with applicable laws and regulations

The above list is not complete and can vary depending on your particular project or organization.

Stakeholders generally tend to want the software testing efforts to succeed and ensure that a quality product be produced. However, some stakeholders can be neither positive or negative about your testing outcome. An example would be the government authorities who are normally only interested in your project or organization following the rules rather than whether you really completed a project successfully or not. As long as you do not violate any applicable laws and rules, they should be fine. Few stakeholders could even be interested in seeing the project fail and could be glad if testing showed up a lot of failures. These could be folks who are interested in maintaining the status quo and resistant to change that the project could bring.  It is important for the software testing group to identify who the testing stakeholders are, which of these stakeholders are supportive, who are neutral and who are not supportive.

Software Testing challenges in the Spiral Lifecycle model

-->

Having looked at the Sequential and Iterative models in the previous posts, let us now look at testing in the Spiral Lifecycle model. The spiral model is generally used in large, complex and expensive projects. Development activity proceeds via a sequence of prototypes that are designed, prototyped and tested. Learnings from earlier versions of prototypes are used as inputs in subsequent prototyping efforts. Spiral model may be considered as an incremental & evolutionary prototyping model. Like the agile models, software is produced early in the life cycle.

Some of the common challenges that the software testing group will encounter with this model are listed here. Firstly, by its very nature, the spiral model is based on the premise of change being constant. Similar to the agile models but more so in the spiral model, changes to the design, technologies or tools used to produce the software can occur widely. The testing team needs to adopt flexible practices in every aspect of its functioning to be both open and adaptable to changes. Testing cannot assume that a particular tool, technique or system will be used throughout the lifecycle. Spiral models are suited in situations where there are a lot of unknowns and risks are being analyzed. In such cases, an early prototype may employ a particular set of technologies or architecture. On evaluation, the decision may be to discard the existing design in favor of a newer design or a radically changed version. Testing needs to be flexible and able to move in step with the changes in development.

Secondly, testing in the spiral model needs to be exploratory in nature, at least in the initial stages. The purpose of the early prototype is to understand risks and explore unknowns. Testing needs to be flexible as well as be able to go deeper to explore specific problem areas as needed. In subsequent stages testing goals may change to more formal & standard testing including regression and related test types. The testing group needs to be able to handle the requirements of non-formal and formal standard testing requirements at different stages of the lifecycle.

Finally, due to the very nature of the spiral model, involving repeated prototyping and dealing with unknowns, accurate test planning and estimating can be a challenge. Given the complexity and degree of experimenting involved, working with predictable time-lines is not usually possible.

Over the course of the past three posts, we have covered some of the common challenges faced in Software Testing with each of the three Lifecycle models - sequential, iterative and spiral.

Software Testing challenges in the Iterative lifecycle models

-->

Iterative / Incremental lifecycle models, as the name suggests, focus on developing software in increments or chunks. Popular iterative models include the Agile methodologies such as Scrum, XP, etc. A common thread amongst the iterative models is that integrated and working systems are produced and delivered at the end of each iteration. Business functionality is divided into chunks. Each iteration delivers a chunk of functionality that is integrated and tested. From a testing perspective, the software testing group will get testable systems early in the lifecycle unlike a sequential approach. However, iterative and incremental models can pose their own set of challenges to the testing team.

The main challenge for testers in agile / iterative models is that the system is constantly changing. New code is being checked in regularly and testing cannot wait for or expect software that is in a final state. For the testing team, the software is a moving target. Software Testing teams need to adopt different approaches, tools and strategies to handle this level of change.

In iterative models, the riskier / more important functionality and features tend to be built in during earlier iterations / increments. Subsequent increments add more functionality on top of what was built in the previous increments. Given the amount of changes that can potentially happen in each increment, the risk of regressions is high. With each new increment, it becomes very important for the testing team to regression test all the features provided in the previous increments to make sure nothing is broken.

Another interesting facet of iterative development is that activities across increments can overlap. It is not usually the case that one increment completes entirely before the next one begins. For example, the testing team will generally be testing the current or previous increment's build in detail while the development team works on the next increment's features. Of course, while testers will also in most cases, be required to help with incremental testing of new features in the increment that the developers / programmers are working on, the primary responsibilities of the testing group is to thoroughly regression test the last increment's build plus the new features delivered then. This overlap can pose challenges in addressing bugs that the testing team identifies and time taken for fixing.

Software Testers also need to be aware that iterative models such as Agile are not really in favor of heavy weight processes or formal methods. There are extreme cases where the value of having testers is questioned. But again, that is the extreme. Most mature agile teams realize the immense value that testers can add in producing a quality product. Testers need to tailor their methods to suit the agile world.

Testing groups need to understand the fact that the organization does not really want "zero-defect" or "defect-free" software. While stakeholders will obviously not state this and will continue to ask for defect free software, the organization will not be ready to make investments necessary to reach that objective or even close to it. In reality, as we approach the objective of defect free software, costs keep increasing to a level (theoretically to flush out all the bugs in the system will cause costs to tend towards infinity) where organizations may not want to invest further. Finding the right balance between costs incurred and value derived is important.

In the next upcoming post let us look at testing in the Spiral Lifecycle model.

Software Testing in Sequential Lifecycle models (waterfall, v-model)

-->

Sequential lifecycle models involve building the system in a sequence of steps or phases. Common sequential lifecycle models are the Waterfall model and the V model. These models have been around for a long time and are sometimes referred to as the traditional lifecycle models.

In this post, let us look at the nature of issues these models can pose to testing, by first examining some of the characteristics of these models.

• The Software Testing phase in sequential models is slated to occur towards the end of the lifecycle
• These models tend to be schedule and budget driven with delivery dates usually being fixed
• For most projects it is hard to correctly make estimates across the different sequential phases for any sizable time frame

Software testing in sequential models are often subject to schedule compression. What is initially estimated may not be what is actually available or suffice for the testing team to complete its activities. When activities in any of the preceding phases of the chosen sequential model extend beyond estimates, it is often the case that towards the end of the project, the time available for testing gets cut back. Usually a trade-off between testing and delivery dates is necessitated. Often, the software testing group faces pressure to approve the release of the product by the delivery date even when the testing team has not received the time they originally estimated and planned for. However, when issues are reported from the field, the testing team is in the line of fire for not having caught all of these issues.

Schedule compression is not limited to the software testing team alone. Even product development teams face this issue. Schedule pressures can result in developers delivering poor quality artifacts to the testing team. Developer testing may be short-circuited too. The effect is that a considerable part of the testing time is spent on identifying, reporting and tracking defects that should not have been there in the first place. In such cases it may seem that the testing team is spending a considerable part of its time performing unit testing on the build that is delivered to the testing group rather than any higher level of testing which the team would have planned.

Sequential models require a fixed or near final set of requirements to be defined at the start of the project. Subsequent project phases including implementation and testing are based on the requirements defined at the outset of the project. Changes to the requirements will impact the testing group's plans. Any change will require the project to take a few steps back, incorporate the changes and be tested before moving ahead.

It is also the case that the testing team is not involved from the outset and testing is relegated towards its phase which is near the end of the software project lifecycle. There is little time for the testing group to be prepared. This will result in testing becoming purely reactive in nature with little scope for any preventive activities. The effectiveness and value of the testing team is reduced.

Effective test management can enable the group to handle the challenges mentioned above. In the next upcoming post we look at testing in the incremental and iterative models.

Software Testing in the Product Lifecycle

In this and subsequent posts, we look at Software Testing and how it fits in with the various Software Lifecycle models.

Software Testing is an integral part of the Software Lifecycle, irrespective of the type of lifecycle followed – sequential, iterative, spiral or incremental. How testing aligns itself will vary depending on the type of lifecycle selected. For example, in the case of a sequential model such as the waterfall or v model wherein the assumption is that the requirements are firmed up at the start of the lifecycle and  changes managed, the test team can adopt a requirements-based test strategy. With such a strategy, the test team is aligned at the outset in the lifecycle and begins test planning and development early.  Such alignment can enable early detection of issues / clarification of the requirements facilitating testing to play a preventive role. 

In the case of iterative / incremental lifecycle models such as agile methodologies, the test team receives requirements in increments at the start of a sprint or iteration. Here, the testing team can adopt a risk based test strategy to identify and prioritize risk areas. Test design & development happens just before execution. Here too, defect detection begins early and proceeds in short iterations through the project. However, the scope of testing to play a preventive role is reduced in such a lifecycle model. Test activities tend to occur in parallel with other activities  in the software lifecycle.

In upcoming posts, we look at each of the lifecycle models and how testing fits in.

The Qualities Of A Modern Quality Engineering Professional

The best quality professionals combine curiosity, technical depth, systems thinking, communication skill, and judgment. Modern QA is no longer sustained by test execution skill alone.

Software testing has always required curiosity and discipline. Those traits still matter. But the quality profession has expanded. Today's quality engineers work with APIs, automation frameworks, CI/CD pipelines, data, observability, security, accessibility, performance, and production incidents. The bar is higher, and that is good for the profession.

Curiosity

Strong testers want to understand how systems behave, how users think, how failures emerge, and where assumptions hide. Curiosity drives exploration beyond the happy path and beyond written requirements.

Technical Depth

Modern QA professionals need enough technical fluency to engage with developers and architects. That does not mean every tester must be a full-time developer. It means understanding APIs, logs, databases, architecture, automation, data flows, and failure modes well enough to ask useful questions.

Risk Judgment

Testing is infinite; time is not. Senior QA professionals know how to prioritize. They understand impact, likelihood, detectability, recoverability, and business context. They know when more testing is useful and when a different kind of evidence is needed.

Communication

Testing often produces uncomfortable information. Defects, weak evidence, missed requirements, performance risks, security gaps, and release concerns must be communicated clearly. The best QA professionals explain risk without drama and evidence without ambiguity.

Diagnostic Skill

A weak defect report says something failed. A strong defect report helps the team understand where and why. Diagnostic skill includes narrowing reproduction paths, collecting logs, identifying data conditions, attaching request IDs, comparing environments, and suggesting likely boundaries.

Creativity

Creative testing is not random testing. It is disciplined imagination. It asks how real users, unusual data, timing issues, integrations, permissions, and operational conditions might expose behavior the team has not considered.

Collaboration

Quality is a team responsibility. QA professionals must collaborate with product managers, developers, designers, SREs, security teams, support teams, and business stakeholders. Influence matters as much as individual execution.

Adaptability

Tools and delivery models change. Testers who stop learning become dependent on old workflows. Quality engineers who keep learning can move from manual testing to automation, from UI testing to API testing, from pre-release testing to observability, and from defect finding to quality strategy.

Professional Courage

Sometimes QA must say the evidence is weak, the release is risky, or the team is solving the wrong problem. Courage is not confrontation. It is the willingness to make risk visible when silence would be easier.

The modern quality professional is not defined by a tool or a test level. The defining capability is judgment: knowing what quality risk matters, how to investigate it, and how to help the team make a better decision.

Tester - skills needed for successful software testing (3)

We continue exploring the traits needed for testers to be successful in testing software. The previous post looked at traits 4-6. In this post, let us look at three more Software Tester traits.

Tester Trait 7: Good judgement (judgment)

There's a saying that good judgement results from experience and experience results from bad judgement! Good judgement when combined with the other tester skills, can make for highly successful software testing. Judgement involves elements such as deciding on what to test, how much to test, estimating the time it would take to test and taking a call if an issue is really a defect or if a bug is worthy of deeper pursuit. Using judgement to determine the extent of testing to be performed involves comparison of the current project with past projects for estimating the quantum of risk. While this trait can produce results, it results from experience and knowledge gained over time and across projects.


Tester Trait 8: Tact and Diplomacy

Software Testing involves providing information and often we carry "bad news". An important part of the testing job is telling developers that their code is defective, highlighting issues and possible causes. At a human level, it is like telling a parent that their baby is ugly. Contrary to popular belief that testers and developers must be at loggerheads, Software testers need to have a good working relationship with developers. Co-operation between both functions is key to producing a quality software product. Tact and diplomacy is important to both convey bad news, follow up for fixes and maintain cordial relationships. Successful testers know how to do the balancing act and deal with developers tactfully and professionally even in cases where the other party is not very diplomatic.

Tester Trait 9: Persuasive

This trait continues from the previously mentioned trait - tact and diplomacy. Once the tester breaks the news about issues in the code, a range of reactions can arise. One of the likely reactions to bugs that testers report could be that the reported issue is categorized as not being important/severe enough to warrant a fix. Bugs may be re-prioritized and downgraded or deferred to a later time frame or be documented as an open issue. Just because the tester thinks a bug must be fixed does not mean that developers will agree and jump on fixing it. If a bug needs fixing, testers must be persuasive and clearly state the reasons for requiring a fix in a specified time frame. In case of a stalemate, communicating effectively to stakeholders and getting their inputs may also be required. Persuasion goes hand-in-hand with the other traits mentioned earlier, to ensure issues are addressed appropriately. 

Coming up next is a neatly consolidated article on the top 10 skills required to be a successful Software Testing professional covering all the attributes we have seen thus far plus an extra skill.