All Posts

  •  

    There are many automate build tools used these days for building, testing, publishing deployment and packaging software like Apache ant, Maven and Gradle.

     Gradle is a general purpose build automation tool.Gradle combines the power and flexibility of Ant with the dependency management and conventions of Maven into a more effective way to build.

     Gradle used Groovy-based domain-specific language (DSL) instead of XML form of declaring the project configuration.It is very flexible and extensible It has built-in plug-ins for Java, Groovy, Scala, Web, OSG.

     The most important points that featured by Gradle are:

     A very general flexible purpose build tool like Ant

     

    • Very powerful support for multi-project builds

    • Ease of integration and migration. Ant, Maven, Ivy are supported out- of-the-box

    • Very powerful dependency management

    • Ease of migration

    • Full support for your existing Maven infrastructure

    • Groovy-based build script

    • A rich domain model for describing your build

    • Free and open source

     

     

    How to install Gradle?

     

    To install Gradle on Windows, do the following:

     

    • Download latest Gradle 2.0 binaries from http://gradle.org/downloads

    • Unzip the Gradle download to the folder to which you would like to install Gradle.

    • Next, right-click on the My Computer icon and select Properties.

    • In the System Control Panel window, select Advanced System Settings from the links on the left.

    • Add Gradle in to environment variables as mentioned in the below screen shot.

     

     

     

     

    • In that same dialog box, select the Path variable under System Variables, then click Edit. Add the text ;%GRADLE_HOME%\bin to the end of the Path variable value.

     

     

     

     

     

    • Open your command line and type gradle -version to get version of Gradle that is installed on your system.

     

     

     

    For more details : https://www.gradle.org/docs/current/userguide/userguide.html

     

     

     

  • Testopia is a test case management extension to the Bugzilla bug tracking system.It is an open source project licensed under the Mozilla Public License.It is designed to be a generic tool for tracking test cases, allowing for testing organizations to integrate bug reporting with their test case run results.

    Advantage of  using Testopia

    • Track the progression of weekly or release-based testing done by various QA team.
    • Test case management and organization
    • Can relate to Bugzilla elements
    • Make connections between bugs and test cases
    • Keep a history for test cases and test runs.
    • Automated test cases using scripts.
    • Automated bug reporting.
    • Test case linking using dependencies
    • Easy reporting using the built-in reporting tool (tables, graphs)
    • Testing results export to CSV
    • Improve communication between the testing teams, the development teams and each other

     

  • One of the important deliverable in software testing are Bug reports. Writing a good bug report is an important skill of a software tester. In order to document a well-written bug report, tester requires a combination of testing and communication skill. The bug report is a medium of communication between tester and developer when the tester uncovers a defect. The bug report explains the gap between the expected result and the actual result.

    A bug report should have the following: 

    • The Title

    • Steps To Reproduce

    • Test Data

    • Expected and Actual Results

    • Attachments

    The Title

    A good title helps reduce duplicate issues and accurately summarize the issue. Include the specific name of the components involved in your bug in the title. A good summary will not be more than 50-60 character.

     You can avoid generic problems in the title. For example: 

    • ABC is not working properly

    • Issue with the page

     When we define a title we should specify what makes it “not working”. 

    Bad – “Application crashed”

    Good – “Canceling from Change Password dialog caused application crash”

    Bad : Issues with GUI on navigation bar.

    Good : Navigation bar is wrapping to a second line.

    Steps To Reproduce

    This is body of the report. This section tells how to reproduce the bug. We should keep the section concise and easy to read. The number of steps should be short and to the point. It is better to write prerequisite to reduce the number of steps. It’s a good exercise to reproduce the bug by following the steps you’ve just outlined. This will help ensure you’ve included everything the developer will need to reproduce it as well.

    Test Data

     

    If the bug is specific for the particular scenario it is better to give the test data, so that developer can recreate the scenarios.

    Expected and Actual Results 

    When describing expected results, explain what should happen, not what shouldn’t happen.

    Instead of writing “The app got crashed”, we can write as “The user should take to XYZ screen".

    When describing actual results, describe what did happen, not what didn’t happen.

    Instead of writing “The user wasn’t taken to the page”, we can write as “The user remained in the ABC page". 

    Attachments 

    Attachments add the bug value by offering proof. The attachment can be images, videos or log files. 

    Images 

    Images are an essential part of the bug report. The bug reports should be effective enough to enable the developers to reproduce the problem. Screen shots should be a medium just for verification. 

    • If you attach screen shots to your bug reports, ensure that they are not too heavy in terms of size. Use a format like jpg or gif, but definitely not bmp.

    • Attach the image files directly to the report. Don’t put images in a Word document or a zip file.

    • Highlight the areas of bug in the image. 

    Video

    Video should be provided if the steps are complex. Actions in the video should match the steps listed in the bug report. Videos should be trimmed to only show the bug.

    Log Files

    Make it a point to attach logs from the logs. This will help the developers to analyze and debug the system easily. If the logs are not too large, say about 20-25 lines, you can paste it in bug report. But if it is large enough, add it to your bug report as an attachment. Avoid proprietary file types (like .docx). Use .txt instead. 

     

  • TestLink is a web-based test management system that offers support for test cases, test suites, test plans, test projects and user management, as well as various reports and statistics. It is developed and maintained by Teamtest that facilitates software quality assurance.

    How to work with TestLink

    1. Create a Project
    2. Create Test Cases (Test Suites) for this Project
    3. Create Test Plan
    4. Specify Build of the Project you are going to test
    5. Add Test Cases to the Test Plan
    6. Assign Test Cases to Test Engineers
    7. Execute Test Cases (Test Engineers)
    8. See Reports and Charts

    Additional facilities 

    • Assigning Keywords (we may form a group of Test Cases for Regression tests)
    • Specifying Requirements (we may bind them with Test Cases in the many-to-many relation and see if our Test Cases cover our requirements)
    • Events log (you can see here the history of all the changes)


    STEP 1. CREATE A PROJECT

    To create a project, go to the Test Project Management section:


    STEP 2. CREATE A PROJECT - IMPORTANT FIELDS

    • Name
    • ID (used for forming a unique Test Cases ID) E.g. FT-03 means that the Test Case is created for Fenestra project and it has ID=3
    • Project Description (what is the aim of the Project, what is the target group, what is the business logic, what is the Test Environment)

      Enhanced features:

    • Requirements feature – we may specify requirements and see if they are well-covered by Test Cases
    • Testing priority – we may assign priority to Test Cases (high, medium, low)
    • Test Automation – we may specify whether the test should be performed manually or automatically

      You can now set this project here, like in Mantis, in the top right corner


    STEP 3. CREATE TEST CASES

                             Or here: 


    STEP 4. CREATE TEST CASES - CREATE TEST SUITE


    • Test Case Title
    • Summary
    • Preconditions
    • Execution type (manual or automated)
    • Test importance (High, Medium or Low)


    • We may also import and export Test Suites and Test Cases (in the .XML/XLS format):
    • We import them from one project

    •  And export the file in other



    STEP 5. SPECIFY TEST PLAN

    • TestLink will not allow you to execute Test Suites if you do not create a Test Plan and specify Test Build.
    • How to do that ? Let’s begin from the Plan


    • Current Test Plan will appear in the top right corner

    STEP 6. SPECIFY BUILD

    • After you’ve added a Test Plan menu, the adding Test Build appears.

    • Add a new build there


    STEP 7. ADD TEST CASES TO THE PLAN

    • Unfortunately, only Test Cases, not Test Suites or the whole Test Specification can be added to a Test plan. So, until you don’t select one separate TC, the button “Add to Test Plans” will not appear.

    • Then you can choose what Test Plans you want to add the selected TC to.


    STEP 8. ASSIGN TEST CASE EXECUTION TO TESTERS

    • Before assigning TC to testers you should create a DB of users with appropriate roles here.
                                    
    • Add the users you need filling in the form.

     

    • Then you can assign TC execution here.

     

    • You can assign test cases to testers and send them email notifications.

     

    STEP 9. EXECUTE TESTS

    • To start executing tests, Test Engineer should go to test Execution section.

     

    • Then choose a TC.

     

    • You may also connect TestLink with our bug-tracking system Mantis, then during execution you will see as below.

     

    • After click on “Create New Bug”, to create the bug using mantis user interface and reorganizing the window

     

    • Test engineer writes the issue ID on Testlink

     

    • It looks like this after saving

     

    • Execution history is being saved

     

    STEP 10. SEE REPORTS AND CHARTS

    • After test case execution is finished you may see the results of it using Test Reports section

     

                                     Or here:

     

    • You can see the following page

     

    Test Plan Report - the document has options to define a content and a document structure. You may choose the info you want to get.

     

    • Test Plan report (part of it)

     

     

    • The document 'Test Report' has options to define a content and document structure. It includes Test cases together with test results.

     

    • Test result matrix

     

    •  Charts

     

    Charts – results by tester (there are only unassigned test cases in the
    diagram)

     

     Charts – Results for top level suites:

    1. Log in the application

    2. News module

     


    Blocked, Failed and Not Run Test Case Reports
    These reports show all of the currently blocked, failing, or not run test cases.
    E.g.

     

    General Test Plan Metrics
    This page shows you only the most current status of a Test plan by test suite, owner and keyword.

     

    • Query metrics – work like filters in Mantis

     

    • Requirements based report

    If we have some requirements specified and have connected them with TC we can see the following report:

    ADDITIONAL FACILITIES - ASSIGNING KEYWORDS

    Go to the “Assign Keywords” section

    Select some Test Suite and then you will be able to go to “Keywords Management”


    Add keywords if there are no KW at all, or if there are no KW you need

     

    • Now you can add Keywords both to Test Suites & Test Cases, either all the Keywords (>>) or only one KW (>)

     

    • Then you will be able to see such a useful chart demonstrating the Results by KW

     

    • You can open the section in this way

     

                                  Or in this:

     

    • Requirements Specification adding