How can I decrease the size of Ratingbar?

There are two ways you can do this.

You have to style the RatingBar with either ratingBarStyleSmall or a custom style inheriting from Widget.Material.RatingBar.Small (assuming you're using Material Design in your app).

Option 1:

<RatingBar android:id="@+id/ratingBar" style="?android:attr/ratingBarStyleSmall" ... />

Option 2:

// styles.xml<style name="customRatingBar" parent parent="android:style/Widget.Material.RatingBar.Small"> ... // Additional customizations</style> // layout.xml<RatingBar android:id="@+id/ratingBar" style="@style/customRatingBar" ... />

Read more...

Android Material Rating Bar - Rating Bar example in Material Design

Rating Bar

How to add?

I. In your build.gradle add latest appcompat library.

dependencies { compile
compile 'com.android.support:appcompat-v7:X.X.X' // where X.X.X version}

II. Make your activity extend android.support.v7.app.AppCompatActivity.

public class MainActivity extends AppCompatActivity { ...}

III. Declare your RatingBar inside any layout.xml file.

<RatingBar android:rating="3.5" android:stepSize="0.5" android:numStars="5" android:layout_width="wrap_content" android:layout_height="wrap_content"/>

How to style?

I. Declare custom style in your styles.xml file.

<style name="RatingBar" parent="Theme.AppCompat"> <item name="colorControlNormal">@color/indigo</item> <item name="colorControlActivated">@color/pink</item></style>

II. Apply this style to your RatingBar via android:theme attribute.

<RatingBar android:theme="@style/RatingBar" android:rating="3" android:stepSize="0.5" android:numStars="5" android:layout_width="wrap_content" android:layout_height="wrap_content"/>

Read more...

Software Testing-Requirements Traceability Matrix

What is the need for Requirements Traceability Matrix in Software Testing?

Automation requirement in an organization initiates it to go for a custom built Software. The client who had ordered for the product specifies his requirements to the development Team and the process of Software Development gets started.

In addition to the requirements specified by the client, the development team may also propose various value added suggestions that could be added on to the software. But maintaining a track of all the requirements specified in the requirement document and checking whether all the requirements have been met by the end product is a cumbersome and a laborious process.

The remedy for this problem is the Requirements Traceability Matrix.

What is Requirements Traceability Matrix in Software Testing?
Requirements tracing is the process of documenting the links between the user requirements for the system you're building and the work products developed to implement and verify those requirements. These work products include Software requirements, design specifications, Software code, test plans and other artifacts of the systems development process. Requirements tracing helps the project team to understand which parts of the design and code implement the user's requirements, and which tests are necessary to verify that the user's requirements have been implemented correctly.

Requirements Traceability Matrix Document is the output of Requirements Management phase of SDLC.

The Requirements Traceability Matrix (RTM) captures the complete user and system requirements for the system, or a portion of the system. The RTM captures all requirements and their traceability in a single document, and is a mandatory deliverable at the conclusion of the lifecycle.

The RTM is used to record the relationship of the requirements to the design, development, testing and release of the software as the requirements are allocated to a specific release of the software. Changes to the requirements are also recorded and tracked in the RTM. The RTM is maintained throughout the lifecycle of the release, and is reviewed and baselined at the end of the release.
It is very useful document to track Time, Change Management and Risk Management in the Software Development.
Here I am providing the sample template of Requirement Traceability Matrix, which gives detailed idea of the importance of RTM in SDLC.

The RTM Template shows the Mapping between the actual Requirement and User Requirement/System Requirement.
Any changes that happens after the system has been built we can trace the impact of the change on the Application through RTM Matrix. This is also the mapping between actual Requirement and Design Specification. This helps us in tracing the changes that may happen with respect to the Design Document during the Development process of the application. Here we will give specific Document unique ID, which is associated with that particular requirement to easily trace that particular document.

In any case, if you want to change the Requirement in future then you can use the RTM to make the respective changes and you can easily judge how many associated test scripts will be changing.

Requirements Traceability Matrix Template Instructions:

Introduction:
This document presents the requirements traceability matrix (RTM) for the Project Name [workspace/workgroup] and provides traceability between the [workspace/workgroup] approved requirements, design specifications, and test scripts.
The table below displays the RTM for the requirements that were approved for inclusion in [Application Name/Version]. The following information is provided for each requirement:
1. Requirement ID
2. Risks
3. Requirement Type (User or System)
4. Requirement Description
5. Trace to User Requirement/Trace From System Requirement
6. Trace to Design Specification
7. UT * Unit Test Cases
8. IT * Integration Test Cases
9. ST * System Test Cases
10. UAT * User Acceptance Test Cases
11. Trace to Test Script

The following is the sample Template of Requirements Traceability Matrix.

Read more...

Requirements Traceability Matrix (RTM)

1. Requirements Traceability Matrix (RTM)

A document showing the relationship/mapping between Test Requirements and Test Cases.

Elements of RTM:

a. Requirements ID

b. Requirements Description

c. Test Case ID

d. Status [Open, Closed, Defer (Later), On hold]

2. Verification and Validation

Verification is the process confirming that something software meets its specification. Validation is the process confirming that it meets the user's requirements.

Difference between Verification and Validation:

Suppose, you are going to buy a pair of shoes having number 9 for you. You have chosen a pair and seen the tag with 9 written on it. This is verification, because your requirement was to buy a pair of shoes with 9 number.

But when you tried to wear it and found that shoe is not fitted into your feet. After inquery, you have found that company has tagged it 9 number by mistake. Actually it was 7 number shoe. This process is called Validation.

Example of Verification: Creating Traceability Matrix

Example of Validation: Executing Test Cases

3. Static and Dynamic Testing

Static black-box testing: Testing the specification is static black-box testing.

Two Types of Static black-box testing:

1. High-level review techniques

a. Research Existing Standards and Guidelines

b. Review and Test Similar Software

2. Low-level techniques

a. Specification Attributes Checklist (e.g. Spec must be complete, accurate, precise, consistent etc)

b. Specification Terminology Checklist (e.g. focus on the terms in Spec like "If…Then…(but missing Else)." or "Etc., And So Forth, And So On" etc)

Dynamic Black-Box Testing: Testing software without knowledge of code is dynamic black-box testing.

Static White-Box Testing: Static white-box testing is the process of carefully reviewing the software design, architecture, or code for bugs without executing it.

Three Types of Static White-Box Testing:

a. Peer Reviews: Peer Reviews are the least formal method. Peer reviews are often held with just the programmer who wrote the code and one or two other programmers or testers acting as reviewers.

b. Walkthroughs: In a Walkthrough, the programmer who wrote the code formally presents it to a small group of five or so other programmers and testers. The presenter reads through the code line by line, or function by function, explaining what the code does and why. The reviewers listen and question anything that looks suspicious.

c. Inspections: Inspections are the most formal type of reviews and more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and a recorder to take notes. The other participants are called inspectors.

Walkthrough:

1. It's a type of Semi Formal Review.

2. 2 to 7 People ate attaining it.

3. Author is Presenter.

4. Lead by Author only.

5. Reviewers are not aware of the subject/topic.

Inspection:

1. It's totally a Formal Review.

2. 2 to 10 or more People attaining it.

3. Author is not presenter. Some one else is giving presentation.

4. Lead by Moderator.

5. Reviewers are aware & well prepared for the subject/topic.

6. Recorder is noting down everything. Like defects, changes, improvements etc.

Dynamic White-Box Testing: is a method of testing software that tests internal structures or workings of an application.

Difference between Dynamic White-Box Testing and Debugging:

The goal of dynamic white-box testing is to find bugs. The goal of debugging is to fix them.

Read more...

How to write software Testing Weekly Status Report

How to write software Testing Weekly Status Report

Writing effective status report is as important as the actual work you did! How to write a effective status report of your weekly work at the end of each week?

Here I am going to give some tips. Weekly report is important to track the important project issues, accomplishments of the projects, pending work and milestone analysis. Even using these reports you can track the team performance to some extent. From this report prepare future actionables items according to the priorities and make the list of next weeks actionable.

So how to write weekly status report?

Follow the below template:
Prepared By:
Project:
Date of preparation:
Status:

A) Issues:
Issues holding the QA team from delivering on schedule:
Project:
Issue description:
Possible solution:
Issue resolution date:

You can mark these issues in red colour. These are the issues that requires managements help in resolving them.

Issues that management should be aware:

These are the issues that not hold the QA team from delivering on time but management should be aware of them. Mark these issues in Yellow colour. You can use above same template to report them.

Project accomplishments:
Mark them in Green colour. Use below template.
Project:
Accomplishment:
Accomplishment date:

B) Next week Priorities:
Actionable items next week list them in two categories:

1) Pending deliverables: Mark them in blue colour: These are previous weeks deliverables which should get released as soon as possible in this week.
Project:
Work update:
Scheduled date:
Reason for extending:

2) New tasks:
List all next weeks new task here. You can use black colour for this.
Project:
Scheduled Task:
Date of release:

C) Defect status:

Active defects:
List all active defects here with Reporter, Module, Severity, priority, assigned to.

Closed Defects:
List all closed defects with Reporter, Module, Severity, priority, assigned to.

Test cases:
List total number of test cases wrote, test cases passed, test cases failed, test cases to be executed.

Read more...