14

To answer the question "are they worthwhile?", you need to explore: How expensive (in terms of time and money) are they to create, maintain, and execute? What value are these tests providing? Are they finding bugs? Providing confidence? Are there other, less expensive, ways to provide similar value? I once worked at a software company which built desktop ...


11

You could setup personas which are designed around real world of users. We have found this quite useful and it really helps to provide a fresh perspective e.g. Today I'm going to be Andy, the super user of the system. Andy is very sharp with numbers and is the user that is responsible for the administration of the system. He enjoys watching sports on the ...


10

Being QA Manager with about 3 years of experience, I just give my team mates testing tasks, which are NOT related to software, e.g.: Compose test cases for blender / vacuum cleaner / etc. - any kind of familiar device / equipment. This results in brain refreshing, and for the cost of 2-4 hours I get team "reloaded")) The same is applicable for testing such ...


7

I think the simple answer is, do something else for a while. Our jobs require a lot of repetition, and we automatically develop habits in response to repetition. That behavior is a deeply ingrained survival technique; habits allow us to do things quickly without thinking them through. Sometimes those habits allow us to discover new things, but other times ...


7

You could try the 'tours' concept and try out different tours of the software. I'd also disagree somewhat with your premise - the more you use a program the more you notice any slight changes. You also understand more how all the parts interact which in turn gives more ideas. I think at the start you may notice more but they are shallower than ones you find ...


5

Maybe an indirect answer, but one way would be to get actual fresh minds. This is the idea behind usability testing, bug bashes, alphas, private and public betas, etc. Another idea would be to rotate from a staffing perspective to different products/features.


4

A test plan is worth creating if there is something that needs documented testing. It may be frustrating to see a test plan with only a few steps, but if you realize the purpose of the necessity of documentation, it doesn't matter how small the test plan is. You should include whatever it is that needs testing. Whether it's an anticipated UI response to ...


4

Answering your question requires knowing why you were asked to write those tests. Unlike solving applied math problems, we usually do not write automated UI tests for the sheer pleasure or the intellectual challenge. I assume you were asked to write them, in that style, for a reason. If there is a reason to believe the UI is particularly buggy and that it ...


4

I'm going to skip answering the parts of the question that do not make sense or are primarily opinion based. So, which plan should actually contain Risk Management, or it should be completely a separate document? Most software organizations don't do this at all or are not formal about it, so you can probably do whatever you want. If you think it ...


3

I have moved my team completely away from test strategy documents. We are using mindmaps instead as they paint a great picture of what you are trying to test and allow for quick conversations with development and analysts. You can then continue to flesh them out and move to test ideas. Excellent blog about this - http://www.bettertesting.co.uk/content/?p=...


3

One approach is to actively recruit team members and other stakeholders for testing of the product. I have found that it is useful to try different approaches and use whatever works best with each person, which can include: Paired testing with a code developer (emphasize the thrill of having a function work on the first build :) ) Asking a content developer ...


3

For an agile project: Focus on testing as a very iterative on-going, highly integrated process. High number of testers at the start may be more reflective of a more traditional approach. Remember that the goal is higher quality, not number of tests Be careful in having 'initial testers' and later a base of testers that you'd replenish. This sounds like ...


3

You may want to look at TFS 2012. It now has a Kanban board in the tool. There is a preview version of the TFS service in the cloud available if you want to check it out. When I looked into it for TFS 2010, I was only able to find free Kanban tools that did not link to TFS, or paid ones like Urban Turtle that could actually integrate with TFS 2010.


2

Find out what qualities are important and make sure these are tested. For example: How many users and what is their usage ? Answers to this will help work out your approach to performance testing, it might not be needed Will the website take payments ? Store personal details - answers to these will help determine the level of security testing Which ...


2

At such an early stage a good first step may be to arrange with the developer(s) who will be working on the UI and asking for little things to ease the testability of the site with automation tools e.g. Relevant identifiers on the web page elements. Specifically addressing User Experience, Security and performance you may not be particularly well served by ...


2

I agree with Aniket, this kind of exhaustive UI test is not worth it. Another thing to consider: Awhile back, I inherited a manual test case plan from someone who left the company. He had been doing things like checking the list sorting behavior in every area of the app. He wasn't a programmer and didn't understand that the code behind the dropdown box for ...


2

For accessing the points related to quality, you can use the James Bach's Heuristic Testing Strategy Model. It looks at the project in five aspects: Project Environment includes resources, constraints, and other elements in the project that may enable or hobble our testing. Sometimes a tester must challenge constraints, and sometimes accept them. Product ...


2

Unlike other engineering professions, there are few to none industry-wide agreed on standards in software and this includes roles. The document you're reading (who's doc btw?, what makes it seem authoritative?) may be touching on a related theme but it is not really about 'role'. Indeed many modern companies have eliminated roles and titles to get away ...


2

In our previous project we had the same issue. Since we are running agile methods I will try to explain our lessons which we made. What we did: Exploratory testing methods. Means that we do testing while learning things that influenced our testing procuedure. Within this methods we used also the tool Tricentis (or former called QASymphony). With each ...


1

I would rate each of these improvements on 2 dimensions: - The impact to quality if it was implemented - The ease/quickness/cost that the improvement can be implemented If you have any high impact, easy to do items - those are your first priorities. Otherwise, you might want to take the highest from each category. (one easy, one high impact) You probably ...


1

Coming to this from the safety critical side of the industry I would say that your Risk Management Plan should start with a Corporate level Risk Management Policy that states how you are going to manage the risk aspects of all of your work, for example how risks are categorized, what documentation, testing policies, etc., must be in place and what type of ...


1

In my view as a Test Engineer - I have to be more detailed oriented with requirements and clear in understanding of product vision, goal & business values. Psychological - keeping mind fresh is more important task for tester, I suggest you follow this idea: Think a product in 3D view, you view more dimensions. (3D can be any new dimensions) (Short ...


1

You could also change your testing approach. In my experience, 90% of time spent testing is Exploratory. this tends to get dull and repetitive. What I then started doing was changing my point of view or testing strategy. Try something in the lines of BVA. (Boundary Value Analysis). Obviously certain test strategies wont work on all types of software. It ...


1

In an Agile environment think of a test plan less in terms of a formal document and more as a conversation that sometimes will result in documentation, sometimes detailed, sometimes none. The key thing is to go over logic, conditions, exceptions and the like with the developer(s) before they start coding to both determine how to test the change and also ...


1

A good test plan doesn't necessarily enumerate everything that will be in the final release of a product. More importantly, a good test plan defines the scope of the feature and most definitely can account for whatever uncertainty you may have. Also keep in mind that test plans are like software in that they are much easier to extend when they have a solid ...


1

We used to use TFS Workbench before we upgraded to TFS 2012. Its a Windows based application but used to work well.


1

You might take a look at this project on Codeplex for a WIP board that you could use in as a Kanban board. It appears to be process agnostic. It does not appear to have moved out of Beta 2 so I am not sure what the level of stability is or if it is getting any work done on it any longer. It does integrate with TFS 2010 though. Visual WIP http://visualwip....


1

Perhaps no link with TFS, but consider to use Trello: it's free and worth it!


1

Welcome to SQA, Teague. Your test plan is part of a feedback loop. You convey something about the project to whoever is testing. They test the project, find some problems, and fail to find others. You incorporate what you observed into how you write your next test plan. It is all about paying attention and being open to changing what you do according to ...


1

IMHO, no. Here's why: Depending upon your UI, cost of implementing will probably be high. Don't forget to sum the cost of maintaining it when your UI changes in the next release and so on. This itself should warrant second thoughts. UI tests can be flaky. In my experience accuracy of UI test cases is pretty low. I'd imagine this to get worse with brute ...


Only top voted, non community-wiki answers of a minimum length are eligible