ISTQB – CTFL Certified Tester Foundation Level – Static Techniques

1. Reviews And The Test Process [CC]

Hi and welcome to the Static techniques section of our course. Let me first introduce you to the meaning and importance of a static techniques and its relation to the test process. Static techniques are often forgotten area of software testing. Static techniques test software without executing the software code. They are therefore important because they can find errors and defects before code is executed and therefore very early in the life cycle of the buoy in nuclear dynamic testing techniques the developer will write the code and build an exitable software and pass this software to the tester to test it.

The tester will need to design test cases and test procedures, run the testable seizures and compare expected result versus the actual result and if they are not the same the tester will try the scenario a few times to make sure it’s severely a failure. The tester then will create a bug report and send it to the developer to fix it. The developer will try the scenario and might communicate with the tester several times till he can verify the failure. The developer then will try to find the root cause of the failure. It might take days to find it and if found the developer will try to fix it and which again might take a long time as well.

After the bug is fixed the developer will send the new executable software with the fix to the tester to confirm the fix which is retesting. As we said before in case the bug is not actually fixed then the cycle will be repeated again till the test confirms to be fixed. Wow that’s a very long trip. Now imagine a situation where a person or a software tool can examine the source code written by the developer and directly find the bug. It will be easy to fix the bug then and we are done.

That’s the magic of static testing. Static testing takes place during a software development lifecycle since this helps to identify defects before they become part of the executable code. Since this helps to identify defects before they become part of the executable code and so makes those defects cheaper and easier to remove. Even though static testing sounds like magic but still we will need to do dynamic testing as running the accessible code can find other types of defects.

So static testing is complementary to dynamic testing techniques. There are two static testing techniques that we need to know. The views are normally completed manually. Static tools is normally completed using tools. We will go into details of both techniques in the coming lectures.

2. Review Process : Introduction [CC]

A review is a systematic examination of a document by one or more people with the aim of finding and removing defects. Giving a draft document to a colleague to read is the simplest example of a review. Reviews can be used to test anything that is written or type. This can include documents such as requirement specification, system designs, code distables, disting cases and so on. Besides finding defects early, there are also other important benefits among them since static testing can start early in the life cycle, then early feedback on quality issues can be established. For example, an early validation of user requirements will help us evaluate the quality of the requirement document and reboot if anything is missing or ambiguous as early as possible.

Development productivity improvement as developers love to work on a stable non buggy software yeah, you can ask me about this for sure. Reviews could be the only time in your organization where a senior person talks to a senior person and point to him what’s wrong with the review document and how to avoid doing the same mistake again. Reviews is done correctly will improve team communication and knowledge transfer. Fewer defects in the final software ensures that ongoing support costs will be lower, which will result in lifetime cost reductions. Reduced fault levels static techniques usually find more hard bugs than those found by dynamic testing, so the overall severity of the bugs get reduced reduce development time scales because the number of bugs get drastically reduced. Hence less time is spent on bug fixing.

Also, the lower the number of bugs will reduce testing time and cost as it will result in less time documenting bug reboots, less time retesting, less time fixing bugs and less time bugs will swing between the developers and testers and so on. All reviews aim to find defects. But sometimes if you’re find certain types of defects more effectively and more efficiently than others, the type of defects most typically found by reviews are requirement defects.

For example the requirement is ambiguous or there are missing elements design defects for example the design doesn’t match the requirement insufficient maintainability for example the code is too complex to maintain incorrect interface specification between two component for example, the interface specification doesn’t match the design or the receiving or sending interface and last deviation from standards. Well, even though this will not introduce a failure in the exitable software, but it establishes readability and maintainability in the reviewed document.

3. Activities of the Review Process [CC]

Review process can vary widely in their level of formality, where formality relates to the level of structure and documentation associated with the activity. Some types of reviews are completely informal. For example, a colleague buys his buy and you ask him to look at one of your documents, so there is no written instruction on how to do the review. It’s very informal, while others are very formal. Before discussing the different types of reviews, let’s talk first about the twelve activities of the review process. We need to memorize the sequence of those activities as this is one of the repeated questions in the Ihtkb exam.

Let’s talk more about each of those activities in detail. Planning deciding which area in each document needs review, when to do it, how long should it take, where to do it, who will do the review and how to do the review and if there’s already any company bosses, guidelines or redefined checklist we could use in the review process. The reviewers should be skilled to do the job, know how to dig for mistake in the document. They should also be of different background, for example, someone with design background, someone who is expert in UI, someone with performance background, another with standards knowledge, and so on. The selected personnel will be assigned rules and with possibilities. Accordingly, we will talk more about planning in the section test Management defining the entry and exit criteria for more formal review types such as inspections.

Entry Criteria Defined what criteria should be fulfilled to start the review, such as making sure that the document is built correctly before starting the review. Empty Criteria defined what criteria should be fulfilled to start the review, such as making sure that the document is built correctly before starting the review and exit criteria define what criteria should be fulfilled to stop the review, such as fixing major bugs found in the document. Kickoff distributing documents to be reviewed to the participants explaining the objectives of the review, the bosses and the documents to the participants.

Kick off can take the form of a meeting or assembly by sending out the details to the reviewers. Review Anticriteria this stage is where the anti criteria agreed upon are checked to ensure that they have been met so reviewers won’t waste time on a nonreading document. Individual Preparation each of the participants alone will read the source documents noting potential defects, questions and comments. The key to this activity is that it should be time boxed, usually two to 4 hours. Noting instance in this stage, each reviewer will log the potential defects, questions and comments found during individual preparation. Review Meeting this is the meat of the review process. Participants will go through a discussion regarding any defects found. The discussion will lead to more defects. Finding every defect and its severity should be logged.

The participant who identifies the defect proposes the severity of vote of the meeting depends upon the time available review objective and the type of the review. Reviewers may only suggest or recommend fixes, but not actual discussion on how to fix the defect. This is done later by the author. Examine at the end of the meeting, a decision on the document under review has to be made by the participants. Should we proceed with this document or do add it all together or assemble? Follow Up Meeting after fixing the defects found will be enough.

Rework after a review meeting, the author will have a series of defects to investigate, answering questions and suggestions raised in the review meeting. Fixing Defects Here, the author will be fixing defects that were found and agreed as requiring effects and recording updated status of defects. Follow up the review leader will check that the agreed defects have been addressed and will gather metrics such as how much time was spent on the review and how many defects were found and so on. Checking Exit Criteria At this stage, the exit criteria defined at the start of the process is a check to ensure that all exit criteria have been met so that the view can be officially closed as finished.

4. Formal Review Roles and Responsibilities [CC]

The participant in any type of formal review should have good knowledge of the review process. Participants should have been properly trained as reviewers when necessary. A typical formal review will include the following rules the author, who is the writer or person responsible for the document or documents to be reviewed the Motivator a person who who leads the review process, including running the meeting and following up after the meeting. The motivator is responsible to make sure no bug fixing will be discussed in the review meeting and also responsible to make sure reviewers will discuss the code objectively, not subjectively.

Reviewers who are the individuals with a specific technical or business knowledge or background, also called the checkers or inexpectives who, after the necessary preparation, identify and describe findings such as defects in the product under review. Reviewers should be chosen to represent different perspectives and rules in the review process and should take part in any review meeting. The manager who decides on the execution of reviews allocates time in the project schedule and determines if the review objects objectives have been met or not scribe or recorder who documents all the issues, problems and open points that were identified during the meeting.

5. Review Types [CC]

Now we have seen the activities of the very formal process. There are factors that affect the decision on the appropriate level of formality for a review, which are usually based on the maturity of the development process. As the more mature the process is, the more formal reviews tend to be legal or regularity requirements. For example, in safety critical software applications domain there are legality or legal requirement determine what kind of review should take place. The need for an audit trail the level of formality in the different types of review used can help to raise the level of audit trail to trace backwards throughout the software development lifecycle. There are four types of reviews which vary in their formality starting from the lowest to the highest formal review type one informal, two walkthrough, three technical review and last for inspection. Questions in the exam are usually about differentiating between the different kinds, so we will try to pinpoint some keywords to highlight the view type Characteristics informal Review The least formal review type where there is no formal process to run the review. Findings in this kind of review are not usually documented.

Their main purpose is to quickly find effects and an inexpensive way to achieve some limited benefit. Informal review varies in usefulness depending on the reviewers. An example of the informal review is payer programming, which is a technique introduced by the Agile Ecstream programming methodology where two programmers work together to write the same code, so one programmer is instantly reviews the code of the other programmer. The keywords in the informal reviews are no process and quick benefit. The second type of reviews is walkthrough, where the author have something to explain or show in his document to the participants.

So the main purpose here is for the participant to learn something from the document or gain more understanding about the content of the document or to find effects in the document. In this type of review, the meeting is led by the author. Review sessions are open ended and may vary in practice from quite informal to very formal. Preparation by reviewers before the workshop meeting, production of a review report or a list of findings and appointment of a scribe who is not the author are all optional components that are sometimes present.

Keywords in the workshop review are led by the author. Main purpose are learning and gaining understanding and most of the view both to see’s activities are optional. Technical Review A technical review is a discussion meeting that focuses on achieving consensus about the technical content of a document. Reviewers are usually experts in their field and can take a technical decision about the document. Technical reviews are documented and use a well defined effect detection process that includes beers and technical experts. Most of the review process activities are executed planning, review, meeting, examine and so on.

The review is usually performed as a beer review without management participation and is ideally led by a trained moderator who is not the author to control the meeting. Technical reviews have a number of purposes including discussion, taking decisions, evaluation of alternatives, finding defects, solving technical problems, and checking conformance to specification and standards. Keywords in the technical review are led by a trained Motivator. The purpose is discussion and taking decisions and evaluating of alternatives. Most of the activities in the view voices are executed. The last type of a view and the most formal one is inspection. The main purpose of inspections is to find effects. They are led by a trained moderator who is not the author.

The inspection bosses is formal based on rules and checklist, and uses entry and exit criteria. Premading preparation is essential, which should include reading of any documents to ensure consistency. An inspection report with a list of findings is reduced, which includes metrics that can be used to aid improvement to the process as well as correcting defects in the document under review. After the meeting, a formal follow up process is used to ensure that corrective action is completed and timely. Keywords in the inspection review are led by a trained moderator. The main papers is finding bugs and all activities in the review bosses are executed so quickly.

In the informal bosses there are no process and quick benefit in the workshop, the meeting is led by the author and the main purpose is to learn and gain understanding and most of the activities in the bosses are optional. In the technical review, the keywords are led by a trained Motivator. Most of the bosses are executed and the main purpose are taking decisions and evaluating alternatives and discussing and last in the inspection review, the main purpose is finding defects and again led by a trained Motivator. And all the activities in the bosses are executed.

In reality, there’s a fine line between the view types often get blurred and what is seen as a technically view in one company may be seen as an inspection in another. The key for each company is to agree on the objective and benefits of the views that they plan to carry out. Also, a single document may be subject to many different review types. For example, an informal review may be carried out before the document is subjected to a technical review or debate in or a technical review or an inspection may take place before a walkthrough with the customer.

6. Review Process : Success Factors [CC]

The key factors for the success of reviews are each review has clear predefined objectives. The right people for the review objectives are involved. The review is conducted in an atmosphere of trust. Everyone knows that the main objective is to increase the quality of the document under review so the outcome of the review will not be used for the evaluation of the participants or the author. I have seen companies that calculate the monthly bonus depending on the number of bugs bird available. This is so unrealistic and so unfair.

Defects found are welcomed and expressed objectively people issues and psychological aspects are dealt with for example making it a boss of experience for the author. A checklist of rules are used if abraham to increase effectiveness of defect identification training is given in review techniques, especially the more formal techniques such as inspection management supports a good review process. For example, by incorporating adequate time for review, testers are valued reviewers who contribute to the review and also learn about the product which enable them to prepare tests as early as possible. There is an emphasis on learning and process improvement. We should learn from our mistakes and we should use the metrics collected to improve the overall software process.

7. Static Analysis By Tools [CC]

Static analysis tools. A static analysis tool runs automatically and reboots all defects it identifies. Like reviews static analysis logs for defects rather than failures without executing the code using software tools. However, reviews work on any written document while static analysis works on only on source code and software models. Source code is any series of statements written in some human readable computer programming language that can then be converted using a tool called compiler to an instruction that the computer understands and can execute. The source code is normally generated by the developer. A software model is a representation of the software for easier comprehension of the software design.

Software models are normally generated by a software designer or a developer. That’s why static analysis is typically used by developers. This is very important point to understand. Notice that there is questions mainly asked about who can do what. So now we know that developers do static analysis by tools. Static analysis is idly performed before the types of formal review. Static analysis can find effects that are hard to find during test execution. It can also be used to calculate code metrics like how many lines of code and how complicated is the code.

Those metrics help us know more about the code and know where and how to improve the quality of the code. Combilers are good examples of a static analysis tool as they can provide us with a lot of metrics about the source code. The value of a static analysis is early detection of defects barrier to test execution. As with reviews the area the defect is found that cheaper and easier is to fix. It also early warning about suspicious aspects of the code or design by the calculation of metrics such as code complexity measure. If code is too complex, then there is a high probability the code might fail. Identification of defects not easily found by dynamic testing as we mentioned before, detecting dependencies and inconsistencies in software models such as links between modules improved maintainability of code and design.

Static analysis can point to complex code that if corrected, will make the code more understandable and therefore easier to maintain. Prevention of defects by identifying the defect early in the software life cycle, it’s a lot easier to identify why it was there in the first place than to wait and know why it was there during test execution. Typical defects discovered by static analysis tools include programming standard violation. For example, if the standard is to add comments only at the top of the code, we can find a tool that would tell us if every developer did follow the standard or not. Referencing a variable with an undefined value using a variable as part of the calculation before the variable has been given a value is really a bad practice and the tool can discover this problem first. Inconsistent interface between modules and components.

For example, module X requests three values for module Y, but module Y has only two outbuts variables that are never used. So we better remove to make the code more readable. Unwitchable code or did code. This means the developer made a logic mistake to either fix the code now or remove it if not needed. Missing Logic some requirements logic has not been handled, so then it’s better to add the missing logic soon overly complicated code. As we said before, we better clean it now for better maintainability security issues. For example, password structures that are not secure, syntax violation of code and software models. For example, incorrect use of the programming or modeling language.

• Category: Uncategorized