Introduction to Agile Testing

While the given application under test is still evolving depending upon the customer needs, the mindset of the end user and the current market condition, it is highly impractical to go for the usual standard SDLC Models like Water Fall, V&V Model etc. Such models are most suitable for the Applications that are stable and non-volatile. The concept of “Time-To-Market” is the key word in today’s IT Business that compels the Software vendors to come up with new strategies to save the time, resources, cut down the cost involved and at the same time, deliver a reliable product that meets the user requirements. In this case, a reasonably good amount of end-to-end testing is carried out and the product could be acceptable with known issues/defects at the end of an intermediate release. These defects are harmless for the Application usability.
To adopt such a process in a systematic way, we have a new concept called Agile Methodology. This methodology continuously strives to overcome the issues of dynamically changing requirements while still trying to maintain a well-defined process.
The process is as follows:
1. The Customer prepares the Business Requirements and the Business Analyst or the Engineering team reviews it. Ideally, the Quality Assurance/Testing team is also involved in reviewing these requirements in order to be able to plan further stages accordingly.
2. During the Design and Implementation stages, the Engineering team writes User Stories and the analysis of issues at various stages. The Customer reviews these on regular basis and updates the Requirement specifications accordingly. The Testing team would follow up on regular basis at every stage until a consolidated documentation is prepared. This is to ensure that the Customer, the Engineering team and the Testing team are at the same page always and thus ensuring complete test coverage.
3. While the Engineering team starts the implementation, the Testing team starts with test planning, test strategies and test cases preparation. These would be properly documented and handed over to the Customer and the Engineering team for review. This is to ensure the complete test coverage and avoid unnecessary or redundant test cases.
4. As and when the Developer implements the code, the Testing team identifies if the application can be built using this code for a quick testing. This is to identify the defects at the early stage so that the developer can fix them in the next round on priority basis and continue with further development. This iteration continues until the end of the code implementation. Once the testing cycle starts, the Test team can now focus more on major test items such as Integration, Usability Testing and System Testing etc.

TESTING TIPS- DAY-1

Its Always good approach to keep the Tester from software Requirement and design phase , so that Tester can have full knowledge of application and if you are not being  part of it , then always Request to your superior and asked to be a part , to have full knowledge of product. Use traceability matrix to maximize Test Coverage whenever you test the application, because might be 100% coverage is not possible, but still try to reach near it. Try to Break the Modules into smaller sub modules  for i.e. if you are testing web based application and there is one functionality of checking User Information , so one should break into different parts like – UI,  Functional,  Security, Browser testing including Positive , Negative , Field type , validation test to ensure maximum coverage. Think positively as well as negatively while doing testing, as it’s very important while testing an application with intend of finding issues, by doing this you will definitely get subtle bugs.

If any TCOE member has similar Testing tips based on their past experience and day to day learning then those can be published through this platform as sharing your own testing experience, ideas or testing secrets will definitely make TCOE more interesting and helpful!!

-Testing Center of Excellence

Software Requirements Specification:

Most modern schools of requirements gathering and system specification development are user driven; this can often be the death of a development project. The truth which is known to the more successful technology development outfits is this: the user is irrelevant, the user does not know what is good for the system, and the user will often try to mislead you into developing software which does something they find useful.

Why do we develop software requirements specifications?

The primary purpose of enterprise software, it should be remembered, is to provide background for the writing of press releases expounding the new technological breakthrough which will bankrupt the competitors and thereby to stampede them into wasting money on competing and equally illogical systems. As a secondary objective, enterprise software is often required to provide credible justifications for the plummeting productivity figures presented at the annual general assembly. It should look exotic and alien; the average shareholder should feel that, because of the very avant garde GTK theme used, it is alien technology which implies that the company is leaps and bounds ahead.

As such, it would make sense for business analysts to spend time watching Independence Day or Minority Report as part of the requirements gathering phase, and possibly also keep a close eye at the latest gentoo screenshots posted. In reality, however, the user-centric specification development cult determines system capabilities, laying waste to the chances for effective systems being developed in the enterprise.

Complicating matters is that the user in question will often be wary of the inclinations to proper project scoping and will instinctively try to lead the project scope amiss. Users are incorrigibly capability driven, and an overbearing focus on capability detracts materially from the resources available for UI obfuscation. Users think business process, communication, process automation, and many other things which bore programmers.

This is another aspect which is often missed in enterprise development: if you bore your coders, you will end up with substandard systems. If the developers want to do an accounting system with a front-end based on the Doom code, the system specifications should be refitted to account for this (including stamping out cheat codes; auditors don't like it when a bean counter can idkfa and iddqd their way to positive cash flows). Bored coders are likely to come up with things like Microsoft Exchange, ODBC, and emacs.

The problem with users

Most users lack vision when it comes to understanding what can really be done with modern technology. This is why development teams are often disparaged for including an email client, an RSS aggregator, CD burning functionality, skinnability, export to Autocad, and embedded flying simulators in the newly launched invoicing system. The user has a very narrow weltanschauung which encompasses only the narrow subset of tasks they are charged to perform, and their consequent failure to evaluate holistic feature impact is therefore a primary culprit responsible for the plethora of uninspiring systems serving the modern business.

Monkeys and compilers

Many requirements analysts employ the focus group as a means of soliciting user requirements. This should be regarded as simply another manifestation of the user centricity blight, albeit one where users can gang up on the analyst and present unreasonable expectations as sine qua non. The focus group as a requirements gathering vehicle may be imposed on the analyst by superiors, but it does not have to be as traumatic as all that given the provision of sufficient alcohol (while corporate policy may need to be reviewed before getting the users drunk, it can often pass if the lunch hour is co-opted for focus group activity). Most marketing officers will be happier to sign off on a requirements document calling for a striped pink and purple UI theme than admit they were drunk at lunch.

hat are the type of certifications offered by ISTQB ?

ISTQB offers two hierarchies of certifications

1) ISTQB - Foundation Level

    Eligibility Criteria : None. Any one can take the exam.

2) ISTQB - Advanced Level

The Advanced Level Exam has 3 Sub - Levels

-Technical Test Analyst
-Test Analyst
-Test Manager 

A single syllabus exists for all the three sublevels. There is an separate paper for each sub-level and each Paper is of 180 Minutes Duration. Sub-Levels can be taken up in any order. An individual Certificate is granted on successful completion of each sub-level.

  Eligibility Criteria for Advanced Level:

  For Bachelor’s Degree (or higher) Holders in Computer Science or related fields

• Foundation Level Clearance
• 24 Months of Testing Experience in IT, Testing, Development,QA, Engineering or related fields (For any 2 sub-levels)
• Min. 36 Months of experience mandatory for Adv. Complete Certification(For all 3 sub-levels)

  

  For Non Bachelor’s Degree (or higher) Holders in Computer Science or related fields

• Foundation Level Clearance
• 60 Months of Testing Experience in IT, Testing, Development,QA,Engineering,or related fields

Why should I take the certification? Is there any market value to the certification?

This is a very controversial topic and can be debated till death.

But here are a few pointers which might assist you in your decision.

- Foremost nothing beats EXPERIENCE.  No certification can provide the exposure and learning you get while working on real time projects. PERIOD!

- If you are a fresher ,or are from a non-technical background and trying to get a job in the software industry ,certification will definitely HELP. Just think about it, as an employer I do not have any other parameters to adjudge your technical caliber, so certification is a good start point.

- If you are an experienced professional and looking for a job change ,a certification will definitely embellish your resume. More so, no matter how rich your experience may be, there will always be some new area of QA that you will learn while studying for the certification. But do not think that you will get a JOB just based on the certification.

Where can I take the examination? What are the Exam Dates ? What is the Exam Fees ?

It all above depends on the Country where you want to take the exam.Please go the link , where you will find the list of member sites of ISTQB.

So in case you want to take the exam in USA, go to the link American Software Testing Qualifications Board.Here you will find the information about Exam Dates, Fees , Registration details etc.                   

For the rest of the article, we will focus on ISTQB Foundation Level. Details about Advanced level will be added later.

What is the Exam Pattern ?

Foundation level exam consists of 40 questions (each having 4 options) which needs to answered in 60 minutes.

Where can I study from?

You can go though our Software Testing tutorials which are based on ISTQB foundation syllabus.  One common demand amongst our members is to explain testing concepts with help real-life scenarios. The lessons use practical case- studies to explain QA concepts.  To maximize your learning it is important that you do the exercises mentioned in the tutorials.