Tag Info

New answers tagged

2

This sounds like a reasonably standard data input problem. Here's how I'd look at it (this method is pretty heavy on up-front work, but has the advantage of making life easier in the long run): First, I'd gather as many input files I can get hold of. These will have the input types you need in the correct format. Next, I'd go through them and split out ...


1

I have over 15 years experience in QA and automation, and am in my first role as a lead, where I have been for less than a year. I have tried to emulate some of the good qualities that I have observed in leads that I really looked up to and respected. I'm not going to repeat other answers, so I'll list a few things in addition to the other answers already ...


1

Lot's of good suggestions. Summarizing few more one liners for Senior QA / Lead's Self Organized Challenges the Environment, Raise testing standards by experimenting new processes/Adopting new Tools Aware of Test Automation Framework Design and Development (Learn if you are not aware of Automation practice) Sound Technical Skills, Selfless, ...


7

First off, everything I say here should be checked against your job description - that's going to tell you what your employer expects of you. As a lead, you probably don't have hire/fire responsibility (that usually goes with the manager title), so your employer's expectations will probably fall into these areas: resource management - making sure that ...


0

There are a lot of great answers here - especially specific examples, so I'd like to add a note about becoming a more "out of the box" tester in general. If you are a tester, hopefully you already have that innate curiosity, a need to know why, and to push things. Even if you don't spend that much time on exploratory testing, I think it's important to ...


0

Please refer below link i think it will useful for you http://msdn.microsoft.com/en-us/library/dn282443.aspx


0

Think of the daft/cleaver things that users do then over do them, think of what happens in the real world, with real people: Power cuts, signal loss, phone calls, door bells, meetings can all interrupt the filling in of a form - what happens if you half fill the form in before leaving for the night then try to finish in the morning? My favourite for web ...


1

This isn't possible without some serious messing around with the TFS API right now. Part of the problem is that internally test cases are stored as work items where test plans and test results are stored in completely different parts of the system with complex relationship structures. As a result, the built in query engine can't access them. ...


0

Ensure that the date field accept dates in the specified format ie dd/mm/yy or mm/dd/yy or yyyy. Ensure that the date field does not accept characters. Ensure that the day field accepts values between 1 and 30/31 according to the month. Ensure that the day field does not accept any values less than 1 or greater than 31. For example; day field should not ...


1

The key question here is the allocation of time and effort. For anything other than a very tiny, trivial embedded controller, the things you COULD test go quickly into the billions and trillions if you start trying to enumerate them. Randomly thinking up cool and clever obscure things to test might be emotionally satisfying, but you may not be helping anyone ...


0

If you're simply looking for examples and formalisations to choose from, I'll add mine... else Kate is kinda right and this needs a bit more direction question wise ;) I like Kate's principles in her answer, I cover mostly the same stuff but in a specific format I find very comfortable for 'me', and applies a little more multi-purposing to the output. I ...


1

Other "must test" areas Regulatory requirements - Industry/Government/etc musts. Safety requirements - personal/mechanical/etc safety requirements Data protection


1

Personally, I find the style of writing a test case is irrelevant as long as the essential information for it is there: Who will be performing the test - the level of detail I use will be different for a test that's being performed by an experienced tester than for one that I expect a novice tester to perform. I'll give more guidelines to a novice and use ...


0

Probability * impact = risk That's the way to go in theory. Practically it's not so easy to correctly, accurately, and consistently across tests to quantify impact and probability. Each of the stakeholders might have a different view of the probability or impact, and the data itself might not be obvious especially when you are dealing with a never ...


0

Here is a simple answer: the most important area to test will be where the bugs are. That sounds flippant, but it is true. Now compare that to your statement in the description about testing the most commonly-used areas of the application. Instead, what you should be testing are the boundaries and gaps in the application. You should be taking functions ...


2

This is a great question. I am in nearly the same point in my career, about 15 months total in QA and honestly my career is taking off like a rocket in my mind. The steps I follow are rather simple. Learn something new constantly This can be difficult depending on the situation you are in with your company and your experiences. I was an API tester with ...


1

I'm struggling to understand your question, although I'd start by advising you to ask your line manager about the possibility of taking the ISTQB ISEB Foundation Software Testing course and exam. Depending on the type of testing you have been exposed to, ask if you can work on some other projects that would involve different testing techniques from what you ...


1

(Of course) it is subjective, here are two key parameters that I employ.... So, how important (business wise) is this feature/area to the end user, w.r.t. the current deliverable (release,patch update,sprint etc) ? What "matters" to the end user ? Which existing features they use most/more ? Which new features are they most likely to use more/most? So, ...


7

You want to save your team time and pain, and you do that by focusing on potential issues that are going to be much less costly if we catch them sooner rather than later. I usually start by asking myself "what feature(s), if broken will…” block me from the majority testing, be particularly difficult/time-consuming for the developer, or require fixes that ...


2

There's a guy called Michael Hunter who goes by the name 'The Braidy Tester', among others. He worked (or maybe still works) at Microsoft as a tester. He's written a great guide to testing the unhappy path - it's called You Are Not Done Yet (pdf), and while its main focus is desktop apps, it's also more widely applicable. I excerpt just some of the section ...


12

Some suggestions in addition to the good ones already listed: Look for things the software shouldn't do. Make it do them. It's web-based, so what happens if it loses the network/internet partway through a multiple-screen operation? Look for words in the specifications/user stories like "should", "always", "never", and so forth. These indicate conditions ...


1

To teach someone to think outside of the box is well, impossible. The thing you have to start doing is think about things like the following: What would happen if I put this into the hands of a 2 year old What would happen if someone used the software with malicious intents What would happen if someone who knows absolutely nothing about the software used ...


2

One thing you can do is to start "breaking things", and test the application's ability to handle failure modes. For example, you can edit or delete cookies during a session. To guide your failure mode testing, you could build a "Failure Mode Effect Analysis", which is essentially a spreadsheet that lists the various things that could fail - the probably ...


4

Welcome to SQA, Eddy. I have no experience in testing your software, so I have no real-world scenarios that may suit your application. And scenarios I know are typical for software that I tested, so they might be useless for you anyway. However, I have a number of general tricks or techniques that opened my mind: Learn from existing bug reports. If your ...


3

There are many ways to answer your question. :) When I start testing something, I always initially approach it from a "black-box" perspective. From a black box perspective testers should not know or imply anything about the internal implementation of the software. However, if I do know something about the implementation, then I may approach the problem ...


3

As others have said, it depends. Testers do not need to understand code to be good testers. Testers who do understand code can use this knowledge to their advantage, but this does not automatically make them better testers than testers who don't understand code. Your example of testing the same module in different locations misses the context: the base ...


1

It depends what do you expect from tester and what kind of tasks. You should understand that test engineer which care about users and understand code, could find narrow places in code costs much more :) I believe it's desirable that manual test engineer can read code but not necessary. But if you mean automation test engineer or common QA engineer (manual ...


2

Should testers understand the code? It depends. How much should testers rely on implementation details? It depends. Why it depends? There are both pros and cons of understanding the code and architecture. When we interviewed candidates for a tester, we asked them to draw an architecture of a system they tested. We did so because: We believed ...


7

Short answers: 1. Yes they should understand the structure, 2. It depends. Long answer: If you ask a software tester why they are testing a specific function or decided to use a specific test technique/approach, they will probably give you the Willy Sutton answer: "Because that is where the defects are." Of course that is going to be different for each ...



Top 50 recent answers are included