coreDevX https://www.coredevx.com/site Centro Privado de Investigación e Innovación para el Desarrollo de Software e Interfaces Digitales (SpA) Fri, 12 May 2017 21:09:52 +0000 es-ES hourly 1 https://wordpress.org/?v=4.7.5 7 Key Characteristics of Testing Bank Applications https://www.coredevx.com/site/7-key-characteristics-of-testing-bank-applications/ https://www.coredevx.com/site/7-key-characteristics-of-testing-bank-applications/#respond Fri, 30 Sep 2016 16:20:30 +0000 https://www.coredevx.com/site/?p=8165 Para acceder a post original click aquí

 

 

Bank applications are quickly turning out to be not just handy, but necessary, as customers grow better educated about their financial options. Inhibitions are fading as more end-users familiarize themselves with the digital functionality of bank applications, whether in the form of Net Banking, or through Mobile Application Banking. While bank applications are constantly impacting customer lifestyle, if not done with precision, they could lead to a laundry list of issues, the most severe of which remains a security threat. Rigorous testing of the app in multiple stages remains vital, for quality assurance through timely bug-fixing. In order to ensure that the application is efficient and helps users navigate it conveniently, the following characteristics need to be kept in mind while testing these bank applications.

 

  1. Security Testing

The importance of security testing for apps today cannot be ignored. Having sensitive financial details displayed out in the open for everyone to see, or operating of a bank account in a mode that is attack-prone is anybody’s worst nightmare. Apart from reputation loss and loss of customer base, the bank can also face severe monetary losses in the event of a security breach. Compliance of the application with regulatory authorities also needs to be incorporated in the application testing process, as part of the legal procedure. This ensures that an unrecognized or unauthorized third-party application is not able to hack into the application for data theft.

 

  1. Domain Expertise

Finance has stood the test of time, and after every downfall, has emerged as an ever more behemoth of an industry. As finance has rapidly taken to digital technology, practices and processes have become further streamlined and innovative. To be able to work in this domain, whether as an application developer or tester, demands a certain level of domain expertise. In order to thoroughly test user requirements, one needs to be adept at understanding financial terminology by incorporating test cases that are in line with bank procedures. A comprehensive bank application ideally should contain all the features desired by an active account holder, from basic Account Summary viewing to the monitoring of Stock Trading.

 

  1. Functional Testing

Testing the functionality of the application by thoroughly understanding its internal workings is essential in most applications, with an added emphasis for bank applications. This is a core part of the testing process, where test cases are prepared, reviewed, and executed. The test cases are typically prepared from business scenarios, which result in further positive or negative test case scenarios. These test cases are then reviewed by Quality Assurance Engineers and are then executed, either manually or through automated testing, using automation tools. System integration testing, regression testing, and user acceptance testing, all together enable a comprehensive functional testing of the bank application.

 

  1. Large-scale Integration

Usually, a bank application is integrated with other third-party payment applications. Movie bookings, restaurant orders, and online shopping, are the e-commerce applications that stand out the most. It is essential that the behaviour of the application while it is summoned by other payment gateways remains consistent and secure. Testing the software to ensure that the internal application is intact is necessary.

 

  1. Mobile Device Diversity

Although seemingly basic, this remains a key aspect to testing. The most important point to note here is not just that there are multiple devices and their respective versions, but also that each application update would have to be incorporated slightly differently according to the device in use. Application functionality within mobile devices, and the corresponding operating systems (OS), need to be tested meticulously and repeatedly. Add to that the limitations of certain OS, delivering the updated application to the end-user seems like a fairly far-fetched dream. A comprehensive mobile testing lab is essential in order to immediately cater to application updates.

 

  1. Performance Engineering

The convenience of using bank applications is encouraging more users to shift to regular usage of a mobile banking platform. This results in heavy load on the application, as many users are simultaneously downloading, installing, updating and using the application. Performance matters greatly, because these applications involve real-time financial tasks to be performed and if the app crashes, it could lead to duplicate charges.

 

  1. Need for Collaborative Effort

This is perhaps the characteristic that easily matters the most and comes relatively early in the software lifecycle of the product. Developers, quality assurance engineers, operations specialist, and subject matter experts, need to all come together and work collaboratively in order to gain the complete understanding of the banking application and resolve issues early in the software life-cycle. Business requirements need to be carefully documented and worked upon, after the careful perusal of stakeholders.

In Conclusion

The testing carried out for bank applications needs to be comprehensive and requires quality assurance engineers with domain expertise. Here at Cigniti Technologies, our domain capabilities in the Banking sector span across multiple functionalities:

  • Recent trends such as eWallets and Self Service Technologies
  • Various delivery channels like Internet, Mobile, Mobile App, etc.
  • Payments / Remittances including Cross Border and multi-currency transactions
  • Fund Transfers through various modes such as NEFT, RTGS, IMPS and Bill Payments
]]>
https://www.coredevx.com/site/7-key-characteristics-of-testing-bank-applications/feed/ 0
Agile Retrospective Meetings – Why It is Necessary and Some Fun Ways to Conduct It https://www.coredevx.com/site/agile-retrospective-meetings-why-it-is-necessary-and-some-fun-ways-to-conduct-it/ https://www.coredevx.com/site/agile-retrospective-meetings-why-it-is-necessary-and-some-fun-ways-to-conduct-it/#respond Thu, 29 Sep 2016 15:45:08 +0000 https://www.coredevx.com/site/?p=8158 Para acceder a post original click aquí

 

Agile Software development is  a set of methods and practices that are based on the Agile Manifesto. Agile methodology emphasizes team collaboration and frequent delivery of a product.

One of the 12 principles listed in the in Agile Manifesto is:

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

This principle is incorporated in an agile team in the form of Agile Retrospective meetings.

 

In this article, we will talk more about retrospective meetings, their purpose and some fun ways to conduct these meetings.

Definition and Purpose of Retrospective Meetings

By definition retrospective means “looking back or dealing with past events or situations”.

True to definition, retrospective meetings are intended to reflect on the most recent sprint/project/milestone and identify areas that need improvement and celebrate team wins.

This ties into the concept of Continuous improvement where teams get together to discuss the areas that the team did well and the areas that the team needs to work together to improve for the next sprint/project/milestone.

 

Conducting Retrospective Meetings

Retrospective meetings can be held at various stages during the project:

  • Retrospective meetings can be scheduled towards the closing days of a sprint and before the next sprint is started to reflect on the most recent sprint
  • To review a specific problematic scenario
  • At a milestone to reflect on the status thus far

Agile Retrospective Steps

Any retrospective meeting will involve the following steps:

agile-retrospective-steps

  • Set Stage – Organize meeting – Involves setting up of the meeting by the facilitator (PM., scrum master, etc.) and sending a meeting invitation to all the required team members and stakeholders.
  • Gather Data – Once the meeting starts, gather all the ideas, opinions, concerns that the team members might have. This can be done via various agile retrospective activities like Start, Stop, and Continue, Paint Me picture etc.
  • Generate Insights – After the data is gathered, meaningful analytics have to be identified and patterns have to be created. The idea is to identify trends and resolve them. E.g. if the team members are unhappy about the long daily stand-ups then we have to figure out what is causing this. It could be unrelated discussions, the tardiness of the team members, unrealistic time set up that does not accommodate the number of updates, etc.
  • Create Actions – Once the underlying issues are identified, create action points to resolve them. Action points should be assigned to an accountable person(s) who will be responsible to resolve it by the decided due date.
  • Wrap Up – Thank the team for their time and for their participation. Make sure that the meeting discussion and action points are documented and circulated to the team members for easy reference.

Agile Retrospective Meeting Formats, Ideas, and Activities

#1) What went well, What should have been done better, Action items

The team members meet and discuss what the team did well, what the team needs to improve, lessons learned and the action points corresponding to improvement areas.

These actions are assigned to an accountable team member. This discussion is documented and circulated to all after the meeting or can be saved on shared drive/intranet for easy access.

JIRA has an inbuilt sprint retrospective template for retrospective meeting based on this exact format as shown below:

agile-retrospective-meeting-formats-ideas-and-activities

(Source: http://blogs.atlassian.com/)

 

#2) Start , Stop and Continue Meeting

In this meeting the team members are asked to provide opinions about what the team should start doing, stop doing and continue doing in the sprints.

This method is very popular and effective, especially for new teams.

  • Start items would be something that the team would like to add to their process e.g. Start coming on time for project meetings.
  • Stop items would be something that the team no longer wants to do e.g. stop checking in code without code review.
  • Continue items will be something team wants to continue doing in future e.g. Continue having daily stand-ups.

The meeting facilitator can set a minimum and maximum limit of a number of items a team member can propose. E.g. Every team member needs to provide 1 item each for Start, Stop, and Continue list and can provide a maximum of 3 items per type.

Additionally, once the complete list is compiled, team members can be asked to vote to narrow down the most important items.

start-stop-and-continue-meeting

————

#3) 5 ‘Why’ format Meeting

This meeting format is based on asking follow up ‘Why’ Questions across team members.

This meeting format is used to find underlying causes for a problematic scenario (symptom), and where the causes may not be obvious.

The goal is not to solve the problem but to understand the situation and possibly narrow down the root cause.

Each team member creates a chain of reasons due to which why they think the issue is occurring. Once the list is ready, the answers can be consolidated into a single chain representing the opinion reached by a common consensus of the group.

This works best for small teams with sizes i.e. 3-5 members.

For example:

Problem: Quality of product was not good.
Question: Why?
Reason 1: Unstable build.
Question: Why?
Reason: No process enforcement- No code freeze.
Question: Why?
Reason: Scope change
Question: Why?
Reason: Impact not identified during project planning

example

#4) Mad , Sad, Glad

In this meeting format, team member takes some time (5-10 minutes) to write down sticky notes for each of the emotions – Mad, Sad, and Glad .

  • ‘Mad’ tends to focus on an obstructions, barriers etc.
  • ‘Sad’ tends to focus on internal issues and
  • ‘Glad’ tends to focus on something the team member is happy about.

After the time is up, the sticky notes are grouped based on emotions. Then the Mad and Sad issues are voted to prioritize them for creating an action item.

#5) Draw me a picture

This technique is a non-verbal retrospective technique.

In this meeting format, team members are given few minutes to collect their thoughts and express their feelings and opinions.

This meeting is a good format for conducting retrospectives where verbal communications within a team are failing, it acts as an ice breaker between team members.

draw-me-a-picture

(Source: https://www.agilealliance.org)

 

#6) Circle Celebration

This technique captures feedback using Pluses and Deltas i.e. what worked well, what could have been better).

In this, the team members gather to form a circle. One team member starts and throws a throw-able soft object (plush toy, stress balls) toward any other member.

Idea is that whoever has the ball would answer 3 question:

  • What they enjoyed,
  • What they appreciated and
  • How will they use what they have learned to improve

The object is randomly passed in the circle till everyone has had an opportunity.

Common Misconceptions

Misconception #1) Retrospective meetings are boring

retrospective-meetings-are-boring

This is the number one reason why team members do not like to conduct or be present for a retrospective meeting.

To make the meeting more engaging the facilitator should come up with fun yet effective ways to conduct these meetings.

 

Misconception #2) Retrospective meeting is my opportunity to point out the below average performance of a team member

A retrospective meeting is not a finger pointing or venting out meeting.

This meeting is not scheduled to pin-point out or call out team member for their weak points. This meeting is setup in a neutral environment with an aim to improve and grow as a team. Avoid making direct comments intended at a single person. And, do remember that the aim is to become better!

respective-meeting

 

Misconception #3) Only meeting organizer leads the Retrospective meetings and discusses issues

The team members should be encouraged to participate and share their point of view.  This meeting is for the betterment of the team and not for a top down discussion dictated by meeting organizer /facilitator.

At the same time, team members should be made comfortable so that they can express their true point of view without the fear of being judged or fear of backlash as a result of speaking up.

 

Misconception #4) Senior Management/Key stakeholders are not be invited at all to retrospective meetings

This varies from project to project. Higher management, product owners may be invited to the meeting for addressing any concerns they might have or any concerns that the team has regarding their governance.

 

Misconception #5) Retrospective meeting outcomes don’t need to be documented

Agile methodology is based on the principle “Working software over comprehensive documentation”, however, that does not mean that team should do away with documentation entirely.

Documenting retrospectives can lead to effective tracking of action points to closure. This can also be added to historical data repositories, where the team can access lessons learned as part of Organizational Process Assets

Conclusion

Retrospectives are very useful for team building and team collaboration.

Team members coming together to celebrate wins and propose improvements also create a more transparent and healthy team environment. Through continuous improvement and feedback, teams become better as time goes by.

The retrospective meetings should include both human issues (personality, attitude, lack of skills, etc.) and technical issues (scope, inconsistent requirements, system stability, etc.).

It is recommended that retrospective meetings be conducted at all levels and not just at the development team level.

The retrospective meetings can be conducted at the end of a milestone, end of a sprint, post mortem of an incident or issue, after major events, etc. Make sure that your retrospective meetings are documented and the action points are tracked to closure.

Last but not the least, make your retrospective meetings fun!

]]>
https://www.coredevx.com/site/agile-retrospective-meetings-why-it-is-necessary-and-some-fun-ways-to-conduct-it/feed/ 0
4 Warning Signs that Your Beta Testing Process is in Danger https://www.coredevx.com/site/4-warning-signs-that-your-beta-testing-process-is-in-danger/ https://www.coredevx.com/site/4-warning-signs-that-your-beta-testing-process-is-in-danger/#respond Wed, 28 Sep 2016 15:35:38 +0000 https://www.coredevx.com/site/?p=8155 Para acceder a post original click aquí

 

Beta testing plays a significant part in the process of mobile app testing. You need to make sure you are working out all the kinks and tangles before introducing it to the public. Ensuring that you have the right beta testers on your side is one part of the puzzle, but there are several other factors to keep in mind as well. Beta testing issues are always occurring but you must know how to deal with it. Being aware of all the components of your beta testing will help you catch and notice the warning signs of a failing test. If caught on time, you can correct it which will inevitably strengthen your test and results.

Below are 4 major warning signs that your beta testing is in danger:

1. Are you having significant delays?

A surefire way to recognize that your beta test is going out of hand is when your delays are becoming extreme. It’s realistic and reasonable to have some minor delays with beta testing, but delays should never be more than 3 – 4 days or maximum 1 week. If your delays are pushing at the two weeks mark, you will need to manage your test better.

What you can do is to make strict deadlines for your team and testers. Give some padding and set a realistic timeframe for the expected delays (less than two weeks), however, inform your testers about the major deadlines. Major deadlines should be set and not be missed. Delays can come up when testers are not required to be aware of what is expected of them. Make your objectives clear at the beginning to avoid any ambiguity or disappointment. With everyone on the same page, your process will keep up to date and everyone will know what is expected from them.

Staying in touch and reaching out to your testers is another way to keep them interested and on board with their mission. Send them updates, check what their status is and ask them if they have any questions. This simple gesture can improve communication and understanding between you and your beta testers which may lead to better feedback.

2. Is your test limited on time?

It’s understandable to want to test your product as fast as you can so that you can get your product out on the market. However, speeding up your beta testing period is not the way to go. The testing stages are really what stands between your success or your failure so it’s better to ensure that you are investing into the proper test management tools as well as investing with your time.

With short beta testing, you should recruit beta people who already have experience being in a beta test. The familiarity will help them to navigate through your test easier than someone who is brand new to the beta testing world. To make your process smoother, you should also inform all your testers about the time crunch and that you will need them to be active with feedback and deadlines. This way, you will eliminate potential delays and everyone will know beforehand what is expected of them and what they are getting into. Only select beta testers who have experience and can fulfill their tasks in this certain amount of time.

 

 

Beta-testing-process-structure.Ubertesters

3. Frustrated Testers

Another aspect that you should pay attention to is the well-being of your testers. Happy testers are more likely to bring you better results. We encourage creating an environment that will bring enthusiasm to your project.

A clear warning sign that you may have frustrated testers is when they are not engaged. They may be slowing down with their response time or just delaying feedback. Be aware that beta testing can often run into many challenges and that it can be frustrating for some testers. With the strict deadlines and confusing tasks, it can easily foster stressful situations. Be aware of the position they are in. In these situations, it’s important to constantly check in with your testers and see where they stand. Appreciating your testers goes hand in hand with managing your beta testers well. Keep the communication lines open and minimize as much friction for your testers as possible. Inform your testers with any updates and listen to their concerns if they have any. Simply saying thank you will show your team that you appreciate their effort and help.

If you do your best to help your testers, your testers are more likely to do their best to help you. Instead of sending out massive surveys for them to complete, it would be more reasonable to limit your surveys to 20 questions. You can also create incentives for your testers late in the testing stages. This will give your team that extra push and motivation to finish the job and do it well. You can create incentives for finishing weekly tasks or when they hit targets towards the end of the beta test. The idea is to reward your team and ensure that they feel important because they really are.

Sometimes things can become very stressful and some beta testers leave. It can happen especially when testers are not happy with how you run your test or if they are not given the chance to voice their concerns. Other times testers are just not as reliable as you had hoped and they turn out to be very slow in giving you back critical feedback. In this case, it may be wise to have a backup plan of knowing where to recruit more testers when you need them.

4. Are we testing the target market/devices?

You need to verify that:

  • your beta testers are from the specific markets that you are about to target with your app and
  • that the most popular devices and carriers in this target market are tested.

What good will it do if you plan to launch your app in the USA and all your beta testers are from Asian markets, with devices that are less popular in the USA such as Xiaomi, UMI or Huawei? Or even if your beta testers will use iPhone or Android popular USA devices, but only with European or Asian carriers? An appropriate beta testing process must include beta testers from your target market with the right devices working with the appropriate carriers.  This is the only way to simulate your target market and ensure the beta testing process meets its goals.

Running a beta test for your project is definitely not an easy task to manage. However, with  awareness to some major warning signs, you may be able to alleviate potential problems and save the journey. Depending on your project, it may be in your best interest to make sure you have the right beta testing tools for both iOS and Android in order to put the right build in the hands of the testers and giving them the tools to easily report issues and feedback. Also, it may be wise to consider the services of professional beta testing companies that offer you paid beta testers, on a turn-key project basis with the help of an experienced project manager. It may be more expensive in the short term but can prove itself in the long run.

Additional tips for what you should really focus on for your beta test is knowing what you’re looking for so that you can get the right feedback. You must be sure that you are first selecting the right testers. Perhaps you should set up a beta test application for your testers to screen out individuals who have never engaged in a test before. This way you have experienced testers on your side who know what they are doing and what they are getting into especially if you are running short on time. With this in mind, do your best to avoid testing issues that you have the power to prevent. Then you can be on your way to managing your perfect beta test.

]]>
https://www.coredevx.com/site/4-warning-signs-that-your-beta-testing-process-is-in-danger/feed/ 0
The Essential Components of a Successful Test Automation Strategy https://www.coredevx.com/site/the-essential-components-of-a-successful-test-automation-strategy/ https://www.coredevx.com/site/the-essential-components-of-a-successful-test-automation-strategy/#respond Tue, 27 Sep 2016 22:35:41 +0000 https://www.coredevx.com/site/?p=8151 Para acceder a post original click aquí

 

 

“Strategy without process is little more than a wish list” – Robert Filek

 

Testing has become a great enabler in this age with business environments becoming increasingly competitive. Neglecting testing due to time or resource constraints results in poor quality products, client dissatisfaction and increased development costs. A very high-quality bar is now key, to stay ahead of the competition.

The rise of agile development methodologies has also driven testing automation to become an inseparable part of the development process. In agile product development, development and testing need to co-exist harmoniously as the aim here is to develop the product, adopt frequent changes and at the same time prevent bugs leaking into production. However, for test automation to be successful and deliver results, having a water-tight testing strategy is essential. In this blog, we take a look at the components of a great test automation strategy

 

1. Build automation into the development plan
For test automation to be successful, it has to be a part of the development project and not an afterthought. Thus it becomes essential to align the test automation strategy with the business objectives and secure the buy-in of all invested parties. Considering the short release windows in agile projects, the test automation strategy has to ensure that it aligns with the product and business strategy from the inception in order to be successful.

 

2. Expectation mapping
It is imperative to set the right expectations to be successful in test automation efforts. Considering 100% automation is not a viable option both in the terms of efforts and costs, it becomes an important part of the strategy to define what needs to be automated and what can be tested manually. For example, the efforts required for automation in GUI testing are considerably higher as compared to manual testing. The objective of automation is not to replace manual testers but to facilitate product development by automating the tests that need to be done repeatedly and frequently to deliver optimal results.

 

3. Define objectives and outcomes
To write quality code, you need to review that code frequently. To do this having strong and defined objectives, similar to those that we have during software development, should be implemented. Instead of listing out vague outcomes, quantify the outcomes with specific goals you would like to achieve with automation for better results. Replacing objectives like, ‘test fast’ or ‘achieve greater coverage’ with something more quantified such as ‘achieve 30% greater test coverage’ or ‘reduce time to market by 20%’ will deliver greater results.

 

4. Have a dedicated team
Test Automation should have a dedicated set of resources. In a blog we wrote previously, we discussed how designing a test automation suite may require resources who are conversant with the elements of coding and programming making it more of a developmental activity. However, it’s the test automation engineers who know which workflows and scenarios need to be automated and which can be tested manually and know the paths in which bugs tend to hide. A dedicated team will have a mix of these capabilities. Having a dedicated team also makes the decision-making process simpler and ensures that the responsible people remain answerable towards the outcomes.

 

5. Select the right tool
Selecting the right tool assumes a very important role in the test automation strategy. With a multitude of tools out there, which one fits the requirements of your project? Testing teams thus need to assess the business need and evaluate the objectives of automation in order to make the right selection. The test automation tool will aid the test-suite creation process by making it simpler. However, for the test automation initiative to be a success, a great automation tool has to be complemented with skilled resources. Thus it makes sense to invest in a test automation tool that uses a language that is familiar to the resources, enables the cost advantage, provides feature based decisions and has solid infrastructure support.

 

6. Plan for product evolution
A test automation strategy also has to account for product evolution and ensure that it remains relevant in the light of frequent product upgrades and releases. Thus testers need to assess which tests they can reuse, test plans that will remain relevant and which need to be discarded, build smaller and independent test cases instead of one big monolithic architecture, and create space to analyze test data etc. to build a solid test automation strategy.

 

When developing a test automation strategy, it helps to bear in mind that the real value of test automation efforts comes from the results that the tests produce and not from the volume of tests that are automated. Thus testers need to choose wisely and decide what to automate, when to automate and how to automate. Only when the test strategy is well thought out and defined will organizations get the desired results from their test automation initiatives.

]]>
https://www.coredevx.com/site/the-essential-components-of-a-successful-test-automation-strategy/feed/ 0
Why Agile Is Critical for Attracting Millennial Engineers https://www.coredevx.com/site/why-agile-is-critical-for-attracting-millennial-engineers/ https://www.coredevx.com/site/why-agile-is-critical-for-attracting-millennial-engineers/#respond Mon, 26 Sep 2016 22:45:14 +0000 https://www.coredevx.com/site/?p=8147 Para acceder a post original click aquí

 

 

Key takeaways

  • A new generation of engineers is not being trained in traditional software development methods, nor are they interested in working for businesses that use them.
  • Young hires have demanded that employers swap legacy development tools for the latest and greatest Agile tools, and some major corporations have complied to the tune of million-dollar investments.
  • As the country’s largest generation, Millennials are influencing Agile transformations in their workplaces.
  • We see at least 11 ways that Agile is a perfect fit for Millennial generation workers.
  • Businesses that adopt Agile sooner will gain a competitive advantage in recruiting as well as productivity.

 

A Fortune 100 enterprise software company recently got schooled by a social media business it acquired. The young engineers there refused to use their new owner’s legacy tools. They revolted, demanding access to world-class planning and development tools. The corporation spent $1 million overhauling their ALM tools with best-of-breed tools.

My company facilitated that integration, and it’s just one of numerous examples we’ve seen of established organizations—including big banks, major credit cards, and brand-name publishers—being prodded by a new generation of developers to adopt more innovative tools and processes, namely Agile. As Agile recruiters, we also see Millennial (age 19-35) engineers consistently passing up job opportunities at shops that either are not Agile, or are known to be not truly Agile. (They know the difference between those who just talk Agile and those who walk the talk.) They’d rather take a lower-paying position working in a true Agile culture working with the best ALM tools.

Millennials reject outdated standards, bureaucratic processes, and antiquated tools. They’ve grown up with easy access to state-of-the-art-technology, and they don’t hesitate to ditch cumbersome tech and slow networks in favor of user-friendly interfaces and speedy systems. They’re accustomed to instant feedback, sharing information, and having a say. And they’re used to knowing more about technology than the older people around them. The Agile work culture speaks to the soul of the Millennial generation, and customized Agile work tools allow them to connect and interact the same way they grew up engaging with their friends.

To be sure, Agile is embraced by knowledge workers and software developers of all ages. A bunch of Baby Boomers birthed the concept, after all. It’s a humanistic philosophy with universal appeal to creative, innovative people. And, as our Agile Practice Lead Kevin Thompson notes, “Agile transformations aren’t driven by Millennials; they’re driven by business needs.”

True. But as a company of Agile trainers, recruiters, and product distributors, we see every day how Agile wins not just the most favor from Millennials, but also their best work.

A Millennial-generation developer who works on JIRA Software at Atlassian told me, “I chose to work in an Agile environment because our industry moves fast, and I don’t want to sink time and energy into something that doesn’t matter, or won’t help me move forward.” Agile development, he said, “goes beyond the technologies we use or the processes we follow. It’s an attitude, and it needs to be present throughout the entire organization.”

For some Millennials, working with less-than-pure Agile methods is a compromise. A 27-year-old project manager told me he left a Big 5 Consulting Firm after nearly 5 years because the architecture-driven version of Agile practiced there was “too constrained by governance.” He made a lateral move to a job with a software developer focused on small, private customers.

“I wanted to be in a position doing Agile without as much regulation, where I could get users’ feedback, be able to iterate on that where you don’t need your own team’s approval before you can release, and have that cycle going continuously,” he said. He finds developing software for his new employer “more euphoric and effortless because there’s not as much friction in the process.”

By virtue of being larger than either of the two preceding generations, Millennials will soon have a lot more clout in the workplace. Considering the stiff competition for tech talent, it’s easy to see how companies that embrace Agile will gain competitive advantage over those that don’t. Here are 11 reasons we see Agile methods as a perfect match for Millennial engineers:

  1. Teamwork. Millennial job candidates we meet with want to know what the group environment is like and whether they will enjoy being a member of the team. Agile done right is about far more than daily standups and scrum. It creates a culture that supports teamwork and values individuals. At the same time, best-of-breed Agile workflow tools do away with time-wasting meetings and unending group email chains, for which fast-moving Millennials have even less patience than the rest of us.
  2. Trust. The Agile approach shares fundamental information with team members—”why are we building this and what is its value to the organization?”—and empowers them to make decisions. These features speak directly to the Millennial demand to understand their contribution in a greater context and to their desire to be trusted to execute on their knowledge.
  3. Ownership. Perhaps more than other generations, Millennials are said to demand work that gives them a sense of purpose. In classic waterfall development, engineers merely follow specs that have been written by someone else. Agile developers are the planners, not the recipients of the plans. Agile teammates are involved in discussing project requirements, ideating, debating, making recommendations, and estimating their own timelines. Each member has a purpose and ownership of the product.
  4. Input. There are no parent-child relationships on an Agile team. Teammates are more like sibling with complementary skills and equal value, and they put their heads together to solve problems. The Millennials we talk to want to be valued and heard. They’re not interested in having their work and deadlines dictated to them or just following orders, even if the pay is better. They want to invest their time in work that makes the most of their skills and lets them grow.
  5. Communication. Millennials don’t use email and a desktop computer to interact with friends and family; they use mobile messaging. Communication tools being implemented today as part of the Agile process allow users to collaborate and share information online with a team faster, more efficiently, and more securely than email ever did. The bonus: They mimic the way Millennials are accustomed to communicating—all the time and anywhere. Specifically, Atlassian’s HipChat facilitates real-time group and private chat, video calling, screen sharing, file sharing, and searchable messaging, while Confluence enables team to capture, organize, and discuss project documents and notes in one accessible place with social sharing features.
  6. Feedback. When you’ve grown up seeing “likes” and comments on all of your social media posts and instant responses to your text messages, you thrive on feedback. Annual or even quarterly performance reviews don’t satisfy Millennials. They need continual reassurance. With its built-in feedback loops, Agile is designed for them. In Agile’s standup meetings, teammates share their successes, describe what they’re working on, and discuss their challenges every day.
  7. Instant gratification. Not only is the pace of development faster in Agile, but the iterative process of working in sprints satisfies the Millennial need for instant gratification. In Agile, there’s no waiting to find out if you’re right. Developers get to see their product taking shape in real time and to see that it works. Atlassian’s JIRA workflow tracking tool gives teams and individual developers real-time, actionable insights into how they are performing sprint over sprint.
  8. Quality of life. At its core, Agile is about building and maintaining a healthy culture. A2016 Fidelity Investments survey found that Millennials would take as much as a $7,600 pay cut for a better work-life balance or a better company culture. Agile methods have balance baked in. Burn-down rates let developers see where they stand and when the next break is coming. And with tools like JIRA, customizable scrum boards and flexible kanban boards give developers a sense of control over the details and pace of their own work as well as a clear view of the big picture and what’s coming next.
  9. Reduced risk. Agile embraces failure, but practically prohibits catastrophic failure. The iterative process catches failures while they’re small and ensures that the product remains aligned with the customer’s goals and needs. The promise for Millennial engineers who will only ever work on Agile projects is that they will experience small, fast failures, but possibly never know huge ones.
  10. Mentorship. Agile values decentralized power and a flat organization. We move faster that way. The traditional manager is more mentor. The scrum master doesn’t presume to know more than team members, but listens to their ideas and problems and coaches and guides them. The approach resonates with Millennials, who want to feel engaged with leadership.
  11. Career Development. In traditional waterfall projects, developers might focus for as long as three years on a single assignment. That’s as long as most Millennials stay with any one employer. Agile gives developers more freedom to hone their skills on work they’re most interested in, and to shift focus more frequently. No member of an Agile team gets stuck with monkey work, nor do they waste time acquiring skills in a method they consider the old way of working.

My colleague Kreisler Ng, a cPrime Agile Coach, told me that he recently asked a room full of young engineers at a startup how they compared waterfall to Agile development. They couldn’t, they said: None of them had never worked in waterfall. They didn’t use it in college—academia already views it as an outdated method. They all sought their first jobs in Agile shops.

As Millennials flow into the workforce, Agile engineers will far outnumber the traditionalists. In our view, companies that want to compete in the marketplace and for talent would be wise to set the wheels in motion for an Agile transformation.

Or you could stick with traditional project management. It’s possible that the post-Millennial generation of engineers will be attracted to working in organizations where they just need to follow orders. But not probable.

 

About the Author

Zubin Irani is co-founder and CEO of cPrime, a full-service consultancy that implements Agile transformations and delivers Agile solutions for more than 50 Fortune 100 firms and many of Silicon Valley’s biggest employers. Irani’s previous experience at Deloitte and DirecTV included management of a wide variety of application deployments with complex back-end integration on projects ranging from 5 to 400 team members and $100,000 to $120 million budgets. He holds an Executive MBA from Columbia University and University of California, Berkeley, and a Bachelor’s degree from University of Southern California. He grew up in England and California.

]]>
https://www.coredevx.com/site/why-agile-is-critical-for-attracting-millennial-engineers/feed/ 0
The GUI is No Longer King – Why API Testing is important https://www.coredevx.com/site/the-gui-is-no-longer-king-why-api-testing-is-important/ https://www.coredevx.com/site/the-gui-is-no-longer-king-why-api-testing-is-important/#respond Sat, 24 Sep 2016 14:30:22 +0000 https://www.coredevx.com/site/?p=8169 Para acceder a post original click aquí

By

Tareq Mamun
SQA Automation Engineer at Data Path Limited

 

 

I’ve been involved with test automation for over 15 years, and in the beginning, pretty much all my test automation efforts focused on automating GUI user interfaces like thick client applications, browsers and even green screen for mainframes.

Now my time is split approximately 50/50 between creating automated tests for UI and creating tests for APIs like REST services. There are a few reasons for this:

  1. Agile practices

The Internet Of things

Agile

With Agile development becoming the standard in most organizations, the ways in which we develop software and automate tests have changed dramatically.

GUI tests that go against a user interface tend to take longer to run.

During certain Agile practices like continuous builds, the amount of time it takes to receive feedback from a GUI regression suite of tests when new code is checked in is too long. In those cases, quicker feedback is needed.

Agile has also increased the frequency with which applications are released, which in turn has created an increased demand for new ways to quickly test them. GUI tests are typically too slow to get the test coverage we need during, say, a typical two-week sprint. Also, since API tests don’t rely on a UI to be ready, they can be created early in the development process.

Mike Cohen’s Testing Pyramid

In his book, Agile: Software Development Using Scrum, author Mike Cohn introduces the concepts of a test automation pyramid:

This image represents the opposite of the way most non-agile development teams perform automated testing.

GUI Test

GUI testing focuses on testing an application user interface to ensure that its functionality is correct. IDE GUI testing is at the top of the pyramid and represents a small piece of the total number of automation test types that should be created.

Unit Test

Unit testing makes up the largest section of the pyramid, forming a solid base. A Unit test is created to verify a single unit of source code, like a method. By doing this, developers can isolate the smallest testable parts of their code. Unit tests are the easiest to create and yield the biggest “bang for the buck.” Since unit tests are usually written in the same language that an application is written in, developers should have an easy time adding them to their development process.

Service – API Test

The middle Service layer is the “sweet spot” that tools like SoapUI, UFT API and rest-assured were created for. Service testing is also known as Integration testing. Integration testing focuses on verifying that the interactions of many small components can integrate together without issue. Since API tests bypass the user interface, they tend to be quicker and much more reliable than GUI tests.

The Internet of Things

The second change that is causing a shift towards API testing is the Internet of things. The Internet of Things is an everyday object with embedded functionality that allows it to talk over the web using HTTP or HTTPS to communicate with remote backend services.

Basically, more and more things will begin to have sensors embedded into them. The other day I saw a video of Enchanted Objects: Design, Human Desire, and the Internet of Things author David Rose being interviewed by John Stewart, who showed a medication “glow” cap, that will tell you when to take your medicine by blinking or texting you so that you don’t forget. This is just one minor application, but I’m sure you can imagine the endless possibilities for this type of technology.

Extending this trend outward, some estimates show that in 2020 there will be over 50 billion objects connected to the internet!

So how do you test, say, a scale that tweets, a refrigerator that tells you when you’re running low on milk, or bio sensors embedded in your clothing that can measure your stress level — and adjust your environment accordingly — based on that information?

None of these examples have a traditional user interface. So how do we test them?

First, let’s look at a typical API test flow:

API Headless Testing

What is an API (Application Programming Interface)? An API specifies how its software components should interact with each other. APIs can be created using a whole host of different technologies. APIs help facilitate communication between a client and a server.

The type of APIs that we’re most likely going to be testing are HTTP/HTTPS- based APIs where communication is done over the web. For example, say we have an internet scale that has an app that makes a request and receives a response from a backend service. How do we test them?

Tools to test APIs

There are many tools available — both open-source and vendor-based. Here are a few of my favorite tools and resources to help you discover more (and prepare for the API testing revolution

]]>
https://www.coredevx.com/site/the-gui-is-no-longer-king-why-api-testing-is-important/feed/ 0
Building Better Software Through Effective Test Coverage https://www.coredevx.com/site/building-better-software-through-effective-test-coverage/ https://www.coredevx.com/site/building-better-software-through-effective-test-coverage/#respond Fri, 23 Sep 2016 19:30:37 +0000 https://www.coredevx.com/site/?p=8143 Para acceder a post original click aquí

 

 

In mid-January 2016 the Nest ‘smart’ thermostat (owned by Google) left users in COLD.  A software snag was responsible for it.  It forced the battery of the devices to drain and thus it was not able to control the temperature.  Nest said that the firmware update in December caused this issue along with old air filters and incompatible boilers.

Such issues can cause major support challenges and unhappy customers.  It dents company’s reputation as well.

The software glitches are mostly associated with inadequate test coverage or not interpreting test coverage results right. Often, too few test cases are written for each user story while not having continuous visibility on the code on what changed during the process.

A constant coordination between development and QA team can help in better understanding the features being delivered in a release and creating test cases that cover every aspect of the feature like how it should work, constraints and validations, dependencies and ancillary functions. Agile developers build features based on a series of user stories (sometimes grouped by themes and epics). Creating your test scenarios at the user story level gives you the best chance of achieving optimal test coverage.

Test Management Tool like QMetry Test Manager For JIRA can play a major role here.  As it is built within Atlassian JIRA; the coordination between development team and QA team becomes very easy.  Through the test coverage report provided within QMetry; test teams can dive down deep and find missing links in test scenarios.

3bfb2baf-7cab-40bc-b733-e0622bfe4116Test Coverage Report – In Depth

 

The Coverage Method:

Once your QA and development teams agree on the features to be delivered, you can begin creating tests for each feature. Coding and test development should be done in parallel to ensure the team is ready to test each feature as soon as it’s published to QA.  As mentioned above;QMetry Test Manager For JIRA is the GOTO tool for having complete visibility on test coverage.  In my next blog; I will also discuss about Traceability.  Coupled with test coverage; it provides a strong metrics for having high quality code.

Some of the key tests suggested are:

 

Positive Tests: Ensuring that feature is working as intended with all functionalities.  The error messages and workflow is working as per giving sequence.

 

Negative Tests: Frequently or mostly users start using the software with little or no training.  Manuals are not referred as well.  This leads to errors and mistakes that are unintended and not considered ever.  Examples like entering special characters in numeric field or entering values that are constrained for a field are common.  Missing out mandatory fields or delete records that have established relationships with other records are also reported.  When you design tests, it’s important to understand the constraints and validations for each requirement and create enough negative tests to ensure that each constraint and validation is tested thoroughly. The ultimate goal is to have a ‘dummy proof’ code.

 

Performance Tests: Testing features under duress is very important.  This is a hybrid exercise with some test cases being automated while some being manual.  Testing the code with large validation dataset is the key.

 

Ancillary Tests: Better designed system write errors to log files, maintains change audits to records and maintain referential integrity to have clean clearing of records where master/child records are deleted simultaneously from their respective tables.  The data purge routines must also be tested before deployment.  Finally, security features like access rights are needed to be tested to avoid unauthorized access due to bugs. Ancillary tests ensure that log files and audits are written, referential integrity is preserved, security is embraced, and purge routines cleanly remove all related data as needed.

To conclude; by following proper methodology and having a strong Test Management add-on likeQMetry Test Manager for JIRA; achieving proper test coverage and traceability (we will talk about it in next blog); we can build a bug-free code in agile projects.

]]>
https://www.coredevx.com/site/building-better-software-through-effective-test-coverage/feed/ 0
Overview of REST API Testing https://www.coredevx.com/site/overview-of-rest-api-testing/ https://www.coredevx.com/site/overview-of-rest-api-testing/#respond Thu, 22 Sep 2016 16:15:23 +0000 https://www.coredevx.com/site/?p=8138 Para acceder a post original click aquí

 

When we are told to test a complete application, the first things that come to our mind are its specifications, requirements and how the different functionalities need to re-tested.

 

We also create a test plan side by side so that ample emphasis is provided to all testing vertices. But when a project has short release cycle and the application is prone to change, we must think of a better approach.

 

In Agile projects, dealing with large and complex applications, we must resort to a testing methodology that tests the application core and verifies responses for specified requests. And this is why API testing is considered the best approach in such circumstances.
In this article, we would look at what one form of API testing, i.e. REST API testing and also mention the different tools and practices recommended for such testing.
API Testing at a Glance
Before we start talking about REST API testing, let’s find out what can be achieved out of API testing.

 

  • Most applications use different APIs (Application Programming Interfaces) to provide distinct features. These APIs can be independently created by the development team, along with other third-party APIs.
  • APIs enables communication or exchange of information between different software systems. As they are mostly driven by the business logic, such interfaces lack any GUI.Due
    the absence of GUI, API testing completely relies on the verification of user inputs and corresponding API responses.
  • API testing doesn’t take the application’s look and feel into consideration and only checks API’s calls and system responses.
  • Testers provide a wide range of requests to the API and checks whether the API returns valid responses. Edge cases like extreme or out-of-bound inputs, time-outs and security related tests are also performed to validate negative test scenarios.
  • In order to test any API, testers need:

► A testing tool to communicate with the API

► Custom code to test the API.
Need of API Testing over GUI Testing
To better understand the need of API testing, let us elaborate the advantage provided by API testing over simple GUI testing.

 

  •  Most applications can be segregated in 3 distinct layers.

► Presentation layer

► Business layer

► Database layer

 

applicationlayer

 

  • GUI testing and test automation are performed in the presentation layer. This, in turn, communicates with the business and database layers to validate the correctness of a test.
  • API testing directly targets the business layer of the application and instead of standard inputs, makes use of software to send calls to different APIs. The responses from these calls are used to validate test scenario.
  • As GUI is not involved, API testing is considered to be much more suitable for continuous testing and for projects which follow Agile Software Development.
  • For projects with short release cycles and prone to frequent changes, testing GUI would require a lot of rework and can be hard to maintain. Such projects should opt for API testing.
  • Test scenarios with a large number of edge cases can be easily executed with API testing than GUI testing.

 

SOAP vs REST API
Now that we are well aware of the capabilities of an API and how important API testing is, let’s discuss in brief the different types of APIs.
SOAP(Simple Object Access Protocol) API

 

  • It is a standard and follows rigid messaging patterns.
  • Uses XML to provide messaging service.
  • It is language and platform independent.
  • Easy to use in distributed enterprises
  • Supports built-in error handling

 

REST(Representational State Transfer) API

 

  • Doesn’t require expensive tools to interact with the Web Service.
  • A light-weight alternative to SOAP.
  • Responses can be generated in a number of different formats, namely CSV, JSON or RSS.
  • Easy to learn
  • Responses are relatively fast
  • Mimics Web technologies and relies on HTTP protocol

 

REST API Testing Fundamentals
To successfully test a REST API, coding knowledge is required. Using a tool we communicate with the API, while using a custom code we validate the API.

 

  • To test the basic features of the REST API, we must know the following keywords.

► POST

► GET

► PUT

► DELETE

  • POST – This keyword is used to create new resources.
  • GET – It is used to read existing resources.
  • PUT – This keyword is used to update existing resources.
  • DELETE – Used to delete resources.
  • Using the GET command with the right URL and authentication data we can validate the response of the API.
  • To create entries we can use PUT command and in return check the response.
  • If the response is returned with the added data, we can confirm that data is correctly getting archived by the API.
  • Thus different edge scenarios and boundary value conditions can be easily verified with REST API testing.
  • Also, we automate the API calls and validate the responses using different automation tools.
  • Some widely used REST API testing tools are

► SoapUI

► vRest

►  Parasoft

►  HP QTP

►  HTTP Master

 

Challenges of REST API Testing

Some of the challenges faced during REST API testing are:

  • Coding knowledge is must for testers who are involved in API testing,
  • Exception handling is taken care of for SOAP web services, but for REST, if there are any issue with the request, response won’t be generated at all. Finding the root cause of such blank responses can be a really tough job.
  • As there is no user interface involved, the edge scenarios must be identified before testing.

 

Conclusion

  • As REST API testing directly addresses the core business layer of an application, it is extremely useful for testing applications which are prone to changes.
  • To test the APIs thoroughly, all edge scenarios must be identified.
  • API testing can also be integrated with automation test  suits which can validate API responses without manual intervention.
]]>
https://www.coredevx.com/site/overview-of-rest-api-testing/feed/ 0
My Unexpected Journey to Becoming a Software Tester (From Entry-level to a Manager) https://www.coredevx.com/site/my-unexpected-journey-to-becoming-a-software-tester-from-entry-level-to-a-manager/ https://www.coredevx.com/site/my-unexpected-journey-to-becoming-a-software-tester-from-entry-level-to-a-manager/#respond Wed, 21 Sep 2016 18:30:27 +0000 https://www.coredevx.com/site/?p=8172 Para acceder a post original click aquí

 

 

“You build a Successful Life…A Day at a time…”

My journey as a Software Tester started a bit unexpectedly.

I appeared for the initial interview rounds assuming it to be a Development opportunity. To be honest, like every other Computer Science graduate out there, I was a bit skeptical about going ahead with Testing.

But finally, I decided to give it a try. Only with a hope that my curious nature will help me in this field. 

I couldn’t accept the offer without putting up this question – Will I get an opportunity to switch to Development in case Testing doesn’t interest me? :).

Believe me- I never even got a thought of leaving Testing after that.

 

When I appeared for the technical round, I wasn’t prepared for anything more than the basic concept of Software Testing. I guess the only thing which took me through was the thought that I am being evaluated logically and not theoretically’.

This was my very first learning in Testing – I understood how we (freshers) were evaluated.

Even today, I use similar techniques while hiring freshers for my team. I check their logic, tenacity and approach to a problem over anything else.

 

I joined Zycus as a QA Trainee and was allocated a product on some third or fourth day. It was one of the biggest (was in concept then) and most ambitious products of the company. After settling down for the initial few weeks, there was no turning back for me.

We started as a QA team of two and soon after few months I was the only one driving the Testing efforts. In the initial 2 – 2.5 years itself I had logged nearly 3000 defects across different categories such as Functional, Performance, Security, UI, Usability, Multilingual, Multi-Tenancy, etc.

For a considerable time before new additions to the Testing team, I was up against a strong 15-16 member development team. Even after the additions, QC:Dev ratio wasn’t very healthy and I can still proudly say it was a successful journey considering all that we tested, delivered and handled.

The important point I want to highlight here is- All this was from an understanding of Testing in practice and not just theory.

I have been in the Software Testing field for almost six years now. It has been an amazing journey with so many different experiences and plenty of fruitful learning.

Presently, I am working as a Senior QA Manager looking after some 5-6 products and modules. But what gives me real joy and happiness is leading a team of 30+ happy and passionate Testers.

Of course, many people have contributed to my learning, but I can still say most of my experience and knowledge has come the hard way (and probably the best way), i.e. Learning/solving it on my own.

“Experience is the best Teacher.”

While I say this, I don’t at all mean to say that you won’t be benefited from learning or following documented theories about Software Testing. What I believe is, this all will surely help but nothing can beat understanding the concept at the core and facing the problems boldly.

I believe documented stuff won’t teach you real testing, though it can give you some direction and then you are on your own. At least in my case, there were problems which may be not documented to solve my exact problems or I couldn’t find them in time. My only choice was to understand the problem/situation at the core and react to it with the approach I found right.

Examples – How I approached in different situations

Let me explain this with the help of problems/situations I was up against and how I approached them.

 

#1) Business understanding is a notch higher over understanding testing

Well, you all know this. Testing isn’t just testing few validations and doing some verification.

As a tester, we are supposed to visualize every possible scenario, even the rarest of the rare scenario without fail. We are supposed to consider every possible test data which the actual user might be using.

For all this, we are supposed to understand the business to the fullest.

It won’t be wrong if I say we should understand the business and user base as much as or even more than a Business Analyst does.

I was facing similar odds.

I was supposed to understand complex business scenarios in the procurement domain, brainstorm the new requirements and weigh them from a user’s perspective. I was not only supposed to work out my cases but also contribute in the Requirement and Design phases of each iteration. Even here, no ready reference came to my rescue apart from my thinking and reasoning ability.

To understand the business better and design your scenarios/cases better, nothing works like pen and paper.

 

Before going to Requirement discussion meeting, I used to write down possible doubts/corrections/unclear points beforehand. I used to write down the scenarios I want to try or build test cases upon; sometimes, even drawing your scenarios works like a charm.

When you write/draw, it enters your mind with better clarity and then your mind works on this information and produces more scenarios and gives better clarity. This goes on till you get that feeling of DONE!!!

 

#2) Performing against the odds and in pressure

I was working on a product which was/is huge and complex enough to make a team of 30 engineers working continuously for three long years to get it to a sellable level.

For most of the initial phase, either I was up (solo) against a team of 15-20 developers ranging from the junior, mid-senior, and senior level or was accompanied by one or couple of other testers. They were all adding new features to product relentlessly, which required equal and parallel attention from the testing side.

Being part of requirement meetings, writing cases, executing them, exploratory rounds, maintaining servers, deployments, nothing was optional.

By then I wasn’t aware of any methodology, best practice, course or a book which can show me solutions to such problems. Even today I’m not sure if there is anything which can precisely help you fight the ground realities as you face them.

 

What I was rather doing is, aggressive and rapid rounds of exploratory testing (I wasn’t aware of the name by then) on each feature one-by-one and then repeat. This solution works purely on how fast you can shift your thoughts and frame situations/scenarios.

Of course, this demanded real fast and aggressive work but it worked for me.

What I mean by aggressive round is, you target one thing at a time(Say one element of a form at a time) and test it independently and in association with other linked elements/things.

 

E.g. How to test a Textbox.

 

What you can test here is:

 

  1. Whether it accepts and stores data as is
  2. Data type validation
  3. Max length validation
  4. Special character’s handling
  5. XSS handling
  6. Multilingual data handling
  7. Handling of empty spaces/no data
  8. Behavior of tab and enter keys
  9. Error handling (cross-browser)
  10. UI alignment (cross-browser)
  11. Copy paste data/dragging links data to textbox
  12. Most important – the behavior of this field w.r.t. other linked elements (any business expectation linked to this field like populating something in some other field based on the data in this field)

Does thinking about above testing give you confidence that nothing much can really go wrong with this field?

Well, targeting one thing at a time always worked for me and I used to get some work completion too.

 

#3) When you are up against the ‘unexpected’

Which book do you think will suddenly help you with ‘How to’ when you are supposed to do something you have never done before?

If we talk specifically then- None.

I remember the time when in the absence of our Product lead, I along with few other Junior and mid-senior members were supposed to deploy our application on Demo (was production to us then) instance for the first time. It was very critical for first ever Demo of our product.

Well, we did it, but with lots of Trial-and-Error. Reason being, none of us had expertise on Linux and shell scripting. I remember, there were concerns raised by our IT department (all in good faith) to my then Manager about me running wrong commands on Production servers. Maybe this was just a catalyst and shell scripting/Linux was my natural interest, but in a short while after that, I ended up taking responsibility of maintaining and upgrading five to six environments simultaneously.

Shell and Linux caught my interest so well, that soon I was the one who started conducting internal training sessions on it.

 

#4) When your performance is measured, your experience is not

Very early in my career, I was getting compared and measured against the very evolved and experienced testers around. I believe many of you must have experienced a similar situation and know what those extra expectations does to you.

The remedy here was to Push myself & Evolve.

The only way forward was to not think about how less experienced I am, not limiting myself by World’s standards of measuring how slow/fast I should grow/learn. Not limiting myself to World’s criteria of how soon one should start leading and the title one needs before doing it.

Well, around this point, I must say, irrespective of which field you belong to, I recommend you read Robin Sharma’s The Leader Who Had No Title. It will help you unleash what lies within you. It will tell you no one except yourself can hold you back.

 

If I have to bind my experience in few sentences, it goes like this:

“Your curiosity, attention to details, discipline, logical thinking, passion for work and ability to dissect things is all what matters to be a Destructive and Successful Tester. It worked for me and I strongly believe it will work for You. If you have these qualities, it has got to work for you.”

Well, reading this far if you are thinking that I am promoting basic human qualities over deeper theoretical knowledge, then that is not completely true. I believe to start with something and to taste success at it, it depends slightly more on your inbuilt qualities than on information you have learned. However, to go far in any field, you have to learn lessons, principles, and experiences.

In my case too, I had to learn the terminologies, concepts, theories to some extent as I reached further in my career. Reason being, as a tester you have to interact with several people who will talk in those terms and you got to understand it.

As a lead or a co-tester, you will have a new tester coming from some part of the world with his/her own knowledge of facts, definitions, and terminologies. Here too, you can’t stay passive towards these things; you got to have a prior knowledge about maximum possible things used/said out there.

 

Learning is inevitable.

I had to learn more about different types of testing, how to execute those and ways to explain it to people in my team at the right stage. I had to evaluate new ideas, tools and implement those. Learning new concepts and methodologies becomes equally important as you move up the ladder.

 

Conclusion

Though it is nearly impossible to write down every major and minute thing I have learned over years, this is my attempt to summarize it in a bulleted list.

  • Testing is very tough to define. Someone can do superb testing and might not be able to define it in words. It is as you see it.
  • Everyone can have their own definition of testing. Mine was simple- “You are given a thing – Find faults and make it better.”
  • You don’t necessarily need big theories, complex matrices or ISTQB to be a destructive tester. You got to be curious, focused, and passionate, think logically and have dissect-ability. However, knowing extra doesn’t harm but not at the cost of losing the crux.
  • The traditional approaches/concepts too have their own importance and I have equal respect towards them considering the fact there is a good part of the world where those are a just necessity. Testing alone can’t evolve; the surrounding also has to evolve for that.
  • As a tester, it becomes equally important to learn new tools, techniques, and methodologies as you move ahead. Test planning, better approaches to perform different types of testing, Situational testing are a few to name.
  • As testing is fluid, the definition of being a right fit also differs vastly from organization to organization. Being a destructive or excellent tester might just be good enough to get a pay cheque if you are lucky or it might demand extra knowledge of how testing works in traditional companies. Both are right at their own place. e.g. I hire people according to my definition of testing (which varies a bit as per candidate experience and profile of course).
  • As there is a style of coding, driving, cooking; there is also a style of testing. You might not enjoy it unless you’re doing it your way. What I mean is Testing can have guidelines but it shouldn’t be hard bound by the micro-processes.
  • The effective lead should make his team choose the work rather than assigning. He can occasionally alter it for the betterment of the Product.
  • Try to train your people in their area of interest and along with where you want them to be trained. Align your team’s thoughts and efforts with end objective, which is ‘The Best Quality’.
  • Don’t try to manage your people, lead them. Be friendly and approachable, it makes work a lot easier.
  • Every member of your team should love the work they are doing, have an attachment to the product and are affectionate towards the people around. Then only the best of them will come out.
  • The testing world has to evolve. Considerable part of World is moving to more practical approaches like Exploratory Testing, Context-driven testing (which many people do without knowing it is it) which even others should try and develop more techniques like the
  • More Testing communities should be formed and like-minded people should get together on a larger scale quite There is so much to share, learn, adapt and innovate.

Hope my experience and findings helps you become a better tester or helps you in understanding testing better.

Further reading => From Beginner to Pro: A Complete Guide to Successful Journey of a Testing Professional

About the author: This article is written by STH team member Mahesh C. He is currently working as Senior Quality Assurance Manager having experience of leading testing front for multiple complex products and components.

]]>
https://www.coredevx.com/site/my-unexpected-journey-to-becoming-a-software-tester-from-entry-level-to-a-manager/feed/ 0
Security Testing: How to Avoid Data Breaches and Lawsuits https://www.coredevx.com/site/security-testing-how-to-avoid-data-breaches-and-lawsuits/ https://www.coredevx.com/site/security-testing-how-to-avoid-data-breaches-and-lawsuits/#respond Tue, 20 Sep 2016 18:15:45 +0000 https://www.coredevx.com/site/?p=8134 Para acceder a post original click aquí

 

 

App security is moving up the agenda for development teams this fall. In case you aren’t aware, Apple has set a deadline of the end of this year for the App Transport Security encryption protocol to be in place. As of the first of January 2017, Apple will no longer support non-HTTPS apps.

Yet encryption’s just one aspect of app security. Security scare stories and cautionary tales circulate widely. I don’t need to tell you how data security vulnerabilities in an enterprise can kill share price, reputation and brand equity in the event of a breach. How can we ensure we build secure apps? As much as I could launch into a personal manifesto on the importance of building security into the dev process, the truth is that app security is highly interlinked with everythingthe app touches. So if you’re about to develop an app for your business, here are ten security considerations that you need to bear in mind.

 

1. Involve the security team – Whether the initial planning and development is being carried out in-house or by an app development partner, bring your security team into the discussion. Firstly, they can set out the standards to which developers need to adhere. Secondly, they can advise on defining the app security architecture and design features. Don’t forget to ensure they’re part of subsequent sprint reviews.

 

2. Secure-as-you-code – Building in security at the development phase makes good sense. It’s much harder to fix flaws at later stages of the process; it costs a lot more in money as well as resources. Agile methodologies will help you here. Writing good security code as you go along lends itself to the Agile way of doing things, and will complement your efforts to drive CI/CD too.

 

3. Coach and mentor – Small, focused development teams, another favorite among Agile practitioners, also suit the transfer of security knowledge. Just as you’d cross-train team members for other disciplines, remember to pair more advanced security coders with less experienced ones, spreading good security practices throughout the SDLC.

 

4. Make it personal – Try to ensure your developers have a vested interest in writing more secure code by making company security standards less like edicts handed down from on high, and more like tools that will improve the way they code. I’ve seen this done by introducing a little bit of competition between teams, but if that approach isn’t right for you, how about implementing a system of shared, standard libraries that are maintained for all to use? It’s a relatively small move but one that helps solve common security problems for developers.

 

5. Use code scanners – App code scanning technologies abound and are to be recommended. A note of caution: these tools aren’t a substitute for a solid security plan that’s implemented and tested throughout the dev process. Use them in conjunction with other measures.

 

6. Use white hat hackers – You can learn a lot about your apps’ vulnerabilities, indeed your whole enterprise IT architecture, from planned penetration testing exercises.

 

7. Learn, re-learn and remain vigilant – How seriously developers take security is a function of how seriously it’s treated in the company. Facilitate learning wherever possible among your own team, stay abreast of the latest threats and look for solid security credentials in your app dev partner. Clients expect us to have deep technology expertise depending on the architecture or tool in question. Part and parcel of that deep understanding is mitigating the security vulnerabilities inherent in a specific area.

 

8. Code reviews – We’re used to code reviews more generally, but make them specific to security. Security-related code (authentication, encryption, etc.) should be reviewed as a minimum. Next, pay attention to other app functions and processes that could inadvertently introduce security weaknesses into the app.

 

9. Regular training – Enterprises that invest in good developer security training will reap the rewards in terms of better code and quicker fixes. Don’t let security training be something that just happens when new developers come on-board. Demonstrate how important security is by mandating regular sessions for team members and consider extending them to your app development partner.

 

10. When bad things happen to good apps – Enterprise security used to be about guarding the perimeter and “keeping the bad guys out”. Now we understand it’s more to do with how information flows through the organization, who has access to it, who controls that access and so on. A large proportion of breaches happen from within organizations, and most involve compromised admin credentials. Unless solid identity and access management is in place in the organization, good app security cannot be assured. There’s no point bolting a basically good app on to a vulnerable structure and hoping for the best.

 

If there are any aspects of your app’s development and testing you’d like to discuss in more depth, please get in touch

]]>
https://www.coredevx.com/site/security-testing-how-to-avoid-data-breaches-and-lawsuits/feed/ 0