Test Data Requirements

Test data requirements


Earlier I have promised you folks that I would write about the list of requirements that we need to meet in all the stages of testing (in List of Requirements) and I guess I have already shared the testability requirements. In this section, I would talk about the requirements that are needed to set the test data in the staging server.
  • Any production data loaded into the test environment is scrambled in a way that it still fits logically together but is impossible to link back to actual clients in the production database.
  • Create a back-up and restore procedure which does not take longer than 4 working hours.
  • Create a back-up and restore procedure which should be possible at least on a weekly basis with a lead time of 1 working day.
  • A representative set of production(like) test data can be unloaded in the test environment.
  • Back-up and restore procedures exist to back-up and release a partial or full data extract.
  • Full Data refresh with scrambled production data is possible on request  with a lead time of at least 1 working week.
  • Make sure a procedure to request for a data is implemented.

Please share in your inputs in all the stages so that we could put together and help our friends online.

Join our community in Facebook and Google+ at the below URL's to stay up to date:

Facebook Page: http://www.facebook.com/SoftwareQaHelp
Google+ : https://plus.google.com/101680718973348361876





List of requirements and checklist in all the stages of testing

I guess most of you would have missed some important task which should have been done earlier before starting to test. To be open I had came across such situations many times. In order to overcome this, I am creating the checklist for all the tasks in the testing phase. For now I have added few and will keep adding the details. Follow this blog or bookmark it to your favorites to see the updates.

To start building our integration test environment.


Testability requirements

  • All applications that exists or to be delivered in the production have to be available or simulated in the test environment. 
  • Getting the list of settings and configurations is available along with the comparisons of the settings and configurations of the production environment is necessary.
  • Get the required tools and licenses ready for testers (If tools can not be provided due to licensing issues, try to put in a work-around is in place to facilitate testing)
  • If the application is going to use any front end devices to access software through different channels (like phones, card readers, GPS Units, desk tops, laptops, pads,...) get that in place
  • Batch procedures are internally controllable and automated as in a production environment (manual trigger, start, pause, stop batch procedures)
  • Measuring tools should be in place to enable monitoring the communication between applications and application layers.
  • External Connectivity to test environments for support, deployment and testing should be ready
  • Database read access is required for all testers
  • Make sure that the Input/output simulators are in place and documented for every interface type
  • At least 1 test user exists for every defined role in the application under test
  • Time traveling is possible in at least one of the following means: "time goes by faster (eg: 1 week = 1 hour)", "move forward and reset from a defined time in the future", "coherent data creation/update to a  time stamp in the past"
  • All configurations of the different interfacing systems within the test environment have to be centrally managed
  • The test infrastructure has an availability of 95% (planned deployments are not included)
  • Defects are centrally managed, using 1 agreed defect managing system and flow 

I would highly recommend you all to have a look at the other requirements, which I have prepared. 
The checklist of Test data requirements -  Test Data Requirements
The checklist for Deployment/Release management requirements -  Deployment or Release management requirements
The checklist for Maintainability requirements - Maintainability requirements

Join our community in Facebook and Google+ at the below URL's to stay up to date:





What is the role of a tester in defect prevention and defect detection?

What is the role of testers in Defect Prevention and Defect Detection


Testers (especially beginners) often get confused with this Question - “What is the role of a tester in Defect Prevention and Defect Detection?”. In this post we will discuss the role of a tester in these phases and how to testers can prevent more defects in Defect Prevention phase and how testers can detect more bugs in Defect Detection phase. Here is the explanation about these questions.

Defect Prevention 

 

Defect prevention is mostly done by the developers. In the development phase, developers do activities like – code reviews/static code analysis, unit testing, etc. before committing the code in the code repositories. Testers are also involved in defect prevention by reviewing specification documents, the testers could try to find out any possible loop holes in the spec with which the developers are working on (Ideally this process is done by the QA’s and the senior members of the team), however this could done by the testers as well once the document is received by the testers. While studying specification documents, testers encounter various queries and many times with those queries, requirement document gets changed/updated.

Finding the defect in the spec plays a major role in addressing the issues before it is developed and it yields rewarding opportunities. Studying the specification document is an art, all the beginners and the less tenured people should learn to master this art.

Developers often neglect primary ambiguities in specification documents in order to complete the project on time; or they fail to identify them when they see them. Those ambiguities are then built into the code and represent a bug when compared to the end-user's needs. This is how testers help in defect prevention.

Defect Detection  


In Defect detection, role of a tester include implementing the most appropriate approach/strategy for testing, preparation/execution of test cases and conducting the necessary tests like - exploratory testing, functional testing, etc.

To increase the defect detection rate, tester should have complete understanding of the application. Ad hoc /exploratory testing should go in parallel with the test case execution as a lot of bugs can be found through these means.

Defect Prevention and Defect Detection







Join our community in Facebook and Google+ at the below URL's to stay up to date:







Rapid Software Testing

Rapid Software Testing.


Most of large organization in the world along with my company also have decided not to rely on pretense and 40 year-old ideas that were discredited 30 years ago. They are instead putting in place a system to recruit and grow highly skilled and highly motivated testers.

The companies are highly investing to identify and encourage testing champions who could become the role models and mentors for the rest of the group. Anyone may aspire to be in this special group, but to be recognized requires that the candidate tester demonstrate vigorous self-education and critical analysis. One of such demonstration has evolved the RST (Rapid Software Testing).

When this was implemented in my organisation some of the testers in the group began as strong skeptics of Rapid Testing. But the methodology is designed for skeptics– it is based on skill development and heuristics rather than pushing “best practices.” In Rapid Testing, the skilled tester is always in charge, not pieces of paper or officious charts.

RST requires each tester to employ his own judgment and technical analysis, much like what airlines expect of pilots, or hospitals expect of doctors. That can’t work on a large scale without a strong corporate commitment to training and personal ethics. Management must drive out fear, so that testers are willing to take the sort of risks that come from making their own decisions about test strategy. But the onus is on the testers to earn personal credibility within an internal community that can effectively police itself. Any tester, at any time, is expected to stand up and explain and defend his work.

Till now, I’m aware of only two large companies in the world that have made a commitment to this kind of professionalism, which is an altogether different sort of professionalism than the ceremonial certification variety that is promoted by most organizations. Such commitment has to be strongly supported by the top management, and I have personally witnessed when this was implemented in my mid size company only in my project, in my weeks of working with them, that the testers at had fire in their eyes. There are testers everyone in world who deserve to have an international reputation.

Rapid testing can be extended with the following activities to make sure the test results are properly aligned and useful to the client.

Analyze bug list

    Assess bug report quality
    Reproduce bugs
    Close duplicates and non-bugs
    Add labels and categorize according to risk
    What did the client know about before we started?
    What does the client consider important that we found?

Produce “official” test coverage outline
Produce “official” Risk List
Produce official sequence of events
Describe our test activities
Analyze test session reports
Describe what we did not test
Analyze tools used
Identify outstanding student work
Write report narrative and summary

In a real project, our reporting (other than the bug list itself) is either oral, or expressed in brief written statements. On a normal project, once we get organized (after a few days if it’s a new project) reporting gets pretty easy.



Join our community in Facebook and Google+ at the below URL's to stay up to date: