Been a looong time since i sat down to blog, (assumption being that you need to go out and learn something new to blog something new). After another burst of heavy testing, i gathered a few essentials of writing good perl scripts for automated testing. Here are a few observations. I hope to continue this serious……
1. Logging is everything - This is one obvious thing that most automation framework developers dont concentrate much on. As a QA person the application log file dump is the first place we go to track/analyze a defect. Similarly when an automation perl script is developed a standardized log record of the various tests and outcomes is very helpful. A good format for (found in most standardized logs would look something like this:)
<timestamp> <Tag>: <Descriptor>
The Tag should be a finite list of callouts like: Fail, Pass, Info, Checkpoint etc.
This is purely for the puropose of running overall searches when you log files become huge. For example, after every run of the script, the tester would be interested in Fails (obviously). This is where these tags
come handy. A simple search for “Fail” would tell me where all the test has failed.
2. Non-interactive automation scripts: These are cases where the user inputs (if any) are recorded into .conf (config files). This helps “silent runs” of the test scripts. Designing good config files are very important. Be sure to provide flexibility of ignoring comments and blank while parsing config files for parameters. See a sample perl code snippet below
s/#.*//; # ignore comments by erasing them
next if /^(\s)*$/; # skip blank line
chomp;
push @test_cases, $_; # push the data line onto the array
Another possibility would be to ignore comments at the end of a line also like:
[test_case_login]
username=mike #place where the username goes in
password=gogogo #place where the password goes in
From a readability perspective, provide users of your automation framework to have such comments in their config files, (make sure you handle these types of comments also). Checkback with me if you need a code snippet for that (Exercise for the reader
Feliz Navidad
Feliz Navidad
Feliz Navidad
Prospero año y Felicidad
I want to wish you a Merry Christmas
I want to wish you a Merry Christmas
I want to wish you a Merry Christmas
From the bottom of my heart
As a continuum of my post on test approach best fit vs first fit, thought id present Heuristictesting as a means of getting this done….
Question is “What is heuristics”
Well, a heuristic is a rule of thumb solution to a problem that may qualify as the solution but need not necessarily be so….. This a terminology where emphasis lies on the potential of a thought, approach or method to be come the solution for a problem.
How does this help testing…… Well QA and testing has reached very appreciable maturity levels the worldover (barring India ) that for any given problem posed you have a sizeable set of solutions as compared to what you would have 10 years back. Let say i want to do funtional testing. There are umpteen number of options at hand like the following:
An automated solution ( just because a testing can be automated it need not be)
The possibility of using my own custom scripts.
Possibility of using COTS products ( high industry affinity)
Now heuristictesting is a methodology where the set of n possible solutions are all given equal importance initially. Then begins the probing stage where the validity of accepting any of these n solutions is questioned and a process of elimination gets kicked off. Darwin says “The fittest will survive”. Well if thats true for the cosmos then why should not hold true for TestingMethodologies ?
The biggest truth is “Winrunner need not be the best solutions for your functinal testing requirements just because your QA Consultant know only that !!!!! ”
Sorry if that came across too hard…… but then in many cases i have seen the following classic case “My carpenter knows how to use the only the hammer and i want him to put in a screw. So he bangs the bejesus out of the screw till it goes in….. End result i have a wall that looks like its survived world war II……… and we give him an award for ontime service delivery but failed to realize that the next day a painter and a mason will have to come in for damage control post deployment………” Now i be that sounds like a familiar story…….
This is where we do Heuristictesting where the primary focus is not on getting A single solution but to ascertain what options we have. Then we get around to finding our best option after careful analysis by questioning the authenticity of each of our options and let the fittest solutions emerge as the winner….
A picture is worth a thousand words…… Presenting the synopsis of what i mean
The nut bolt analogy would give u a small idea of how this is relevant to testing. There is always a set of N possible ways to test and application/product. This is the “superset of all solutions”. Out of this a small subset can be derived by using filters like
Feasibility
Compatibility
Efficiency
Capability
Time
Once this subset has been derived, we reach the set of n possible testing solutions. Now in most delivery models that i have encountered, the focus of the testing group is to find out “a” solution rather than “the” solutions. Especially in the Indian IT scenario testers are highly susceptible to the “tunnel vision syndrome” where the first solutions that rings a bell is pursued.
What do I do about it?
Well for starts here are a few pointers:
To start creating an overall strategy, have the best testers on-board work in silos.
DO NOT rely on the collective intelligence of the team at this stage. That will come in later.
DO NOT interfere with the independent thought process of the the “silo’ed testers”.
Once individual approaches are derived, bring the team to the table.
Battle mode: This is where “collective intelligence” begins. Discuss the various approaches on table.
Survival of the fittest: Darwinian theory will do the rest for you. The best will emerge as none of the “silo approaches” but as the common maximum of the best approaches put forth by each tester.
This is how you can ascertain the “best fit” test approach and NOT pursue the first stray thought.
Testing principle: Excellence is always instilled never inbuilt.
Myself & jOHn (a.k.a “the pikey” cos he’s watched snatch one too many times n takes the software down in the first punch )were sitting down to our usual boxing match on software testing. They say tha’ testing is never complete. Well this is what we made of it tha’ day…..
Let’s start at the very beginning, a very good place to start. I have this code snippet that I have boxed into a wonder software. This is wha’ it does “Find the sum of 2 numbers”. Now if the world of software testers out there say that we could all sit and test it for a decent amount of time but still not ship it bug free, its time we hung up our boots
So this is the anthem, “Theoretically the number of bugs in an application/software is a finite number. The process of testing uncovers these bugs and their numbers go down. Hence mathematically there is a point in time (which does not tend to infinity) where there are actually 0 bugs in the software under test.”
The loudest outcry against this is that “time is your biggest enemy”. Most software development projects do not/cannot afford the time factor to reach that stage of zero defects. Most commercial testing is hence forced to stop at the light blue zone. The pink zone is classified as “phantom defects” and left to be.
Hence the job of software testing needs to re-classified from that finds bugs to one that also finds the time to find bugs. Let a so called “phantom bug” be just because we didnt get the time to do it is inexcusable (Sounds kinda like a developer saying that he didnt implement only 90% of the functionality cos that all the time he had).
This is where we require approaches and philosophies to improve test efficiency. Software testing needs to be a defect-time function. Below is a proposed methodology to increase your testing efficiency called the Weighted GraphMethodology.
The normal process followed for execution of test cases manual or automation is to follow the sequential order of test case as presented in the overall test plan for the concerned module. The common order of cataloging test cases in the test plan for a particular module would be to group them by functionality or by the common factors of the various test scenarios involved. This is to ensure that the designer of the test case does not miss any valid test scenario. The purpose of the approach which is presented in the following sections addresses the following problem area which is typically encountered.
“Tester xyz is handling the testing of a particular module which encompasses 5 broad functionalities. The test plan he uses has test cases grouped into these 5 categories and presented sequentially in his test plan document. He is scheduled to complete testing of the module in 10 days. He starts off execution of test cases sequentially and ends up repeatedly executing test cases relevant to the first functionality to completion and so on.
Assumption: Of the 5 functionalities assume the first 3 are extremely bug free while the 4th and 5th are extremely buggy. Since tester xyz will spend the major part of the early period testing the first 3 modules sequentially he would take longer to zero in on the bugs hence delaying the reporting of bugs leading to delayed cycle times where the development team would be waiting on him during the early period.”
The weighted graphmethodology modifies the process of test case execution as follows. The module to be tested is first represented in the format of a weighted graph for example:
Where the leaf node represent the different functionalities bundled in the module. The squares in blue represent the weights of each limb of the graph in the beginning (here 0). The cylinders show the subset of test cases that can be tagged to each of these functionalities.
To begin execution of test cases using weighted graphs; QA first develops a script which performs the following:
1.Pick a test case using a probabilistic approach depending on the weight of the limb from any one of the subset of test cases for all the functionalities.
2.The tester then executes that test case either manually of via automation scripts.
3.The result of the test case namely “pass” of “fail” is communicated to this master script.
4.If the test case fails then the script increases the weight of the limb for that functionality by a factor say 1.
5.In the next iteration of the above steps the probability of a test case from the limb with more weight being picked is higher.
6.The above steps repeat till all test cases have been covered.
The weighted graph approach is beneficial because the tester ends up executing more test cases that are tagged to a possibly buggy module hence the ratio of the number of defects identified to the number of test cases executed increases. Hence the defects in a module are identified at the early stages of testing. This translates to reduced cycle times and more throughput for the testing activity.
As for pikey…..well he now wants to take the software down with every punch
The most critical component where about 70-90% of QA efforts are concentrated in testing data intensive systems is a “data processing/ transformation engine” which can be identified as a “common critical component” of all these systems. This lion share of testing efforts is commonly concentrated around this engine which forms the core of such systems since all these systems are in place to process the streamed data into usable information.
From observations of such systems any “data processing/transformation engine” is governed by a set of data transformation rules whose complexity can range from low to extremely high depending on system design.
The common test automation approach for such projects would be to automate the verification and validation of the transformations that occur to the data since it forms a critical component of the system and huge testing efforts are concentrated around the same. A common yet wrong approach noticed to automate the same is to mimic the end to end transformation rules governing each module of the system using test scripts and performing a “parallel feed” of the candidate test data through the QA setup and test script and compare the outputs of the same.
QUESTION: If a QA personnel can mimic the end to end transformation rules governing a module for the purpose of testing the same and certify a bug free test script, cant the code be ported to be in-place within the application for a bug free rollout?
2.Proposed Approach
An alternative approach to automate the testing of the same; referred henceforth as the reverse tree parse methodologyon a high level is described as an approach to invert the parsing of such transformation rules algorithms so that QA would be undertaking a bottom up parsing technique.
In this approach the relevant part of a transformation engine is converted into a flow diagram. The flow diagram is then reverse parsed to generate and codify an optimum number of reverse parse trees which will then be predictive parsed to validate the transformation scenario and arrive at certain subset of “base states” which denote a passed test case. In this approach QA would be adopting a “inverted logic flow” to validate the scenario. The plus point of this approach being that the test scripts would be able to not only predict the validity of a test case but also give pointers to what “base scenarios” would generate the current output.
3.Where do we start???
The following section attempts to do a step by step walkthrough of adopting the approach.
1.Modularize the transformation rules: Every transformation engine or the design specification governing them can be classified into modules such that for every module we have a finite set of rules governing the transformation of the data relevant to the module.
2.Define the finite set of relevant rules: Depending on the complexity of the transformation rules the optimum approach to maintain the modularity of the automation effort would be to identify andisolate every single rule governing the relevant module. This would form the superset of all rules within the transforming logic.
** Rules can be classified into the following broad categories:
ØRules that are independent of all other rules.
ØRules which act as the “invoker” of other rules.
ØRules which are “exclusivelyinvoked” by other rules. They don’t have independent existence.
ØRules which act as “invoker” at times and as being “invoked” at other times.
Irrespective of the classification of the rule; every rule is then converted into a flow diagram.
4.Process of creating flow diagrams for codifying
Terminology:
The following are the major components of parse trees:
Nodes: These are the finite set of all states that the transforming process will reside in during the course of parsing the rule. Each node is associated with a set of data and a finite set of conditions which need to be verified to exist for the algorithm to move out of that node to the next node.
Start Node: This is the set of states from where a possible parse can start. The set of start nodes are dependant on the data which needs to be validated.
End Nodes: This is the finite set of nodes where the parse algorithm can reside; at the end of the parsing process. The test case is said to have passed when the algorithm resides in any of these set of nodes.
Process Arrow: This is a unit of processing that happens in the parse algorithm that will take the algorithm from on state to another. Every parse arrow exist attached to a node, hence they are in effect the conditions that help the algorithm to move from 1 valid node to another
** The algorithm can never reside at the following states:
ØA state which is not pre-defined and whose conditions are not known.
ØA state which does not have a valid outgoing process arrow attached to it.
If the process of executing takes the algorithm to a node other than an end node which has no valid process arrow which can be called; then it indicates a failed test case.
The process of creating the parse tree is to create a representation of the process flow of the rule in terms of start nodes, process arrows and end nodes. Since we reverse parse this tree for the purpose of validation the nodes that define the beginning of the transform rule will become the end node (the nodes that denote success when the tree is codified) and the leaf nodes defined will become the start nodes for the algorithm when the tree is coded. Refer to a sample transformation rule to explain the process of creating a parse tree.
“If modified date (MD) present and is greater than update date (UD) then output 1 else if modified date(MD) is not present or less that update date (UD) then output 0”
The following simple rule can be represented as a parse tree as follows:
In the above parse tree the nodes marked in gold will be the start nodes from where the algorithm can be initiated. The green node is the end node which signals a passed test case.
6.Coding for nodes
To convert the parse tree to an executable script each node in the tree is defined as an object of a custom class. The class definition for each node would contain the variables to hold the data that are relevant to the node e.g. variables MD and UD for node number 4, MD alone for node number 2 etc. The class definition would also contain functions to represent each process arrow and perform the validation check attached to that process arrow. Each process arrow would also pass relevant data to its target nodes if needed.
7.Building that “Parse Director”
The parse director module is a wrapper script which directs the calling of parse trees and performs the actual reverse parse of the transformation rule.
Need for parse director:
Every transformation will have a set of many rules. The parse director will perform the following:
Will hold the structure that defines the rules that can be called after evaluating one rule in the reverse parse process.
Direct the parsing of the tree by calling the appropriate parse tree to validate the test case.
8.Benefits of using parse tree oriented automation
This automation framework when developed will enable the QA team to predict the finite set of permutations that are possible for the process flow in each module.
This will enable them to finalize the minimum number of test cases required to ensure test coverage of all valid process paths.
This can serve as the direct replacement for orthogonal arrays to enhance and streamline the testing of each module.
** note that this would serve to minimize test case to achieve coverage at a “function call level” and not a “code branching level”. This is justifiable for the black box level testing relevant to QA.
The ratio of number of test cases execute to the number of defects identified will be minimized thus enhancing the productivity of the QA team and facilitate cut downs in QA schedules.
9.Requirements to adopt the approach
In depth understanding of the transformation engine under test.
QA tester with experience in building automation scripts using object oriented languages like JAVA/ RUBY etc.
Testing teams with expertise in refining and analyzing test scripts developed in the above languages.
The normal process followed for execution of test cases manual or automation is to follow the sequential order of test case as presented in the overall test plan for the concerned module. The common order of cataloging test cases in the test plan for a particular module would be to group them by functionality or by the common factors of the various test scenarios involved. This is to ensure that the designer of the test case does not miss any valid test scenario. The purpose of the approach which is presented in the following sections addresses the following problem area which is typically encountered.
“Tester xyz is handling the testing of a particular module which encompasses 5 broad functionalities. The test plan he uses has test cases grouped into these 5 categories and presented sequentially in his test plan document. He is scheduled to complete testing of the module in 10 days. He starts off execution of test cases sequentially and ends up repeatedly executing test cases relevant to the first functionality to completion and so on.
Assumption: Of the 5 functionalities assume the first 3 are extremely bug free while the 4th and 5th are extremely buggy. Since tester xyz will spend the major part of the early period testing the first 3 modules sequentially he would take longer to zero in on the bugs hence delaying the reporting of bugs leading to delayed cycle times where the development team would be waiting on him during the early period.”
The weighted graphmethodology modifies the process of test case execution as follows. The module to be tested is first represented in the format of a weighted graph for example:
Where the leaf node represent the different functionalities bundled in the module. The squares in blue represent the weights of each limb of the graph in the beginning (here 0). The cylinders show the subset of test cases that can be tagged to each of these functionalities.
To begin execution of test cases using weighted graphs; QA first develops a script which performs the following:
1.Pick a test case using a probabilistic approach depending on the weight of the limb from any one of the subset of test cases for all the functionalities.
2.The tester then executes that test case either manually of via automation scripts.
3.The result of the test case namely “pass” of “fail” is communicated to this master script.
4.If the test case fails then the script increases the weight of the limb for that functionality by a factor say 1.
5.In the next iteration of the above steps the probability of a test case from the limb with more weight being picked is higher.
6.The above steps repeat till all test cases have been covered.
The weighted graph approach is beneficial because the tester ends up executing more test cases that are tagged to a possibly buggy module hence the ratio of the number of defects identified to the number of test cases executed increases. Hence the defects in a module are identified at the early stages of testing. This translates to reduced cycle times and more throughput for the testing activity.
The content about xtreme testing that i have stumbled across focuses and emphasizes only on the software development process with little or no emphasis of how a testing team fits into an extreme programming project or how the process needs to be tailored to accommodate testing teams and the activities initiated by them to test software.I have also attempted to outline methodologies that can be adopted for testing teams to undertake the principles of extreme programming when the corresponding development is undertaken using conventional software development paradigms.
Extremetesting derives from the concepts outlined for extreme programming (XP) and distributed extreme programming (DXP) and tailored to be applicable to onshore-offshore model of software development, single & multi vendor model of software development. This approach retains the classical concepts of eXtreme Programming like simplicity, discipline, communication, quality, and flexibility
Introduction
Extremetesting (XT) derives from the XP and DXP agile development methodology and implements its core practices like communication, simplicity, feedback and courage. The following section outlines how most of the 12 practices of DXP can be applied to conventional software testingmethodology namely,
The principals from above will be adopted into extremetesting on a strict need to have basis and should be aggressively tailored to appreciate the fact that the process was initially designed for software development by keeping testing as a back end activity.
The methodologies of extremetesting (XT) which will be detailed in later sections will appreciate the core problem areas that current DXPmethodology addresses namely,
quick and lean response to changing customer requirements from a testing perspective. How an extremetesting (XT) flavor can be added as a plug-in to a conventional development project.
The following are the practices from eXtreme Programming that are adopted for eXtremeTesting.
1. Planning Game
The “planning game” concept of typical Distributed eXtreme Programming (DXP) address the following key decisions:
What will be accomplished by the due date?
What to do next?
The extremetesting (XT) approach will also answer these 2 questions. The tailored form of it being:
What deliverables will be tested by the due date?
What deliverables will be accepted into QA?
Conventional DXP works in iterations of 2 weeks. Where the planning game is re-envisioned and re-factored at the end of every 2 weeks. The 2 key planning steps involved in the planning game are:
1.QA Test planning:
What modules would be tested over the next 2 weeks? This forms a very critical part of steering of the QA activities since QA provides a customer commitment to provide complete test results of a named list of modules. The number of modules to be incorporated in a 2 week burst has to be kept at an optimum since the XT model of testing would aggressively test the modules in QA. Hence, the number of bugs reported for the module would be higher in the 2 week burst and if QA test more than an optimum number of modules the development team may be bogged down by defects reported and fail to make a defect fix delivery for all the modules.
* The core of this activity lies in the fact that
All modules that can be tested in parallel SHALL NOT be accepted into QA even if a build is available for deployment
The focus of eXtremeTesting(XT) is to aggressively test a select list of modules in a burst and NOT lukewarm testing of multiple modules
Advantages of this model of planning
The number of defects reported at any given point will cluster around a select list of modules.
The tracking of bugs is less tedious.
The development team can focus on the clean-up of a restricted number of modules.
The modules that will be tested are prioritized by the customer.
The customer perceived value addition in terms of a bug free roll-out of his high priority modules will be enhanced.
The completeness of testing is inherently transparent to the customer since the team is entirely focused on a select list of high priority modules.
2.Iteration Planning
This is the stage of planning where the QA team gets an alignment with customer regarding the next modules that needs to go into QA on a priority basis. Depending on the extent of bug fixes delivered and tested in the previous 2 week burst the QA team can factor what number of modules can be accepted into QA and still retain team focus on testing of the new modules and re-testing of builds.
The advantage of this type of planning from conventional test execution planning is that in conventional planning, periods and dates are tagged to modules to move into QA at the envisioning and planning phase. The is no room to accommodate scenarios where extensive cycle times are required or where the number of bug fixes are high which would require increased regression testing efforts. The end result of such planning is an overlap of the QA efforts in testing new modules and regression testing of old modules. This often results in mayhem with respect to tracking and closure.
In iteration planning of eXtremeTesting(XT) QA can take a call to ramp down the number of new modules hitting QA at the end of every 2 weeks. Thus they can retain their focus and efforts on select modules thus ensuring better delivery.
2.Simple Design
This feature of XP has been tailored to suit testing efforts by laying emphasis on the design of test plans for a module to be tested to be kept simple. This would be the guiding principle of the entire test planning phase where the inclusion of a test case into a test plan will be on a strict “need to” basis. Rather than design and document n number of test cases for a scenario (which does not aid testing anyway) the testing team would study and arrive at a complete list of all possible scenarios for a module (this could be a derivative of use cases if implemented for the project). This activity shall be the precursor to writing test cases. From the list of these possible scenarios, the team would then identify scenarios that that be clubbed and tested in one shot. The team would then proceed to write the minimum number of test cases for each of such “clubbed scenarios”.The alternative approach for simplifying test design phase of (XT) for project which neither implement use cases nor do scenario based testing is outlined below:
1.List out the comprehensive set of functionalities that can/ need to be tested as part of the module under test.
2.Begin writing the first test case.
3.Analyze if the test case written address some supporting functionality/ dependency/ requirement.
4.If yes, analyze if the test case completely address the supporting functionality/ dependency/ requirement.
5.IF it addresses it completely knock off that requirement from the set of functionalities that you need to test since it has already been covered and a further test case would be superfluous.
6.IF it addresses it only partially THEN attempt to re-work the scope of the written test case to encompass this requirement too. IF you succeed then execute step ‘e’. ELSE continue writing test cases.
7.After completion of writing all test cases re-analyze the test cases written in the light of steps ‘b’ to ‘f’.
This concept has been derived from the classical XP concept of “pair programming”. Pair testing is however, not a mandatory requirement to implement eXtremeTesting (XT). The concept of pair testing can be adopted when the team is extremely focused on testing a very few modules in parallel, that too extremely aggressively. The test pair formed should then resort to classical testing concepts like “exploratory testing” and “intuitive testing” since 2 resources are deployed for testing 1 module the productivity of bugs reported to testing efforts should not be compromised.
This scenario is applicable to a highly mature team of tenured testers who have a comprehensive grasp of the system functionalities and can perform real time prioritizing of the test cases planned to be executed by spotting the defect density in a module and zeroing in on testing those functionalities early in the testing cycle.
Enhance the customer perception that the test team is highly efficient in spotting defects.
The paired team has to be dismantled as soon as the defect reporting stage reaches its “critical mass”. This methodology therefore assumes importance when fresh modules get deployed into QA. This would not be necessary for regression testing efforts where the number of bug fixes delivered is less.
4.Metaphor
This is an approach where the testing team evolves a common and complete understanding of what the system is intended to do at a macro level and what each piece of it coming into QA during a 2 week burst is supposed to address. The implementation of this concept is done through brain storming sessions prior to starting a 2 week testing burst where the team will review and strategize the activities planned for the week to arrive at a common understanding of the modules coming in and how it integrates to the already certified modules. This can help test teams evolve their understanding of the system and will help at advanced testing stages like end-to-end or clean pass testing.
5.Refactoring
This is a critical concept of eXtremeTesting (XT) where the initial test design documents, test strategy documents and test plans are treated as “live documents” and the team is free to enhance their test suite, augment the test coverage in real time during test execution or during the look ahead meeting they would have every 2 weeks to evolve the common metaphor (discussed in the above segment). These documents can then be updated on a “need to” basis. This flexibility would allow the testing teams to actively document their test efficiency improvements during the entire lifecycle of the project.
6.Collective Ownership
Collective ownership of all QA deliverables is a mandatory part of eXtremeTesting (XT). This means that all artifacts and plans can be reviewed and changes proposed at any point of time.
The benefits of implementing collective ownership:
The QA deliverables get the attention of the entire team.
Cross dependencies and redundancies of test strategies and test cases can be caught by any member of this team.
The probability of code segments and snippets of automation scripts developed being re-used is greatly enhanced.
The testing activities will hence become further lean and the bulk of test cases and LOC’s involved in automation scripts would be reduced because of extensive re-use or re-scoping them to be used for multiple scenarios. This involves test cases and automation scripts used across modules being re-scoped or re-used to produce a lean mode of operation.
Collective ownership will ensure that there is cross expertise in the team. This would help is de-risking the project by being heavily reliant on a single person to ensure delivery.
7.Continuous Integration
Continuous integration requests will be done for to the development team. This is so that instead of testing individual components till the fag end of testing or till end-to-end testing the QA team will be testing new modules by integrating them into the bug free modules already existing in QA. The benefit of this mode of operation is that integration does not become a one shot activity where multiple interfaces can fail OR integration leads to collateral damage on a large scale. This could make the task of defect analysis extremely tedious. Hence the focus in eXtremeTesting is on a continuous bottom up integration in QA. This would ensure that during end-to-end testing the entire system as a whole can be tested without being bogged down by minor interfacing issues being raised and fixed at the end of the testing effort.
8.40-Hour Week
This is a mandate of eXtreme Programming (XP) that is retained as is in eXtremeTesting (XT). Since teams adopting eXtremeTesting would endure long periods of concentrated efforts it is mandatory that they are not to work overtime. It is deemed in this paper that the necessity of adhering to this and the impact of not adhering to it need not be explained.
