Software Quality Engineering Journal: November 2009

Testing in the Agile World (Part 3)

Testing in agile is not something that happens at “the end” of the development or implementation phase. Testing happens as development happens. Incremental testing is the norm and increments of functionality that gets developed is tested and issues reported immediately. The short & quick feedback loop helps deliver better quality code and reduce cost of fixing defects much later when the cost of fixing them is higher. Also, the ability to have working and demonstrable piece of software at the end of each sprint is a huge benefit – customers and product owners can quickly review and “play around” with the developed artefact and provide feedback quickly. This helps ensure that the agile team is developing what the customer needs and also keeps the customer appraised of the team's progress in real time.

An important aspect of agile development is the ability to “release” after each iteration or sprint. A working copy of the product is expected to be ready for “release” at the end of each iteration. This ability to release frequently is important. It may be the case that the team may not wish to actually release after each iteration but having the capability and working towards delivering working software by the end of each iteration is key. Customers may choose to pick up a deliverable after an iteration (could be every few days or few weeks) and either review that the development is on track or even choose to deploy in increments. The agile team can get regular updates on their development and incorporate into their efforts quickly rather than wait for the complete product to be developed and then released to customers.

Customers get a better say in how development happens. The product owner can make decisions to even stop further development on some areas or suggest changes where needed. The focus on getting working software out at the end of each iteration also brings together the various functions together as a close knit team – everything from development to installation, documentation and testing needs to be taken care of rather than leave any item for later in the release. Issues are identified sooner and as stated earlier, the short feedback loop helps incrementally deliver better quality software faster.

Agile development also involves lesser documentation than traditional models of development. Agile methods focus on face-to-face interactions and meetings to keep the communication channels open and clear. In the Scrum methodology which we follow, daily stand-up meetings are conducted where all members of the agile team share their status updates, plans and impediments encountered. In addition, planning and retrospective meetings are held at the start and end of each sprint. Testers work along with their counter-part developers and help to regularly test every testable bit of work product providing regular feedback to ensure a better quality feature goes in. Communication on agile teams tend to be quick and direct, with agile methodologies favouring co-located teams and human interactions. It gets to be far more effective and easier to pop-in to your neighbouring cubicle and get something clarified rather than start an email thread and await responses.

Agile development requires a customer representative to be part of the team. This gets better than having to rely on a requirements document. You can always ask the representative for clarifications directly and get first hand feedback. Requirements are prioritized based on what is most important to the customer and listed in what is normally known as the backlog for the product. The agile team goes through the backlog list in order and picks up the items that they can commit to delivering within the iteration.

***

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.

Testing in the Agile World (Part 2)

Continuing from the previous post

In such a scenario, the role of individuals who consider themselves dedicated testers, may be questioned. When agile development already emphasizes practices such as test-first development, developers writing unit tests and so on, is there a need for dedicated or specialist testers on agile teams ? The answer is very much a resounding, Yes !

Testers bring to the table a range of special skill sets and abilities that help enhance the quality of the work product. Testers can perform testing that goes beyond the unit and component level tests which developers / programmers may perform. Testers on agile teams can, like their counterparts in the traditional models, add a lot of value by performing tests from a customer / end user perspective; develop and execute a variety of different test types such as performance, functional, security, interoperability, compatibility and so on.

In our group at my current organization, we follow an agile development method called called Scrum. In brief, product development activity happens in short iterations called “sprints” which may be of a few weeks duration (generally up to ~4 weeks). Members from the different functional groups come together and form a single team that works together on delivering the features which the team commits to. The list of features, enhancements, defects to be addressed is put up in a prioritized list known as the backlog. The sprint team picks up tasks from this list which members think they can accomplish during the duration of the sprint. The scrum process is co-ordinated and facilitated by an individual who dons the role of a “scrum master”. Daily stand-up meetings happen where members share information on their achievements since the last meeting, any obstacles faced and plans for the next day. Reports such as burn down charts and information captured during the meetings help introduce a greater degree of transparency into the development activities when compared to traditional models that were followed. Testers are paired with developers, normally a tester works together with a developer on a particular area and works in tandem on producing the product.

***

Testing in the Agile World (Part 1)

In this and subsequent few posts, i shall post content from my paper on Agile testing which was recently published by the Quality Assurance Institute. We start with a look at the concept of Agile development and progress towards testing in the agile context with specific emphasis on the Scrum model.

Agile Software Development refers to a philosophy, a mind-set based on iterative development. Agile methodologies support the agile values based on the agile philosophy. The Agile Manifesto lists the following agile values

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The manifesto goes on to state that while there is value in the items on the right, agile development values items on the left more.

Greater transparency into how software is produced, better predictability, faster time-to-market, frequent releases, increased productivity, higher levels of quality ... all this and more, lure organizations that have been following “traditional” development models to “try out” agile methodologies.

Traditional methods of development generally follow a set of models that usually define phases of activity involving release planning, requirements definition, sign-off, design, implementation, testing and so on. Work products are passed on from one phase to the next. Experience shows that these models tend to involve release cycles that are fairly long, thereby delaying the time-to-market and being pretty inflexible to changes through the development lifecycle. The general aim tends to be to deliver all functionality captured in the initial requirements specification as a completed finished product. The testers in this case prepare for testing by way of creating test plans based on the requirements & other documentation that are available and then await the finished work product after the implementation is complete to begin formal testing.

Agile methods however, introduce a paradigm shift in how products are produced. Development happens in short cycles of a few weeks duration; at the end of a cycle a working product or artefact is ready and available to be displayed to the customer and even shipped if need be. The product owner / customer sets the quality criteria for each iteration or sprint. This definition of quality signifies what is important from a customer's view point rather than what a formal testing team may choose to define. For example, it may so happen that issues which testers might think are important to be addressed immediately may actually be deferred to a later iteration if the customer does not think it is a priority. Agile development would not usually encourage specialized roles, such as a tester or developer. Members from various groups are drawn together to form an agile team. This team could comprise representatives from development, testing, technical writing, internationalization, etc. as required for producing the product.

***

De-centralized / distributed test teams

Here, testers are organized by line of business or products. Having testers assigned to specific products enables them to develop subject matter expertise to a level that is not usually possible when operating in a centralized test team. Test coverage and effectiveness of testing is enhanced since testers have greater knowledge of the product and use that knowledge to test wider & more complex scenarios. The interaction between development and testing tends to be better. Both groups mostly work together closely and interact often through-out the product life cycle. Processes for engagement and interaction between functional groups is pretty well set and happen more smoothly than a centralized model.

Testers normally report into the development organization or application owner. Testers, though considered peers with development at a product / project level, are often viewed as part of the development engineering team at a higher level.

Resource constraints can more easily affect test teams in such a model, since there is'nt a pool from which resources may be drawn when needed. Managing resources through the demand highs and lows can be challenging. Also, processes, tools and techniques followed tend to be local to individual test teams, with little consistency across product groups. Some element of redundancy exists, while issues could crop up when trying to integrate different products. Generally owing to the smaller size of de-centralized teams, the opportunities to specialize may also be fewer.

Having looked at both the centralized and de-centralized approaches, organizations may choose to follow either of these or even a mixed approach by centralizing some areas that can benefit from a central group while de-centralizing areas that would work best by being part of the product group. Irrespective of the approach taken, the testing team needs to be allowed to function as independently as possible, be responsible for important decisions affecting testing and receive sufficient senior management support.

Centralized QA Teams: Benefits, Drawbacks, and a Better Hybrid Model

Centralized QA teams can create consistency, shared expertise, and stronger standards. They can also become bottlenecks if they are separated from product decisions and treated as a downstream service.

The right operating model depends on scale, product complexity, regulatory needs, team maturity, and the depth of quality skills across engineering.

Where centralized QA helps

A central team can build reusable automation frameworks, performance testing capability, security-testing awareness, test-data strategy, tooling standards, metrics, training, and governance. This is especially useful when many product teams need capabilities they cannot each build alone.

Central QA can also provide independent risk assessment for high-impact releases, audits, migrations, and platform changes.

Where it breaks down

The model fails when product teams throw work over the wall. QA receives late builds, limited context, unstable environments, and pressure to certify decisions already made. That creates delay and weakens quality ownership.

A central team can also drift into process policing if it lacks technical credibility and close engagement with engineering realities.

The hybrid model

A better model embeds quality ownership in product teams while keeping a central quality engineering function for standards, coaching, specialist capability, and cross-product risk. Product teams own day-to-day quality. Central QA raises the floor and helps solve problems that exceed one team's scope.

Centralization should amplify quality, not isolate it.

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.

Software Testing Certifications: Useful Signal, Not a Substitute for Skill

Software testing certifications can be useful, but they are not proof of professional competence by themselves. They show that a person has studied a body of knowledge. They do not prove judgment under delivery pressure.

That distinction matters for hiring managers, QA leaders, and testers planning their careers.

Where certifications help

A certification can provide shared vocabulary, exposure to formal testing concepts, and a structured learning path. For people entering the profession, that foundation can be valuable. For organizations, it can help establish baseline language around test levels, test design, defect management, and risk-based thinking.

Certifications are also useful when clients, regulated environments, or consulting contexts expect a recognizable professional credential.

Where certifications fall short

The hard part of QA is applying judgment. A tester must decide what matters, ask better questions, investigate ambiguous behavior, communicate risk, and adapt to architecture, data, tooling, and business context. That cannot be fully measured by an exam.

A certified tester who cannot reason about risk may contribute less than an uncertified tester with strong product understanding and disciplined exploration.

A practical career view

Use certifications as one part of development, not the destination. Combine them with hands-on testing, automation literacy, API knowledge, SQL, logs, accessibility basics, security awareness, performance fundamentals, and strong defect communication.

The credential may open a door. Skill, judgment, and credibility keep you in the room.

How this shows up in QA leadership

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.

Centralized Software Testing

A common question that arises amongst testing professionals is around the ideal way to organize test teams - should organizations have centralized test groups or de-centralized test groups ? In this and the next set of posts, let us look briefly at each of these types of test group organization as well as some of their benefits and drawbacks.

Today's post will look at "Centralized test groups" and their benefits.

Centralized test groups comprise a pool of resources that are shared across applications and projects. Each tester may work on one or more projects at a time. While developing a centralized testing group, it is important to assemble testers with a diverse set of technical and other skills. Testers may get assigned to projects on a part-time or full-time basis depending on the project requirements. As the need for testers increase, more specialized testers may get assigned to support the project. Centralized test groups have a defined test leadership hierarchy in place.

Advantages

Process consistency - deployment of standard testing methodology & processes helps improve quality and efficiency of testing
Benefits from economies of scale and centralized spending
Hardware and software licensing consolidation helps reduce costs
Centralized groups can more easily & consistently implement practices such as CMM, continuous improvement and common metrics
Allows better focus and specialization in test processes and tools
Affords flexibility in utilization of resources. On-demand allocation of resources to projects ensuring better resource utilization
Better sharing & leveraging of best practices
Better career paths for testers to build a “career” in testing. More opportunities for testers to gain expertise and skills on a wide range of applications, tools and techniques
Testers have more opportunities for specialization
Testers have better mentoring opportunities from more senior testers in the centralized organization
Better objectivity in testing. Since testers do not report into a development organization or project managers, they remain insulated from any outside pressures or influence. Testing can better position itself as a peer to development in the organization's reporting hierarchy

Blue Ocean Strategy

I recently participated in reviewing the book - “Blue Ocean Strategy” and found it to be a pretty interesting exercise. The book is about business strategy and is written by W. Chan Kim and Renée Maubborgne of INSEAD business school. Here's a brief summary.

The book classifies the business universe as consisting of two distinct kinds of spaces - red and blue oceans. Red oceans represent all the industries in existence today-the known market space. In red oceans, industry boundaries are defined and accepted, and the competitive rules of the game are well understood. Here, companies try to outperform their rivals in order to grab a greater share of existing demand. As the space gets more and more crowded, prospects for profits and growth are reduced. Products turn into commodities, and increasing competition turns the water bloody.

Blue oceans denote all the industries “not” in existence today-the unknown market space, untainted by competition. In blue oceans, demand is created rather than fought over. There is ample opportunity for growth that is both profitable and rapid. There are two ways to create blue oceans. In a few cases, companies can give rise to completely new industries, as eBay did with the online auction industry. But in most cases, a blue ocean is created from within a red ocean when a company alters the boundaries of an existing industry.

Blue oceans differ from traditional models which are focused on competing in the existing market space. While the term “Blue Oceans” may be new, the concept has always been around. Take a look back over the past century and try to find out how many of today's industries were then unknown. You would notice that many of today's fundamental industries such as automobiles, aviation, petrochemicals, pharmaceuticals and many others were not just unheard of but people then would not have even thought these industries were possibilities. If a hundred years seems long, try looking back at a shorter period of a few decades ago and try to find the answer to the same question. You are sure to find several new industries – such as mobile phones, biotechnology, satellite television, internet start-ups and many more that were not around then. Now, look ahead at the next few decades and ask yourself the question – how many industries that are unknown today will exist in the future – a decade or two from today ? If the past is any indicator of the future, the answer would be obvious – we are sure to have many new industries that we are not aware of now.

Organizations have a tremendous capacity to create new industries and recreate existing ones. Various factors such as rapid technological advances, enhanced industrial productivity, falling trade barriers between nations and regions, ready global availability of information on products and prices – and such others are contributing towards the contraction of niche markets and monopolies. Prospects in many established market spaces a.k.a. Red oceans are steadily declining. This situation has speeded up the commoditization of products and services, led to price wars and reduced profit margins. With commoditization, most brands across categories tend to become more and more alike. This leads to consumers increasingly basing purchase decisions on price. In overcrowded market spaces, differentiation between brands becomes harder.

So, why do organizations still focus their strategies greatly on the red oceans ? A possible answer would be to trace the roots of corporate strategy - which seems to be heavily influenced by military strategy. References to officers, headquarters, troops, front line, etc. are borrowed from the military. Strategy in the military context is all about red ocean competition – fighting an opponent and taking over the battlefield or limited territory. Blue ocean strategy is however, about doing business where there is no competition. It is about creating new land and not dividing existing land. Red ocean focus implies an acceptance of the limitations of war – limited land and the requirement to beat an enemy to be successful.

Blue ocean strategy rejects a fundamental principle of traditional strategy – of a trade-off between cost and value. According to conventional strategy, organizations can either create greater value for customers at a higher cost or create moderate value at a lower cost. The relationship between value and cost seems to be proportionally driven, higher value driven by higher cost and vice versa. However, organizations that have successfully followed blue ocean strategy pursue both value differentiation and lower costs together and not as a trade-off. Blue ocean strategy works when organizations adopt a total-system approach wherein all systems of the organization such as the value offering, price and costs are well aligned. Observance of companies that have created blue oceans show that they are able to benefit without facing strong challenges for over a decade. This is due to the nature of blue ocean strategy which creates significant economic and cognitive barriers to competition.

Both blue and red oceans have always existed and will continue to do so. When organizations understand the rationale behind both types of strategies, they will be better able to balance their efforts across both strategy types and create more blue oceans.

Advantages / disadvantages of the Waterfall model

Continuing from the previous blog entry that talked about the Waterfall model, this post presents some of it's advantages and disadvantages.

Some advantages of the Waterfall model

Clearly divides the problem into distinct phases that may be performed independently
Simple concept
Natural approach to solving the problem
Fits well into a contractual setting where each phase is considered a milestone

Some of the drawbacks of the Waterfall model

In many projects, the strict sequencing of phases advocated by the waterfall model is not followed. The model assumes that one builds an entire system all at once, perform end-to-end testing after all the design and most of the coding is completed. In reality, feedback from downstream phases are passed upstream to make refinements. For example, while implementing a design, issues with the design may be observed which would require the design to be improved upon. Similarly during other phases. There could be quite a few such iterations to firm up requirements, design and get to actual implementation.

Evidence of failures in practicing the waterfall model comes from one of its most frequent users, the US Department of Defence (DoD). The DoD required most of its projects to follow the waterfall model which was documented in the standard DoD STD 2167. A report on project failure rates showed that up to 75 percent of the projects failed or were never used. Subsequent analysis recommended replacing the waterfall model with an iterative and incremental approach to development.

Some of the assumptions in the waterfall model include

A well-defined set of requirements is available. These are assumed to be reasonably well stated and the attempt is to freeze these early. The onus is then on making sure these requirements are well-understood and implemented
Any changes to defined requirements would be small enough to be able to be managed without having to make significant changes to the development plans or schedule
Software development and associated research & development activity can fit into a predictable schedule
Integration of the various pieces of the monolithic system, their behavior, performance and other attributes are predictable and that the architectural plans and designs would be able to handle any integration issues

In real world development, it is not feasible to assume the above. Having a clear set of requirements firmed up at the outset is nearly impossible. Assuming that requirements thus defined are unlikely to change much is another fallacy. Experience shows that requirements do change and in many cases change significantly requiring re-work and re-design. The greater the time between gathering requirements and delivery of the finished product, the greater the likelihood of changes to the requirements. While trying to integrate the various pieces of the system, even thorough analysis and plans would not be able to accurately predict nor control the process. Often, assumptions made around integration tend to be wrong. Any upstream slippages in schedule tend to compress the time available for later phases and importantly for adequate system integration testing. The model could also lead to early finalization of technological and hardware related decisions which may not turn out to be the most appropriate. Real world observations of software development highlights the fact that the “big-bang” approach of trying to deliver a monolithic solution is too risky and prone to cost and schedule overruns.

The Waterfall model

The waterfall model is generally attributed to Royce (1970). The model encourages the product development team to specify what the software is supposed to do (gather & define requirements) before implementing the system. Product development is split into multiple sequential steps (design, implement, test) with intermediate deliverables leading to a final product.

To ensure proper execution with good quality, each step has defined entry and exit criteria. The ETVX (Entry-Task-Validation-eXit) model proposed by IBM fits the waterfall approach wherein each phase may be considered as an activity structured using the model.

The waterfall model may be viewed as a divide-and-conquer approach to development. It allows for tracking project progress across phases and forces the organization to adopt a more structural approach to developing software. The model also requires documentation to be generated which will be used to test and maintain the system. The waterfall model emphasizes careful analysis before building the system. The idea is to avoid wasted effort in building something which does not meet the customer's requirements. Hence, attempt is made to fully specify and finalize customer requirements as early as possible. Requirements are documented in the requirements specification document. In subsequent phases, “verification” activities are performed to ensure conformance to requirements listed in the requirements specification document. A problem with this sort of reliance on the requirements document is the possibility of incomplete or incorrect requirements being specified. Adequate “validation” with the customer is required.

At a high level, the waterfall model comprises the following phases.

Requirements
Design
Development / Implementation
Testing
Maintenance

In the next blog post, we shall briefly look at some of the advantages and disadvantages of this model.

Dealing with information overload

Continuing from the previous post, help is at hand for dealing with “information overload” and the problems it presents. Various technological methods are available to deal with the problem and to aid both individuals and organizations. In addition there are some non-tech methods that involve changes to mind-set and culture, requiring individuals and organizations to modify current thinking and behaviour towards managing information.

Listed below are some tips, summarized from the HBR issue, to “reduce e-mail overload”.

As a recipient

To avoid constant distractions, turn off automatic notifications of incoming mails. Establish specific times during the day when you check and take action on messages
Do not waste time sorting messages into folders. Today's powerful inbox search features make that unnecessary
Do not highlight messages you intend to deal with later by marking them as “unread”. In email clients such as Microsoft Outlook, accidentally typing in the wrong keyboard shortcut will irrevocably designate every item in your inbox as “read”
If you will not be able to respond to an email for several days, acknowledge receipt and tell the sender when you are likely to get to it

As a sender

Make messages easy to digest by writing a clear subject line and starting the body with the key point
To eliminate the need for recipients to open very short messages, put the entire contents in the subject line, followed by “eom” (end of message)
Whenever possible, paste the contents of an attachment into the body of the message
Minimize email ping-pong by making suggestions such as “should we meet at x time ?” rather than asking open ended questions such as “when should we meet?”
Before you choose “reply to all”, stop and consider the email burden on each recipient
Send less email: an outgoing message generates, on average, roughly two responses

The above represent a few of the many suggestions and tips to manage information. There's a lot more information available online on how to manage information overload !

Information Overload

Based on the Harvard Business Review, September 2009 article on “Death by Information Overload”

The article talks about the phenomenon of information overload which most of us would be familiar with. I have attempted to summarize points from the article for the benefit of readers of this blog.

In the knowledge economy, information is considered to be our most valuable commodity. And, these days it's available in infinite abundance delivered automatically to our electronic devices or easily accessible. Current research suggests that the surging volume of available information and its interruption of people's work can adversely affect not only personal well-being but also decision making, innovation and productivity. Today, information rushes at us in seemingly infinite formats – email, text messages, twitter tweets, facebook alerts, voice mail, instant messaging, rss feeds and so many other ways. People are drawn towards information that in the past did not exist or that we did not have access to earlier but now that it's available, we dare not ignore.

What does this deluge of information mean for individuals ?

The stress of not being able to process information as fast as it arrives – combined with the personal and social expectation that, say, you will answer every message – can deplete and demoralize you. Edward Hallowell, a psychiatrist and expert on attention deficit disorders argues that the modern workplace induces what he calls “attention deficit trait” with characteristics similar to that of the genetically based disorder. Also, a study commissioned by Hewlett Packard reported that the IQ scores of knowledge workers distracted by email and phone calls fell from their normal level by an average of 10 points – twice the decline recorded for those smoking marijuana ! While a section of people feel overwhelmed with the information overload, there are some who seem to be stimulated by it and display what is termed as “information addiction”. An AOL survey of 4000 email users in the United States reported that 46% of the email users surveyed were “hooked” on e-mail. We must also be aware of the tendency of always-available information to blur the boundaries between work and home thereby affecting personal lives in unexpected ways.

What does this information overload mean for companies ?

An email notification or a message alert means more than just time spent reading and responding to the message. There's also time required to recover from the interruption and re-focus attention. A study by Microsoft researchers tracking the email habits of coworkers found that once their work was interrupted by an email notification, people took, on average, 24 minutes to return to the suspended task. Why is so much time wasted if all that needs to be done is to simply read a message? Studies further indicate that dealing with the message was only a portion of the time off task. People used the interruption as an opportunity to read other un-opened messages, engage in unrelated activities such as surfing the web, text-messaging, etc. Also, surprisingly over half the time was spent cycling through open applications on their computers to determine what they had been doing when interrupted and reestablishing their state of mind once they had finally arrived at the application they had initially abandoned when they were interrupted. Distractions caused by email and other types of information also have more subtle consequences. Research has identified reduced creative activity on days when work is fragmented by interruptions.

While it is not easy to quantify the costs of the consequences of information overload, one calculation by researchers put Intel's annual cost of reduced efficiency, in the form of time lost to handling unnecessary email and recovering from information interruptions, at nearly $1 billion. The researchers go on to say that organizations ignore that kind of number at their peril.

In the next post, we'll look at some ways to manage this information overload.

Can test automation run without human intervention ?

A common assumption with regard to test automation is that automated test suites can be executed with zero human intervention. After all isn't that what the tool vendors claim their products can do. Theoretically, you should be able to move your human testers to other tasks once they complete automating their tests.

In the real world, automation does not make human testers redundant. Almost all automation test suites, require human intervention in order to remain effective. Consider two simple instances requiring skilled human intervention - analyzing the results of automated test execution and maintaining the automated tests. Also, one must realize that practically getting a complex automation test suite to execute without issues is itself a difficult task.

When the underlying product being tested changes, it is but natural that the automation which tests the product is affected. Even seemingly minor changes to the product, can require fixes to the automation tests. Regular monitoring of changes and the automated tests requires skilled human testers. In the real world, it is common to find that various external factors such as issues with the file system, memory, networking, product dependencies, etc., can also easily disrupt smooth execution of automated tests.

We must also remember the fact that test automation development is very much a software development project by itself and must be treated as such. Like any software that is developed, automated tests are also not bug-free. Regular testing of the automated tests and monitoring of their execution is essential so you can know whether your automated tests are doing what you expect it to be doing. Any changes to the automation tests must follow a similar process akin to a comparable change in the software product, requiring reviews and testing to make sure fixes do not introduce additional defects.

Exploratory Testing: Structured Learning, Not Random Clicking

Exploratory testing is one of the most misunderstood practices in software testing. It is sometimes dismissed as informal clicking, but strong exploratory testing is disciplined, focused, and deeply professional.

The tester learns the product, designs tests, executes them, interprets results, and adjusts direction in real time. That flexibility is exactly why exploratory testing finds issues that scripted checks often miss.

When exploratory testing is valuable

It is especially useful when requirements are incomplete, workflows are complex, user experience matters, integrations are uncertain, or the team suspects risk that has not been captured in test cases.

Exploratory testing is not a replacement for automation or regression coverage. It complements them by investigating the unknowns.

How to make it credible

Start with a charter: what risk, workflow, or question will be explored?
Use realistic data, roles, devices, and environments.
Take notes on coverage, observations, defects, and unanswered questions.
Capture evidence: screenshots, logs, request IDs, data records, and reproduction details.
End with a summary that separates findings from uncertainty.

The senior tester's advantage

Experienced testers build mental models of how software fails. They notice inconsistent wording, strange delays, suspicious defaults, brittle permissions, unclear recovery paths, and data states that developers may not have considered.

Exploratory testing turns that experience into useful product evidence.

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.

Agile testers ... role and requirements

Given the close association of testers with developers in agile, and the nature of incremental testing of partial work products, the tasks that testers perform may sometime seem hazy. Would testers do the unit testing on the partially implemented or incremental bits of code ? Or would testers duplicate the unit tests that developers have already run ?

The role of testers in agile is not to perform the unit tests of programmers nor to duplicate the unit tests that developers perform. Agile testers perform a significant amount of manual (yes, manual) exploratory type testing. The purpose of these tests is to reveal issues which the unit tests would not have discovered. The exploratory tests need to be as wide as possible, meaning they need to get to as end-to-end an effort as possible. Given that unit tests focus on the specific module or area of code, the exploratory tests which focus on the interactions between modules and user scenarios tend to throw up issues that were not found earlier. Such end-to-end tests find issues quicker.

For testers to be able to successfully operate in an agile environment, it is important that they be familiar with the tools-of-the-trade. Testers need to know the language used in development, be able to checkout and build the source code, work with the development environment (IDEs, version control, continuous build integration systems, unit test frameworks such as xUnit, etc), be able to configure the system and its dependencies, wherever needed write code / scripts to workaround any as yet undeveloped interfaces or harness, add to the existing automation suites as needed, be able to work together and communicate comfortably with programmers.

Agile Testers: The Skills That Matter on Modern Delivery Teams

An Agile tester is not simply a manual tester working in shorter cycles. The role requires earlier involvement, stronger collaboration, better technical awareness, and the ability to produce useful feedback quickly.

The tester's value is no longer defined by the number of test cases executed at the end of a sprint. It is defined by the quality of risk information the team receives throughout delivery.

Skills that matter

Questioning requirements before they become expensive code.
Using examples to clarify expected behavior and edge cases.
Understanding APIs, data, logs, automation, and CI/CD basics.
Exploring workflows where user behavior and system behavior meet.
Explaining risk clearly without creating unnecessary drama.

The collaboration shift

Agile testers work closely with product owners, developers, designers, support, and operations. They review stories, challenge assumptions, help define acceptance evidence, and give feedback on partial work.

This requires confidence and humility. The tester must be willing to challenge weak thinking while also understanding delivery constraints.

What separates strong Agile testers

Strong Agile testers do not wait for perfect documentation. They create clarity. They do not complain that automation is missing; they help the team decide which checks should be automated and where. They do not report only defects; they report confidence, uncertainty, and options.

The Agile tester is a quality partner, not a release gatekeeper.

How to apply this inside an Agile team

The practical move is to bring this thinking into refinement and sprint planning. Before implementation starts, ask what risk the story carries, which examples clarify the expected behavior, and what evidence will be needed before the work can be considered releasable.

Agile quality improves when testers influence the conversation early. If QA only reacts after development is finished, the team may be using Agile ceremonies while still operating with a late-inspection quality model.