How to improve agility of an Agile Team

Often as an Agile Project Manager or an Agile Scrum Master, your very first challenge is to improve the agility of teams.  So in this article, I will try to post my thoughts on how to improve Agility of a Team in my own words of course and out of my experience.

•   Change their mindset

Agile is a lot about mindset.  Once someone is into that mindset, obviously he/she will contribute the best to the team's cause and thereby it will increase the speed and also the agility of the team.

•   Change your mindset

Acknowledge the fact that you need a mental conditioning as much as the team.  First of all, try to understand what Agile is all about and how it benefits the different stakeholders in the teams.  Try to understand that Agile is not a miracle game and it takes time, proper execution, support from every team member and support from team as a whole to reap its benefits.

•   Improve collaboration

Agile is lot about team working together to complete challenging tasks rather than several team members working in silos.  Emphasize the fact that Agile is a team game.  So Improve the collaboration among the team members, ask them to pair up for some problems and encourage good collaborative team work and make collaboration a habit.

•   Improve the engineering practices

Agile is lot about being nimble, which means that unless proper engineering practices are followed, it may not be very helpful to the team.  If all team members have the right mindset but lack the engineering practices, then that will be a bottleneck to agility.

•   Focus on knowledge sharing

Knowledge shared is knowledge gained.  The problems with traditional teams was that everyone worked in silos and very few members shared their knowledge.  But the main focus of an Agile team is to share the knowledge it gained among its team members so that as a team, they will be in a better position to respond to uncertainties.  As they say, Knowledge is Power.  The more as a team they know, the better inputs they have to solve the problems at hand.

•   Continuous learning

The more you learn, the more you know and the more you can share.  One of the strengths of good Agile teams is that they focus on continuous learning.  As teams continuously learn it enhances the knowledge and hence provides a competitive atmosphere for learning and knowledge sharing.

•   Embrace changes and new ideas

Often the team knows what is going well and what isn't and what needs to be changed.  So give a thought to those ideas and you might see a whole lot of improvements in the Agility.  Embrace changes from the teams also.

•   Strike the right balance between process and innovation

Processes are required to a point to define some standards and to mechanize certain parts of the life cycle.  But over reliance on processes will make the project boring and there will be no scope for innovation.  And focus too much on innovation, you tend to lost of the current goals.  So try to balance between process and innovation.  By that way, you will improve the agility without hurting the current goals and also the innovative ideas of teams.

•   Give the team proper coaching

Unless the team understands the benefits of Agile for them, the customers and the project as a whole, it will be difficult to get a buy in from them.  So give them proper coaching on what is Agile all about and what are the areas of focus.  By understanding, they will try to realize what their roles should be to improve the agility.

•   Take it slow, Embrace the power of small wins

There is no point in rushing.  As already put forward, Agile is not about miracles overnight.  It can be beneficial in the long term, but for that to happen, start small and keep on improving.  Try to identify areas that can be improved and do it one step at a time.  That is when the power of small wins come into picture and the team will get a natural way of progression.

•   Remove impediments for the team

One of the biggest Agility killers is the impediments for the team.  Impediments can be in terms of technical challenges, unwanted distractions from the product roadmap, no clear vision of product goals, waste of time due to lack of effective engineering practices, lack of automation, lack of team work and collaboration, and so on.  Removing these impediments will reduce the friction so that the wheels of Agile can move smoothly.

The Future of Software Testing

 I believe that in the future will we see changes in 6 key areas of software testing:-

1.Accurate information provision (in the language of the recipient)

Software testing’s role is the provision of data to enable go live decisions to be made. If we get this information wrong, wrong decision will be made. If testing can’t provide the right information it actually adds little value.

Key to this is the understanding of what data is required. So many times I see that Test Managers have just produced what they think is right without asking, or even worse don’t understand the goals of the project so don’t know what data should be collected to indicate whether those goals have been achieved.

Test Management tools can help, but they are only as good as the way they are implemented. In a lot of cases this is straight out of the box, with no configuration or understanding of what is to be reported, with a view that the standard reports will be good enough! Test cases are then loaded and then it’s found that the right data is not available!

I believe the way forward for information provision is actually to learn something from the Agile world and start to work/talk to each other. Everyone’s requirement for information is different and so the closer projects work together and people mix the more we can understand and the closer we will be.

I think a software delivery project is much like an orchestra, if each part works together in harmony it can be beautiful, but if only one element works on its own the result will be disastrous. We need to work together so that the software delivery orchestra works, and delivers beautiful results.

2. Building quality in, rather than testing it out, prevention rather than detection

Traditionally software testing’s objective is seen as finding defects, whereas in reality it is a great way of preventing defects.

It continually amazes me how many clients I see who leave testing until the last possible minute. When will companies understand that the earlier a test team is involved, and of course the better trained they are, the more they will recognise problems early in the lifecycle enabling them to be resolved before they become execution defects?

What do I mean? Well, if you knew your back wall was going to fall down, would you wait until it did or do something to stop it falling. The same can be said for a software tester. If early enough in the lifecycle it is identified that elements of the software may fail would it not be better to stop it failing by some corrective action, rather than to leave it to fail and then checking it has!

What I am referring to hear is a risk based approach to testing, understanding what risks the product has at the earliest possible point and putting in place mitigating actions to lessen or completely remove the risk of failure

3. Ensuring that quality is considered and not seen as a burden, alongside time and cost

Many have said that you can’t balance the three sides of the eternal project triangle, time cost and quality. The view seems to be that you can’t have all three you have to pick two!

In my experience, by adopting a collaborative approach and being able to get involved at the earliest point in a project, it is possible to achieve all three.

Whilst working for a large Insurance Company, I liaised very closely with the Development Manager lending him my testing staff so that he could be sure that when his developers had finished developing the code would work. They asked for a week’s extra time, which I agreed to. When the code was delivered to test it just worked and we therefore reduced the lifecycle timescales by 6 weeks and saved over £400k. The developers were happy, the testers were happy and most of all the business got their software early.

The testing costed roughly the same as the back ended budget, but was spread out from a far earlier point, all of the savings were in development not having to support an extended testing window!

The key to this success was the joint ownership of the quality between all parts of the project team. So by focusing on quality early in the lifecycle you can meet the joint objectives of cost, time and quality.

4. Software Testing Qualifications

The reality is that a good software tester or test manager needs a mixture of skills and knowledge to make them successful. In my view the qualifications account for about 10% to 15% of the knowledge required for the practical application in the workplace.

ISEB have recently revised their single Practitioner Exam, into three, the Intermediate, Test Management and Test Analyst, but only prescribe a 3 day training course followed by an exam. There is minimum entry requirement, but they do not include practical test experience, more a passing of time between taking the Foundation exam.

ISTQB on the other hand have just launched their Advanced level qualifications. Like ISEB there are three of them, Test Manager, Test Analysts and Technical Test Analysts, with a minimum training period of 5 days each followed by an exam, with basically the same entry criteria.

I believe software testing qualifications have a very important part to play in the future education and verification of software testers and test managers. The reality is that the qualification together with real practical experience is what makes a good tester. After all would you allow a surgeon who had just passed their exams but had no practical experience to operate on you? I don’t think so.

Employers need to consider what structures and support need to be in place subsequent to a qualification course to ensure what has been learnt is put into practice in the best possible way.

5. Standards

The few standards currently out there are developed by a wide working international group (can be as many as 1000 contributors) who build and review the content. However, by necessity they are generic and some concessions have to be made to gain global agreement.

It continually amazes me that even knowing that the standards exist, testers prefer to start from a blank sheet of paper when constructing their processes and templates. They may not be perfect but to start from a point above zero has to be better than no help at all?

I believe we need to embrace the standards more and take from them the information that is right for the project.

6. Test Process Measurement Models

There are many test process measurement models available for testers to review what they do against. For some very strange reason, a lot of test consultancies will build their own version, mainly for the creation of a sales opportunity, and not to help the customer. As a result, the models are woefully short of the real detail required to help improve processes.

There are many standard models out there, but in my opinion the most effective model available today is the new TMMi Model. It is a model that has been developed out of research (rather than commercial interest) and therefore provides a very independent and structured view.

It works along the same lines as CMMi, providing 5 levels of maturity to measure against and supporting key process areas.

Again as in the 5th point above, it may not be perfect but like standards it is there and has many hours of experience vested in it, so why do people still start from a blank sheet of paper when looking at their process, when a short cut is available?

Testing Interview questions

 1. Differentiate between QA and QC?

QA:
      It is process oriented
      It involve in entire process of software development.
      Prevention oriented.
QC:
     It is product oriented.
     Work to examine the quality of product.
     Deduction oriented.

2. What is a bug?
A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result.

3. What is a test case?
Test case is set of input values, execution preconditions, expected results and execution
Post conditions, developed for a particular objective or test conditions, such as to exercise a particular program path or to verify compliance with a specific requirement.

4. What is the purpose of test plan in your project?
Test plan document is prepared by the test lead, it contains the contents like introduction, objectives, test strategy, scope, test items, program modules user procedures, features to be tested features not to tested approach, pass or fail criteria, testing process, test deliverables,testing,tasks,responsibilities,resources,schedule,environmental requirements, risks & contingencies, change management procedures, plan approvals, etc all these things help a test manager understand the testing he should do & What he should follow for testing that particular project.

5. When the relationships occur between tester and developer?
Developer is the one who sends the application to the tester by doing all the necessary code in the application and sends the marshal id to the tester. The tester is the one who gives all the input/output and checks whether he is getting req. output or not. A developer is the one who works on inside interfacing where as the tester is the one who works on outside interfacing

6. When testing will starts in a project?
The testing is not getting started after the coding. After release the build the testers perform the smoke test. Smoke test is the first test which is done by the testing team. This is according to the testing team. But, before the releasing of a build the developers will perform the unit testing.

7. If a bug has high severity then usually that is treated as high priority, then why do priority given by test engineers/project managers and severity given by testers?
High severity bugs affects the end users ....testers tests an application with the users point of view, hence it is given as high severity. High priority is given to the bugs which affects the production. Project managers assign a high priority based on production point of view.

8. What is the difference between functional testing and regression testing
Functional testing is a testing process where we test the functionality/behavior of each functional component of the application...i.e. minimize button, transfer button, links etc. i.e we check what is each component doing in that application...
Regression testing is the testing the behavior of the application of the unchanged areas when there is a change in the build. i.e we check whether the changed requirement has altered the behavior of the unchanged areas. the impacted area may be the whole of the application or
Some part of the application...

10. Do u know about integration testing, how do u integrate diff modules?
Integration testing means testing an application to verify the data flows between the modules. For example, when you are testing a bank application, in account balance it shows the
100$ as the available balance. But in database it shows the 120$. Main thing is "integration done by the developers and integration testing done by the testers"

11. do u know about configuration management tool, what is the purpose of maintaining all the documents in configuration management tool?
It is focused primarily on maintaining the file changes in the history.
Documents are subjected to change for ex: consider the Test case document.
Initially you draft the Test cases document and place it in Version control tool(Visual Source Safe for ex).Then you send it for Peer Review .They will provide some comments and that document will be saved in VSS again. Similarly the document undergoes changes and all the changes history will be maintained in Version control.
It helps in referring to the previous version of a document.
Also one person can work on a document (by checking out) at a time.
Also it keeps track that has done the changes, time and date.
Generally all the Test Plan, Test cases, Automation design docs are placed in VSS.
Proper access rights needs to be given so that the documents don’t get deleted or modified.

12. How you test database and explain the procedure?
Database Testing is purely done based on the requirements. You may generalize a few features but they won't be complete. In general we look at
1. Data Correctness (Defaults)
2. Data Storage/Retrieval
3. Database Connectivity (across multiple platforms)
4. Database Indexing
5. Data Integrity
6. Data Security

13. Suppose if you press a link in yahoo shopping site in leads to some other company website? How to test if any problem in linking from one site to another site?
1) First i will check whether the mouse cursor is turning into hand icon or not?
2) I will check the link is highlighting when i place the cursor on the link or not?
3) The site is opening or not?
4) If the site is opening then i will check is it opening in another window or the same window that the link itself exits (to check user-friendliness of the link)
5) How fast that website is opening?
6) Is the correct site is opening according to the link?
7) All the items in the site are opening or not?
8) All other sub links are opening or not?

14. What are the contents of FRS?
F → Function Behaviors
R → Requirements (Outputs) of the System that is defined.
S → Specification (How, What, When, Where, and Way it behavior's.
FRS → Function Requirement Specification.

This is a Document which contains the Functional behavior
of the system or a feature. This document is also known as EBS External Behavior Specification - Document. Or EFS External Function Specification.

15. What is meant by Priority and severity?
Priority means "Importance of the defect w.r.t customer requirement"
Severity means "Seriousness of the defect w.r.t functionality"

16. What is meant by Priority and severity?
Severity: 
1. This is assigned by the Test Engineer
2. This is to say how badly the deviation that is occurring is affecting the other modules of the build or release.
Priority:
1. This is assigned by the Developer.
2. This is to say how soon the bug as to be fixed in the main code, so that it pass the basic requirement.
E.g., the code is to generate some values with some valid input conditions. The priority will be assigned so based on the following conditions:
a> It is not accepting any value
b> It is accepting value but output is in non-defined format (say Unicode Characters).
    A good example i used some Unicode characters to generate a left defined arrow, it displayed correctly but after saving changes it gave some address value from the
Stack of this server. For more information mail me i will let you know.

17. Give me some example for high severity and low priority defect?
If suppose the title of the particular concern is not spelled correctly, it would give a negative impact.eg ICICC is spelled as a title for the project of the concern ICICI. Then it is a high severity, low priority defect.

18. What is basis for test case review?
The main basis for the test case review is
1. Testing techniques oriented review
2. Requirements oriented review
3. Defects oriented review.

19. What are the contents of SRS documents?
Software requirements specifications and Functional requirements specifications.

20. What is difference between the Web application testing and Client Server testing?
Testing the application in intranet (without browser) is an example for client -server.(The company firewalls for the server are not open to outside world. Outside people cannot access the application.)So there will be limited number of people using that application.
Testing an application in internet (using browser) is called web testing. The application which is accessible by numerous numbers around the world (World Wide Web.)
So testing web application, apart from the above said two testing’s there are many other testing’s to be done depending on the type of web application we are testing.
If it is a secured application (like banking site- we go for security testing etc.)
If it is an ecommerce testing application we go for Usability etc. Testing’s.

21. Explain your web application architecture?
Web application is tested in 3 phases
1. Web tier testing --> browser compatibility
2. Middle tier testing --> functionality, security
3. Data base tier testing --> database integrity, contents

22.suppose the product/application has to deliver to client at 5.00PM,At that time you or your team member caught a high severity defect at 3PM.(Remember defect is high severity)But the client is cannot wait for long time. You should deliver the product at 5.00Pm exactly. Then what is the procedure you follow?

The bug is high severity only so we send the application to the client and find out the severity is priority or not. If its priority then we ask him to wait.
Here we found defects/bugs in the last minute of the delivery or release date
Then we have two options
1. Explain the situation to client and ask some more time to fix the bug.
2. If the client is not ready to give some time then analyze the impact of defect/bug and try to find workarounds for the defect and mention these issues   in the release notes as known issues or known limitations or known bugs.  Here the workaround means remedy process to be followed to overcome the defect effect.
3. Normally this known issues or known limitations (defects) will be fixed in next version or next release of the software

23. Give me examples for high priority and low severity defects?
Suppose in one banking application there is one module ATM Facility. In that ATM facility whenever we are depositing/withdrawing money it is not showing any conformation message but actually at the back end it is happening properly without any mistake means only missing of message. In this case as it is happening properly so there is nothing wrong with the application but as end user is not getting any conformation message so he/she will be confuse for this. So we can consider this issue as HIGH Priority but LOW Severity defects..

24. Explain about Bug life cycle?
1) Tester->
2) Open defect->
3) Send to developer
4) ->if accepted moves to step5 else sends the bug to tester gain
5) Fixed by developer ->
6) Regression testing->
7) No problem inbuilt and signoff
8) ->if problem in built reopen the issue send to step3

25. How can you report the defect using excel sheet?
To report the defect using excel sheet
Mention    :    The Feature that been effected.
Mention    :    Test Case ID (Which fail you can even mention any other which are              dependency on this bug)
Mention    :    Actual Behavior
Mention    :    Expected Behavior as mentioned in Test Case or EFS or EBS or SRS document                                                                                     with section
Mention    :    Your Test Setup used during Testing
Mention    :    Steps to Re-Produce the bug
Mention    :    Additional Info
Mention    :    Attach a Screen Shot if it is a GUI bug
Mention    :    Which other features it is blocking because of this bug that you are unable to
                     Execute the test cases.
Mention    :    How much time you took to execute that test case or follow that specific TC
                     Which leaded to bug?

26. If you have executed 100 test cases ,every test case passed but apart from these test case you found some defect for which test case is not prepared, then how you can report the bug?
While reporting this bug into bug tracking tool you will generate the test case I mean put the steps to reproduce the bug.

27. What is the difference between web based application and client server application
The basic difference between web based application & client server application is that the web application are 3 tiers & client based are 2 tiers. In web based changes are made at one place & it is reflected on other layers also whereas client based separate changes need be installed on client machine also.

28. What is test plan? And can you tell the test plan contents?
Test plan is a high level document which explains the test strategy, time lines and available resources in detail. Typically a test plan contains:
-Objective
-Test strategy
-Resources
-Entry criteria
-Exit criteria
-Use cases/Test cases
-Tasks
-Features to be tested and not tested
-Risks/Assumptions.

29. How many test cases can you write per a day, an average figure?
Complex test cases 4-7 per day
Medium test cases 10-15 per day
Normal test cases 20-30 per day

30. Who will prepare FRS (functional requirement documents)?
What is the important of FRS?
The Business Analyst will prepare the FRS.
Based on this we are going to prepare test cases.
It contains
1. Overview of the project
2. Page elements of the Application (Filed Names)
3. Proto type of the application
4. Business rules and Error States
5. Data Flow diagrams
6. Use cases contains Actor, Actions and System Response

31. How you can decide the number of test cases is enough for testing the given module?
The developed test cases are covered all the functionality of the application we can say test cases are enough. If u know the functionality covered or not u can use RTM (Requirement Traceability Matrix)
32. What is the difference between Retesting and Data Driven Testing?
Retesting: It is manual process in which application will be tested with entire new set of data.
Data Driven Testing(DDT)-It is a Automated testing process in which application is tested with multiple test data.DDT is very easy procedure than retesting because the tester should sit and need to give different new inputs manually from front end and it is very tedious and boring Procedure.

33. What is regression testing?
After the Bug fixed, testing the application whether the fixed bug is affecting remaining functionality of the application or not. Majorly in regression testing Bug fixed module and it's
Connected modules are checked for their integrity after bug fixation.

34. How do u test web application?
Web application testing
Web application should have the following features like
1. Attractive User Interface (logos, fonts, alignment)
2. High Usability options
3. Security features (if it has login feature)
4. Database (back end).
5. Performance (appearing speed of the application on client system)
6. Able to work on different Browser (Browser compatibility), O.S compatibility (technical led called as portability)
7. Broken link testing.........etc
So we need to follow out the following test strategy.
1. Functionality Testing
2. Performance Testing (Load, volume, Stress, Scalability)
3. Usability Testing
4. User Interface Testing (colors, fonts, alignments...)
5. Security Testing
6. Browser compatibility Testing (different versions and different browser)
7. Broken link and Navigation Testing
8. Database (backend) Testing (data integrity)
9. Portability testing (Multi O.s Support)....etc

35. How do you perform regression testing, means what test cases you select for regression?
Regression testing will be conducted after any bug fixed or any functionality changed.
During defect fixing procedure some part of coding may be changed or functionality may be manipulated. In this case the old test cases will be updated or completely re written
According to new features of the application where bug fixed area. Here possible areas are old test cases will be executed as usual or some new test cases will be added to existing test cases or some test cases may be deleted.

36. What are the client side scripting languages and server side scripting languages?
Client side scripting languages are
                    Java script, Vb Script, PHP...etc
Server side Scripting languages are
                    Perl, JSP, ASP, PHP...etc
Client side scripting languages are useful to validate the inputs or user actions from user side or client side.
Server side Scripting languages are to validate the inputs at server side.
These scripting languages provide security for the application. And also provides dynamic nature to web or client server application
Client side scripting is good because it won't send the unwanted input's to server for validation. From frontend itself it validated the user inputs and restricts the user activities and guides him

37. If a very low defect (user interface) is detected by u and the developer not comprising with that defect what will u do?
User interface defect is a high visibility defect and easy to reproduce.
Follow the below procedure
1. Reproduce the defect
2. Capture the defect screen shots
3. Document the proper inputs that you are used to get the    defect in the defect report
3. Send the defect report with screen shots, i/puts and procedure for defect reproduction.
Before going to this you must check your computer hard ware configuration that is same as developer system configuration. And also check the system graphic drivers are properly
Installed or not. If the problem in graphic drivers the User interface error will come.
So first check your side if it is correct from your side then report the defect by following the above method.

38. if u r only person in the office and client asked u for some changes and u did not get what the client asked for what will u do?
One thing here is very important. Nobody will ask test engineer to change software that is
not your duty, even if it is related to testing and anybody is not there try to listen carefully if you are not understand ask him again and inform to the corresponding people immediately.
Here the client need speedy service, we (our company) should not get any blame from customer side.

39. How to get top two salaries from employee tables
Select * from EMP e where 2>= (select count (*) from EMP e where sal>e.sal) order by desc sal.

40. How many Test-Cases can be written for the calculator having 0-9 buttons, Add, Equal to buttons? The test cases should be focused only on add-functionality but mot GUI. What are those test-cases?
Test-Cases for the calculator
so here we have 12 buttons totally 0,1,2,3,4,5,6,7,8,9,ADD,Equalto -12 buttons
here u can press at least 4 buttons at a time minimum for example   0+1= for zero u should press 'zero' labeled button for plus u should press '+' labeled button for one  u should press 'one'  labeled button for equal to u should press 'equal to'  labeled button 0+1=here + and = positions will not vary so first number position can be varied from 0 to 9 i.e from permutation and combinations u can fill that space in 10 ways in the same way second number position  can be varied from 0 to 9 i.e from permutation and combinations u can fill that space in 10 ways
Total number of possibilities are =10x10=100
This is exhaustive testing methodology and this is not possible in all cases.
In mathematics we have one policy that the function satisfies the starting and ending values of a range then it can satisfy for entire range of values from starting to ending.
then we check the starting conditions i.e one test case for '0+0=' (expected values you know that is '0') then another test case for '9+9='(expected values you know that is '18') only two test cases are enough to test the calculator functionality.

41. What is positive and negative testing explains with example?
Positive Testing - testing the system by giving the valid data.
Negative Testing - testing the system by giving the Invalid data.
For Ex, an application contains a textbox and as per the user's Requirements the textbox should accept only Strings. By providing only String as input data to the textbox & to check whether its working properly or not means it is Positive Testing. If giving the input other than String means it is negative Testing.

42. How will you prepare Test plan. What are the techniques involved in preparing the Test plan.
Test plan means planning for the release. This includes Project background
Test Objectives: Brief overview and description of the document
Test Scope: setting the boundaries
Features being tested (Functionalities)
Hardware requirements
Software requirements
Entrance Criteria (When to start testing):
       Test environment established, Builder received from developer, Test case prepared and reviewed.
Exit criteria (when to stop testing):
   All bug status cycle are closed, all functionalities are tested, and all high and medium bugs are resolved.
Project milestones: dead lines

43. What is the Defect Life Cycle?
Defect life cycle is also called as bug life cycle. It has 6stages namely
1. New: found new bug
2. Assigned: bug assigned to developer
3. Open: developer is fixing the bug
4. Fixed: developer has fixed the bug
5. Retest: tester retests the application
6. closed/reopened: if it is ok tester gives closed status else he reopens and sends back to developer.

44. Explain about metrics Management?
Metrics: is nothing but a measurement analysis. Measurement analysis and Improvement is one of the process areas in CMM I L2.

45. What is performance Testing and Regression Testing?
Performance Testing:-testing the present working condition of the product
Regression Testing:-Regression Testing is checking for the newly added functionality causing any errors in terms of functionality and the common functionality should be stable
In the latest and the previous versions

46. How do you review test case?? Type of Review...
Types of reviewing test cases depend upon company standards, viz..,
Peer review, team lead review, project manager review.
Sometimes client may also review the test cases reg what is approach following for project

47. In which way tester get Build a, Build B, Build Z of an application, just explain the process...
After preparation of test cases project manager will release software release note in that Document there will be URL path of the website link from that we will receive
The build In case of web server projects, you will be provided with an URL or a 92.168. ***. *** (Web address) which will help you access the project using a browser from your system.

In case of Client server, the build is placed in the VSS (Configuration tool) which will help you get the .exe downloaded to your computer.

48. Apart from bug reporting what is your involvement in project life cycle?
As a Test engineer we design test cases, prepare test cases Execute Test cases, track the bugs, analyze the results report the bugs. Involved in regression testing, performance of system testing system integration testing at last preparation of Test summary Report

49. Contents of test report
There are two documents, which should be prepared at particular phase.
1. Test Results document.
2. Test Report document.
Test Results doc will be prepared at the phase of each type of Testing like FULL FUNCTIONAL TEST PASS,REGRESSION TEST PASS, and SANITY TEST PASS etc...Test case execution against
The application. Once you prepared this doc, we will send the doc to our TL and PM. By seeing the Test Results doc , TL will come to know the coverage part of the test case. Here I Am giving you the contents used in the Test Results doc.

1. Build No
2. Version Name
3. Client OS
4. Feature set
5. Main Feature
6. Defined Test cases on each feature.
7. QA engineer Name
8. Test cases executed.(Includes pass and fail)
9. Test cases on HOLD (Includes blocking test cases and deferred Test cases)
10. Covereage Report (Which includes the coverage ratings in % ,like % of test cases covered,% of test cases failed)

Coming to Test report, generally we will prepare Test report, once we rolled out the product to our client. This document will be prepared by TL and delivered to the client. Mainly, this document describes the what we have done in the project, achievements we have reached, our
Learning’s in throughout the project etc...The other name for Test report is Project Closure Report and we will summarize the all the activities, which have taken place in throughout the project. Here I am giving you the contents covered in the Test Report.
1. Test Environment (Should be covered the OS, Application or web servers, Machine names, Database, etc...)
2.Test Methods(Types of Tests, we have done in the project like Functional Testing, Platform Testing, regression Testing, etc..
3. Major areas Covered.
4. Bug Tracking Details. (Includes inflow and outflow of the bus in our delivered project)
5. Work schedule (When we start the testing and we finished)
6. Defect Analysis
6.1 Defects logged in different types of tests like Functional Test, regression Test as per area wised.
6.2 State of the Defects at end of the Test cycle.
6.3 Root cause analysis for the bugs marked as NOT A BUG.
7. QA observations or learning’s through the life cycle.

50. Write high level test cases
Write all the test cases under high level TC, which can be covered the main functionalities like
Creation, edition, deletion, etc....as per prescribed in the screen.
Write all the test cases under low level TC, which can be covered the screen, like input fields are displayed as per the requirements, buttons are enabled or disabled, and test case for low priority functionalities.
Example a screen contains two edit boxes login and password and a post buttons OK and Reset and check box for the label "Remember my password". Now let us write high level TC
And low level test cases.

HIGH LEVEL TC
1. Verify that User is able to login with valid login and valid password.
2. Verify that User is not able to login with invalid login and valid password.
Etc...
..
3. Verify that Reset button clears the filled screen.
4. Verify that a pop up message is displayed for blank login.
Etc...
Etc...

LOW LEVEL TC
1. Verify that after launching the URL of the application below fields are displays in the screen.
1. Login Name 2.Password.3.OK BUTTON 4.RESET button etc.
5. Check box, provided for the label "remember my pwd" is unchecked.
2. Verify that OK button should be disabled before selecting login and password fields.
3. Verify that OK button should ne enabled after selecting login and password.
4. Verify that User is able to check the check box, provided for the label "remember my pwd".
Etc...
In this way, we can categorize all the test cases under HIGH LEVEL and LOW LEVEL.

51. What is test scenario?
Test scenario will be framed on basis of the requirement, which need to be checked. For that, we will frame set of test cases, in other terms, we can say all the conditions, which can be determined the testing coverage against business requirement.
Please see the below example, which is exactly matched to my explanation.
As we know all most all the application are having login screen, which contains login name and password. Here is the test scenario for login screen.
Scenario: USER'S LOGIN
Conditions to be checked to test the above scenario:
----------------------------------------------------
1. Test login field and Password field’s individually.
2. Try to login with valid login and valid password.
3. Try to login with invalid login and valid password etc.

52. What is build duration?
it is a tine gap between old version build and new version build  in new version build some new extra features are added

53. What is test deliverables?
Test deliverables are nothing but documents preparing after testing like test plan document  test case template bug report template Test deliverables will be delivered to the client not only for the completed  activities ,but also for the activities, which we are implementing for the better productivity.(As per the company's standards).Here I am giving you some of the Test deliverables in my project.
1. QA Test Plan
2. Test case Docs
3. QA Test plan, if we are using Automation.
4. Automation scripts
5. QA Coverage Matrix and defect matrix.
6. Traceability Matrix
7. Test Results doc
8. QA Schedule doc (describes the deadlines)
9. Test Report or Project Closure Report.(Prepared once we rolled out the project to client)
10. Weekly status report (sent by PM to the client)
11. Release Notes.

54.Wat is your involvement  in test plan
Test lead is involved in preparing test plan test engineers are no way related in preparing test plan role TE is test case design and execution and bug tracking and reporting them generally TL is involved in preparation of the Test Plan. But it is not mandatory only TL will take main part in the preparation of the TP. Test engineer can suggest to TL, if he(or) she has good understanding on project and resources, if he or she has more exp with the project, if TL is wrongly given deadlines. If your suggestions are valid,   TL will incorporate all of them to the Test Plan. But in most of the companies Test engineers are just audience.

55. Which test cases are not to be automated?
All the test cases which are related to a feature of the product, that keeps on changing (there are always some or the other enhancements in it). Frequent enhancements may change the UI, add/remove few controls. Hence such cases, if automated, would involve lot of a intendance

56. If a project is long term project, requirements are also changes then test plan will change or not? Why
Yes. Definitely. If requirement changes, the design documents, specifications (for that particular module which implements the requirements) will also change. Hence the test plan would also need to be updated. This is because "Resource Allocation" is one section in the test
Plan. We would need to write new test cases, review, and execute it. Hence resource allocation would have to be done accordingly. As a result the Test plan would change

57. Explain VSS
Virtual Source Safe:
After completion of all phases from development side developer store the code in development folder of VSS, Testing team copying code from that folder to testing folder, after completing above phages from testing, testers put the build in base line folder. It is version control Tool
Mainly useful to developer, to storing code and maintains version Copying a code from VSS By developer is called CHECK-IN Upload the code in to VSS is called CHECK-OUT.

58. Who will assign severity & priority?
The tester/dev should give the priority based on severity of the bug
Severity means: is the impact of the bug on the app. i.e seriousness of the bug in terms of the functionality.
Priority means: is how soon it should get fixed i.e importance of the bug in terms of customer

59. What is the Difference between Stub Testing and Driver Testing?
Stub testing:
In top down approach, a core module is developed. to test that core module, small dummy modules r used. so stubs r small dummy modules that test the core module.
Driver testing:
In bottom up approach, small modules r developed. to test them a dummy core module called driver is developed.

60. What is a "Good Tester"?
Is one who tries to break the developers software and in a position to venture the bugs. So that at least 80% bugs free software can deliver.

61. What is cookie And Session testing?
A small text file of information that certain Web sites attach to a user's hard drive while the user is browsing the Web site. A Cookie can contain information such as user ID, user preferences, archive shopping cart information, etc. Cookies can contain Personally Identifiable
Information. Session is a connection between a server and client.

62. How would u do performance testing manually for web site.
By noting the time to load  apge or perform any action with stop watch. I know it sounds funny but this is the way performance is tested manually.

63. What is use case? Tell me the attribute of use case?
“Use Case is description of functionality certain features of an application in terms of Actors, actions and responsibilities."
Use Case attributes are:
1.   Information of Document, 2. Description, 3. Objective, 4. Actors, 5.Pre-conditions, 6.Data-element descriptions, 7.post conditions, 8.primary flow, 9. Alternative flow and Business rules/interaction implementations and etc....

64. What is the difference between stress, volume and load testing?
Load Testing: we gradually increase the load and check the performance of the application. We check at what point or maximum load application can sustain.
Stress testing: In this testing v check the performance of application under extreme condition which rarely occurs like
(1) Many concurrent user access the application for short time.
(2) Extra ordinary long transaction.
(3) Very short transaction repeated quickly.

65. When will do the beta test? when will do the alpha test?
Alpha and Beta tests comes under User acceptance test. We will conduct these two system being released. We are giving opportunity to customer to check all functionalities covered or not.
Alpha testing conducting for software application by real customer at development site.
Beta testing conducting for software product by model customer at customer site.

66. How do you select test cases for Regression Testing (The point is when there is change code how do you come know which part of code or modules it will affect).
Consider an example of a form which has a username, password and Login button.
There is a code change and a new button "Reset" is introduced. Regression testing (for that build) will include testing only the "Login" button and not the Reset button (testing Reset button will be a part of cunation testing). Hence the Regression tester need not worry about the change in code, functionality. But he has to make sure that the existing functionality is working as desired. Testing of "Reset" button will be included as a part of Regression, for the next build

67. Can anyone explain the example of high severity and low priority, low severity and high priority, high severity and high priority, low severity and low priority
1. High severity and high priority - Database connectivity cannot be established by multiple users.
2. Low severity and low priority - Small issues like, incorrect number of decimal digits in the output.
3. Low severity and high priority - Images not updated.
4. High severity and low priority - In a module of say 2 interfaces, the link between them is broken or is not functioning.
(1)High priority & High Severity: If u clicks on explorer icon or any other icon then system crash.
(2) Low priority & low severity: In login window, spell of ok button is "Ko".
(3) Low priority & high severity: In login window, there is a restriction login name should be 8 characters if user enter 9 or than 9 in that case system get crash.
(4) High priority & low severity: Suppose logo of any brand company is not proper in their product. so it affects their business.

68. What will be the Test case for ATM Machine & Coffee Machine?
Test cases for ATM Machine
1. Successful in section of ATM card
2. Unsuccessful operation due to insert card in wrong angle
3. Unsuccessful operation due to invalid account ex: other bank card or time expired card
4. Successful entry of PIN number
5. Unsuccessful operation due to enter wrong PIN number 3times
6. Successful selection of language
7. Successful selection of account type
8. Unsuccessful operation due to invalid account type
9. Successful selection of withdrawl operation
10. Successful selection of amount to be withdrawl
11. Successful withdrawl operation
12. Unsuccessful withdrawl operation due to wrong denominations
13. Unsuccessful withdrawl operation due to amount is greater than day limit
14. Unsuccessful withdrawl operation due to lack of money in ATM
15. Unsuccessful withdrawl operation due to amount is greater than possible balance
16. Unsuccessful withdrawl operation due to transactions is greater than day limit
17. Unsuccessful withdrawl operation due to click cancel after insert card
18. Unsuccessful withdrawl operation due to click cancel after inserts card & pin number
19. Unsuccessful withdrawl operation due to click cancel after insert card, pin number & language
20. Unsuccessful withdrawl operation due to click cancel after insert card, pin number, language &account type
21. Unsuccessful withdrawl operation due to click cancel after insert card, pin number, language, account type & withdrawl operation
22. Unsuccessful withdrawl operation due to click cancel after insert card, pin number, language, account type, withdrawl operation &amount to be withdrawl

69. Tell me about your daily activities as a test engineer.
Role:
1. Understanding the BRS and Use cases Document
2. Giving system demo to PM, System analyst, designer, Dev lead.
3. Preparing the Test Actions in xls sheet.
4. Updating the Test Actions based on review comments by System analyst/Business Analyst.
5. Preparing the Test cases and Datasets (System level and global level datasets) in word document
6. Updating the Test Cases based on review comments by System analyst.
7. Installing the application-Testing environment set up.
8. Performing Functional, GUI, System, Compatibility testing (If necessary), Regression testing based on Test cases
9. Preparing the defect report, Bug tracking list and sending daily status report to PM, leads.

70. In sdlc process what is the role of PM, TL, DEVELOPER, tester in each and every phase? Please explain me in detail?
In the sdlc we have these phases
1. Initial phase
2. Analysis phase
3. Designing phase
4. Coding phase
5. Testing
6. Delivery and maintenance

    In the initial phase project manager can prepare a document for the requirements, team leader will prepare a team which is having  test engineers, developer will provided by the project manager, tester will prepare test cases for that particular project
   Analysis phase all the members have a meeting to finalize the technology to develop that project, the employee, time ,...
   Designing phase the project manager like senior level management will give the directions and source code to the team members to develop the actual code that is guidelines will be given in this phase
    Coding phase developer will develop the actual code using the source code and they release the application to the tester
    Testing phase they deploy their test cases to that application and prepare a bug profile document if there is any defect/bug in that application and send it back to developer, developer may rectify and releases the application as next build and if the bug not understand it will send to the project lead   in the delivery phase the Sr.Test engg can deploy the application in the client environment
     Maintenance phase if the client get any problem with the application it may solved by the project lead with the help of testers and developers

71. How do you Test Application with having any requirement and Document?
If it is an existing system or if a build is available then we explore the system while testing. This helps knowing the functional use of the system, and its usability.
By asking questions to end users and how they use it will be more beneficial. Also, you may work with BA to know more about the system.
Black box test is nothing but the same where you explore the system without having any prior knowledge to the system.

72. What is backend testing using SQL?
Executing SQL statements to check if the data submitted by a GUI program is updated in the database or not? Executing the statement the data base is connecting to those particular changes, updating or not it will test. Backend testing is the testing the integration between the application and the database. It is checking the changes made in the database are getting reflected in the application.
   Example: A new column is added in the table. Here we test by giving values in the application and value has to be stored in the table.

73. What are the reasons why parameterization is necessary when load testing the Web server and the database server?
When you test your applications, you may want to check how the application performs the same operations with multiple sets of data. For example, suppose you want to check how your Web site responds to ten separate sets of data. You could record ten separate tests, each with its own set of data. Alternatively, you can create Data Table parameters so that your test runs ten times, each time using a different set of data.

74. Difference between strategic test plan & test plan?
Strategic test is an organizational level term which is applied for all the projects in the organization with small customizations.
Test plan is project level term and which can be applied for that specific project only.
Test plan is a strategic document which describes how to perform testing in an efficient effective and optimized way. Quality lead test lead can prepare this test plan
  Strategic test plan is an already or new test plan which can be used in the future for another project also with some changes in the same organization.

75.Draw Backs of automated testing?
DRAW BACKS OF AUTOMATION
Expensive, lack of expertisation, all the areas we cannot automate

76. When will u make update and modify the test object properties in the repository?
Whenever the developer may change any one of the object properties definitely we have to change the same in the OR object repository. If new version net build released from the development department then the test engg must to modify or update the same is compulsory, otherwise the test will show the bug

77. What are the documents needed to create a test case? How u tell it is test case?
System requirements specification, Use case document, Test Plan

78. in customer details from having fields like customer name, customer address. After completion of this module, client raise the change as insert the two radio buttons after customer address. How you can check as a tester.
1. First we need to verify whether the radio button is there are not?
2. Confirm the radio buttons are present after the customer address or not.
3. Verify the no of radio button.
4. Verify only one radio button should be checked initially when we open the Customer details form (if it is mentioned in FRS)
5. Verify the functionality of the radio buttons i.e. if we check one ratio button, second radio button should be unchecked.
6. Verify the spell check of radio button label name.
7. Verify the alignment of radio buttons in the form.

79. at the time of testing web based applications and client server applications, what you observed as a tester?
We generally check for the links, data retrieving and posting.
We perform load and stress testing especially for Web based and Client-Server applications.

80. What are the documents required to prepare test plan?
Introduction, scope, test team and their responsibilities, test environment,  S/W&H/W requirements, test data preparation ,levels of testing, severity  & priority , schedule ,risk, automation plan, features to test, bug life cycle all these are documents of test plan.

81. What is testing policy and testing methodology? And what is the difference?
Testing policy means all types of testing or testing techniques (i.e. functional testing, sanity testing etc).Testing methodology means white box and black box testing.

82. What is comparison testing?
Comparison Testing means comparing your software with the better one or you’re Competitor.
While comparison Testing we basically compare the Performance of the software. For ex If you have to do Comparison Testing of PDF converter(Desktop Based Application) then you will compare your software with your Competitor on the basis of:-
1. Speed of Conversion PDF file into Word.
2. Quality of converted file.

83. What is the general testing process?
Testing Process:
1. Test requirements analysis
2. Creation of Test Strategy (Which includes creation of Test Cases)
3. Creation of Test Plans (Which includes Test Cases and Test Procedures)
4. Execution of test cases
5. Analyze the test results
6. Report the defects if any

84. What participation a manual tester can do in documentation? Are there any tools available for only documentation?
Yes, Manual tester will do Sub Test plan documents, as of my knowledge no tool is used to prepare documentation

85. What is the difference between low and high level test cases? Examples please.
High level Test cases are those which covers major functionality in the application (i.e. retrieve, update display, cancel (functionality related test cases), and database test cases).
Low level test cases are those which are related to UI related test cases.

86. is it mandatory to use USECASES or directly one can write test cases from requirements?
It’s not mandatory to write Use Cases, If the requirements are clear you can go ahead with Test Cases. Use Cases are written to know the business flow of the module/application.

87. How does u develop test harness?
Test Environment +Test Bed
Test Environment: S/w and H/w
Test Bed: Test Documents like Test Plan Document, Test Case Document.
Test Environment means
• Test Bed installation and configuration
• Network connectivity’s
• All the Software/ tools Installation and configuration
• Coordination with Vendors and others

88. Given n requirement collection doc, tester can prepare which test plan?
Test lead can prepare a test plan which performs testing on an application in an efficient effective and in an optimized way. Test development will do by the testers using the test plan in the test plan they prepare the test strategy (Test Strategy is a Document, developed by the Project manager, which contains what type of technique to follow and which module to test).

89. Tester with development knowledge will be more effective. Justify?
If tester has experience in Development, it will be useful when testing for logical thinking where the error occurs, what is the cause? He can guess the functionality of component? He can easily understand the application environment? Those are plus points which people have Development experience.
Precisely he can justify that either functionality is wrong or right and can analyze the defects

90. Last test case for project will be written in which phase?
As far as the SDLC is concerned last test case will be written for "Maintenance Phase"
As far as the STLC is concerned last test case will be written for "Acceptance Testing"

91. What is test scenario and test case? Please explain detail
Test Scenario:
Test scenario is like laying out plans for testing the product, environmental condition, number of team members required, making test plans, making test cases and what all features are to be tested for the product. Test scenario is very much dependent on the product to be tested.
Test scenario is made before the actual testing starts.
Test Case:
Test case is a document which provides the steps to be executed which has been planned earlier. It also depends on the type of product to be tested. Number of test cases is not fixed for any product.

92. What is the difference between Project Based Testing and Product Based Testing?
Project based is nothing but client requirements. Product based is nothing but market requirements. Ex. stretching shirt is a project based and readymade shirt is product based

93. What is testing process in related to Application testing?
Testing process is the one which tells you how the application should be tested in order to minimize the bugs in the application. One main thing no application can be released as bug free application which impossible.

94. What is the difference b/n Testing Methodology and Testing methods?
Testing Methodology define process, set of rules and principle which are follow by group concerned with testing the application. Here i explain 7 step testing methodology:
1. Test Requirement Analysis
2. Test Plan
3. Test Design
4. Test execute
5. Defect track
6. Test Automation
7. Test Maintain
Testing methods or we can say that Testing Techniques:
White Box Testing (Unit Testing, Integration Testing)
Black Box Testing (System Testing, Functional Testing, Performance Testing>Load testing>stress testing>volume testing & Security Testing) UAT (done by user/client with actual/live data)

95. What are starting link to test while website testing?
Web based systems are those using the internet, intranet and extranets Web based testing only needs be done once for any applications using the web. Web based testing are as follows:
1. Functional correctness
2. Integration
3. Usability
4. Security
5. Performance
6. Verification of code

96. How GUI testing will be done in manual testing for a website?
For any testing there should be some set of standards to be followed. Particularly in GUI testing, look and feel should be good. We should follow the requirements specification documents for GUI testing.
There should be some screen shots (given by client) which we should follow as it is.
And for button sizes, font, font size , colors  used, placing of links, objects and the placing of the objects in the page should be followed some standards. If we take a button in the page that should be some standard size. If the size of that button is more or less the client feel bad about that. So we should have minimum common sense while testing GUI testing. some time there may be some mistakes in the screen shots provided by the client also, but that is our responsibility to raise those issues.

97. What thing should be tested in regression testing?
While doing Regression Testing a tester must check that any new updating or Modification or Change in Functionality of a Particular Component or Module does not create any disorder and any negative effects on the functionality of the Application

98. What are the documents required to prepare during testing?
Normally Test engineers are responsible for any release of a project. Even the release is for staging environment or change request release or production release
The minimum documents are
1. Test Plan
2. Test Cases
3. Test Case Report
4. Bug report.
5. Release notes (which contains known issues).
6. Installation document.

99.What is Test data ?Where we are using this in testing process?
What is the importance of this data?
To execute test cases we should have test data. This test data should be for positive and negative testing. For win runner we can get this test data from keyboard, excel sheets or from data base

100. What is the difference between test case and test script?
Test case is a description what data to be tested and what data to be inserted what are the actions to be done to check actual result against expected result what are the actual inputs we will use? What are the expected results? is called test script
Test Script: Is a short program written in a programming language used to test part of the functionality of the software system. a written set of steps that should be performed manually can also be called a test script, However this is more correctly called a test case.

101. What is the difference between bug, error, and defect.
At the time of coding mistake error, when the mistake noticed by the tester defect, tester sends this defect to development team if the developer agrees then it is bug.

102. What is the difference between quality assurance and system testing explains in detail with an example?
Quality Assurance: It is nothing but building an adequate confidence in the customer that the developed software is according to requirements. Entire SDLC comes under QA. It is process oriented.
System Testing: It is the process of executing entire system i.e. checking the s/w as well as parts of system.

103. How do you decide when you have 'tested enough?'
When the 90% of requirements are covered, Maximum defects  are rectified except (some)low level defects are not covered , customer satisfy that project and time is less, then we are closing the testing.

104. What is the difference between Build Management and Release Management?
When will conduct build verification and end to end testing?
Build Management is managing the issue fixture tasks in the builds whereas Release management is managing the functionality to be incorporated in the Release.
Build Verification Test (BVT)is done when the build is first received by the testers. The basic functionality is checked with valid data. This is done to check whether the build is testable or not. This is done by testers.
End to End testing is also called system testing. Done by senior test engineers or Test lead.

105. What is boundary value analysis? What is the use of it?
Boundary value analysis is a technique for test data selection. Test engineer chooses the values that lie along the data extremes. It includes max, min, just inside, just outside, typical values and error values.
Boundary Value Analysis is a technique used for writing the test cases..For example: If a particular field accepts the
Values from 1 to 1000, then we test that field by entering only 1, 1000, 0, 1001, 999, 2.
i.e we check on the boundaries and then
Minimum-1, minimum +1 and maximum+1, maximum-1.

106. What is equivalence partition? What is the use of it?
Equivalence nothing but select the valid and valid classes example as per client requirement the edit box access only
3-5 capital alphabets then we divided in ecp like valid values only A-Z invalid values are a-z and special characters like ^,8<%

107. If there is no sufficient time for testing & u have to complete the testing then what will u do?
When I have less time to test the Product then I will take these following steps---
1)  Sanity or smoke testing
2)  Usability Testing
      3) Formal Functionality and GUI Testing
      4) Walk through with the Product

108. What is meaning by prototype in SDLC?
This is a cyclic version of the linear model. In this model, once the requirement analysis is done and the design for a prototype is made, the development process gets started. Once the prototype is created, it is given to the customer for evaluation. The customer tests the package and gives his/her feed back to the developer who refines the product according to the customer's exact expectation. After a finite number of iterations, the final software package is given to the customer. In this methodology, the software is devolved as a result of periodic shuttling of information between the customer and developer. This is the most popular development model in the contemporary IT industry. Most of the successful software products have been developed using this model - as it is very difficult (even for a whiz kid!) to comprehend all the requirements of a customer in one shot. There are many variations of this model skewed with respect to the project management styles of the companies.
New versions of a software product evolve as a result of prototyping.

109. What is difference between desktop and web application?
The biggest d/f b/w Desktop and web application is Desktop App (DA) is the machine independent, hence every change has only reflects at the machine level.   Where as Web App (WA) is the Internet dependent program, hence any change in the program reflects at every where, where it becomes use.
EX:  Suppose there are 5 machines in DA, 5 times installed individually at every machine and if there is any change made in DA then at every machine change has to be made.  In WA where the program or Application at the Server or at  the one common machine, then if changes made at only central or server or common machine all the changes get reflected at Every client machine.

110. Difference between application testing and product testing?
Product testing means when any company does testing for their own (company's) product ex... Norton Ant Virus is the Symantec's product; if Symantec test the Norton ie. Called
As the Product testing. Where as if any company take some projects from some other
Companies like ABC Company takes projects from IBM and test that project on some charges ie called as Application Testing.

111. What is a broken link in web testing and how test it.
When we clicked on Hyperlink if it opens Page can't be displayed then that Hyperlink is called as broken link

When Test Automation Is Not Good

Machines do the job accurately but they lack flexibility which only human mind possesses. Thus, if we write automated tests, upon their execution we can find that there are a lot of obvious bugs missed out. That is because we design automated tests so that they are focused on one thing only and therefore many related errors remain overlooked.

It is thought by many now that all testing should be automated, because automated tests are cheap while testers need costly salaries. Someday it may be true, but not yet. Test automation is a right solution when the project is in sustaining mode, though it is not effective when a new product is tested. In this case it is better to combine automated and combine testing rather than rely only on test automation. Otherwise a lot of bugs will occur in the aspects unforeseen in automated tests.
The latency of automation is also higher as well as the cost caused by mistakes. There is an example of a situation when automated test misses obvious things. An automated test set to test CD playback would never notice that every next song somehow plays louder than the previous one. This bug is absolutely clear for anybody but not for automated tests. For them the state of things is normal as the next song is playing and that is what they were designed to check.

There are many of such examples and all of them show that test automation can’t cover all the aspects, especially in newly developed features. To cover all the possible errors a lot of separate test cases should be designed and that is very costly.

Besides a lot of side effects in automated tests may occur and thus many bugs will be not revealed as well. In the aftermath the unfound bugs may result in huge losses of profit if the product is released in such a condition and the users come upon these bugs.

To conclude, it should be said that using only manual or automated testing is not the way for successful development, that’s way they must be wisely incorporated to prevent possible failures successfully.

Useful Tips for Agile Tester

Who is agile tester?

Agile tester is a skilled professional who is guides and controls the product development team in order make sure that the product and its features behaves as it should and no bugs involved. He makes conversations with owners or stakeholders of the product to have a clear vision of the features. He needs to understand all the features with maximum clarity, so all the team would be on the same page about the product and its features.

Agile testers should be technically experienced, cooperate with people well to automate tests and also do additional exploratory testing. Also agile testers should be capable to insure that the non-functional requirements are also met.

Agile tester is a member of a team who drives agile testing. Not necessary that he or she starts with agile testing on the first place, meaning that most of agile testers used to start with some other area of specialization and only after certain time decided to become an agile tester.

The agile team should always look forward to bring the best product ever. For that the whole team and its members should be well-organized, disciplined, have time to learn new things, make experiments and be able to collaborate with each member of a testing team.  Creative, results-oriented, craftsman-like, open-minded, ready to take any task and an ability to see a bigger picture are the components of a mind-set of a successful agile tester.

The principles that are valuable and vital for an agile tester are:

Always give a feedback.
Bring on the value to the customer.
Manage face-to-face communication.
Be courageous.
Make it easy.
Deliver constant enhancement.
React to modifications.
Be self-disciplined.
Be focused on people.
Enjoy the process.
A good agile tester can make a significant impact and contribution on a positive outcome of a project. Thus, it is necessary to have the above mentioned qualities to succeed.

Things To Remember While Doing Exploratory Testing

While doing exploratory testing it’s often difficult to decide what to start with since the opportunities abound.

In order to do it effectively we offer testers to concentrate on the three starting points to keep in mind all the way through.

Don’t follow the documentation.

Exploratory testing is something you can perform without any specification and scripted test cases. However, if such handy guides are at hand, it’s always tempting to resort to their instructions. This is the mindset you have to avoid. While checking in with the documentation, you tend to rely on their standpoints and assume the tactic of confirming that everything works as expected. Instead your role now is the opposite, because you have to find the points where the system fails. It’s better to do cross-reference using documentation afterwards. Without resorting to it you think broader, you may even unintentionally discover some undocumented implicit requirements, errors and inconsistencies in documentation etc.

Question rather than verify.

When there’s a need to test some feature, we are naturally inclined to make prove that it works properly. This inclination is likely to restrict our interaction with this feature and place in focus only its positive responses. Our mission here should start with breaking the traditional frame of mind and try to contradict the expected rather than verify it. While testing, ask yourself negative questions such as “In which case it wouldn’t work?” or “In which case it couldn’t work?” to question the expected order of things and test it properly.

Be Persistent.

Since the temptation to believe that everything works right is strong, we often give up our hunt for bugs after several tests indicating none. To test more thoroughly, here are some additional ideas to dig up more bugs:

Explore the type, length, formats and other properties of complex input data.
Test the product’s performance on computers with different capacity, in an environment under different data production quantities etc.
See if it’s possible for malicious users to use the given feature or its parts in non-provided ways.
Test it against different browsers, platforms, databases etc.
Check if the actions performed by several users conflict.
Test how the feature reacts to the missing external components.
Try out how different users handle the feature and what can be improved for better usability.
Check if non-English users understand everything and if something needs localization.
The ideas for effective exploratory software testing are infinite if you assume the given mindsets.

When To Use Exploratory Testing

When scripted tests are carried out and some information that offers a new test strategy comes up, it is the time for exploratory testing to reveal itself. It is especially useful in complicated situations when you don’t know much about the product and you have to prepare a set of scripting tests.

Exploratory vs. Scripted Testing

While scripted testing mechanizes the test process by writing down the scenarios and executing them, exploratory testing aims to exceed the bounds of this approach and make testing a more intellectually rich and fluid process.

Scripted testing includes test cases and following them strictly. The steps are documented and the bugs are reported. This methodology can simply lead a tester to a desired result but many bugs users might face can fall out of scope. In this way you successfully solve certain issues and pass over the other ones.

Exploratory tests are carried out ‘on the go’ and allow the tester to take steps which a user might take but not the ones the script tells. Having no restraints it shows how the product might be used ‘in the wild’. A common thing for the creators of the product is to miss some unexpected details. Exploratory testing brings a fresh eye here.

In general, while scripted approach is a way of intensive testing of prescribed cases, the exploratory approach may uncover the unexpected defects.

Pros And Cons Of Exploratory Testing:

Pros:

No need for long preparation
More intellectual approach
Quick detection of bugs
Does not require documentation

Cons:

Requires a certain mindset
Its unstructured nature makes it easy to lose focus
Due to performing ‘on-the-fly’ it can sometimes be difficult to define exactly which tests were run and hard to repeat certain cases if necessary
When To Use Exploratory Testing

You need to learn the product quickly and provide a rapid feedback
You don’t know what the next test should be
To diversify the testing process after having done scripts
To do a brief check of other testers’ work

Conclusion

Exploratory and scripted testing are the two approaches that are not mutually exclusive but, on the opposite, fully compatible and can be used on the same project. Actually, most of the software testing problems cannot be solved from only one of these approaches but require both of them on different stages.

Fake tester

Have you every worked with a fake tester? How would you notice? How would you notice how much they are faking? 

Fake Testers
What are fake testers? Fake testers are testers that take the requirements documents, use Microsoft Word’s search & replace function to replace all “should” to “verify”, and save that document as their test plan. Fake testers are testers that steadily increase the amount of tests executed counter on their desk for management reporting. Fake testers are testers that surf the web while executing test cases.

What’s the problem with fake testers? They make the impression that they are working while they actually aren’t. Fake testers maximize the impression that they are busy all day to the extent that you rarely want to provide them with more work while they are actually fetching new coffee all day.

Fake testers have an impact on your team morale. Of course, whether management attention focuses on fake testers or not, their team mates will notice over time whether they executed the amount of tests that they report in their numbers. Team colleagues will notice that they are faking. Most of the time they will even know how to make procrastination look like work – even more so if they are measured by the wrong numbers with surrogate measurements, but don’t get me started on these.

So, your loyal testers will know that someone is faking work, but then what? These loyal testers will wonder why they get the same raise as that other guy that is faking work. Why are they putting so much effort into their work while they could actually do that other fun stuff over there. Yeah, right, some of you, dear readers, will tell me “but I ain’t faking”, “I am morally giving my best”, blablabla. But I tell you – and so does Sutton – the majority of you will become a fake tester on their own in such an environment. They will find ways to deliver the same results with fewer effort – just because someone else can do so. Oh, they won’t actually deliver the same outcome, just the same output. They will make the impression to deliver the same results, while not providing the same value.

Over time, you will get a working environment of fake testers. They will drive down morale to the point where good people leave. At that point, you will have a fake testing organization, while still wondering why your bug metrics look correct. That will be too late – for you and your customers.

Are you faking?
I think to some extent we might be faking at times. It’s hard to tell whether you are fake testing right now while reading my blog entry, or whether you are using your power of procrastination. Call it whatever you would like to call it, but I think to some extent we are all faking work at times.

Just as we all are acting as assholes at times – especially so during emotionally stressful challenges that life might put on our own. The same applies to fake testing. Us humans can’t perform the same way every day at work. There are phases where we are more productive, and phases where we are less productive. If your productivity shows no variation, that would make me suspicious.

The thing is, you shouldn’t cross a certain boundary when you notice you are faking or becoming an asshole. At that point, you might become the asshole that draws down productivity in the overall company, and should probably leave.

But how do you notice that you are the problem? Just as the classic joke with the ghost driver goes, if you find yourself surrounded by ghost drivers all over the road, chances are, it’s you that is the ghost driver. If you find yourself surrounded with assholes, chances are it’s you that is the asshole. If you find yourself surrounded with fake testers, chances are it’s you who started that.

Don’t go down that road. Remember to do a good job, and try to minimize negative effects as best as you can.

The No-Fake-Tester Rule
But my claim goes further. I think we should go way further. Instead of throwing out fake testers from our companies, I think we need to fire fake testers from our profession. We should publicly announce their names, and tell the whole industry that they should not hire that guy.

The profession of software testing has taken serious damage by these fake testers. Programmers, project managers, and customers are suspicious about the value that we can provide. And I think they are rightly so. We should be able to explain ourselves. We should be able to explain what we are doing, and why we are doing it, and how we are providing value to them by doing it. If we are not, then we are setting up ourselves to disappoint more people around us, and leave a negative impression on the profession for the generations yet to come. We shouldn’t do that.

We should install a No-Fake-Tester Rule deeply into our profession, and get rid of anyone who is providing a harmful disservice to their clients, their stakeholders, and our profession. It’s not too late to face the problem, as long as we decide against becoming that asshole or fake tester on our own.

Some Classic Testing Mistakes

The role of testing

•     Thinking the testing team is responsible for assuring quality.
•     Thinking that the purpose of testing is to find bugs.
•     Not finding the important bugs.
•     Not reporting usability problems.
•     No focus on an estimate of quality (and on the quality of that estimate).
•     Reporting bug data without putting it into context.
•     Starting testing too late (bug detection, not bug reduction)

Planning the complete testing effort

•     A testing effort biased toward functional testing.
•     Under-emphasizing configuration testing.
•     Putting stress and load testing off to the last minute.
•     Not testing the documentation
•     Not testing installation procedures.
•     An over-reliance on beta testing.
•     Finishing one testing task before moving on to the next.
•     Failing to correctly identify risky areas.
•     Sticking stubbornly to the test plan.

Personnel issues

•     Using testing as a transitional job for new programmers.
•     Recruiting testers from the ranks of failed programmers.
•     Testers are not domain experts.
•     Not seeking candidates from the customer service staff or technical writing staff.
•     Insisting that testers be able to program.
•     A testing team that lacks diversity.
•     A physical separation between developers and testers.
•     Believing that programmers can't test their own code.
•     Programmers are neither trained nor motivated to test.

The tester at work

•     Paying more attention to running tests than to designing them.
•     Unreviewed test designs.
•     Being too specific about test inputs and procedures.
•     Not noticing and exploring "irrelevant" oddities.
•     Checking that the product does what it's supposed to do, but not that it doesn't do what it isn't supposed to do.
•     Test suites that are understandable only by their owners.
•     Testing only through the user-visible interface.
•     Poor bug reporting.
•     Adding only regression tests when bugs are found.
•     Failing to take notes for the next testing effort.

Test automation

•     Attempting to automate all tests.
•     Expecting to rerun manual tests.
•     Using GUI capture/replay tools to reduce test creation cost.
•     Expecting regression tests to find a high proportion of new bugs.

Code coverage

•     Embracing code coverage with the devotion that only simple numbers can inspire.
•     Removing tests from a regression test suite just because they don't add coverage.
•     Using coverage as a performance goal for testers.
•     Abandoning coverage entirely.

Tips to do Cookie Testing

 What is Cookie?
Cookie is small information stored in text file on user’s hard drive by web server. This information is later used by web browser to retrieve information from that machine. Generally cookie contains personalized user data or information that is used to communicate between different web pages.

Two Stage Process:
Cookies are based on a two-stage process. First the cookie is stored in the user's computer without their consent or knowledge. For example, with customizable Web search engines like My Yahoo!, a user selects categories of interest from the Web page. The Web server then creates a specific cookie, which is essentially a tagged string of text containing the user's preferences, and it transmits this cookie to the user's computer. The user's Web browser, if cookie-savvy, receives the cookie and stores it in a special file called a cookie list. This happens without any notification or user consent. As a result, personal information (in this case the user's category preferences) is formatted by the Web server, transmitted, and saved by the user's computer.
During the second stage, the cookie is clandestinely and automatically transferred from the user's machine to a Web server. Whenever a user directs her Web browser to display a certain Web page from the server, the browser will, without the user's knowledge, transmit the cookie containing personal information to the Web server. 

Why Cookies are used?
Cookies are nothing but the user’s identity and used to track where the user navigated throughout the web site pages. The communication between web browser and web server is stateless.
For example if you are accessing domain http://www.domain.com/1.html then web browser will simply query to example.com web server for the page 1.html. Next time if you type page as http://www.domain.com/2.html then new request is send to example.com web server for sending 2.html page and web server don’t know anything about to whom the previous page 1.html served.

What if you want the previous history of this user communication with the web server?
You need to maintain the user state and interaction between web browser and web server somewhere. This is where cookie comes into picture. Cookies serve the purpose of maintaining the user interactions with web server.

How cookies work?
The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are two types of HTTP protocol. Stateless HTTP and Stateful HTTP protocol. Stateless HTTP protocol does not keep any record of previously accessed web page history. While State full HTTP protocol do keep some history of previous web browser and web server interactions and this protocol is used by cookies to maintain the user interactions.

Whenever user visits the site or page that is using cookie, small code inside that HTML page (Generally a call to some language script to write the cookie like cookies in JavaScript, PHP, Perl) writes a text file on users machine called cookie.

Here is one example of the code that is used to write cookie and can be placed inside any HTML page:

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME;

When user visits the same page or domain later time this cookie is read from disk and used to identify the second visit of the same user on that domain. Expiration time is set while writing the cookie. This time is decided by the application that is going to use the cookie.

Generally two types of cookies are written on user machine.

1) Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the browser this session cookie gets deleted. Some time session of say 20 minutes can be set to expire the cookie.

2) Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.
Where cookies are stored?
When any web page application writes cookie it get saved in a text file on user hard disk drive. The path where the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet explorer store cookies on path “C:\Documents and Settings\Default User\Cookies”
Here the “Default User” can be replaced by the current user you logged in as. Like “Administrator”, or user name like “VijayDeenanathChauhan” etc.

The cookie path can be easily found by navigating through the browser options. In Mozilla Firefox browser you can even see the cookies in browser options itself. Open the Mozilla browser, click on Tools->Options->Privacy and then “Show cookies” button.

How cookies are stored?
Let’s take example of cookie written by rediff.com on Mozilla Firefox browser:
On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk. To view this cookie simply click on “Show cookies” button mentioned on above path. Click on Rediff.com site under this cookie list. You can see different cookies written by rediff domain with different names.

Site: Rediff.com Cookie name: RMID
Name: RMID (Name of the cookie)
Content: 1d11c8ec44bf49e0… (Encrypted content)
Domain: .rediff.com
Path: / (Any path after the domain name)
Send For: Any type of connection
Expires: Thursday, December 31, 2020 11:59:59 PM






Applications where cookies can be used:


1) To implement shopping cart:
Cookies are used for maintaining online ordering system. Cookies remember what user wants to buy. What if user adds some products in their shopping cart and if due to some reason user don’t want to buy those products this time and closes the browser window? When next time same user visits the purchase page he can see all the products he added in shopping cart in his last visit.

2) Personalized sites:
When user visits certain pages they are asked which pages they don’t want to visit or display. User options are get stored in cookie and till the user is online, those pages are not shown to him.

3) User tracking:
To track number of unique visitors online at particular time.

4) Marketing:
Some companies use cookies to display advertisements on user machines. Cookies control these advertisements. When and which advertisement should be shown? What is the interest of the user? Which keywords he searches on the site? All these things can be maintained using cookies.

5) User sessions:
Cookies can track user sessions to particular domain using user ID and password.

Drawbacks of cookies:

1) Too many Cookies:
If you are writing too many cookies on every page navigation and if user has turned on option to warn before writing cookie, this could turn away user from your site.

2) Security issues:
Some times users personal information is stored in cookies and if someone hack the cookie then hacker can get access to your personal information. Even corrupted cookies can be read by different domains and lead to security issues.

3) Sensitive information:
Some sites may write and store your sensitive information in cookies, which should not be allowed due to privacy concerns.

How do I enable cookie support in my browser?
Cookies are enabled by default in most browsers, however if you think your browser has cookie support disabled then please follow these instructions:-

For Internet Explorer:
1. Left Click the 'Tools' menu.
2. Left Click 'Internet Options'.
3. Left Click 'Privacy' tab.
4. Left Click the 'Sites' button.
5. Type www.weighin.net into the top box.
6. Left Click the 'Allow' button.
7. Left Click the 'Ok' button.
8. Left Click the 'Ok' button.

For Internet Explorer 7 or 8:
1. Click Start > Control Panel. (With Windows XP Classic View, click the Windows Start button > Settings > Control Panel).
2. Double-click the Internet Options icon.
3. Select the Privacy tab.
4. Click Advanced.
5. Select "Override automatic cookie handling" under the "Cookies" section in the Advanced Privacy Settings window.
6. Select the "Accept" or "Prompt" option under "First-party Cookies."
7. Select the "Accept" or "Prompt" option under "Third-party Cookies." (If you select the "Prompt" option, you'll be asked for approval every time a website attempts to send you a cookie.)
8. In the Internet Options window, click OK to exit.

For Mozilla Firefox:
1. Left Click the 'Tools' menu.
2. Left Click 'Options'.
3. Left Click 'Privacy' tab.
4. Left Click 'Exceptions' button.
5. Type www.weighin.net into the top box.
6. Left Click the 'Allow' button.
7. Left Click the 'Close' button.
8. Left Click the 'Ok' button.

For Chrome in Windows:
1. Click the Tools menu.
2. Select Options.
3. Click the Under the Hood tab.
4. Click Content settings in the "Privacy" section.
5. Select Allow local data to be set to allow both first-party and third-party cookies. If you only want to accept first-party cookies, check the box next to "Block all third-party cookies without exception."
Important Scenarios to test cookie testing for websites:

Test cases:
1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.

2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.

3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.

4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like “For smooth functioning of this site make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test)

5) Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.

6) Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behavior of the pages.

7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can’t be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data.

8 ) Checking the deletion of cookies from your web application page: Some times cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user.

9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.
10) If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value says if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.