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

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

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.


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 ...


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

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 ...


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 ...


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

1 What are the most common set of environments and [2] best practices for each environment? (1) System Test, UAT, Performance Test, Staging are all classical environments (2) Best Practices is a harder one :-) .. Here is a cool Test Environment Maturity Model TEMMI .. Other than that my advice is this ... "Understand your environments .. Without knowledge ...


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