Quality is delighting customers
I work in a small software company.I test a product which it develops from scratch.I just test without documents however by the guidance of developers.There is no spec for this project and hence I cant prepare test cases.What methodology should I adopt in testing and what are the testing documents I can prepare for this type of project?How must I go about preparing the documents as the product evolves?
If you don't have any documents then you can do exploratory testing means you have to explore the application as much as you can and come up with the queries to the development team. Also, if your application have GUI, then you can go for validation things, talk to the developers and get the validations for the fields as mush as you can. create a document screen wise and note down the fields with validations, data types and boundary values, this will help you further when you create the testcases. also if you have any back end then explore the tables and relationship to other tables and primary keys which help to populate the data in tables and fetch the data.
Hope this will help you.
As far as Documents in testing is concerned , they are as follows:-
1) Test Policy
2) Test Strategy
3) High Level Test Plan
4) Detailed Test Plan
5) Test Specification
6) Test Scenario
7) Test Procedure
8) High Level test case ( will go through life cycle Draft----> Review ----> Rework ----> Baseline )
9) Low Level Test case ( with Concrete data ( Test Input ). ( Test Suite will be created )
10) Test execution Log. ( Regression test suite will be maintained )
11) Bug Report / Incident report.
12) Test Summary Report.
Apart from these all :- Traceability Matrix and Reverse Traceability Matrix will also me maintained. Test Matrix will be maintained throughout the life cycle...
But frankly speaking , In rarest of the rare cases these all documents are prepared ... and it is next to Impossible in your organization ... so better :--------------
In such a situation where you are in small organization and documentation is not done in your Org...... I think its better to go with Exploratory testing , Explore the system and test it.... keep on talking with the development team regarding the Functionality as well as any changes made in the system.. as far as Documents are concerned , I personally think that for You its better to Prepare High level test scenario and at least prepare Bug Report ..!
any Correction is highly appreciated ..
Considering above comments is valid, however since understanding the fact that I suggest few points. Since the company is too small and if at all you have a framework or a process in place where your company appreciated such goals and process to follow then go ahead else I would suggest that you first get all the application functionality in brief understanding and write few scenarios and get it reviewed/walkthrough. If the developer gets comfort understanding then continue the same. Later you can align and convert into TC.
Understand and write the critical cases considering frequent changes if needed (If it is product being developed, so lease bother of getting changes). The scenario would help not only tester but business and developers too and any anticipate changes can be easily converted into testcases more effectively and
can be tracked for any purpose in near or future. And also whole team would be in Sync and can work effectively and avoid confusions :) and parallel you have a traceability maintained.
Samrat did an excellent job on the usual documents in an organization that does follow process. In normal situations these documents are key to a traditional waterfall or incremental test process with coverage of new features, milestone criteria and metrics, regression, automation etc etc etc.
As far as methodology goes I would say you are in an agile like environment working with the developers and continuously delivering features. When you say you are done you are done.
What can you do as the product evolves?
Asking this question shows initiative! The one document that I recommend is the Test Strategy. The test strategy is key to not only addressing the product evolution plans but as your company grows you can use it to align the organization of the test process and most importantly the need of resources, capital and human. The strategy can be addressed by reverse engineering the performance expectations of the product, customer issues that have surfaced, the build process, the number of backwards compatible release in the field, platforms/hardware revisions, capacity and all should be viewed as a forward thinking vision.
There are some good templates on the web for a solid test strategy document.
Look to the development, customer support, product owners, managers and peers to help reverse engineer the product needs. It will be very fun and great brainstorming sessions! At the end you will be the champion and then the real work starts!
@ Larry W. Shackelford,
Sir, thank you very much for noticing my answer ..