Hot answers tagged

22

Although unit tests are normally good enough, it's nice to see a developer ensure that they've run a process from start to finish, not just the unit tests. Because the types of tests that should be run vary greatly with the type of application, I would discuss with a testing point of contact for the product. With new developers to me, I usually ask them ...


22

Good and Interesting question. Here are some to make the tester's job easier: Developers should perform basic testing before giving the product to the tester. Include QA from the beginning of the project, not when the product is ready to test. Work as a Team, not as two different departments [Developer & QA] As the developer, never ask the QA to ...


19

What has worked well for me is the following steps. The developer makes their best effort at writing good code. The developer gets a code-peer review from another developer The developer runs their unit tests, and checks that they all pass. The developer and the tester sit down for a review: The developer walks through with the tester to let them know ...


13

Ideally, the DoD for each user story should mean all tests for that user story are passing, and all automation is completed, running as part of the overall automation (as opposed to on one person's machine), and running with no errors. Real world usually means compromises, since there's rarely enough time or resource to cover all the potential implications ...


13

Treat them as equals. I have seen a lot of developers thinking they are more or better then testers in their companies and also treat them that way. Developers and testers have a similar goal: Making high quality software.


12

One of the most common problems that I've faced is the role of the tester. Often times, teams/companies start to believe that an agile approach using TDD eliminates the need for testing. My first experience with it was when of my former teams was told that they were going to become an agile team. Agile Testing by Lisa Crispin and Janet Gregory helped me ...


11

I would have a staging enviroment thats an exact clone of live. Then when you have to rollback a bug you can also track it down and fix it on the staging enviroment. Once you have a comprehensive list of bugs and their causes you can work on finding trends and stopping them happening again.


11

Just a few quick ones off the top of my head: Run the code they've completed at least once on their machine before marking it as 'Done'. Consult with QA on their intended route to implement a feature or bug fix to help flush out potential issues or bugs before even one line of code is written Encourage QA to participate in sprint planning/grooming, design ...


11

I've worked in both roles for a while and my recommendation is: Pair (before coding when possible) on test plans See QA as an asset that is protecting you and customers from the mistakes we all make Have an open mind when a QA approaches and avoid the (common) mistake of explaining away an issue as their lack of understanding Don't assume that they can ...


10

Errors occur when some user enters data that is different than the test data. Fuzz testing in addition to boundary testing could help. Really any kind of randomly generated or randomly mutated data (by your business rules) can help find these kinds of errors. Dedicated testers who try to break the system and who do not just test that it is working ...


9

Agile Testing This is the (IMO) canonical book I refer people to in this situation. It's a fun book to read, and gives you plenty of ideas and context to start with as you transition.


9

If you can, try & promote the idea of test first development (aka TDD, BDD, ATDD, Specification By Example) with Continuous Integration (frequent commits to a pipeline such as Hudson or GO from Thoughtworks which continuously runs the automated checks to see if any of them have broken after a recent commit) Before Developers write the code, they write ...


9

I know this problem way too well. There's no "right" answer, unfortunately, but there are some things you can do to help with this problem. Dependency map - do you have a list of application features that have heavy dependencies and tend to break when changes occur in other areas? If you know changes in feature X tend to break feature Y, you know you ...


8

Maybe you will find a predefined checklist somewhere. But How will you be sure that it is appropriate or correct? What if its not really for you? Will you just take the word of somebody without understanding your needs?


8

Testing is not a standalone activity because: resolving bugs means talking with product and development to make sure that the bugs are well understood and that the path to correct them makes sense for all. understanding business requirements and what an application is trying to achieve means working with business users and product owners understanding ...


6

There is no hard and fast rule for what kind of testing a developer should do before handing off to QA. It depends on the developer, the QA team, the organization, and the product. Testing is a means to an end, not an end in itself. The important thing is to pay attention to the quality of what QA receives and the quality of the released product. If the ...


6

The elephant in the room: maintenance. How do we maintain this new feature: what things need to be configurable? can we easily roll this out (what's the roll out?)? what support tools do we need to resolve issues with this in production quickly? I worry that one day all of humanity will be maintining code of our forefathers... think of the children!


6

System requirements are the translations of user requirements in a much more technical language. They are basically the things that a software must perform. Not exactly. The system usually consists of hardware and software. In some situations, it could even include humans performing well defined processes (for instance, changing depleted batteries). The ...


6

If you want to go fast, you need to assume that once something is tested and working in a cycle, it will continue to work in that cycle. If you cannot make that assumption, you either need to spend more time testing (by yourself or with the help of others) or your developers need to deliver higher-quality code. No one but you and your developers can decide ...


6

The short version: regardless of the development methodology, your role is to provide information about the overall quality of the application. You do that via testing anything that isn't included in the developer-maintained automation, and reviewing the developer-maintained automation. The long version: This question and its answers is a good starting ...


6

To start off, have a positive attitude towards tester's activities & identified issues Provide unit + dev-smoke tested builds to QA Share release notes with info like included fixes, features and known bugs etc Provide support in technical & back-end understanding of system Provide support in analyzing hard-to-reproduce issues Be appreciative ...


6

This is a simple point, but very effective: Be a developer who says "thanks" or "good catch!" or something positive whenever a tester finds a defect. It's the daily currency of the respectful working relationship. All the formal processes are good, but they flow from the basic attitude of respect.


6

By the success of the company. Buy-in for QA will need to come from the top rather then the justification being looked for in data. You will, over time, be able to point to things like some major bugs prevented from reaching customers performance issues anticipated and planned for unusual bugs discovered for certain conditions more new customers more ...


5

I'd recommend seriously looking at building a framework that has the absolute minimum of repeated script code - this has the advantage of minimising update work. Similarly, I'd consider data-driven scripts with an object-oriented framwork where you're building your transaction objects to harness the application's features. That way, as the application ...


5

This is the exact problem that bedevils the environment where I work, and have yet to find a strategy that works well and consistently. Some of the strategies and techniques that help are: The testing specialist works with the coding specialists on the unit tests. Even if the testing specialist isn't a coder, knowing the coverage of the unit tests and ...


5

It is hard to say what your workflow will be. I've worked a few SDET/QA jobs, and it really seems to vary quite a bit. I'll try to cover some of my experiences, though, and hopefully that will be helpful. Everyday Things I usually like to start my day with a little bit of blackbox, just to get my brain into motion. I'll spend a little while every morning ...


5

According to me, you should not go for a ready made checklist. More appropriate way is to develop your own checklist. Understand you requirements, analyse them and then sort it in a form of a checklist. Then you can get feedback or opinions of others and see if it is adequate or if it need any improvement...


5

All the answers so far are good. A few other comments: Remember that the testers aren't there to make your life miserable. They're there to provide business stakeholders with information about how well the software fits what its intended users need from it. Don't just throw code over the wall and figure the testers will catch any bugs. They might, but ...


4

There are several useful heuristics for stopping testing. A few I can think of 'No more time' - i.e. we stop due to a business imposed deadline. Have you come to understand what you set out to understand about the feature (you do set specific goals for test sessions right?) Mission critical bug unearthed at which point documenting and fixing the bug ...



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