Zephyr- A Next Generation Test Management System

Recently I came across a newly launched Test management System called Zephyr which is a next generation system.

I spend some time on it and found good. I am sure you will find it better than you using any Test Management System. You can find out all about this by clicking to http://www.getzephyr.com

Zephyr is a slick, feature rich and affordable Test Management System aimed at global SME, IT Departments and Testing Vendors. It brings a whole bunch of innovation in a space that has lacked it for the longest time. We'd like to draw your attention particularly to our customized Testing Desktops, real time Collaboration and Live Reporting via slick Dashboards as well as a host of Web 2.0 features.

Typical Software Testing Process

Every Software development organization follow about similar testing process. Still It can be slightly different for organization to organization.
However in Tekriti we follows the following testing process for the most of our project/products.

1-Requirement Analysis:
Testing process starts in very early phase of software development life cycle(SDLC). In this phase we gather requirement . The requirement for testing can be gather with the help of following documents:
-> Software Requirement Specification(SRS)
-> Functional Specification
-> Designed Documents
-> Use case Documents
All the above documents are prepared by PM, TL and Dev teams itself with meetings with client or Client itself.
This is very first step in testing process. Now once we have requirement, we move to next phase so called planning.

2- Test Planning:
Now in this phase once we have the exact requirement, we plan for testing. It may be the answer of few questions like How to test, what to test, when to test, etc. We can exactly say that this phase is where we make test strategies, test plan or test Bed. The Test plan may have the answer of the questions
-What to test first
-Technologies to be used
-who will test and what
-Methodologies to be used
-Whether it is manual or automated (If automated then what to be automated)
-Risk management
-Which bug tracking tools to be used. etc
Now once we completed with this phase we start setup with test environment. That is our next phase of testing process.

3- Test environment setup:
In this phase of software testing we setup the test environment in which we have to test the application.
It depends upon the software/application to be tested.
Setup the test environment may include
-Network Configuration
-Software and hardware installation.
-Meetings with vender's
-Internet service provider may be the crucial part for for any S/w development Organization.
In Tekriti it all about the system team 's responsibility. So tester can starts working for directly 4th phase
after planning.

4-Test Design:
In this phase we write the test cases. Once the test cases writing completed , we refer this document to the senior level , In some cases we also send it to the client, but it totally depend on the nature of project.
If the process is automated then we also write test script in this phase.
Now once the test case documents is reviewed we plan then to execute.

5-Test execution :
Now exactly the task of testers comes. In this phase we execute the test cases . We also run test script (if applicable) to execute these test cases with the help of automation tools.

6-Defect tracking and report:
In this phase we track the defects which are being monitored in previous phase. If we having any bug tracking tool then we reported and manage through them otherwise we can also track them through xls sheet. Here we are using Mantis, Bugzilla, and Zira for different projects.

7- Test report:
finally, testing team prepare following documents
-Test summary report
-build release notes
-note on what is covered and what to cover in next release.
-Review acceptance. It may be the release note's mail reply from client

Finally,

As testing is never ending process and its depends on project , the process can repeat itself. The requirement changes daily so the writing test cases may be the continue process.

- Vishal Sachan

The software release process

The build is the pulse of any software development activity, and a good build process facilitates the quality software development.
We(my project team) have prepared and using the following release process in my current organization.

Build Machine:-
The build machine is a dedicated physical or virtual machine whose whole purpose is to build you product/project। It should not use for development or for QA activities. here are some points to keep in mind when setting up build machine.
-> Keep the number of softwares installed on the build machine to a minimum.
-> More space
-> Machine should be fast
-> Remote access to this build machine for emergency access from out of work station.

Process to a release:-
The process is for web application we using for our project.
Three instances of the same code should be deployed for development team, QA team and the end client.
Dev Instance or Dev Server - Deployment for the dev team when the daily check ins made to the repository will be verified. This deployment can be updated twice or thrice in a day according to the number of commits made to the repository.
QA Instance or QA Server - This is the instance for the QA team. QA instance will be updated on every once in a week(say wednesday) The revision number of the code should be tracked by the QA team when this instance is updated (say it R). Dev team will send the list of all the features implemented or the bug fixes in the system from (say Monday). After Wednesday this instance will be updated only for the blocker and critical fixes. So some files in this instance will be on revision number greater than R and those needs to tracked also.
Staging Instance or Server Sever - This instance is meant for showcasing the system to the end clients. There should be no dummy data (like test post, or test user) on this instance. Sanity check on this instance has to be performed by giving some meaningful test data. The revision of this server should be same as of QA instance. By the end of day QA team will send the release notes for the revision R.

Make sure this is a process for my project. any one can set a process with some change as required in their project.

here the release note should be generated by QA lead for each build, this can be done by either pulling in the list of changes from the source control or by pulling in the task ids that have been implemented since the last build from whatever issue tracking system you are using.