Mar 22

Reviews,Walkthrough and inspection in software Testing

Before stating Review, Walkthrough and inspection why not we do understand static and dynamic testing and how these three are divided in to these two.

So lets have a look on Static and Dynamic Testing.

  • Static Testing v/s Dynamic Testing

Static testing is done basically to test the software work products , requirement specifications, test plan , user manual etc. They are not executed, but tested with the set of some tools and
processes. It provides a powerful way to improve the quality and productivity of software development.

Dynamic Testing is basically when execution is done on the software code as a technique to detect defects and to determine quality attributes of the code. With dynamic testing methods,
software is executed using a set of inputs and its output is then compared to the the expected results.

  • Static Review and its advantages

Static Review provides a powerful way to improve the quality and productivity of software development to recognize and fix their own defects early in the software development process.
Nowadays, all software organizations are conducting reviews in all major aspects of their work including requirements, design, implementation, testing, and maintenance.

Advantages of Static Reviews:-

1. Types of defects that can be found during static testing are: deviations from standards, missing requirements, design defects, non-maintainable code and inconsistent interface specifications.

2. Since static testing can start early in the life cycle, early feedback on quality issues can be established, e.g. an early validation of user requirements and not just late in the life cycle during
acceptance testing.

3. By detecting defects at an early stage, rework costs are relatively low and thus a relatively cheap improvement of the quality of software products can be achieved.

4. The feedback and suggestions document from the static testing process allows for process improvement, which supports the avoidance of similar errors being made in the future.

  •  Roles and Responsibilities in a Review

There are various roles and responsibilities defined for a review process. Within a review team, four types of participants can be distinguished: moderator, author, scribe ,reviewer and
manager.Lets discuss their roles one by one:-

1. The moderator:- The moderator (or review leader) leads the review process. His role is to determine the type of review, approach and the composition of the review team.The moderator also
schedules the meeting, disseminates documents before the meeting, coaches other team members, paces the meeting, leads possible discussions and stores the data that is collected.

2. The author:- As the writer of the ‘document under review’, the author’s basic goal should be to learn as much as possible with regard to improving the quality of the document.The author’s
task is to illuminate unclear areas and to understand the defects found.

3. The scribe/ recorder :- The scribe (or recorder) has to record each defect found and any suggestions or feedback given in the meeting for process improvement.

4. The reviewer:- The role of the reviewers is to check defects and further improvements in accordance to the business specifications, standards and domain knowledge.

5. The manager :- Manager is involved in the reviews as he or she decides on the execution of reviews, allocates time in project schedules and determines whether review process objectives
have been met or not.

  • Phases of a formal Review

A formal review takes place in a piecemeal approach which consists of 6 main steps. Let’s discuss about these phases one by one.

1. Planning

The review process for a particular review begins with a ‘request for review’ by the author to the moderator (or inspection leader). A moderator is often assigned to take care of the scheduling (dates, time, place and invitation) of the review. The project planning needs to allow time for review and rework activities, thus providing engineers with time to thoroughly participate in reviews. There is an entry check performed on the documents and it is decided that which documents are to be considered or not. The document size, pages to be checked,composition of review team, roles of each participant, strategic approach are decided into planning phase.

2. Kick-Off

The goal of this meeting is to get everybody on the same page regarding the document under review. Also the result of the entry and exit criteria are discussed. Basically, During the kick-off meeting, the reviewers receive a short introduction on the objectives of the review and the documents. Role assignments, checking rate, the pages to be checked, process changes and possible other questions are also discussed during this meeting. Also, the distribution of the document under review, source documents and other related documentation, can also be done during the kick-off.

3. Preparation

In this phase, participants work individually on the document under review using the related documents, procedures, rules and checklists provided. The individual participants identify
defects, questions and comments, according to their understanding of the document and role. Spelling mistakes are recorded on the document under review but not mentioned during the
meeting. The annotated document will be given to the author at the end of the logging meeting. Using checklists during this phase can make reviews more effective and efficient.

4. Review Meeting

This meeting typically consists of the following elements:-
-logging phase
-discussion phase
-decision phase.

During the logging phase the issues, e.g. defects, that have been identified during the preparation are mentioned page by page, reviewer by reviewer and are logged either by the author or by a scribe. This phase is for just jot down all the issues not to discuss them in detail. If an issue needs discussion, the item is logged and then handled in the discussion phase. A detailed discussion on whether or not an issue is a defect is not very meaningful, as it is much more efficient to simply log it and proceed to the next one.

The issues classified as discussion items will be handled during discussion phase. Participants can take part in the discussion by bringing forward their comments and reasoning. The moderator also paces this part of the meeting and ensures that all discussed items either have an outcome by the end of the meeting, or are defined as an action point if a discussion cannot be solved during the meeting. The outcome of discussions is documented for future reference.

At the end of the meeting, a decision on the document under review has to be made by the participants, sometimes based on formal exit criteria. The most important exit criterion is the average number of critical and major defects found per page. If the number of defects found per page exceeds a certain level, the document must be reviewed again, after it has been reworked. If the document complies with the exit criteria, the document will be checked during follow-up by the moderator or one or more participants. Subsequently, the document can leave or exit the review process.

5. Rework

Based on the defects detected and improvements suggested in the review meeting, the author improves the document under review. In this phase the author would be doing all the rework to ensure that defects detected should fixed and corrections should be properly implied.Changes that are made to the document should be easy to identify during follow-up, therefore the author has to indicate where changes are made.

6. Follow-Up

After the rework, the moderator should ensure that satisfactory actions have been taken on all logged defects, improvement suggestions and change requests.If it is decided that all
participants will check the updated document, the moderator takes care of the distribution and collects the feedback.In order to control and optimize the review process, a number of
measurements are collected by the moderator at each step of the process. Examples of such measurements include number of defects found, number of defects found per page, time spent
checking per page, total review effort, etc. It is the responsibility of the moderator to ensure that the information is correct and stored for future analysis.

  • Types of Review

1. Walkthrough

A walkthrough is conducted by the author of the ‘document under review’ who takes the participants through the document and his or her thought processes, to achieve a common
understanding and to gather feedback. This is especially useful if people from outside the software discipline are present, who are not used to, or cannot easily understand software
development documents. The content of the document is explained step by step by the author, to reach consensus on changes or to gather information.The participants are selected from different departments and backgrounds If the audience represents a broad section of skills and disciplines, it can give assurance that no major defects are ‘missed’ in the walk-through. A walkthrough is especially useful for higher-level documents, such as requirement specifications and architectural documents.

The specific goals of a walkthrough are:-
• to present the document to stakeholders both within and outside the software discipline, in order to gather information regarding the topic under documentation.
• to explain and evaluate the contents of the document.
• to establish a common understanding of the document.
• to examine and discuss the validity of proposed solutions and the possible alternatives.

2. Technical review

A technical review is a discussion meeting that focuses on technical content of a document. it is led by a trained moderator, but also can be led by a technical expert.Compared to inspections,
technical reviews are less formal and there is little or no focus on defect identification on the basis of referenced documents. The experts that are needed to be present for a technical review
can be architects, chief designers and key users. It is often performed as a peer review without management participation.

The specific goals of a technical review are:
• evaluate the value of technical concepts and alternatives in the product and project environment.
• establish consistency in the use and representation of technical concepts.
• ensuring at an early stage, that technical concepts are used correctly;
• inform participants of the technical content of the document.

3. Inspection

Inspection is the most formal review type.It is usually led by a trained moderator (certainly not by the author).The document under inspection is prepared and checked thoroughly by the
reviewers before the meeting, comparing the work product with its sources and other referenced documents, and using rules and checklists. In the inspection meeting the defects found are
logged.Depending on the organization and the objectives of a project, inspections can be balanced to serve a number of goals.

The specific goals of a Inspection are:
• help the author to improve the quality of the document under inspection.
• remove defects efficiently, as early as possible.
• improve product quality, by producing documents with a higher level of quality.
• create a common understanding by exchanging information among the inspection participants.

 

Mar 01

Book Review: Selenium WebDriver Practical Guide

Selenium WebDriver Practical Guided

Are you trying to switch in to Selenium WebDriver automation and your boss  is insisting to automate all web application over which you working since long time then I think Selenium WebDriver Practical Guide by  Satya Avasarala  is going to help you in the best way. This book has incorporated everything that is going to help both Beginners along with experienced automation testers and it is easy to follow because this book has featured step by step tutorial approach and this step to step approach is going to help every reader to digest every chunk of content written in this book. So any one can start his learning with this book.

What is inside this book

The books starts with a detail history of Selenium, and has also included “how each flavor of selenium component like IDE, Selenium 1.0 and WebDriver are different from each other” and what has made Selenium Webdriver to win the race of all the previous components. This chapter also includes project setup and along with interaction with browser and commonly used actions on generic web-elements present on any web-page.

Next Chapter has covered interaction of WebDriver with Keyboard and mouse and has also included examples to show how it works

Chapter 3 is the one which is dealing the most asked question on internet . How to handle alert, frame and pop-up and how I can take screenshot of any page during script execution. Lastly in Chapter 3 implicit wait and explicit wait has been mentioned means after reading this you would learn the lesson to prevent your script breaking from Stale Elements on page or Element not visible kind of exceptions.

Chapter 4 is going to help you how to run your IE Browser, Chrome browser and all other browser by setting the property of its executable binaries

Chapter 5 is the my favorite because this chapter is going to help  you to understand how to deal with the event-handling aspect of  WebDriver. You can read this chapter on this link. This is the chapter that has been written for experienced WebDriver user .So this chapter will intend experience WebDriver user to purchase this book.

Chapter 6 is for the people who are not quite familiar with the file handling in java and want to read it in detail and its proper use in WebDriver. So this chapter is also going to help beginners to learn some raw java concept that is going to help them in their scripting with WebDriver.

Chapter 7 and 8 is one of the most talked topic in Selenium Script. These two chapter include detailed description of RemoteWebDriver and WebDriverBackedSelenium  and has also included the concept of Selenium Grid concept .

Chapter 9 has included the concept of Page Object model and how to use it when developing your tests using java language. Author has made an effort to explain this topic with real time examples so might be you would find a way to understand the concept of Object Model in WebDriver. But still need some tweaking in page object model description.

Chapter 10  is going to help you out to understand the concept of mobile automation using appium and I am pretty sure that people who are seeking help related mobile automation is going to be benefited with this part of the book a lot.

Conclusion

Overall this book is meant to both beginner and experienced WebDriver user. But this books is missing the most important part i.e Junit/Testng framwork and without junit and testng reading Webdriver is like eating food without taste and somewhere you would feel like language of this book is becoming awkward.
But if you have bought this book then don’t forget to read Chapter 5 and 6.