Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab

Monday, November 19, 2018

These Software Development Facts You Should Know

Agile Development is subject to all kinds of theories, including my own (which is really a mishmash of what other people have said and what other people have did – I cannot pretend to have walked down the mountain with stone tablets dictating the Commandments of Building Software and I think the Agile Manifesto – the first page at least – is common sense).



Yes, a lot of this stuff is simple but taking the simple and fine-tuning it for a specific environment takes discipline and skill. The traditional project manager blankets a methodology over a project and tucks it in here, loosens it there. They are nervous right now, except in large organizations where silos hold the place up (and those same places will be overtaken in my opinion by leaner, more Agile, more realistic and “human” organizations).

Agile, in my mind, is undergoing a bit of a transformation at least in part to Mark Kennaley’s book: SDLC 3.0 Beyond a Tacit Understanding of Agile.  It turns out that the “Waterfall” approach is an erroneous interpretation of a paper from the 70’s.

At least, I will try to not assume one or the other before going down a mental path. As a side note, mostly for Scott Ambler, I do not think that calling someone a Certified Scrum Master implies superpowers any more than calling them a Scout Master or Master of Ceremonies does. People are not silly enough to accept things without asking questions, although I have had HR approach me saying they want a CSM with 10 years of SharePoint 2007 experience. HR is a different animal.

We want to be in the middle somewhere but above all else, I believe we (as Clients) want to be the place where the information is and the center of collaboration. The Client organization, if possible, wants to be the “Single Point of Truth” for both documentation and process control. That is the knowledge that will be invaluable at some point and it will prevent obfuscation. If a vendor already has something like Bugzilla mastered, you want a login. Do not force change where it will not be helpful, please.

The funny software developers call bugs “features” and I guess after 20 years that is still funny. I prefer separating bugs from issues at least in category buckets myself because then the difference between them becomes more obvious and they are handled differently. If math is being executed and addition is inaccurate, we have a bug/issue but if we are not sure if interfacing with an overseas payment processor is possible without their being PCI audited, that is an issue. An issue I actually encountered not too long ago: a development shop wanted to build a RoR font end on top of Ektron.

This was one of those delicate issues that were tracked offline. As with most things, our objective should be to prevent the disease instead of band-aiding the symptoms. To do that, you also need visibility into the overall project health. You do not need granular detail, but if you know that we have 100 units of stuff to fix last week and this week we have 140, things are not getting better.
This concept of assigning points to features can be applied to bugs as well.

It is all is the estimate and difficulty level. You wind up getting a very visible “velocity” over time where you can see time on the X-axis and total open points of the Y-axis… you want that line to wind up at zero by a date you have in mind or, more realistically, let it tell you when you will hit zero and adjust the feature/bug (product backlog) accordingly. A tell-tale sign that your vendor is not as familiar with bug tracking or issue tracking is, in my opinion, if their unique identifier (ID) changes or if both entities are tracked in the same manner. The idea of velocity and the multiplicity of velocity is staggering. It does not simply apply to Scrum burndown charts.

What is its Business Impact?

From low to high and “showstopper” with numeric values attached to the single decimal point. I maintain that with every bug there is associated Business Value, Difficulty, and User Value. These things are not obvious to the tester but they are to the Product Owner. They combine, via simple math, to give a final value. The “showstopper” assignation is there to really propel the bug’s value into the stratosphere. If low is 1 and high is 3, the showstopper is 100. How severely will this impact the business if it is not resolved by go-live?
business-impacts

What is it’s User Impact? Like Business Impact in the calculation, but answers the question: is this just annoying, or does it require a disturbingly complex UX?

How hard will it be to fix? This is often a tie-breaker between bugs when creating the next iteration of work and is also potentially an indicator of weaknesses in the team.  I like it when these are estimates or are story points.

Status: Unassigned, assigned, UAT, accepted. You can add or remove as you choose but I like this foundation. When in UAT, it is waiting for Client approval. These should be no bugs that depend on other bugs if possible, and if a bug can be broken into separate bugs, they should be. Open is vague and not required. If it is assigned to someone or a group, it is not closed.

It makes sense to run through bug priorities as time allows to be sure that their values have not changed. If functionality has been cut out, those bugs will have less Impact. However, one bug does not lose value simply because 8 other high-value bugs have been found. New functionality should *not* be added until a development team that is constrained by resources can catch up. It is better to have 50 percent of the features complete with 50 percent buggy than 100 percent of the features unusable. Maybe the System cannot be used with 50 percent functionality, but you have value in your pocket there and have paid for something that can be moved to another vendor, another release, or re-purposed or sold. Always try to retain rights to and a copy of your source code in your contracts involving custom development. Otherwise, with a new vendor, you are better off starting over. Earned Value will be nil. This is only one of many reasons why “percent complete” is a false indication of anything. Others include that the task/bug changes has facets revealed that were hidden before, and are as apt to change as anything else.

When a bug is introduced, anyone can introduce it. The default owner should be the Project Manager / Coordinator / Technical Liaison, or whatever the role is called. The Product Owner may also do this but are better off using their time in other ways. This is where the traditional Project Manager can breathe a little sigh of relief amongst all the talk that Agile and Scrum are making the PM role irrelevant.

The Project Manager, in a technical setting, should have knowledge of technical systems. They can and should work with the Product Manager to tune value and assign bugs or issues after they are introduced into the System. However, the project manager does not assign to a person. People come and go. They get hit by the proverbial bus. Bugs and tasks are assigned to groups, such as “Development” and then divvied up within that group (hopefully using the same tool) so people are mapped to bugs and there is a face at the standup who will be speaking about it.

Also, much as we get a sense of project velocity, we can get personal velocity. I say that and bite my lip because there is always the “X factor” leaning on everything we do and using pure metrics to ascertain the value of a person is bad, bad, bad, and horrible. This, again, is where the classic project manager could be knowledgeable. You may notice that I am mixing and matching Scrum terms, Agile terms, and more common terms to describe roles.

That is not without reason. There is a basic methodology-independent rationale here: keep track of things, limit dependencies, keep visibility and communication high, and stay flexible. Look at what work there is to do and compare it to your deadline instead of trying to shove 10 pounds of tasks into a 5-pound box.

How is a bug tracking system working

  1. Reported By
  2. Date Reported
  3. Owner (defaulting to the PM/Technical Liaison)
  4. Summary/Description
  5. Acceptance Criteria
  6. Supporting Documentation (documents with screenshots, etc)
  7. Site/s
  8. Business Value (1-10 or 100 with one decimal place)
  9. User Value (1-10 or 100 with one decimal place)
  10. Technical Difficulty (high value means it is more difficult and risky… a risk mitigation worksheet is already available and complimentary).
  11. Status
  12. Date of Status Change (so if something lies around for a week, for instance, it is obvious).

Wednesday, November 14, 2018

2 Easy Ways to Show Percent Complete in Agile Method



1. Plain old Metrics


The above is pretty easy to understand, but the percent complete field comes from the total number of story points in a given feature (the pure sum of the points belonging to stories within a feature) and the number of points for features that have had all stories complete.

There is your number, viola. Is it accurate? As long as nothing is added to the feature, sure I guess it is as accurate as anything can be given context. The better question might be “is it wrong or misleading” and the answer would be “depends, but you are not lying or misrepresenting what you are being asked for.” If I ask you to poke me in the eye, you might do a really good job at it and blind me, but does that mean you completed a valid task? Depends on who you ask, their mental state, their goal, and a number of things but overall – yeah, you did. Thanks a lot.

2. Colors…


People like colors. With this method you get not only more detail but what might be a more accurate (or complete) view of what is complete. Your “not started” line will look smaller, but that is not a function of misrepresentation, only of the technique. “In Progress” might mean it just started or that it is almost done, but it is just a tool.

Something besides Excel would be better than this, as the legend states (may a .mpp format although your PMPs might freak) because your Story Points could be numbered left to right with a degree of accuracy that I cannot provide at the moment. Again, the goal is the same. You get the block which represents features but the WIP (Work In Progress) exists as something real and tangible. For the overall Epic, you could, in theory, have a giant list of these that together spelled out the whole shebang and I do expect this may only serve to elicit “so, how close are we?” at which point you can either stare like a gopher who just popped his head out of his hole or be almost as cool as a quick draw cowboy and whip out the first diagram.

Friday, November 9, 2018

,

Why PRODUCT ROADMAP is so IMPORTANT in AGILE DEVELOPMENT?

What is product roadmap in agile development?

In order to achieve a goal, you should always work with a plan. A product roadmap is an outstanding action plan which construes how the product is expected to evolve over time. It allows you to express where you want to take your product, and why it is worthwhile investing in it. Moreover, an agile product roadmap expedites the learning curve and adopts reforms. A goal-oriented roadmap focuses on project objectives, business goals, and outcomes like customer acquisitions, augmenting engagement. In simple terms, a product roadmap initiates the emergence and development of a product or solution to a project.



 Technology is rapidly changing which means new and unexpected markets will open up. With upcoming markets, business will boom or suddenly drop, and all of these changes will affect what you are able to build both in the short- and long-term. In addition, you cannot exactly know what you are going to build ahead of time, however, you can plan for how to respond those changes in order to keep on track with your innovative vision. Product roadmap encourages the project team to work together to achieve long-term goals for successful project delivery in agile development. For this reason, a few agile teams tend to share a unanimous product roadmap. A roadmap is not a plan that you develop once and adheres forever. The plan remains agile which means brainstorming, prioritizing ideas, discussing and adjusting your process roadmap is needed when the environment changes.

Reasons why product roadmap is needed in agile development?

Make adjustments during long-term plans



For example, like airplane instruments, a good roadmap will tell you if you have reached cruise altitude or if the product’s engagement needs to boost. In order to do so, you should compare your current metrics with the ones you have previously defined with your team when building the roadmap. Base on what you have found, your team can refine the features, sprint’s goals, make decisions based on data or, at least, realize sometime in advance that some desired outcome is not going to be achieved, enabling you to activate your plan B. Otherwise your team is just working sprint after sprint with no acknowledgment about the impact of its work on the business.

Roadmap connects pieces into a big picture



It is much more motivating to know what your team is going to deliver as a whole. This is where the real meaning of work takes place, instead of just delivering tasks that were assigned to you through your team’s board. Moreover, the roadmap should be accessible and visible on a daily basis, so everyone can take a look at it every day and feel the importance of their hard work.

Clarifies priorities and improve setting


Another important skill that a product team should know is the ability to reject. Because users are going to make requests, stakeholders are going to have opinions and even the CEO of the company may issue some special feature requests. However, if you are going to satisfy all of them, you will not do any good for anyone. In order to refuse requests that are not related, you should have a clear vision about what you are doing.

Product roadmap motivates the team



There are a lot of technical issues and things that go wrong when delivering a feature. As a consequence, the motivation to work and overcome will decrease. To avoid these problems you should have a clear vision of what is going on and the importance of it.

The clear vision for stakeholders


The product roadmap will help you to avoid as many meetings as possible. Nowadays, we are working in an agile environment and we do not have to report the status of the task to stakeholders. However, your product is a part of a bigger company strategy. Thus, goals and progress towards it must be accessible for everyone in a company. Moreover, if things will not go as expected, you can adjust it. Finally, it creates a sense of collaboration with everyone involved.

Monday, November 5, 2018

,

Difference between Quality Assurance and Software Testing



What is Quality Assurance (QA)? What is Testing? 


These are common questions for those who first go into the software development industry. It is particularly important for software managers to know the differences between these two terms as they could help in risk management during the software development process. Below is the definition of each term:

  • Quality Assurance includes activities to ensure the quality in the software development or maintenance process in order to ensure the software will fulfill its ultimate objectives.
  • Testing includes activities of executing a system in order to find bugs/errors/defects in the software.


A clear diagram illustrating the difference between quality assurance and testing | Source:





Basically, there are 6 stages in the software development process: Planning → Analysis → Design → Development & Implementation → Testing → Maintenance. The software testing stage is considered the most important one in the process. QA Leader and Test Leader are the key members of the team, who have the clearest understanding of process and methodology. QA Leader is considered the captain of the ship. Meanwhile, Test Leader is QA Leader’s right hand who has a clear understanding of not only the software development process but the customer’s requirements as well.

It’s is absolutely crucial for the QA Leader to have a deep understanding of the testing process, data management, trouble reporting, and resolution and ensure the software will be given to the customers with high quality, on schedule and satisfying their expectations. He/She will be responsible for:
  • Defining quality metrics.
  • Defining testing strategies.
  • Deciding the test budget and planning the entire testing process.
  • Identifying the testing activities for other team members like testers or test engineers.
  • Checking the availability of the resources to execute testing activities.
  • Managing Risks.
  • Reporting to the project manager.
The Test Leader is responsible for organizing and examining the testing process to ensure the high quality for the software. Those are their tasks:
  • Defining the scope of testing
  • Staying updated about the latest test approaches and tools.
  • Validating the quality of the testing requirements such as testability, test design, and script, test automation, etc.
  • Implementing the test process.
  • Writing summary reports on test status.

Conclusion

A number of people are still confused about the difference between quality assurance and testing. In fact, they are closely related but have some considerable differences that I have mentioned in this blog. However, they are both absolutely necessary in the software development as they ensure the final high-quality product will be delivered to the customers.

Thursday, November 1, 2018

,

Why Software Testing plays important role in software development?

We all make mistakes, some of those mistakes are unimportant, but some of them are expensive or dangerous. We need to check everything and anything we create as things can always go wrong – humans make mistakes all the time. That’s why, software testing is an indispensable part in any project.

What is Software Testing?

What is software testing?


Software testing is the process of executing a program or application for the purpose of finding software defects. In other words, it is the process of validating and verifying that a software program, application or product is functioning properly, or meets the customer’s business, technical, design and development requirements or not.

Read more:



Why software testing is important in software development?


Since we assume that our work can be wrong, so all we need to do is test our work. However, some mistakes come from bad assumptions and blind spots, so we can make the same mistakes when we examine our work, as we do and have done. it. So, we can not see the mistakes in the process.

Ideally, we will pick up someone else to test our own work. Because they are likely to be more likely to spot our mistakes.

There are a number of obvious reasons for us as to why software testing is important and the main things that we should consider when examining any product or application.

So, why is software testing important? Some of the reason are listed below:


  • Software testing is really necessary as it points out the defects and errors that have been made in the development phase.
  • It is important because it ensures the reliability of the customers and their satisfaction in the application.
  • It is very important as it ensures the quality of the product. Quality products delivered to customers help in gaining their confidence. (Know more about software quality)
  • Testing is necessary as it provides facilities to customers such as delivering high quality products or software applications that require lower maintenance costs and thus results into more accurate results, appropriate and reliable.\
  • Testing is required for an effective operation of the software application or product.
  • It is important to make sure that the application does not have any failed results, because it can be very expensive in the future or in the later stages of development.
  • That is the essential requirement to help the product survive in business.


What are the main goals and objectives of software testing?

  • Software testing has different goals and objectives. But its main goal is:
  • Find defects that can be created by programmers when developing software.
  • Gain confidence and provide information on quality level.
  • To prevent defects.
  • To ensure that the final results meet the business requirements and users.
  • To gain the credibility of the customer by offering them a quality product.

Software testing will help to complete the software or product applications versus business requirements and users. It is very important to be able to guarantee to test the software application completely and make it sure that it works well and according to the specifications

Wednesday, October 24, 2018

,

TOP 5 Manual testing interview questions with answers you SHOULD KNOW

Manual testing interview questions are the questions that you may encounter when applying for a developer job. In this post, we will cover some popular manual testing interview questions as well as the best answer to these questions.

tester interview, tester career, top manual tester question
Top 5 manual testing interview questions and answer


1, During testing, you find a bug and assigned it to developer. But developer rejects the bug saying that it is not a defect. How you will handle this situation? (one of the most challenging manual testing interview questions)

First of all bugs should be logged with proper reproducible steps, screenshots etc…
If developer rejects the bug, we should first look out for the reason or justification on why the bug was rejected. If the justification is valid I would agree for the rejection. On the contrary, I will go back and try to reproduce the bug with the steps I had provided earlier. If it is still reproducible, I shall reopen the bug with valid comments and will provide additional information (if I found any). Then I would go back to the developer asking for justification on the rejection. At this point I shall include BA and technical lead also is to take confirmation on the defects

2, What is your approach in case there is not enough time for test execution?

In that case, my first focus will be on the priority of the requirements and the functionality would be the first tested, followed by the areas where the probability of finding defects is high. I would also analyze by test cases and execute the high priority test cases first followed by medium and low if time permits. If I know the application well and have previous experience about it, then exploratory testing is a good approach when there is limited time left. All these should be approved by the Test Manager and documented in the test strategy. 

3, What is exit criteria of testing? / When to stop testing? (This manual testing interview question is the easiest question to answer out of the 5 covered in this post)

It is almost impossible to make sure that an application is completely defect-free. At some point the testing should be stopped and we have to give a sign off so that the application can be released. The exit criteria of testing will be mentioned in the Test Plan before testing itself. We consider a lot of criteria to decide when to stop the testing. All the defects have been addressed and closed, all the test cases have been executed, traceability metrics is done (which means test cases have been executed for each of the requirements). Some factors should be considered for stopping the testing.

4, Have you written any test plan? What are the contents of test plan?

(Yes I have been involved in writing test plan). Test plan will contain the scope and all the activities of testing. The main contents of test plan is the scope, approach, resources and testing schedule. In testing scope we will say the testable and non-testable functionalities. In testing approach we would mainly mention the testing environments, different kinds of testing, testing cycles, the test cases which will be executed, testing data and scripts.…It will also say the test entry and exit criteria. Which means when testing will be started and stopped. The roles and responsibilities of each resources would be mentioned and testing schedule and timelines are also mentioned in the test plan. In addition any risk/assumptions and dependencies are also mentioned in the test plan. 

5, Have you done any reviews for QA deliverables?

(Yes, I have reviewed QA deliverables mainly test plan and test cases). QA checklist is maintained for each of the deliverables and the reviews will happen against the checklist. First of all, I do a self-review for all the deliverables that I prepare. Then I would give it to my team member for peer review and vice versa. Before the review, walkthrough of the document is done for better readability. All the test cases and test data is inserted, risk and dependencies are described etc… During reviewing test cases I will first check the requirement traceability, which means for each requirements if the test cases are available. Next my focus will be on test coverage. I will check of all the scenarios have been covered etc…

Above are some of the most popular manual testing interview questions and some of the best ways to answer.  

Thursday, September 27, 2018

What is ISTQB and its benefits?

The demand for testing in the quality assurance industry is on the rise nowadays. According to the World Quality Report 2015-16, the budget for quality assurance is going to reach 40% of the IT budget in 2018, so you can understand why many people are finding their way into this promising field. One of the ways is to obtain a manual testing certificate.

These certificates provide proof that someone has somewhat knowledge and skills in software testing. Right now, one of the most popular testing certification in the world is ISTQB.

ISTQB stand for International Software Testing Qualifications Board - a non-profit organization issue thousands of internationally recognized certifications over more than 70 countries. That why, In this article I will focus only on it.

OSTQB. testing, tester,
ISTQB and ITS BENEFITS


Type Of ISTQB

Foundation level certification

The only criteria are to have 6 months experience in the testing position. This level demonstrates the understanding of the basic concepts of software testing. Anyone can take it, even if you have nothing to do with the IT industry.

The syllabus covers six main topics:

  • fundamentals of testing
  • testing in the software lifecycle
  • static techniques like reviews
  • behavioral (black-box)
  • structural (white-box)
  • test design; test management and testing tools.


Advanced level certification

This level is designed for at least 5 years practical experience in the testing role. The syllabus is divided into three main areas:

  • advanced behavioral or black box testing and testing standards for business-oriented testers
  • test automation and advanced structural or white box testing for technically-oriented testers and programmers
  • sophisticated test management concepts for managers.

Expert level certification

Design for those who have at least 8 years experience as a tester.

Now you have understood its structure, I want to go deeper into why you should get an ISTQB certification. Below is some reason:

As I have mentioned above, testing certification helps the new start in the Software QA world. Most employers will consider a good certificate as an important criterion in the resume. To obtain one is a plus point in your resume and make you stand out compared to other competitors. When you prepare for the test, you don’t have to take any expensive course. You can self-study, hire a trainer or use ASTQB-accredited education, whatever works best for your finance.

The advantages of ISTQB certfication


It also helps tremendously with professionals who have years of experience. ISTQB Certification helps you gain knowledge about the standard testing definitions and updated technology, so you can have more opportunities to enter a new market. But the most fundamental benefit is to help skilled tester reduce defects.

For software development companies, these certificate help reduce cost and offer greater efficiency and speed, and higher software quality since it’ll be able to reach to knowledgeable and skilled employees. Your companies can also qualify lower tech insurance costs if you hiring ISTQB certified employees.

However, I hope you understand a manual testing certification like ISTQB can’t be enough if you are looking for growth in this technology world. It can be a great extra to your profile but if you want to get somewhere, you must keep learning new things and keep up with all new innovation.

Wednesday, September 12, 2018

, ,

How to Become a Software Tester?

Software testing plays a critical role in the quality and usability of the final product. Testing at times is a demanding position on the rise. If you are one of those who wants to have a foot in, then you have come to the right place. This post will give you an insight on how to become a software tester.

What is a software tester?

They are the quality assurance experts who root out bugs and save end user from poor performance and highly buggy software or application. They are a part of what builds a good company image for decreasing support calls from frustrated customers.

software tester, testing software,
How to become a software tester

How can you become a software tester?

1. Education Background and Training

Many employers look for candidates with a bachelor’s degree in computer science, software engineering or related to math field, although that’s not always the case. There are still people getting into this job without a college degree. If you do not hold any of these degrees, then you can complete a software testing certification like:

  • International Software Testing Qualifications Board (ISTQB) - This is one of the most the popular software certificate in the world - an excellent investment that makes your resume stand out.
  • Rapid Software Testing (RST) - a methodology focus on testing software.


It is not mandatory, but most of the companies have this criterion. Having this will give off an excellent impression and ensure a better chance to land the job. A newbie can also find internship programs to give you a good experience. Maybe you will have to work for free but try your best in this position because a letter of recommendation and influence reference is going to help you wonder.

You need to have a solid background in this field in other to excel in this. Most people work in the tech industry must have self-learning skill, a strong passion and a mind of curiosity. There are many open resources for tester out there for you to explore. Try reading good books, blogs or articles about software testing,  working on various tools, keeping up with the latest trends.

2. Find a job.

According to the World Quality Report 2015-16, the budget for quality assurance expert in tech companies is going to reach 40% in 2018. This has indicated that software testers have become promising jobs at the time. If you want to become a software tester, then you should prepare as soon as possible, not just about knowledge but also about your non-technical skills like critical thinking, analytics, communication, etc.  

You should start spending time browsing jobs sites like Linkedin, Indeed, and Dice. Make sure to have a well-written, scannable resume, and you’ll better consider composing a cover letter before sending out applications. Practice mock interviews. Take the feedback and fix the issues after mock interviews.

Here a small tip: if you are finding the job when having little experience than your attitude is what difference you from other candidates. Don't worry too much since you are a newbie in this field employers won't expect you to know complex ideas.

Testing can be an exciting area since it doesn’t focus on just one particular technology. But, in the end, what matters the most is the pure passion that will lead you to success if you truly want to become a software tester.